Requirements Engineering and Cost Estimation - Einleitung

Einleitung

Lassen Sie uns mit einer Situation beginnen, die Sie alle kennen: Sie schreiben eine Einkaufliste und bitten jemanden, Ihnen unter anderem Milch aus dem Supermarkt mitzubringen.

Nachdem ich annehme, dass Sie mit den Milchregalen in den gängigen Einkaufs­tempeln vertraut sind, wie hoch ist – Ihrer Meinung nach – die Wahrscheinlichkeit, dass die einkaufende Person Ihnen genau die Milch mitbringt, die Sie sich vorstellen?

Damit sind wir auch bereits bei der üblichen Ausgangssituation des Requirements Engineering. Damit Sie wirklich das erhalten, was Sie sich wünschen, ist es notwendig, dass Sie Ihre Anforderung – in diesem Fall ‚Milch‘ – genau spezifizieren:

• Packungsgröße (Wie viel Milch hätten Sie gerne?)
• Hersteller (Möchten Sie eine bestimmte Marke?)
• Fettgehalt (Voll- oder Halbfettmilch?)
• Haltbarkeit (Längerfrisch- oder H-Milch?)
• Label ‚bio‘ (Legen Sie Wert auf nachhaltige Landwirtschaft?)
• Pflanzendrink (Sind Sie jemand, der mit ‚Milch‘ gar kein Milchprodukt mehr bezeichnet, sondern eine pflanzliche Alternative aus Soja, Nüssen oder Getreide?)

In Ihrem beruflichen Alltag und in dieser Lehrveranstaltung geht es nicht ‚nur‘ um Milch, sondern um Softwareprojekte, die – wie Sie sicher bestätigen können – wesentlich komplexere Anforderungen mit sich bringen.

Für ein kundenorientiertes, zuverlässiges und wartbares (Software-)System braucht es eine konsequente, systematische Vorgehensweise und die Vermittlung dieser ist Ziel der Lehrveranstaltung. Für ein erfolgreiches Entwicklungsprojekt ist ein funktionierendes Requirements Engineering Voraussetzung. Diese Lehr­veranstaltung widmet sich dementsprechend folgende Themen:

• Grundlagen und Kernaktivitäten des Requirements Engineering
• Projektumgebung: Ziele, Stakeholder und Systemkontext
• Anforderungen & deren unterschiedliche Arten
• Qualitätskriterien und Standards
• Ermitteln und Analysieren von Anforderungen
• Dokumentation von Anforderungen
• Review von Anforderungen
• Requirements Management
• Aufwandsschätzung

In den jeweiligen Kapiteln finden Sie die relevantesten Informationen zum jeweiligen Inhalt sowie meist Hinweise auf vertiefende Literatur. Aufgrund der aufbauenden Thematik empfiehlt es sich das Skriptum von vorne nach hinten durchzuarbeiten.

„It isn’t that they can’t see the solution. It is that they can’t see the problem.”

Die ‚Lösung‘ scheint aufgrund des quasi immer vorherrschenden Drucks sowie unserer gesellschaftlichen Konditionierung als das ständig erstrebenswerte Resultat. Viel zu schnell landen Projekte deshalb bei einem vermeintlichen Ergebnis, das allerdings, ohne die entsprechende Vorbereitung, die Entschlüsselung der Rahmenbedingungen sowie der Bestimmung der tatsächlichen Anforderungen, voller unvorhersehbarer Details ist. Die Blendung durch die Lösung ist oft so stark, dass zum Beispiel im allseits bekannten ‚Hitch-Hiker’s Guide to the Galaxy‘ von Douglas Adams die Antwort auf alle Fragen der Welt ‚42‘ euphorisch gefeiert wird. Ohne zu wissen, wie die Frage dazu lautet, ist die Antwort aber müßig. Dem Anschein nach meinen die Beteiligten in vielen Projekten, das Problem zu verstehen und stecken Unmengen an Bemühungen und Leistung in die Arbeit an der Lösung. Häufig kommen diese dann erst (zu) spät zur Erkenntnis, dass der eigene Eifer und die gesetzten Aktivitäten das Problem nicht lösen bzw. kaum in die Lösung zu integrieren sind.

Requirements Engineering ist also ein Versuch, Projekte beherrschbar zu machen, in dem wir uns mit der jeweiligen Situation, den betroffenen Menschen und den Prozessen vertraut machen. Dabei darf nicht übersehen werden, dass sich eine komplexe Welt per se nicht kontrollieren lässt.

‚To begin with the end in mind‘ ist eine hilfreiche Einstellung, um an Projekte heranzugehen. Denn eine Vision und konkrete Ziele erhöhen die Chancen der Zielerreichung. Um zu starten, ist es hilfreich, sich neben der Frage, wo wir überhaupt hin wollen, damit auseinanderzusetzen, wer von dem Problem und/oder der Lösung betroffen ist und wie die Grenzen bzw. der Kontext des Systems genauer aussehen.

Unzureichende oder mangelhafte Beschreibungen von Requirements sind dann zusammen mit einem unausgereiften und dadurch potentiell chaotischen Anforderungsmanagement die häufigsten Ursachen, warum Projekte nicht erfolgreich verlaufen. Mit Hilfe von sorgfältig definierten Anforderungen und einem systematischen Vorgehen in deren Erhebung, Dokumentation und Abstimmung, können Entwicklungskosten gesenkt und gleichzeitig die Kundenzufriedenheit erheblich erhöht werden.

Requirements Engineering beinhaltet, wie in diesem Skriptum noch ausführlich erläutert wird, das methodisch unterstützte Erarbeiten, Spezifizieren und Validieren, Priorisieren, Vereinbaren und Verfolgen aller Anforderungen in einem Projekt. Darunter fallen sowohl Prozessrequirements, funktionale und nicht-funktionale Anforderungen.

Diese Tätigkeiten sind in der Praxis weder unter sich noch im Kontext mit den anderen Aktivitäten eines Entwicklungsprozesses als Kreislauf mit nacheinander ablaufenden Phasen zu sehen. Vielmehr laufen immer wieder einzelne der Aktivitäten – entgegen dem Modell – parallel bzw. greifen vor- und zurück.

Ablaufmodell der Systementwicklung

Die Vorgehensweise und Methodik des Requirements Engineerings zur Generierung von Anforderungen ist in jedem Fall aber eine eigenständige, in ihrer Bedeutung nicht zu unterschätzende Disziplin. Sie liefert als Resultat die notwendige Grundlage für das Design, die Implementierung und den Betrieb eines Systems und begleitet diese Prozesse durch die Verwaltung und das Change Management der Anforderungen. Dieses methodische Vorgehen erfordert eine gewisse Disziplin, führt dadurch aber zu einer besseren Qualität des daraus entwickelten Systems und erleichtert später den Betrieb sowie die Kalkulation möglicher Konsequenzen einer Änderung oder Erweiterung des Systems.

Von der erfolgreichen Einführung von Softwaresystemen ist dann die Rede, wenn die Requirements der relevanten Stakeholder umgesetzt sowie geplante Termine und Budgets eingehalten sind.

Erfolgsquote von IT-Projekten laut Standish Group 2011

Obwohl sich die Erfolgsquote von Softwareprojekten in den letzten Jahren erheblich verbessert hat, sind dennoch nur 34 % aller Projekte in diesem Sinne erfolgreich. Über die Hälfte aller Projekte können entweder nicht zeitgerecht oder im vereinbarten Budget geliefert werden und etwa ein Sechstel scheitern gänzlich. Weitere Zahlen und Fakten des Projektalltags sprechen eine deutliche Sprache bezogen auf das Ausmaß meist des Versagens im Requirements Engineering. Eine Studie der Hertie School of Gouvernance analysierte die größten Misserfolge bei Projekten in Deutschland. Wie im SPIEGEL Online dazu nachzulesen ist, sind drei der katastrophalen Top 5 IT-Projekte mit hundertfacher Kostenübersteigung. Die verschrienen Großbauvorhaben, wie Flughäfen, Bahnhöfe oder Straßenbau, schneiden im Vergleich dazu mit durchschnittlich ‚nur‘ 33-44 % höheren Kosten harmlos ab.

• Toll-Collect (LKW-Mautsystem): 6,9 Mrd., Kostensteigerung 1150%
• FISCUS Steuerverwaltungssystem: 4,6 Mrd., Kostensteigerung 1150%
• Schneller Brüter Kalkar (Atomkraftwerk): 2,8 Mrd., Kostensteigerung 494%
• Inpol (Polizei-Informationssystem): 119 Mio., Kostensteigerung 491%
• Bischofsresidenz Limburg: 25 Mio., Kostensteigerung 425%

Laut dem Chaos-Report der Standish-Group, die über 8000 ganz oder zum Teil gescheiterte Softwareprojekte untersucht hat, sind die Ursachen für Misserfolge zahlreich. Als die drei Hauptgründe, warum Projekte erfolgreich sind, nennen sie das Einbeziehen von Usern, die Unterstützung des höheren Managements und die klare Darstellung von Anforderungen.

Ein Klassiker, der Kommunikations- und Interessenskomplexität gut abbildet, ist der folgende Comic, in dem eine einfache Schaukel gebaut werden soll. Auch wenn darin natürlich Stereotype bedient werden, soll er Sie darauf aufmerksam machen, welche Herausforderungen grundlegend im Requirements Engineering auf Sie warten. Der geplante Bau erzeugt hier einerseits die in der Softwareentwicklung ‚typische‘ Spezifikation, Korrektur und Kommunikation, andererseits am Ende enttäuschte Nutzer und einen zerstörten Baum. Um zu verhindern, dass verschiedene Stakeholder in einem Projekt die Anforderungen auf unterschiedliche Art und Weise interpretieren, müssen diese möglichst eindeutig erhoben, dokumentiert und miteinander kommuniziert werden. Nur so lassen sich Ziel- und Anforderungskonflikte rechtzeitig identifizieren und beilegen sowie ein zielführender Umgang mit Diversität und Komplexität finden.

Requirements Engineering at its worst

Was der Kunde erklärte, sind Fragmente, kein Zielsystem. Der Projektleiter verstand eine sichere, aber nicht funktionale Version davon. Der Entwurf der Analytiker erfüllt zwar die Vorgaben, verfehlt jedoch das Ziel. Was der Programmierer umsetzt, rettet den Baum und ‚erdet‘ die Schaukel. Die Berater versprachen das Blaue vom Himmel, denn das ist für die Kunden gerade gut genug. Die Projektdokumentation ist ein Schatten ihrer selbst. Was installiert wurde, entspricht dem Sprichwort: gute Freunde, strenge Rechnung. Im Gegensatz dazu sei dem Kunden, bei dem was ihm in Rechnung gestellt wurde, empfohlen: drum prüfe, wer sich ewig bindet. Die Wartung durch den Support zeigt, Operation gelungen, Patient tot. Und die Bedürfnisse und Wünsche des Kunden? Tja, die blieben in dem Beispiel auf der Strecke! Die folgenden Kapitel sollen Sie dabei unterstützen, dass Ihre Projekte nicht ebenso ein Schicksal erleiden.