www.wikidata.de-de.nina.az

Software Requirements Specification Definitionen von IEEESQAP Software Quality Assurance Plan IEEE 730 SCMP Software Con

Software Requirements Specification

Definitionen von IEEE

Die Software Requirements Specification (SRS) ist ein vom 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. Die momentan neueste Version ist Std 29148-2018.

Die SRS umfasst das Lastenheft wie auch das Pflichtenheft.

Qualität Bearbeiten

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.

Dokumentation Bearbeiten

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.

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

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 Bearbeiten

  • 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.

Weblinks Bearbeiten

wikipedia, wiki, deutsches, deutschland, buch, bücher, bibliothek artikel lesen, herunterladen kostenlos kostenloser herunterladen, MP3, Video, MP4, 3GP, JPG, JPEG, GIF, PNG, Bild, Musik, Lied, Film, Buch, Spiel, Spiele
Veröffentlichungsdatum:
Definitionen von IEEESQAP 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 amp Verification Plan IEEE 1012 SDD Software Design Description IEEE 1016 SPMP Software Project Management Plan IEEE 1058 SRA Software Reviews and Audits IEEE 1028Die Software Requirements Specification SRS ist ein vom IEEE Institute of Electrical and Electronic Engineers erstmals unter ANSI IEEE Std 830 1984 veroffentlichter Standard zur Spezifikation von Software Das IEEE hat die Spezifikation mehrmals uberarbeitet Die momentan neueste Version ist Std 29148 2018 Die SRS umfasst das Lastenheft wie auch das Pflichtenheft Inhaltsverzeichnis 1 Qualitat 2 Dokumentation 3 Literatur 4 WeblinksQualitat BearbeitenDie IEEE Kap 4 3 definiert acht Charakteristika guter SRS korrekt unzweideutig eindeutig vollstandig widerspruchsfrei bewertet nach Wichtigkeit und oder Stabilitat verifizierbar modifizierbar verfolgbar traceable Korrekt und vollstandig beziehen sich dabei auf die in der SRS genannten tatsachlichen Anforderungen externer Bezug Widerspruchsfreiheit bezieht sich auf die Anforderungen in Form der SRS alleine interner Bezug Unzweideutigkeit lasst genau eine Interpretation zu Verifizierbarkeit begrenzt die Komplexitat einer Anforderungsbeschreibung zusatzlich auf ein effizient prufbares Mass Modifizierbarkeit setzt insbesondere Redundanzfreiheit voraus Traceability umfasst die vor und ruckwartige Richtung Dokumentation BearbeitenDie 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 grundsatzlich 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 Mit Requirements deutsch Anforderungen ist sowohl die qualitative als auch die quantitative Definition eines benotigten Programms aus der Sicht des Auftraggebers gemeint Im Idealfall umfasst eine solche Spezifikation ausfuhrliche Beschreibung von Zweck geplantem Einsatz in der Praxis sowie dem geforderten Funktionsumfang einer Software Hierbei sollte fachlichen Was soll die Software konnen wie auch technischen Aspekten In welchem Umfang und unter welchen Bedingungen wird die Software eingesetzt werden Rechnung getragen werden Eine SRS enthalt nach IEEE Standard mindestens drei Hauptkapitel Die vorgeschlagene Gliederung sollte zwar in den Kernpunkten eingehalten werden in der Praxis wird diese jedoch haufig im Detail modifiziert Eine exemplarische Gliederung konnte wie folgt aussehen Name des Softwareprodukts Name des Herstellers Versionsdatum des Dokuments und oder der SoftwareEinleitung Zweck des Dokuments Umfang des Softwareprodukts Erlauterungen zu Begriffen und oder Abkurzungen Verweise auf sonstige Ressourcen oder Quellen Ubersicht Wie ist das Dokument aufgebaut Allgemeine Beschreibung des Softwareprodukts Produktperspektive zu anderen Softwareprodukten Produktfunktionen eine Zusammenfassung und Ubersicht Benutzermerkmale Informationen zu erwarteten Nutzern z B Bildung Erfahrung Sachkenntnis Einschrankungen fur den Entwickler Annahmen und Abhangigkeiten Faktoren die die Entwicklung beeinflussen aber nicht behindern z B Wahl des Betriebssystems Aufteilung der Anforderungen nicht Realisierbares und auf spatere Versionen verschobene Eigenschaften Spezifische Anforderungen im Gegensatz zu 2 funktionale Anforderungen stark abhangig von der Art des Softwareprodukts nicht funktionale Anforderungen externe Schnittstellen Design Constraints Anforderungen an Performance Qualitatsanforderungen Sonstige AnforderungenDie Schwierigkeiten die sich in der Praxis bei einer solchen Anforderungsanalyse ergeben sind mogliche Interessenkonflikte also unterschiedliche Ziele seitens der Nutzer unklare oder sogar unbekannte technische Rahmenbedingungen sich andernde Anforderungen oder Prioritaten schon wahrend des Entwurfsprozesses Literatur BearbeitenIEEE Guide to Software Requirements Specification ANSI IEEE Std 830 1984 IEEE Press Piscataway New Jersey 1984 Colin Hood Susanne Muhlbauer Chris Rupp Gerhard Versteegen Hrsg iX Studie Anforderungsmanagement Methoden und Techniken Einfuhrungsszenarien und Werkzeuge im Vergleich 2 Auflage Heise Hannover April 2007 OCLC 255168117 Weblinks BearbeitenIEEE Software Engineering Collection via the IEEE Shop 830 1998 IEEE Recommended Practice for Software Requirements Specifications Beispiel einer Software Requirements Specification anhand der Software Gephi Abgerufen von https de wikipedia org w index php title Software Requirements Specification amp oldid 227963206