Einer der Gründe für Projektversagen: Mangelhaftes Requirements Engineering
Es hat sich zwar in den letzten Jahren merklich verbessert, dennoch geht laut dem Chaos Report der Standish Group immer noch mehr als ein Sechstel aller Software-Projekte schief. Fast zweieinhalb Mal so viele Projekte enden teurer, später oder nicht in der geplanten Qualität (in der Abbildung 1 mit „Challenged“ gekennzeichnet).
Abbildung1: Chaos Report der Standish Group, Werte von 2013
Die Grundursachenanalyse der Fehler (Abbildung 2) zeigt, dass 60% der Fehler in der Anforderungsanalyse entstehen. Nach und nach durchdringt das Bewusstsein für gute Anforderungen die Unternehmen, nicht zuletzt auch durch lauter werdende Stimmen der Tester, die sich verstärkt in Reviews der Anforderungsdokumente hineinreklamieren.
Abbildung 2: Entstehung der Fehler im Entwicklungszyklus
Management von Requirements oft unterschätzt
Man findet durchaus für sich gute Anforderungsbeschreibungen auf unterschiedlichen Ebenen, von Anwendungsfällen bis zu technischen Detailspezifikationen. Was aber oft noch fehlt, ist der gezielte ergebnisorientierte Einsatz der geeigneten Beschreibungsform zur richtigen Zeit. Nicht zuletzt fühlen sich viele Entwickler durch die Forderung nach der gerade notwendigen Dokumentation („Just enough documentation“) in agilen Ansätzen verunsichert. Ähnlich ergeht es dem Bereich Änderungsmanagement, der durch unterschiedliche Strömungen eher aufgewühlt als gefestigt erscheint: Die Palette reicht vom streng prozesskonformen Change Control Board, das über jede Änderung entscheidet, ob und wann sie aufgenommen wird, bis zur Diskussion und Entscheidung im agilen Team über veränderte Anforderungen auch spät im Projekt, oder nicht selten der undokumentierten Änderungen auf Zuruf.
Die notwendige Entwicklungsrichtung im Requirements Engineering legt das Augenmerk auf den Bereich der Verwaltung. Diese umfasst unter anderem
- Planung der angemessenen Dokumentationsarten zur passenden Zeit,
- Attributierung, Filterung
- Statusübersicht
- Versionierung, Variantenbildung,
- Änderungsmanagement,
- Verfolgbarkeit,
- eine geeignete Toolauswahl und
- das Verwalten des Requirements Engineering Prozesses als Ganzes.
Als Beispiel sei die Analyse und Organisation der Anforderungsinformation als Grundlage für die Dokumentation angerissen:
Vor der Anforderungsdokumentation
Zu Projektbeginn ist es an der Zeit, zu überlegen und zu planen, wie, wo und wann Anforderungen auf welchem Detaillierungsgrad beschrieben werden sollen. Gegenstand der Anforderungsbeschreibung kann eine erste Zielformulierung sein, aber auch ein Story-Board oder Szenario bis hin zu technischen Funktionen, Abläufen und Schnittstellen. Je nach Projektgegebenheiten wird nicht alles davon benötigt. Ziele sollten am Beginn stehen, detaillierte Anforderungen werden aus den Zielen abgeleitet. Hilfreich ist ein Requirements Information Model, in dem festgelegt wird, wie Randbedingungen, funktionale Anforderungen und Qualitätsanforderungen jeweils in den benötigten Granularitäten beschrieben werden. Es werden Dokumentationsformen auch nach einer weiteren Dimension unterschieden, die sich zwischen geschäftsbezogenen Zielen bis hin zu technischen Lösungen aufspannt (Abbildung 3).
Abbildung 3: „Informationswürfel“: Dimensionen der Anforderungsinformationen (Quelle: IREB)
In einem Requirements Information Model (RIM) können die Dokumentationsarten dargestellt werden, die für bestimmte Bereiche dieses Informationswürfels sinnvoll erscheinen und in einem folgenden Schritt genauer geplant werden. Ein erstes Modell kann dabei wie in Abbildung 4 gezeigt aussehen. In einer weiteren Verfeinerung kann dann zum Beispiel festgelegt werden, was davon vorwiegend mit Modellen grafisch dargestellt werden soll und mit welchen Modellen, und was eher textuell mit wenigen ergänzenden Bildern oder tabellarisch.
Abbildung 4: Ein einfaches RIM (Quelle: IREB)
Das Seminar Certified Professional for Requirements Engineering (CPRE) Advanced Level: Requirements Management
Das Erstellen und Konkretisieren der oben geschilderten Informationsmodelle ist nur ein Teil der Seminarinhalte. Sie erfahren im Seminar auch, worauf es beim Attributieren von Anforderungen ankommt, wie Sie Anforderungen gezielt bewerten und priorisieren, was Sie von einem Versions- und Änderungsmanagement erwarten sollten, wie Sie mit Variantenbildung für Produkt und Anforderungen umgehen und vieles mehr.
Wie Sie Anforderungen erheben, welche Dokumentationsmöglichkeiten es gibt, warum Prüfen und Abstimmen so wichtig sind, wird in diesem Seminar aus dem Foundation Level als bekannt vorausgesetzt. Wenn Sie die Bereiche Erheben und Abstimmen unter den Stakeholdern vertiefen wollen, empfehlen wir das Seminar CPRE Advanced Level: Elicitation and Consolidation.
Nähere Informationen und Seminartermine finden Sie in unserem Onlineshop: IREB CPRE Advanced Level: Requirements Management
