Die Erstellung der Anforderungsphase des Softwareentwicklungsprozesses ist Softwareanforderungsspezifikationen (SRS) (auch genannt a Anforderungsdokument ). Dieser Bericht legt eine Grundlage für Software-Engineering-Aktivitäten und erstellt, wenn vollständige Anforderungen ermittelt und analysiert werden. SRS ist ein formeller Bericht, der als Darstellung einer Software fungiert und es den Kunden ermöglicht, zu überprüfen, ob sie (SRS) ihren Anforderungen entspricht. Darüber hinaus umfasst es Benutzeranforderungen an ein System sowie detaillierte Spezifikationen der Systemanforderungen.
Der SRS ist eine Spezifikation für ein bestimmtes Softwareprodukt, Programm oder eine Reihe von Anwendungen, die bestimmte Funktionen in einer bestimmten Umgebung ausführen. Es dient mehreren Zielen, je nachdem, wer es schreibt. Erstens könnte der SRS vom Client eines Systems geschrieben werden. Zweitens könnte der SRS von einem Entwickler des Systems geschrieben werden. Die beiden Methoden schaffen völlig unterschiedliche Situationen und legen insgesamt unterschiedliche Zwecke für das Dokument fest. Der erste Fall, SRS, wird verwendet, um die Bedürfnisse und Erwartungen der Benutzer zu definieren. Der zweite Fall, SRS, wird für verschiedene Zwecke geschrieben und dient als Vertragsdokument zwischen Kunde und Entwickler.
Eigenschaften eines guten SRS
Im Folgenden sind die Merkmale eines guten SRS-Dokuments aufgeführt:
1. Richtigkeit: Die Benutzerbewertung wird verwendet, um die Richtigkeit der im SRS genannten Anforderungen sicherzustellen. SRS gilt als perfekt, wenn es alle Anforderungen abdeckt, die tatsächlich vom System erwartet werden.
2. Vollständigkeit: Das SRS ist genau dann vollständig, wenn es die folgenden Elemente enthält:
(1). Alle wesentlichen Anforderungen, sei es in Bezug auf Funktionalität, Leistung, Design, Einschränkungen, Attribute oder externe Schnittstellen.
Sitzung ist abgelaufen
(2). Definition ihrer Reaktionen der Software auf alle realisierbaren Klassen von Eingabedaten in allen verfügbaren Situationskategorien.
Hinweis: Es ist wichtig, die Antworten sowohl auf gültige als auch auf ungültige Werte anzugeben.
(3). Vollständige Beschriftungen und Verweise auf alle Abbildungen, Tabellen und Diagramme im SRS sowie Definitionen aller Begriffe und Maßeinheiten.
3. Konsistenz: Das SRS ist genau dann konsistent, wenn in seinem Konflikt keine Teilmenge der einzelnen Anforderungen beschrieben wird. Im SRS gibt es drei Arten möglicher Konflikte:
(1). Die angegebenen Eigenschaften realer Objekte können widersprüchlich sein. Zum Beispiel,
(a) Das Format eines Ausgabeberichts kann in einer Anforderung als tabellarisch beschrieben werden, in einer anderen jedoch als textuell.
(b) Eine Bedingung kann besagen, dass alle Lichter grün sein müssen, während eine andere besagt, dass alle Lichter blau sein müssen.
(2). Zwischen den beiden genannten Maßnahmen kann ein begründeter oder zeitlicher Konflikt bestehen. Zum Beispiel,
(a) Eine Anforderung kann bestimmen, dass das Programm zwei Eingaben addiert, und eine andere kann bestimmen, dass das Programm sie multipliziert.
(b) Eine Bedingung kann besagen, dass „A“ immer auf „B“ folgen muss, während eine andere erfordert, dass „A und B“ gleichzeitig auftreten.
(3). Zwei oder mehr Anforderungen können dasselbe reale Objekt definieren, für dieses Objekt jedoch unterschiedliche Begriffe verwenden. Beispielsweise kann die Anforderung eines Programms nach Benutzereingaben in einer Anforderung als „Eingabeaufforderung“ und in einer anderen als „Hinweis“ bezeichnet werden. Die Verwendung von Standardterminologie und -beschreibungen fördert die Konsistenz.
4. Eindeutigkeit: SRS ist eindeutig, wenn jede feste Anforderung nur eine Interpretation hat. Dies legt nahe, dass jedes Element eindeutig interpretiert wird. Falls eine Methode mit mehreren Definitionen verwendet wird, sollte der Anforderungsbericht die Auswirkungen im SRS festlegen, damit er klar und einfach zu verstehen ist.
5. Ranking nach Wichtigkeit und Stabilität: Das SRS wird nach Wichtigkeit und Stabilität eingestuft, wenn jede darin enthaltene Anforderung über eine Kennung verfügt, die entweder die Bedeutung oder Stabilität dieser bestimmten Anforderung angibt.
Normalerweise sind nicht alle Anforderungen gleich wichtig. Einige Voraussetzungen können insbesondere für lebenskritische Anwendungen unerlässlich sein, während andere wünschenswert sein können. Jedes Element sollte identifiziert werden, um diese Unterschiede klar und deutlich zu machen. Eine andere Möglichkeit, Anforderungen einzustufen, besteht darin, Elementklassen in wesentliche, bedingte und optionale Elemente zu unterscheiden.
6. Modifizierbarkeit: SRS sollte möglichst modifizierbar sein und in der Lage sein, bis zu einem gewissen Grad schnell Änderungen am System vorzunehmen. Änderungen sollten perfekt indiziert und mit Querverweisen versehen sein.
Java-Eingabezeichenfolge
7. Nachweisbarkeit: SRS ist korrekt, wenn die spezifizierten Anforderungen mit einem kostengünstigen System überprüft werden können, um zu prüfen, ob die endgültige Software diese Anforderungen erfüllt. Mithilfe von Gutachten werden die Anforderungen überprüft.
8. Rückverfolgbarkeit: Das SRS ist nachvollziehbar, wenn der Ursprung jeder Anforderung klar ist und wenn es die Referenzierung jeder Bedingung in der zukünftigen Entwicklungs- oder Erweiterungsdokumentation erleichtert.
Es gibt zwei Arten der Rückverfolgbarkeit:
1. Rückverfolgbarkeit: Dies hängt davon ab, dass jede Anforderung in früheren Dokumenten explizit auf ihre Quelle verweist.
2. Vorwärtsrückverfolgbarkeit: Dies hängt davon ab, dass jedes Element im SRS einen eindeutigen Namen oder eine eindeutige Referenznummer hat.
Die Vorwärtsverfolgbarkeit des SRS ist besonders wichtig, wenn das Softwareprodukt in die Betriebs- und Wartungsphase eintritt. Wenn Code und Designdokument geändert werden, ist es notwendig, den vollständigen Satz von Anforderungen zu ermitteln, die von diesen Änderungen betroffen sein können.
9. Designunabhängigkeit: Für das endgültige System sollte die Möglichkeit bestehen, aus mehreren Designalternativen auszuwählen. Genauer gesagt sollte der SRS keine Implementierungsdetails enthalten.
10. Testbarkeit: Ein SRS sollte so geschrieben sein, dass es einfach ist, Testfälle und Testpläne aus dem Bericht zu generieren.
img CSS ausrichten
11. Für den Kunden verständlich: Ein Endbenutzer ist möglicherweise ein Experte auf seinem/ihrem spezifischen Gebiet, verfügt jedoch möglicherweise nicht über eine Ausbildung in Informatik. Daher sollte der Zweck formaler Notationen und Symbole so weit wie möglich vermieden werden. Die Sprache sollte einfach und klar gehalten werden.
12. Das richtige Abstraktionsniveau: Wenn der SRS für die Anforderungsphase geschrieben wird, sollten die Details explizit erläutert werden. Für eine Machbarkeitsstudie hingegen können weniger Analysen durchgeführt werden. Daher ändert sich die Abstraktionsebene entsprechend der Zielsetzung des SRS.
Eigenschaften eines guten SRS-Dokuments
Die wesentlichen Eigenschaften eines guten SRS-Dokuments sind folgende:
Prägnant: Der SRS-Bericht sollte prägnant und gleichzeitig eindeutig, konsistent und vollständig sein. Ausführliche und irrelevante Beschreibungen beeinträchtigen die Lesbarkeit und erhöhen zudem die Fehlerwahrscheinlichkeit.
Strukturiert: Es sollte gut strukturiert sein. Ein gut strukturiertes Dokument ist einfach zu verstehen und zu ändern. In der Praxis wird das SRS-Dokument mehrfach überarbeitet, um den Benutzeranforderungen gerecht zu werden. Oftmals entwickeln sich Benutzeranforderungen im Laufe der Zeit. Um die Änderungen am SRS-Dokument zu vereinfachen, ist es daher wichtig, den Bericht gut zu strukturieren.
Black-Box-Ansicht: Es sollte lediglich definiert werden, was das System tun soll, und nicht angeben, wie dies zu tun ist. Das bedeutet, dass das SRS-Dokument das externe Verhalten des Systems definieren und nicht die Implementierungsprobleme diskutieren sollte. Der SRS-Bericht sollte das zu entwickelnde System als Blackbox betrachten und das nach außen sichtbare Verhalten des Systems definieren. Aus diesem Grund wird der SRS-Bericht auch als Black-Box-Spezifikation eines Systems bezeichnet.
Konzeptionelle Integrität: Es sollte konzeptionelle Integrität aufweisen, sodass der Leser es lediglich verstehen kann. Reaktion auf unerwünschte Ereignisse: Es sollte akzeptable Reaktionen auf unerwünschte Ereignisse charakterisieren. Diese werden als Systemreaktion auf außergewöhnliche Bedingungen bezeichnet.
Nachweisbar: Alle Anforderungen des Systems, wie im SRS-Dokument dokumentiert, sollten korrekt sein. Dies bedeutet, dass es möglich sein sollte, zu entscheiden, ob Anforderungen in einer Implementierung erfüllt wurden oder nicht.