Zum Inhalt springen
L

Wikipedia · einfach zusammengefasst · Stand

Software Requirements Specification

Die Software Requirements Specification (SRS) ist ein Standard zur Spezifikation von Software, der durch den IEEE-Berufsverband veröffentlicht wird.

Inhalt4 Abschnitte
  1. 1. Bedeutung und Aufbau einer SRS
  2. 2. Kunden- und Entwicklungsanforderungen
  3. 3. Qualitätsmerkmale
  4. 4. Entwicklung und praktische Schwierigkeiten

Bedeutung und Aufbau einer SRS

Eine Software Requirements Specification (SRS) ist ein vom IEEE-Berufsverband veröffentlichter Standard zur Spezifikation von Software. Sie beschreibt die Anforderungen an ein benötigtes Programm sowohl qualitativ als auch quantitativ aus Sicht des Auftraggebers. Eine SRS umfasst das Lastenheft (LH) und das Pflichtenheft (PH).

Ziel ist eine möglichst ausführliche Beschreibung des Zwecks einer Software, ihres geplanten Einsatzes in der Praxis und ihres geforderten Funktionsumfangs. Dabei müssen fachliche Fragen berücksichtigt werden, also „Was soll die Software können?“, ebenso wie technische Fragen: „In welchem Umfang und unter welchen Bedingungen wird die Software eingesetzt werden?“.

Kunden- und Entwicklungsanforderungen

Die IEEE-Definition legt den grundsätzlichen Aufbau des Dokuments fest. Es besteht aus zwei Teilen:

  • C-Requirement (customer requirement): mit einem Lastenheft vergleichbar. Hier werden Anforderungen aus Sicht des Kunden und/oder End-Anwenders erfasst.
  • D-Requirement (development requirement): mit einem Pflichtenheft vergleichbar. Hier stehen Entwicklungsanforderungen aus Sicht des Entwicklers im Mittelpunkt; technische Aspekte erhalten dabei mehr Gewicht als bei der Kundensicht.

Eine SRS enthält nach IEEE-Standard mindestens drei Hauptkapitel. Die vorgeschlagene Gliederung soll in ihren Kernpunkten eingehalten werden, wird in der Praxis aber häufig im Detail angepasst. Zu einer beispielhaften Gliederung gehören Angaben zum Softwareprodukt, Hersteller und Versionsdatum sowie eine Einleitung mit Zweck, Umfang, Begriffen oder Abkürzungen, Quellenverweisen und einer Übersicht über den Dokumentaufbau.

Die allgemeine Beschreibung behandelt unter anderem Produktperspektive zu anderen Softwareprodukten, Produktfunktionen, erwartete Benutzermerkmale, Einschränkungen für Entwickler sowie Annahmen und Abhängigkeiten. Außerdem kann sie Anforderungen aufführen, die nicht realisierbar sind oder auf spätere Versionen verschoben werden. Die spezifischen Anforderungen umfassen funktionale und nicht-funktionale Anforderungen, externe Schnittstellen, Design Constraints, Anforderungen an Performance, Qualitätsanforderungen und sonstige Anforderungen.

Qualitätsmerkmale

IEEE Kapitel 4.3 nennt acht Merkmale einer guten SRS. Sie soll korrekt, unzweideutig, vollständig, widerspruchsfrei, nach Wichtigkeit und/oder Stabilität bewertet, verifizierbar, modifizierbar und verfolgbar (traceable) sein.

„Korrekt“ und „vollständig“ beziehen sich auf die in der SRS genannten tatsächlichen Anforderungen und damit auf einen externen Bezug. Widerspruchsfreiheit betrifft dagegen allein die Anforderungen in der Form der SRS, also den internen Bezug. Unzweideutigkeit bedeutet, dass genau eine Interpretation möglich ist. Verifizierbarkeit verlangt, dass eine Anforderungsbeschreibung nur so komplex ist, dass sie effizient geprüft werden kann. Modifizierbarkeit setzt besonders Redundanzfreiheit voraus. Traceability umfasst sowohl die vorwärtige als auch die rückwärtige Richtung der Verfolgung von Anforderungen.

Entwicklung und praktische Schwierigkeiten

Die erste Version des Standards erschien 1984 als ANSI/IEEE Std 830-1984. Der Standard wird regelmäßig überarbeitet; die aktuelle Version ist Std 29148-2018.

In der praktischen Anforderungsanalyse können unterschiedliche Ziele der Nutzer zu Interessenkonflikten führen. Weitere Schwierigkeiten sind unklare oder unbekannte technische Rahmenbedingungen sowie Anforderungen oder Prioritäten, die sich bereits während des Entwurfsprozesses ändern.

Lernvideos zu Software Requirements Specification

Weiterlesen