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) Diskussion:Software Requirements Specification#c-131.188.6.21-2015-03-14T17:00:00.000Z11)
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
[Quelltext bearbeiten]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:
- Einleitung
- Allgemeine Beschreibung
- Spezifische Anforderungen (Specific requirements )
- Anforderungen an externe Schnittstelle (External interface)
- Benutzerschnittstellen (User interfaces)
- Hardwareschnittstellen (Hardware interfaces)
- Softwareschnittstellen (Software interfaces)
- Kommunikationsschnittstellen (Communications interfaces)
- Funktionale Anforderungen (Functional requirements)
- Mode 1
- Funktionale Anforderung 1.1
- ...
- Funktionale Anforderung 1.n
- ...
- Mode m
- Funktionale Anforderung m.1
- ...
- Funktionale Anforderung m.n
- Mode 1
- Performance Anforderungen (Performance requirements)
- Entwurfs-Einschränkungen (Design constraints)
- Softwaresystem-Attribute (Software system attributes)
- Sonstige Anforderungen (other requirements)
- Anforderungen an externe Schnittstelle (External interface)
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) Diskussion:Software Requirements Specification#c-Momesana-2011-02-21T10:48:00.000Z-Aufbau des dritten Abschnitts der Anforderungsspezifikation11)
- 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) Diskussion:Software Requirements Specification#c-Doenertir-2016-09-29T13:16:00.000Z-Momesana-2011-02-21T10:48:00.000Z11
SRS: Spezielle Instanz von Pflichtenheft?
[Quelltext bearbeiten]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) Diskussion:Software Requirements Specification#c-212.185.199.138-2009-08-11T15:37:00.000Z-SRS: Spezielle Instanz von Pflichtenheft?11)
Defekte Weblinks
[Quelltext bearbeiten]Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt. |
---|
|
– GiftBot (Diskussion) Diskussion:Software Requirements Specification#c-GiftBot-2015-12-20T14:06:00.000Z-Defekte Weblinks11