Vorlage für eine Software-Anforderungsspezifikation (SRS): Aufbau und Beispiele

Eine Software-Anforderungsspezifikation (Software Requirements Specification, SRS) beschreibt, was ein System leisten muss und unter welchen Randbedingungen — nicht, wie es gebaut wird. Ob Sie sie für einen Kunden oder für eine Lehrveranstaltung schreiben: Am schwersten ist meist die leere Seite.

Die Gliederung unten folgt der Struktur, die ISO/IEC/IEEE 29148 (die aktuelle Norm) von der älteren IEEE 830 übernommen hat. Sie müssen ihr nicht sklavisch folgen, aber Leser und Prüfer erwarten die Informationen an diesen Stellen. Im deutschsprachigen Raum erfüllt die SRS oft die Rolle des Pflichtenhefts.

1. Einleitung#

Zweck: für wen das Dokument ist und was es festlegt. Umfang: der Name des Systems, was es leistet und was nicht, und welchen Nutzen es bringt. Begriffe: jede Abkürzung und jeder Fachbegriff, den ein Leser nicht kennen könnte. Referenzen: Normen, Verträge und andere Dokumente, auf die sich diese SRS stützt. Überblick: wie der Rest des Dokuments aufgebaut ist.

2. Allgemeine Beschreibung#

• Produktumfeld — ist es ein neues System, ein Ersatz oder Teil eines größeren Systems? Ein einfaches Kontextdiagramm hilft.
• Produktfunktionen — eine kurze Zusammenfassung der wichtigsten Fähigkeiten (die Details folgen in Abschnitt 3).
• Benutzer und ihre Merkmale — wer das System nutzt, wie oft und mit welcher Erfahrung.
• Randbedingungen — Vorschriften, Hardware, vorgegebene Technologien, Termine.
• Annahmen und Abhängigkeiten — worauf Sie sich verlassen, das sich ändern könnte, etwa die Verfügbarkeit eines externen Dienstes.

3. Konkrete Anforderungen#

Das ist der Kern der SRS und meist der größte Teil der Seiten. Jede Anforderung erhält eine eindeutige ID und wird als eine prüfbare Aussage formuliert.

• Externe Schnittstellen — Benutzer-, Hardware-, Software- und Kommunikationsschnittstellen. Beispiel: „IF-03: Das System muss Berichte als PDF exportieren.“
• Funktionale Anforderungen — was das System tut, gruppiert nach Funktion oder Benutzeraufgabe. Beispiel: „REQ-012: Das System muss einem Mitglied erlauben, eine Ausleihe bis zu zweimal zu verlängern.“
• Leistungsanforderungen — messbare Antwortzeiten, Kapazität, Durchsatz. Beispiel: „PERF-02: Die Katalogsuche muss für 95 % der Anfragen innerhalb von 2 Sekunden Ergebnisse liefern.“
• Qualitätsmerkmale — Verfügbarkeit, Sicherheit, Benutzbarkeit, Wartbarkeit, jeweils mit einer Zahl oder einem Test. Beispiel: „SEC-04: Passwörter dürfen nur als gesalzene Hashes gespeichert werden.“
• Entwurfsvorgaben — Normen oder Technologien, die die Lösung verwenden muss.

4. Verifikation und Anhänge#

Viele Teams ergänzen einen Abschnitt zur Verifikation, der für jede Anforderung festlegt, wie sie geprüft wird (Test, Inspektion, Analyse oder Vorführung), oder eine Traceability-Tabelle von Anforderungen zu Tests. Anhänge enthalten Datenmodelle, Diagramme und alles, was für den Haupttext zu detailliert ist.

Die häufigsten Fehler#

• Die Lösung statt des Bedarfs beschreiben („eine MySQL-Datenbank verwenden“, wo „die Ausleihhistorie von 10 Jahren speichern“ gemeint war).
• Vage Wörter ohne Zahlen: schnell, einfach, flexibel, benutzerfreundlich.
• Zwei Anforderungen in einem Satz, verbunden mit „und“, sodass keine allein getestet werden kann.
• Keine IDs, sodass niemand in einem Test, Ticket oder Review-Kommentar auf eine Anforderung verweisen kann.
• Fehlender Umfang: Leser erkennen nicht, was das System nicht leisten wird.
• Keine Versionshistorie, sodass unklar ist, welche Version freigegeben wurde.

Mit einer Vorlage beginnen#

Übernehmen Sie die Überschriften oben in Ihr Dokument und füllen Sie sie von oben aus: zuerst den Umfang, dann die Benutzer, dann die Anforderungen. Die Einleitung können Sie auch zuletzt schreiben — das fällt leichter, wenn Sie wissen, was das Dokument enthält.

In Requify können Sie eine Software- (SRS) oder Hardware-Spezifikation (HRS) mit dieser Struktur beginnen, darin Anforderungen mit IDs schreiben und das Ergebnis zur Abgabe oder zum Review als PDF oder Word exportieren.