Software Requirements Specification
aus Wikipedia, der freien Enzyklopädie
| Definitionen von IEEE |
| SQAP - Software Quality Assurance Plan IEEE 730 |
| SCMP - Software Configuration Management Plan IEEE 828 |
| STD - Software Test Documentation IEEE 829 |
| SRS - Software Requirements Specification IEEE 830 |
| SVVP - Software Validation & Verification Plan IEEE 1012 |
| SDD - Software Design Description IEEE 1016 |
| SPMP - Software Project Management Plan IEEE 1058 |
Die Software Requirement Specification (SRS) ist ein von IEEE (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 und die momentan neuste Version ist Std 830-1998.
Inhaltsverzeichnis |
[Bearbeiten] Allgemein
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 ist das Dokument grundsätzlich in 2 Bereiche aufgeteilt:
- C-Requirement (Customer-Requirement)
- D-Requirement (Development-Requirement)
Unter C-Requirement sind die Anforderungen aus Sicht des Kunden und/oder des End-Anwenders zu erfassen. Unter D-Requirement versteht man die Entwicklungs-Anforderungen. Dies ist die Sicht aus den Augen des Entwicklers, der technische Aspekte in den Vordergrund stellt, im Gegensatz zum Kunden.
Mit "Requirements" (deutsch: "Anforderungen") ist sowohl die qualitative als auch die quantitative Definition eines benötigten Programms aus der Sicht des Auftraggebers gemeint. Im Idealfall umfasst eine solche Spezifikation ausführliche Beschreibung von Zweck, geplantem Einsatz in der Praxis sowie dem geforderten Funktionsumfang einer Software.
Hierbei sollten fachlichen - "Was soll die Software 'können'?" - wie auch technischen Aspekten - "In welchem Umfang und unter welchen Bedingungen wird die Software eingesetzt werden?" - Rechnung getragen werden.
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
- Einleitung
- Zweck (des Dokuments)
- Ziel (des Softwareprodukts)
- Verweise auf sonstige Ressourcen oder Quellen
- Erläuterungen zu Begriffen und / oder Abkürzungen
- Übersicht (Wie ist das Dokument aufgebaut?)
- Allgemeine Beschreibung (des Softwareprodukts)
- Produkt Perspektive (zu anderen Softwareprodukten)
- Produktfunktionen (eine Zusammenfassung und Übersicht)
- Benutzermerkmale (Informationen zu erwarteten Nutzern, z.B. Bildung, Erfahrung, Sachkenntnis)
- Einschränkungen (für den Entwickler)
- Annahmen und Abhängigkeiten (nicht Realisierbares und auf spätere Versionen verschobene Eigenschaften)
- Spezifizierte Anforderungen (im Gegensatz zu 2.)
- funktionale Anforderungen (Stark abhängig von der Art des Softwareprodukts)
- nicht-funktionale Anforderungen
- externe Schnittstellen
- Design Constraints
- Anforderungen an Performance
- Qualitätsanforderungen
- Sonstige Anforderungen
Die Schwierigkeiten, die sich in der Praxis bei einer solchen Anforderungsanalyse ergeben, sind
- mögliche Interessenkonflikte, also unterschiedliche Ziele seitens der Nutzer
- unklare oder sogar unbekannte technische Rahmenbedingungen
- sich ändernde Anforderungen oder Prioritäten schon während des Entwurfsprozesses
[Bearbeiten] Literatur
- IEEE Guide to Software Requirements Specification, ANSI/IEEE Std 830-1984, IEEE Press, Piscataway, New York, 1984.
