Diskussion:Software Requirements Specification

Der Verweis auf Kapitel 4.3 der IEEE-Norm im Kapitel Qualität ist meiner Meinung nach falsch bzw. veraltet, in der aktuellen Norm 29148.2011 ist dies im Kapitel 8.3 aufgeführt (siehe z.B. hier: IEEE-Norm). (nicht signierter Beitrag von 131.188.6.21 (Diskussion) 18:00, 14. Mär. 2015 (CET))

Artikel Pflichtenheft sehr ähnlich - evtl zusammenfassen?

Ich würde sagen, hier geht es um eine besondere "Instanz" der Klasse "Pflichtenheft". Deshalb halte ich einen eigenen Artikel für durchaus extistenzberechtigt. der.Marcus.

Aufbau des dritten Abschnitts der Anforderungsspezifikation

Der hier dargestellte Aufbau des dritten Abschnitts einer Anforderungsspezifikation deckt sich mit keiner der im IEEE Std 830-1993 dargestellten Varianten (siehe IEEE std 830-1993 Annex A). Die erste und scheinbar gängiste Variante (A. l Template of SRS section 3 organized by mode: Version 1) würde so aussehen:

1. Einleitung
2. Allgemeine Beschreibung
3. Spezifische Anforderungen (Specific requirements )
   1. Anforderungen an externe Schnittstelle (External interface)
      1. Benutzerschnittstellen (User interfaces)
      2. Hardwareschnittstellen (Hardware interfaces)
      3. Softwareschnittstellen (Software interfaces)
      4. Kommunikationsschnittstellen (Communications interfaces)
   2. Funktionale Anforderungen (Functional requirements)
      1. Mode 1
         1. Funktionale Anforderung 1.1
         2. ...
         3. Funktionale Anforderung 1.n
      2. ...
      3. Mode m
         1. Funktionale Anforderung m.1
         2. ...
         3. Funktionale Anforderung m.n
   3. Performance Anforderungen (Performance requirements)
   4. Entwurfs-Einschränkungen (Design constraints)
   5. Softwaresystem-Attribute (Software system attributes)
   6. Sonstige Anforderungen (other requirements)

Ich plädiere dafür dass wir uns hier an den Vorgaben des IEEE Standards halten, da sie diesbezüglich die einzig maßgebende Institution darstellt. Sollten keine Einwände erhoben werden, werde ich diesen Artikel innerhalb einer Woche entsprechend aktualisieren. (nicht signierter Beitrag von Momesana (Diskussion | Beiträge) 11:48, 21. Feb. 2011 (CET))

Ich finde den Einwand absolut berechtigt, würde aber die "Modes" weglassen, um nicht zu detailliert zu werden. Die "Software system attributes" sind alle ganz eindeutig nicht-funktionale Qualitätseigenschaften und sollten im Deutschen wohl auch so genannt werden. Warum aber wird dann Performance extra aufgezählt? Ist das in der 29148-2011 (nicht vorliegend) anders? --Doenertir (Diskussion) 15:16, 29. Sep. 2016 (CEST)

SRS: Spezielle Instanz von Pflichtenheft?

Auf jeden Fall ist ein eigenes Stichwort für die SRS gemäss IEEE gerechtfertigt!

Zusammenhang SRS, Lastenheft, Pflichtenheft:

IEEE-Welt: SRS = Lastenheft (Kapitel 2) + Pflichtenheft (Kapitel 3)

Lastenheft= Kundensicht, Kundenanforderungen,C-Requirement Pflichtenheft = detaillierte Spezifikation der zu erstellenden Software, D-Requirement

RUP-Welt (Rational Unifid Process): Lastenheft -> Vision SRS = Use Case Model + Supplementary Specification

---

Im IEEE Std 830 steht nirgendwo etwas von C- und D-Requirements. Obwohl es die Begriffe gibt ist das der deutsche LH/PH-Ansatz. In der Softwarepraxis gibt es das Problem, dass es häufig nicht möglich, dass der Auftraggeber zuerst ein vollständiges LH erstellt, aus dem der Auftragnehmer dann ein Pflichtenheft als Basis für den Projektvertrag erstellt. Der Grund liegt in der Komplexität heutiger Softwaresysteme und das oft fehlende Know How beim Auftraggeber. Der Ablauf LH - PH ist idealtypisch und kommt meines Erachtens bei der Mehrzahl der Projekte so nicht vor.

LH und PH gehören zum Wasserfallmodell, einem linearen Vorgehensmodell. Für viele moderne Vorgehensmodelle ist das LH/PH nicht geeignet. Die Norm weist auch darauf hin, dass die Anforderungsermittlung iterativ erfolg, wobei Auftraggeber und Auftragnehmer an den Iterationen beteilligt sein können. Im englischen Sprachraum existieren darum viele verschiedene Begriffe für die SRS zu verschiedenen Zeitpunkten, z.B. auch Vision oder Scope Document.

Die Begriffe Lastenheft und Pflichtenheft kommen ursprünglich aus der Industrie, wo es sie auch noch gibt. Dort scheint die Trennung auch wunderbar zu funktionieren, in der Softwareentwicklung gibt aber so viele verschiedenartige Projekte dass die deutsche Definition für mich etwas veraltet klingt.

Bei den Artikeln ist der SRS der wichtigste. Hier geht es um den Kern des Problems, wenn eine Software durch einen Dienstleister erstellt werden soll, muss es eine Dokument geben das den Leistungsumfang komplett beschreibt. Wie dieses Dokuments entstanden ist ist letztlich unwichtig. Beim Lastenheft und Pflichtenheft würde ich den Unterschied der allgemeinen Bedeutung und der Bedeutung für die Softwareentwicklung hervorheben und ggf. in eigene Artikel auslagern. (nicht signierter Beitrag von 212.185.199.138 (Diskussion | Beiträge) 17:37, 11. Aug. 2009 (CEST))

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• https://sbwsweb.ieee.org/ecustomercme_enu/start.swe?SWECmd=GotoView&SWEView=Catalog+View+(eSales)_Standards_IEEE&mem_type=Customer&SWEHo=sbwsweb.ieee.org&SWETS=1192713657
  • Netzwerk-Fehler (7) andere Artikel, gleiche Domainhttp://giftbot.dwl.invalid/https://sbwsweb.ieee.org/ecustomercme_enu/start.swe?SWECmd=GotoView&SWEView=Catalog+View+(eSales)_Standards_IEEE&mem_type=Customer&SWEHo=sbwsweb.ieee.org&SWETS=1192713657

– GiftBot (Diskussion) 15:06, 20. Dez. 2015 (CET)