Software Requirements Specification

Software Requirements Specification
Definitionen von IEEE

Die Software Requirements 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 neueste Version ist Std 830-1998.

Die SRS umfasst das Lastenheft wie auch das Pflichtenheft.

Inhaltsverzeichnis

Qualität

Die IEEE Kap. 4.3 definiert 8 Charakteristika guter SRS:

  • Korrekt
  • Unzweideutig
  • Vollständig
  • Konsistent
  • Bewertet nach Wichtigkeit und/oder Stabilität
  • Verifizierbar
  • Modifizierbar
  • Verfolgbar (Traceable)

Korrekt und Vollständig bezieht sich dabei auf die SRS bezüglich der tatsächlichen Anforderungen (externer Bezug). Konsistenz bezieht sich auf die Anforderungen in Form der SRS alleine (interner Bezug). Unmehrdeutigkeit 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.

Dokumentation

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): Bereich ist mit Lastenheft vergleichbar
  • D-Requirement (Development-Requirement): Bereich ist mit 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.

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 sollte 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
  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 (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

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

Literatur

  • IEEE Guide to Software Requirements Specification. ANSI/IEEE Std 830-1984. IEEE Press, Piscataway/New Jersey 1984.
  • Colin Hood, Susanne Mühlbauer, Chris Rupp, Gerhard Versteegen (Hrsg.): iX-Studie Anforderungsmanagement. Methoden und Techniken, Einführungsszenarien und Werkzeuge im Vergleich. 2. Auflage. Heise, Hannover April 2007, OCLC 255168117 (Übersicht bei Heise).

Weblinks


Wikimedia Foundation.

Игры ⚽ Поможем написать реферат

Schlagen Sie auch in anderen Wörterbüchern nach:

  • Software Requirements Specification — A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. Use cases are also known …   Wikipedia

  • Software Requirement Specification — 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… …   Deutsch Wikipedia

  • Software prototyping — Software prototyping, a possible activity during software development, is the creation of prototypes, i.e., incomplete versions of the software program being developed.A prototype typically simulates only a few aspects of the features of the… …   Wikipedia

  • Requirements analysis — in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders,… …   Wikipedia

  • Comprehensive & Robust Requirements Specification Process — The Comprehensive Robust Requirements Specification Process (CRRSP), or CRRSP (pronounced crisp), is a methodology for gathering, defining, and validating software requirements. CRRSP is not a step by step restrictive process, but an adaptable… …   Wikipedia

  • Requirements Management — Anforderungsmanagement (AM, englisch Requirements Management, RM) ist eine Managementaufgabe für die effiziente und fehlerarme Entwicklung komplexer Systeme. Es umfasst die Anforderungserhebung (Requirements Engineering) sowie Maßnahmen zur… …   Deutsch Wikipedia

  • Requirements management — Anforderungsmanagement (AM, englisch Requirements Management, RM) ist eine Managementaufgabe für die effiziente und fehlerarme Entwicklung komplexer Systeme. Es umfasst die Anforderungserhebung (Requirements Engineering) sowie Maßnahmen zur… …   Deutsch Wikipedia

  • Requirements — Das Erheben der Anforderungen (englisch requirements engineering) ist ein Teil des Anforderungsmanagements im Systementwicklungsprozesses. Ziel ist es, die Anforderungen des Auftraggebers an das zu entwickelnde System zu ermitteln.… …   Deutsch Wikipedia

  • Requirements Engineering — Das Erheben der Anforderungen (englisch requirements engineering) ist ein Teil des Anforderungsmanagements im Systementwicklungsprozesses. Ziel ist es, die Anforderungen des Auftraggebers an das zu entwickelnde System zu ermitteln.… …   Deutsch Wikipedia

  • Software Design Description — 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… …   Deutsch Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”