Teil I Einführung
Da Anforderungen eine zentrale Rolle im Entwicklungsprozess spielen und unterschiedlichste Stakeholder darauf zugreifen müssen, ist es nicht einfach, eine Darstellungsform für Anforderungen zu finden, die allen Stakeholdern gleichermaßen gerecht wird. Insbesondere besteht ein Interessenskonflikt zwischen dem Wunsch nach einer möglichst freien Notation (die eine kreative Anforderungserarbeitung fördert), einer möglichst strukturierten Darstellung (die eine systematische Anforderungserarbeitung, Vollständigkeit und Konsistenz fördert) und einer möglichst formalen Notation (die eine präzise Anforderungsdokumentation und einen leichten Übergang ins Design fördert). Hierfür liegt der Einsatz von Modellen nahe. Ziel dieser Arbeit ist es daher, die verschiedenen Bedürfnisse der Stakeholder in Hinblick auf die Anforderungsdokumentation zu identifizieren, zu bewerten und eine modellhafte Darstellungsform und Methodik zur Dokumentation von Anforderungen zu entwickeln, die den Interessenkonflikt zwischen Formalität, Verständlichkeit und Flexibilität so weit wie möglich auflöst.
Bevor damit begonnen werden kann, die Software für ein System zu entwickeln, muss definiert werden, was das System eigentlich tun soll. Dies wird in der Regel[1] in Form von Anforderungen an das zu entwickelnde System beschrieben. Eine Anforderung (engl. Requirement) ist
„(1) eine Bedingung/Fähigkeit/Eigenschaft, die ein Stakeholder[2] für ein Produkt […] fordert, um ein Problem zu lösen oder ein Ziel zu erreichen; (2) eine Bedingung/Fähigkeit/Eigenschaft, die ein System erfüllen/haben muss, um einen Vertrag, einen Standard, eine Spezifikation oder andere formal vorgegebene Dokumente zu erfüllen; (3) eine dokumentierte Repräsentation einer Bedingung/Fähigkeit/Eigenschaft wie in (1) oder (2) definiert“. [IEEE98, FK+07]
Kurz gesagt, Anforderungen beschreiben, welche Fähigkeiten und welche Eigenschaften ein System haben soll[3].
Daher nehmen nahezu alle Teilprozesse im weiteren Entwicklungsprozess die Anforderungen als Ausgangsbasis für ihre Aktivitäten (siehe Abbildung 1).
Die Anforderungen an das zu entwickelnde System sind also ein zentrales Artefakt im Entwicklungsprozess, auf das die unterschiedlichsten Teilprozesse (mit ganz unterschiedlichen Stakeholdern und Zielsetzungen) aufbauen, beispielsweise:
Design und Implementierung: Aus den Anforderungen wird direkt die Funktionalität des Systems abgeleitet; die Architektur und Implementierung wird maßgeblich durch die in den Anforderungen formulierten Constraints und nichtfunktionalen Eigenschaften beeinflusst. Falsche oder fehlende Anforderungen können die Funktionalität oder Architektur des Systems massiv verschlechtern.
Test: Die Testfälle werden in der Regel aus den Anforderungen gewonnen. Da das fertige Produkt gegen diese Anforderungen getestet wird, können Fehler in den Anforderungen nicht durch Tests aufgedeckt werden.
Risikomanagement: Das Risikomanagement beruht zu einem Großteil aus der Bewertung der Anforderungen. Falsche oder fehlende Anforderungen können zu einer falschen Risikoabschätzung führen.
Projektmanagement: Ein wesentlicher Teil des Projektmanagements basiert auf der Analyse der Anforderungen. Falsche oder fehlende Anforderungen können zu Budgetüberschreitungen und Verzögerungen im Zeitplan führen.
Abbildung 1: Prozessschnittstellen des Anforderungsmanagements [FB+06]
Somit sind Anforderungen die Grundlage für die gesamte Systementwicklung. Daher haben fehlende oder fehlerhafte Anforderungen dramatische Auswirkungen auf Nutzen und wirtschaftlichen Erfolg des Produktes, ebenso auf die Entwicklungszeit und -kosten:
Ein nicht unbeträchtlicher Anteil des von Fahrern als Fehler empfundenen Verhaltens des Fahrzeugs beruht nicht auf Programmierfehlern, sondern auf einer von Anfang an unzureichenden Spezifikation des Verhaltens. Je nach Studie sind 40% bis 60% aller schweren Fehler auf Fehler in der Anforderungsanalyse zurückzuführen.
Fehler, die im Anforderungsmanagement gemacht werden, sind signifikant schwerer und zeitaufwändiger zu beheben als Fehler, die später im Entwicklungsprozess gemacht werden: je später ein Fehler entdeckt wird, desto teurer wird er. Wird ein Fehler bereits in der Anforderungssphäre entdeckt, ist er – beispielsweise laut Abschätzungen von [Rup02b] – deutlich billiger zu korrigieren als wenn er erst im fertigen Produkt entdeckt wird:
Abbildung 2: Relative Fehlerbehebungskosten [Rup02b]
In einem Fallbeispiel aus der Automobilindustrie [VH+03], das von der Firma Hood durchgeführt wurde, kommt man zu ähnlichen Abschätzungen für die Aufwände zur Fehlerbehebung:
Abbildung 3: Fehlerbehebungsaufwände an einer Fallstudie aus der Automobilindustrie [VH+03]
Laut der Chaos-Studie von 1995 [Sta95] sind knapp 44% aller Gründe für das Scheitern von Softwareprojekten unmittelbar auf einen unzureichenden Umgang mit Anforderungen zurückzuführen. Der häufigste Einzelgrund für das Scheitern liegt dabei mit 13,1% in unvollständigen Anforderungen (siehe Abbildung 4).
Abbildung 4: Die wichtigsten 10 Einflussfaktoren, die den Projekterfolg gefährden [Sta95, IA02]
Und auch an den Wartungskosten haben Änderungen in den Anforderungen den größten Anteil:
Abbildung 5: Quellen für Wartungskosten (in %), nach der Standish Group [VH+03]
Je komplexer ein System ist, je mehr Menschen an der Entwicklung des Systems beteiligt sind, je sicherheitskritischer ein System und je komplexer die Systemumgebung (die Art und Anzahl der Nachbarsysteme, mit denen das zu entwickelnde System kooperieren muss) ist, desto wichtiger wird es, die Anforderungen möglichst präzise, vollständig und korrekt zu beschreiben. Um dies zu gewährleisten müssen Methoden eingesetzt werden, um systematisch Anforderungen hoher Qualität zu erarbeiten (konstruktive Qualitätssicherung), und die Qualität der erarbeiteten Anforderungen, also insbesondere ihre Korrektheit, Konsistenz und Vollständigkeit, zu evaluieren (analytische Qualitätssicherung), bevor die Anforderungen den anderen Teilprozessen zur Verfügung gestellt werden. Innerhalb des Entwicklungsprozesses ist für das Erarbeiten, Dokumentieren, Validieren, Verwalten und Qualitätssichern der Anforderungen das Anforderungsmanagement zuständig.
Das Anforderungsmanagement hat in den letzten Jahren nicht zuletzt im Automobilbereich erheblich an Bedeutung gewonnen [VH+03]: Da die in Fahrzeugen verwendeten Steuergeräte Teil einer immer komplexer werdenden Systemlandschaft sind und da diese Steuergeräte zum Teil extrem sicherheitskritisch sind [Rib03], wird in der Automobilindustrie immer größerer Wert auf die Erarbeitung qualitativ hochwertiger Anforderungen gelegt. Bei der Entwicklung sicherheitskritischer Systeme wird heute zudem die Erfüllung von Standards, Gesetzen und Normen gefordert, wie beispielsweise SPICE [SP07a, SP07b] und CMMI [CMMI], die beide ein systematisches Anforderungsmanagement verlangen.
Je mehr Aufwand aber in die Erarbeitung und Qualitätssicherung von Anforderungen investiert wird, desto mehr wächst auch das Bedürfnis, diese Investition optimal auszuwerten:
Dies wird zum einen durch eine systematische Wiederverwendung bereits qualitätsgesicherter Anforderungen in späteren Projekten (bis hin zur Entwicklung und Pflege von Produktlinien [PB+05]) angestrebt.
Ebenso wird eine hohe Durchgängigkeit zu Nachbarprozessen angestrebt, vor allem eine möglichst nahtlose Übernahme der Anforderungen ins Design (sodass die Übersetzung von Anforderungen in Designelemente mit möglichst wenig Aufwand verbunden und nicht fehleranfällig ist) oder auch ins Testmanagement (sodass aus Anforderungen möglichst leicht und soweit wie möglich automatisch Testfälle generiert werden können).
Entsprechend der großen Bedeutung der Anforderungen für den Verlauf des Entwicklungsprozesses und für das zu entwickelnde Produkt wird ein effektives Anforderungsmanagement immer wichtiger. Daher beschäftigen sich sowohl in der Forschung als auch in der Praxis Wissenschaftler und Praktiker damit, das Anforderungsmanagement zu verbessern.
Das Anforderungsmanagement kann dabei in verschiedene Aufgaben zerlegt werden[4]: Die Anforderungserarbeitung (Elicitation) beispielsweise beschäftigt sich damit, woher die Anforderungen an ein System kommen (zum Beispiel welche Stakeholder einbezogen werden müssen, oder welche weitere Quellen ausgewertet werden können) und wie die Anforderungen am besten erarbeitet werden können (zum Beispiel durch Einzelinterviews,...