Zum Hauptinhalt springen

ISO29148 - Systems and software engineering - Life cycle processes - Requirements engineering

Anforderungsmanagement

Die Software Requirements Specification (SRS) ist ein vom Institute of Electrical and Electronic Engineers erstmals (unter ANSI/IEEE Std 830-1984) veröffentlichter Standard zur Spezifikation von Software. Das IEEE hat die Spezifikation mehrmals überarbeitet. Die momentan Version ist 29148.

image-20231024160533172

Die IEEE Kap. 4.3 definiert acht Charakteristika guter SRS:

  • korrekt
  • unzweideutig (eindeutig)
  • vollständig
  • widerspruchsfrei
  • bewertet nach Wichtigkeit und/oder Stabilität
  • verifizierbar
  • modifizierbar
  • verfolgbar (traceable)

„Korrekt“ und „vollständig“ beziehen sich dabei auf die in der SRS genannten tatsächlichen Anforderungen (externer Bezug). Widerspruchsfreiheit bezieht sich auf die Anforderungen in Form der SRS alleine (interner Bezug). Unzweideutigkeit lässt genau eine Interpretation zu, Verifizierbarkeit begrenzt die Komplexität einer Anforderungsbeschreibung zusätzlich auf ein effizient prüfbares Maß. Modifizierbarkeit setzt insbesondere Redundanzfreiheit voraus. Traceability umfasst die vor- und rückwärtige Richtung.

Die IEEE hat mit dieser Definition festgelegt, wie das Dokument aufgebaut werden soll. Die Kapitel, die in diesem Dokument vorkommen sollen, stehen somit fest. Dabei besteht das Dokument grundsätzlich aus zwei Teilen:

  • C-Requirement (customer requirement): dieser Teil ist mit einem Lastenheft vergleichbar,
  • D-Requirement (development requirement): dieser Teil ist mit einem Pflichtenheft vergleichbar.

Unter C-Requirement sind die Anforderungen aus Sicht des Kunden und/oder des End-Anwenders zu erfassen. Unter D-Requirement versteht man die Entwicklungsanforderungen. Dies ist die Sicht aus den Augen des Entwicklers, der technische Aspekte in den Vordergrund stellt, im Gegensatz zum Kunden.

image-20231024161017613

Eine SRS enthält nach IEEE-Standard mindestens drei Hauptkapitel. Die vorgeschlagene Gliederung sollte zwar in den Kernpunkten eingehalten werden, in der Praxis wird diese jedoch häufig im Detail modifiziert. Eine exemplarische Gliederung könnte wie folgt aussehen:

  • Name des Softwareprodukts
  • Name des Herstellers
  • Versionsdatum des Dokuments und/oder der Software
  1. Einleitung
    1. Zweck (des Dokuments)
    2. Umfang (des Softwareprodukts)
    3. Erläuterungen zu Begriffen und / oder Abkürzungen
    4. Verweise auf sonstige Ressourcen oder Quellen
    5. Übersicht (Wie ist das Dokument aufgebaut?)
  2. Allgemeine Beschreibung (des Softwareprodukts)
    1. Produktperspektive (zu anderen Softwareprodukten)
    2. Produktfunktionen (eine Zusammenfassung und Übersicht)
    3. Benutzermerkmale (Informationen zu erwarteten Nutzern, z. B. Bildung, Erfahrung, Sachkenntnis)
    4. Einschränkungen (für den Entwickler)
    5. Annahmen und Abhängigkeiten (Faktoren, die die Entwicklung beeinflussen, aber nicht behindern z. B. Wahl des Betriebssystems)
    6. Aufteilung der Anforderungen (nicht Realisierbares und auf spätere Versionen verschobene Eigenschaften)
  3. Spezifische Anforderungen (im Gegensatz zu 2.)
    1. funktionale Anforderungen (stark abhängig von der Art des Softwareprodukts)
    2. nicht-funktionale Anforderungen
    3. externe Schnittstellen
    4. Design Constraints
    5. Anforderungen an Performance
    6. Qualitätsanforderungen
    7. Sonstige Anforderungen

Stakeholder requirements specification document​

image-20231024161237787

System requirements specification document​

image-20231024161310142

Software requirements specification document​

image-20231024161339832