Antwort.

SRS ist ein strukturierter Dokument, das alle Anforderungen an das zu entwickelnde System beschreibt. Seine Aufgabe ist es, die Geschäftserwartungen so eindeutig und vollständig wie möglich in die Sprache des Projektteams zu "übersetzen". Die wichtigsten Abschnitte:

1. Einleitung (Ziele, Anwendungsbereich, Terminologie)
2. Produktbeschreibung und Geschäftskontext
3. Benutzerbeschreibungen und ihre Rollen
4. Funktionale Anforderungen (Use Cases, User Stories)
5. Nichtfunktionale Anforderungen (Sicherheit, Leistung, Benutzerfreundlichkeit)
6. Einschränkungen
7. Schnittstellen
8. Externe Abhängigkeiten
9. Annahmekriterien für Anforderungen
10. Begriffswörterbuch

Wesentliche Merkmale:

SRS enthält sowohl funktionale als auch nichtfunktionale Anforderungen.
Anforderungen werden eindeutig formuliert, mit minimaler Mehrdeutigkeit.
In der SRS müssen Nutzungsszenarien, Einschränkungen und Erfolgs- kriterien unbedingt berücksichtigt werden.

Zur Kontrolle der Vollständigkeit und Qualität verwendet der Analyst Validierungschecklisten, Vorlagen, Standards IEEE 830 und regelmäßige Abstimmungen mit wichtigen Stakeholdern.

Fangfragen.

Ist es ausreichend, nur User Stories zur vollständigen SRS zu beschreiben?

Nein. User Stories zeigen die funktionale Seite, decken jedoch nicht die nichtfunktionalen Anforderungen, Einschränkungen, Schnittstellen, Ausnahme- senarien und Annahmekriterien ab.

Kann man unterschiedliche Begriffe für dasselbe Element im Dokument verwenden?

Nein. Es ist unbedingt erforderlich, die Terminologie einheitlich zu halten: hierfür wird ein Begriffsverzeichnis erstellt und es wird eine Querver- zeichnung des Dokuments durchgeführt.

Sollte die SRS Sicherheits- und Leistungsanforderungen enthalten?

Ja. Nichtfunktionale Anforderungen sind von entscheidender Bedeutung: Ihr Fehlen führt zu technischem Schulden oder zur Unmöglichkeit des Betriebs des Systems.

Typische Fehler und Anti-Patterns

Unzureichende Detaillierung der Anforderungen, Mangel an Beispielen und Annahmekriterien.
Verwendung mehrdeutiger Formulierungen: "schnell", "bequem", "zuverlässig" ohne numerische Merkmale.
Ignorierung nichtfunktionaler Anforderungen.

Beispiel aus dem Leben

Negativer Fall

SRS ist nur auf der Grundlage von User Stories geschrieben, Anforderungen an Leistung und Sicherheit wurden vergessen.

Vorteile:

Schnelle Erstellung der Dokumentation.

Nachteile:

Das Projekt hat das Sicherheits-Audit nicht bestanden, erfüllt die notwendige Anzahl gleichzeitiger Benutzer nicht.

Positiver Fall

SRS deckt die vollständige Liste der erforderlichen Attribute ab — Funktionalität, nichtfunktionale Anforderungen, Annahmekriterien, Glossar.