Christof Ebert ist Geschäftsführer der Vector Consulting Services. Zuvor war er zwölf Jahre in Führungsaufgaben bei einem IT-Marktführer tätig, zuletzt mit weltweiter Verantwortung für Softwareplattformen. Er arbeitet in verschiedenen industriellen Boards und Aufsichtsgremien, ist Professor an der Universität Stuttgart sowie an der Sorbonne in Paris und Autor mehrerer Bücher. Seit vielen Jahren ist er in den Herausgeberkomitees von führenden Zeitschriften wie »IEEE Software« und »Journal of Systems and Software«.
Folgen Sie ihm auf Twitter: @ChristofEbert
Kontakt: christof.ebert@vector.com, www.christofebert.de
Homepage des Buches: www.vector.com/RE-Buch
Der QR-Code rechts führt Sie schnell zur Homepage des Buches.
|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.plus |
Anforderungen ermitteln, dokumentieren, analysieren und verwalten
6., überarbeitete und erweiterte Auflage
Christof Ebert
christof.ebert@vector.com, www.christofebert.de
Lektorat: Christa Preisendanz
Copy-Editing: Friederike Daenecke, Zülpich
Satz: III-satz, www.drei-satz.de
Herstellung: Stefanie Weidner
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik: Prof. Dr. Heidi Heilmann · heidi.heilmann@augustinum.de
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN: |
|
Buch |
978-3-86490-562-9 |
978-3-96088-452-1 |
|
ePub |
978-3-96088-453-8 |
mobi |
978-3-96088-454-5 |
6., überarbeitete und erweiterte Auflage 2019
Copyright © 2019 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Meinen Eltern Elfriede und Otto
und meinem Lehrer Rudolf Lauber.
Sie haben mir gezeigt,
dass ein Werk nur Wert schafft,
wenn die Anforderungen verstanden und umgesetzt sind.
Es ist nicht genug zu wissen, man muss es auch anwenden.
Es ist nicht genug zu wollen, man muss es auch tun.
Johann Wolfgang von Goethe
Unternehmen ohne Requirements Engineering laufen im Nebel ständig gegen Hindernisse. Jene mit durchschnittlichem Requirements Engineering lernen, wo die Hindernisse sind; Unternehmen mit gutem Requirements Engineering bauen Hindernisse für andere auf. Oft erkennt man diese Hindernisse erst, wenn es zu spät ist. Dieses Buch ist aus der Praxis für die Praxis geschrieben und zeigt Ihnen, wie Sie Hindernisse frühzeitig aus dem Weg schaffen und damit Wert für sich und Ihr Unternehmen kreieren.
Anforderungen sind der Schlüssel zum Erfolg. Projekte scheitern, weil ihre Ziele und Anforderungen unklar sind. Produkte kommen am Markt nicht an, weil sich niemand Gedanken über die Ziele und Randbedingungen gemacht hat. Ständige Nachbesserungen sind teuer, zu komplex oder sind inakzeptabel. Das weiß jeder, und trotzdem tappt auch in diesem Jahr wieder ein Drittel aller Projekte in genau diese Falle. Offensichtlich ist es nicht genug zu wissen, man muss es auch wollen und tun.
Systematisches Requirements Engineering entscheidet über Erfolg oder Misserfolg eines Projekts und Produkts. Dieses Buch beschreibt praxisorientiert und systematisch das gesamte Requirements Engineering – von der Konzeption bis zur Evolution eines Projekts oder Produkts. Es adressiert Requirements Engineering in einem breiten Kontext, sodass sich ganz unterschiedliche Anwendungsbereiche wiederfinden, sei es Software und IT, aber auch Hardware, Systemtechnik oder Serviceentwicklung.
Auch in seiner sechsten Auflage ist dieses Buch eine Referenz für Ihren Schreibtisch. So ist diese komplett überarbeitete Auflage auch für bisherige Leser lohnend. Neue Beispiele, Tipps, Abbildungen und Inhalte schaffen Abwechslung zu den früheren Auflagen. Agiles Requirements Engineering hat nun ein eigenes Kapitel, und eine Fallstudie zu IoT macht die praktische Umsetzung lebendig.
Die meisten Projekte umfassen Änderungen existierender Systeme. Das Buch adressiert diese Situation und bewegt sich nicht akademisch auf der »grünen Wiese«. Der Kanon des IREB Certified Professional Requirements Engineer wird abgedeckt und dort erweitert, wo nach Ansicht des Autors im Lehrplan Inhalte fehlen, beispielsweise bei der Schätzung und im Test. Die Checklisten wurden erneuert, denn man lernt in Projekten ständig dazu. Ein Selbsttest hilft bei der Bewertung Ihrer Fähigkeiten im Requirements Engineering. Der Nutzen und ROI von Requirements Engineering wird an verschiedenen Stellen herausgestellt. Damit haben Sie konkrete Ansatzpunkte, wie Sie mit Ihren eigenen Herausforderungen umgehen können. Die vorgestellten Vorlagen und viele aktuelle Tipps sowie Hinweise auf Trainings sind auf der Homepage dieses Buches verfügbar: www.requirements-excellence.com.
Mein Dank geht an die Mitarbeiter und Kunden von Vector Consulting, mit denen wir die genannten Praktiken umsetzen und verbessern. Besonders danken möchte ich Kai Rüdele für seine Impulse. Danke an Christa Preisendanz und den dpunkt.verlag für die gewohnte Geduld und Professionalität.
Al Davis hatte mich vor 25 Jahren als Chefredakteur von IEEE Software dazu angeregt, Requirements Engineering in der Industrie zu verankern. Dank an Al und die vielen Kollegen, die dieses Thema in der Praxis antreiben, wie Ian Alexander, Dan Berry, Anthony Finkelstein, Don Gause, Michael Goedicke, Martin Glinz, Matthias Jarke, Neil Maiden, Barbara Paech, Klaus Pohl, Mary Popendieck, Suzanne Robertson, Ian Sommerville und Karl Wiegers.
Viele Leser der früheren Auflagen haben mir wertvolle Tipps für diese Überarbeitung gegeben. Wie bereits bisher stehe ich Ihnen, verehrte Leserinnen und Leser, während und nach der Lektüre des Buches für Fragen und Unterstützung gerne zur Verfügung. Um die Sätze kurz zu formulieren, verwende ich im Folgenden übrigens die männliche Form – wohl wissend, dass gerade das Requirements Engineering stark durch Frauen geprägt wird. Ich hoffe, die Kolleginnen werden es mir nachsehen.
Produkte sind, was wir liefern. Wert ist, was die Kunden wahrnehmen. Das läuft oft stark auseinander. Mehr Requirements bedeuten nicht unbedingt mehr Wert, aber definitiv mehr Kosten und Komplexität. Zu viele oder falsche Anforderungen ruinieren Budgets, Termine und die Qualität. Man startet mit unklaren Bedürfnissen und Zielen, rudimentären Ideen, Luftschlössern aus dem Vertrieb, nicht bewerteten Abhängigkeiten und vagen Vermutungen. Später rächt sich diese Nachlässigkeit in Gestalt von Änderungen und Nacharbeit. Entwickeln Sie nicht nur Anforderungen, sondern verfolgen Sie das Ziel, für Ihre Kunden Wert zu schaffen – und für Ihre Mitbewerber Hindernisse.
Ihnen, liebe Leser und Kunden, wünsche ich dabei viel Erfolg! Dieses Buch gibt Ihnen mit lösungsorientiertem Requirements Engineering die nötigen Impulse. Es liegt ganz an Ihnen, ob Sie nur wissen oder auch wollen und tun – und damit Erfolg haben.
Christof Ebert
Bengaluru, September 2018
»… ein hervorragendes Buch für den praxisnahen Einstieg in die vielschichtigen Themenkomplexe der Anforderungsanalyse und des Anforderungsmanagements.«
Chip.de (Juli 2010 zur 2. Auflage)
»›Systematisches Requirements Engineering‹ ist die wertvollste Anleitung für Anforderungen, die Sie finden können. Christof Ebert deckt die gesamte Landschaft von Praktiken ab, die ein Requirements-Ingenieur, Projektmanager oder Produktmanager kennen sollte. Für Praktiker und Manager gleichermaßen kann ich dieses Buch nicht hoch genug empfehlen. Ich war schon immer ein Fan von seinen Schriften – und werde es auch weiterhin sein!«
Alan M. Davis, Entrepreneur und Professor
University of Colorado, Colorado Springs
»Inzwischen ein Klassiker für den systematischen Umgang mit Anforderungen. Geschrieben von einem Praktiker für die Praxis – einfach, verständlich und anwendbar! Dass der Autor sein Metier versteht, durfte ich in einem gemeinsamen Praxisprojekt hautnah erleben.«
Hans Leibbrand
ehem. Chief Operating Officer und Vorstand, Thales
»Mit den Anforderungen werden die Weichen gestellt für den Projekterfolg – oder Misserfolg. Aus fehlerhaften, unvollständigen oder widersprüchlichen Anforderungen wird niemals gute Software entstehen. Das vorliegende Buch hilft, den richtigen Einstieg in die Softwareentwicklung zu finden und die vielen Klippen zielgerichtet zu vermeiden.«
Peter Liggesmeyer, Direktor Fraunhofer IESE
ehem. Vorsitzender der Gesellschaft für Informatik
»Christof Ebert schafft es, sowohl Frischlingen als auch alten Hasen Neues beizubringen. Anschaulich und ohne Besserwisserei zeigt er, wie Requirements Engineering im Unternehmen optimal aufgesetzt wird. Ein Muss für Entscheider und alle, die Erfolg bei Softwareprojekten haben wollen.«
Gerhard Mack, Chief Operating Officer und Vorstand
Vodafone – Kabel Deutschland
»Christof Ebert hat ein Talent dafür, zum Kern der Sache zu kommen und die einfache (aber schwer erkennbare) Wahrheit freizulegen. Danke für die immer klar und elegant formulierten Ratschläge!«
Suzanne Robertson, Gründerin und Principal
The Atlantic Systems Guild Ltd.
1Motivation
1.1Warum ein Buch über Requirements Engineering?
1.2Projekte scheitern wegen unzureichender Anforderungen
1.3Wirtschaftlicher Nutzen und Return on Investment (ROI)
1.4Wie Sie von diesem Buch profitieren
1.5Selbsttest
1.6Ein Blick über den Tellerrand
2Requirements Engineering – kurz und knapp
2.1Was ist eine Anforderung?
2.2Perspektiven: Vom Markt zur Realisierung
2.3Arten von Anforderungen
2.4Was ist Requirements Engineering?
2.5Requirements Engineering in der Praxis
2.6Wichtige Begriffe
2.7Durchgängiges Beispiel: iHome
2.8Tipps für die Praxis
2.9Fragen und Impulse
3Anforderungen ermitteln
3.1Ziel und Nutzen
3.2Bedürfnisse verstehen, Ziele vereinbaren
3.3Anspruchsträger managen
3.4In 10 Schritten zu guten Anforderungen
3.5Qualitätsanforderungen und Randbedingungen
3.6Fallstudie: Security Requirements Engineering
3.7Checkliste für die Anforderungsermittlung
3.8Tipps für die Praxis
3.9Fragen und Impulse
4Anforderungen dokumentieren
4.1Ziel und Nutzen
4.2Lasten und Pflichten: Vom Was zum Wie
4.3Dokumentation und Vorlagen
4.4Struktur und Lesbarkeit
4.5Attribute und Filter
4.6Glossar
4.7Checkliste für die Dokumentation
4.8Tipps für die Praxis
4.9Fragen und Impulse
5Anforderungen modellieren und analysieren
5.1Ziel und Nutzen
5.2Modelle und Methoden
5.3Architektur und Anforderungen
5.4Modellierung mit UML, SysML und BPMN
5.5Aufwandsschätzung
5.6Analyse in zehn Schritten
5.7Checkliste für die Anforderungsanalyse
5.8Tipps für die Praxis
5.9Fragen und Impulse
6Anforderungen prüfen
6.1Ziel und Nutzen
6.2Qualitätskriterien für Anforderungen
6.3Verfahren zur Prüfung
6.4Kriterien für Testende und Abnahme
6.5Testorientiertes Requirements Engineering
6.6Checkliste zur Prüfung von Anforderungen
6.7Tipps für die Praxis
6.8Fragen und Impulse
7Anforderungen abstimmen
7.1Ziel und Nutzen
7.2Abstimmung im Kernteam
7.3Risiken abschwächen
7.4Priorisierung von Anforderungen
7.5Recht, Compliance und Haftung
7.6Verträge und Vertragsmodelle
7.7Checkliste für Abstimmung und Verträge
7.8Tipps für die Praxis
7.9Fragen und Impulse
8Anforderungen verwalten
8.1Ziel und Nutzen
8.2Änderungsmanagement
8.3Nachverfolgung von Anforderungen
8.4Änderungen und Altsysteme
8.5Versionierung und Varianten von Anforderungen
8.6Maße und Kennzahlen
8.7Checkliste für die Verwaltung
8.8Tipps für die Praxis
8.9Fragen und Impulse
9Agiles Requirements Engineering
9.1Agile Entwicklung
9.2Komplexität beherrschen
9.3Praxis des agilen RE
9.4Design Thinking
9.5Skalierbare Agilität
9.6Fallstudie: Agile Skalierung
9.7Fallstudie: Lean Development
9.8Tipps für die Praxis
9.9Fragen und Impulse
10Werkzeuge
10.1Ziel und Nutzen
10.2Werkzeuge und Bewertung
10.3Praxis: von DOORS bis PREEvision
10.4Werkzeuge einführen
10.5Checkliste für Werkzeuge
10.6Tipps für die Praxis
10.7Fragen und Impulse
11Requirements Engineering leben
11.1Organisation
11.2Projektmanagement
11.3Produktmanagement
11.4Lieferantenmanagement
11.5Serviceorientierung und Dienste
11.6Fallstudie: Funktionsmodellierung und Produktlinien
11.7Fallstudie: Prozessverbesserung
11.8Tipps für die Praxis
11.9Fragen und Impulse
12Soft Skills und weitere konkrete Tipps
12.1Der Requirements-Ingenieur
12.2Zertifizierung nach IREB
12.3Soft Skills
12.4Konflikte lösen
12.5Top-5-Tipps für Sie
12.6Fragen und Impulse
13Stand der Technik und Trends
13.1Der »Stand der Technik«
13.2Standards und Normen
13.3Benchmarks, Faustregeln und Kennzahlen
13.4Trends in der IT und Softwaretechnik
13.5Trends im Requirements Engineering
13.6Ein konstruktiver Ausblick
13.7Top-10-Tipps
Anhang
AInternetressourcen
BGlossar
CLiteratur
Index
Ihr Nutzen aus diesem Kapitel:
»Wenn Du nicht weißt, wohin Du gehen willst, kannst du jeden Weg nehmen.« Alice im Wunderland wusste es, wie auch viele Denker vor und nach ihr. Klare Ziele werden erreicht, unklare Ziele werden sicher verfehlt. In diesem Kapitel zeige ich, wie Sie mit Requirements Engineering Ziele schrittweise klären und kommunizieren. Insbesondere möchte ich den Nutzen eines systematischen Requirements Engineering darstellen. Beantworten Sie die folgenden Fragen einfach spontan und ehrlich: Sind Ihre Anforderungen strukturiert und testbar dokumentiert? Hat Ihr derzeitiges Projekt einen expliziten Business Case, der auch geprüft wird? Gibt es für jede Anforderung eine kurze Begründung, die den Nutzen und Wert beschreibt? Falls nicht, ist das Buch das Richtige für Sie. Falls ja, lesen Sie die Fragen nochmals und gehen Sie in sich.
»Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen.« Douglas Adams hatte in seinem fünfbändigen Werk »Per Anhalter durch die Galaxis« präzise erkannt, warum im Leben, im Universum und dem ganzen Rest nicht immer alles so klappt, wie wir wollen. Die Anforderungen sind häufig unpräzise – oder fehlen.
Wir Menschen entwickeln uns, weil wir aus Anforderungen Lösungen machen. In den Sechzigerjahren überlegte man sich, wie man im All schreiben kann. Kugelschreiber funktionierten aufgrund der fehlenden Schwerkraft nicht so gut. Die Amerikaner entwickelten einen aufwendigen »Space Pen«, der ganz aus Metall gefertigt und gekapselt in einem weiten Temperaturbereich auf verschiedenen Oberflächen und ohne Schwerkraft funktioniert. Die Russen mit den gleichen Anforderungen nutzten dafür einen einfachen Bleistift.
Komplexe Anforderungen brauchen keine komplizierten Lösungen. Die kleine Anekdote aus den unergründlichen Weiten des Weltalls zeigt uns noch mehr. Funktionale Anforderungen benötigen zur praxisorientierten Umsetzung flankierende Qualitätsanforderungen und einschränkende Randbedingungen. Da fällt der Bleistift natürlich durch, da Holz und Graphit in der sauerstoffreichen Atemluft eines Raumschiffes ein Brandrisiko darstellen. Abgebrochene Bleistiftminen sind zudem in der Schwerelosigkeit gefährlich, denn sie könnten eingeatmet werden oder ins Auge gelangen. Die Amerikaner setzten jedenfalls den Space Pen mit Erfolg ein – allerdings zum Preis von drei Dollar pro Stück, und auf der Erde.
Oft zerbrechen wir uns vorschnell den Kopf über eine Lösung, ohne verstanden zu haben, welches Problem wir lösen müssen. Wir gehen zu Besprechungen, ohne zu hinterfragen, was sie bringen. Wir entwickeln Funktionen für ein Softwaresystem und wissen nicht, welchen Wert sie für die Käufer darstellen. Wir optimieren und bemühen uns ständig, bessere Produkte zu entwickeln – und fühlen uns wie im Hamsterrad. Während des Projekts wundern wir uns, dass sich die Anforderungen ständig ändern. Dabei war niemals klar, was wir eigentlich konkret erreichen wollen – und was nicht.
Abbildung 1-1 zeigt ein typisches Beispiel einer Anforderung. Sie ist Prosa, weil das leichter zu schreiben ist, und wirft mehr Fragen auf, als sie beantwortet:
Abb. 1-1Eine Anforderung – so viele Fragen
Anforderungen an Software werden zunehmend komplexer. Abbildung 1-2 zeigt die Entwicklung verschiedener Softwaresysteme, die wir untersucht haben.1 Auf der waagrechten Achse sind die Jahreszahlen angegeben, während senkrecht das Softwarevolumen in tausend Objektcodebefehlen dargestellt ist. Diese Darstellung erschien uns als die einzig praktikable, wenn wir so unterschiedliche Systeme wie Apps für Mobiltelefone und eingebettete Software vergleichen wollen. Der Umfang der Software verdoppelt sich alle zwei bis vier Jahre. Mit diesem Wachstum steigt auch der Umfang der Spezifikationen an. Gab es Anfang der Neunzigerjahre beispielsweise einige wenige Steuergeräte in einem Neuwagen mit ungefähr hundert Seiten an Spezifikationen, so sind es heute bereits fünfzig und mehr Steuergeräte mit über 100.000 Seiten an Spezifikationen. Diese schnell wachsende Komplexität fordert systematisches Requirements Engineering (RE), um die Qualität und Kosten nachhaltig kontrollieren zu können.
Ein gutes Beispiel für diese nicht hinterfragte künstliche Komplexität sind Migrationsprojekte. Die Anspruchsträger sind sich oft schnell darin einig, dass alle Funktionen des existierenden Altsystems übertragen werden müssen. Ein Fehler. Erstens kann sowieso niemand mehr alle existierenden Altfunktionen im Zusammenhang beschreiben. Und zweitens ist gerade ein neues System die einzige Chance, alte Funktionen und Workflows über Bord zu werfen. Dass es anders geht, zeigen Start-ups und exzellente Unternehmen wie Apple. Bei ihnen lautet die erste Frage nicht, welche Komplexität noch zusätzlich entwickelt werden soll, sondern wie das Produkt hinreichend schlank bleibt.
Abb. 1-2Komplexität von Softwaresystemen über die Zeit
Erfahrene Projektmanager und Entwickler wissen, dass es erprobte Methoden sowie werkzeugunterstützte Hilfsmittel für das Requirements Engineering gibt. Häufig fehlt ihnen aber der Überblick über die Theorie und Praxis des Requirements Engineering, um die für ihre Situation passenden Methoden, Verfahren und Hilfsmittel auszuwählen, sowie die notwendige Kenntnis im Detail, um sie produktiv nutzen zu können.
Das Buch füllt diese Lücke. Es liefert umsetzungsorientiert Theorie und Praxis des Requirements Engineering. Die gängigen Verfahren der Anforderungsanalyse sind beschrieben. Die Leser erhalten Einblick in die Art und Weise, wie Anforderungen ermittelt, entwickelt, dokumentiert und im Projekt verfolgt werden. Die grundsätzlichen Methoden, Verfahren, Werkzeuge und Notationen des Requirements Engineering werden übersichtlich behandelt. Sie werden durch konkrete Beispiele aus der Projektarbeit illustriert. Notationen und Modelle sind in der Regel mit UML 2.0 beschrieben. Fallstudien demonstrieren die konkrete Umsetzung und Erfahrungen aus der Praxis.
Zu viele Projekte scheitern, und Produkte erreichen die Marktziele nicht. Unzureichendes Requirements Engineering ist immer unter den Top-3-Ursachen. Eine aktuelle Studie der Standish Group zeigt, dass ein gutes Drittel aller Projekte erfolgreich abgeschlossen wird. Ein Fünftel wird abgebrochen, und der Rest kommt zwar zu einem Abschluss, aber nur unter Aufgabe von ursprünglichen Zielen (Abb. 1-3) [Standish2018]. RE erhält im Schnitt nur 2–5 % des Projektaufwands, aber Fehler in den Anforderungen haben die größten Effekte [Gartner2018]. Die meisten abgebrochenen Projekte hatten nur ungenügend geklärte initiale Anforderungen und konnten Änderungen der Anforderungen nicht beherrschen [Anthopoulos2016, Standish2018, Charette2017, Tan2011, Ebert 2014a, Ebert2007].
Beispiel:
Viele Projekte scheitern, da sich Anforderungen ändern, aber die Projektstruktur und IT-Architektur das nicht berücksichtigen. Aktuelles Beispiel ist das amerikanische Versicherungssystem »Obamacare«. An das Projekt wurden politisch hohe Erwartungen geknüpft, sollte es doch erstmals einen Basisschutz für alle amerikanischen Bürger schaffen. Doch die Webseite mit der Online-Registrierung lieferte nie die erwartete Performance. Kundendaten verschwanden oder mussten wiederholt eingegeben werden. Schließlich funktionierte die Webseite rudimentär, stimulierte aber politische Gegner, damit das gesamte Programm zu hinterfragen. Die Mehrkosten der IT liegen im Bereich von knapp 500 Mrd. US$. Die Gründe für das Scheitern waren zu viele Anspruchsträger, die mitwirkten, sich stark ändernde Anforderungen, eine unzureichende Validierungsstrategie und ein monolithisches System, das ungeeignet für Teillösungen und inkrementelle Änderungen war. Viele eGovernment-Projekte leiden unter diesem Dilemma, es allen Anspruchsträgern recht machen zu wollen. Damit haben sie ein so weiches Ziel, dass das System nie fertig wird [Anthopoulos2016].
Die wesentlichen Befunde aus Kundenprojekten, bei denen wir zur Unterstützung und Moderation gerufen wurden, sind im Folgenden aufgelistet – als Warnung, aber auch, damit Sie sich selbst prüfen können:
Abb. 1-3Unzureichendes Requirements Engineering reduziert den Projekterfolg.
Ein wichtiger Grund dafür, dass Projekte ihre Ziele nicht erreichen, liegt in nicht sauber formulierten Zielen. Abbildung 1-3 zeigt im unteren Teil diesen Zusammenhang und unterstreicht schon aufgrund der Datenlage die immense – und wachsende – Bedeutung eines guten Requirements Engineering. Bei einem Großteil aller abgebrochenen Projekte war unzureichendes RE ein wesentlicher Grund für das Scheitern. Häufiger wurden nur noch »unzureichende Prozesse« und »unklare Verantwortungen« genannt, aber das sind auch offensichtliche Allgemeinplätze, die man sich in jedem verkorksten Projekt gut vorstellen kann.
Technologische Herausforderungen lassen sich beherrschen. Schlechtes Management nicht. In Krisenzeiten, wie 2001 und 2008, geht die Erfolgsquote zurück. Dann werden vermeintlich unnötige Ausgaben, wie für Requirements Engineering, reduziert – mit durchschlagenden Konsequenzen.
Erfolg ist machbar. Hier die wichtigsten Erfolgsfaktoren aus der Industriepraxis:
Es geht nicht um eine spezielle Methode, sondern darum, dass diszipliniert gearbeitet wird. Wir wollen in diesem Buch darauf eingehen, welche Techniken des RE Sie einsetzen sollten, um mit Ihren Projekten und Produkten zu den Gewinnern zu gehören.
Auf was muss man beim RE achten? Aus unterschiedlichen Praxiserfahrungen lassen sich die wichtigsten Risiken im RE ableiten [Ebert2014a]. Die Risiken zu kennen, heißt, dass man sich darauf vorbereiten kann, um sie beim nächsten Mal zu vermeiden. Die folgende Liste hatte ich ursprünglich mit weiteren sehr erfahrenen RE-Praktikern erstellt [Lawrence2001]. Sie wurde hier nochmals aktualisiert.
Häufig werden bestimmte Anforderungen übersehen, und es werden nur greifbare und nachvollziehbare Funktionen spezifiziert. Aber Anforderungen haben verschiedene Ausprägungen, wie wir gesehen haben. Neben den funktionalen Anforderungen gibt es Qualitätsanforderungen und Randbedingungen. Neben den Produktanforderungen gibt es auch Marktanforderungen und Komponentenanforderungen. Nur die Hinterfragung aller dieser Typen macht die Anforderungsdokumentation vollständig. Wichtig wird diese Vollständigkeit vor allem auch bei der Testspezifikation. Testfälle müssen alle diese Kategorien von Anforderungen abdecken.
Aus vertraglichen Gründen sollte man dem Kunden das liefern, was er will, und nicht das, was er braucht. Interpretieren Sie also nicht, was denn »passen könnte«, denn Sie kennen die Welt des Kunden und seine konkreten Bedürfnisse niemals so gut wie er selbst. Im Zweifelsfall zählt, was vertraglich abgestimmt wurde. Das ist vor allem dort wichtig, wo verschiedene Anspruchsträger auf Kundenseite mitwirken und wo wir Anforderungen priorisieren. Ein Lieferant sollte im Interesse einer nachhaltigen Kundenbeziehung im Vorfeld klären, was der Kunde wirklich braucht, um dann vor Projektbeginn eine Abstimmung zu erreichen zwischen dem, was gebraucht wird, und dem, was gewünscht und damit vertraglich festgehalten wird. Eine wirksame Basis für erfolgreiches Kundenmanagement ist es, zuallererst den Business Case des Kunden zu verstehen. Dabei geht es darum, zu erkennen, was der Kunde – anders – machen will, wenn er erst einmal das gewünschte Produkt in den Händen hält. Den Business Case zu verstehen bedeutet, dass man als Produkt- oder Projektmanager erkennt, welche Funktionen oder Anforderungen an das Projekt den größten Nutzen bringen.
Anforderungen sind grundsätzlich unvollständig und fehlerhaft. Sie sind unvollständig, da wir das System nicht in jedem Detail vorab spezifizieren können – und dies auch niemand bezahlen wollte. Sie sind fehlerhaft, weil bei jeder Arbeit Fehler entstehen.
Wir Menschen machen pro zehn Zeilen Text ungefähr einen inhaltlichen Fehler, den wir nicht sofort entdecken. Die Hälfte dieser Fehler entdecken wir bei einer Schlussdurchsicht – sofern wir uns die Zeit dafür nehmen. Die andere Hälfte bleibt im Dokument und muss durch zusätzliche Techniken aufgedeckt und behoben werden. Das ist gerade bei Anforderungen kritisch, denn viele Fehler werden erst spät bei Test und Abnahme des Produkts entdeckt, und dann sind Korrekturen aufwendig.
Typische Fehler sind sowohl handwerklicher Natur, wie vage und ungenaue Beschreibungen, Widersprüche, Inkonsistenzen, Lücken, als auch inhaltlicher Natur, wie Denkfehler, falsche Priorisierung, falsche Abstraktionen und Vermischung von Was und Wie.
Fehler entstehen durch nicht beherrschte Komplexität. Kunden, der Vertrieb und das Marketing spezifizieren Funktionen, die niemand braucht. Entwickler versuchen, Anforderungen, die sie vermeintlich verstanden haben, mit Leben zu füllen, und entwickeln so Funktionen, die nie vereinbart wurden. Branchenübergreifend ist ungefähr die Hälfte der gelieferten Funktionalität ohne Wert und wird dementsprechend kaum oder nie verwendet (Abb. 1-4). Das gilt für ein Fahrzeug genauso wie für eine Office-Software. Jede unnötige Funktion bringt Abhängigkeiten von anderen Funktionen, Sonderfälle, Ausnahmesituationen – und damit zusätzliche Entwicklungs-, Korrektur- und Testaufwände, die sich über die Lebensdauer mit jedem Release vervielfachen.
Prüfen Sie Anforderungen mit Reviews (siehe dazu auch Kap. 6). Nutzen Sie dazu Checklisten und Szenarien wichtiger Abläufe. Spielen Sie vor allem die Szenarien durch, mit denen Ihr Kunde Geld verdient oder die dem Benutzer später Schwierigkeiten machen, wenn sie nicht optimal funktionieren. Prüfen Sie, ob Abhängigkeiten oder Fehlerszenarien übersehen wurden. Wer macht diese Reviews? Im Bestfall ein Tester. Tester haben einen Blick für Fehlermöglichkeiten und entdecken in Reviews sehr viel mehr Fehler als Designer oder Projektmanager. Achten Sie auch darauf, dass die Anforderungen kundenseitig geprüft und formal freigegeben wurden.
Abb. 1-4Falsche Anforderungen erhöhen die Kosten.
Kontrollieren Sie Änderungen. Anforderungen, deren Änderungen nicht beherrscht werden, führen zu Kosten- und Terminüberschreitungen und reduzieren die Qualität. Anforderungen ändern sich in beinahe jedem Projekt. Die Änderungsrate hängt von verschiedenen Faktoren ab, beispielsweise vom Neuigkeitsgrad von Produkt und Technologie. Häufig existiert eine gewisse Basis von Anforderungen, mit denen ein Projekt gestartet wird. Einige Punkte sind noch offen und klären sich im Laufe der Zeit. Auftraggeber haben allerdings oftmals gar kein großes Interesse daran, diese Punkte zu klären. Erstens ist es Zusatzaufwand und zweitens könnte der Auftraggeber bei der Abnahme davon profitieren, wenn nicht alles so läuft wie abgesprochen, denn das ist die Chance, komplett neue Anforderungen als Kompensation für diesen Projektfehler kostenlos zu erhalten.
Kontrollieren Sie die Änderungsrate im Projekt. Zu bestimmten Meilensteinen muss die Änderungsmenge reduziert werden, um die nächste Phase erfolgreich durchlaufen zu können. Üblich ist es, mit einem Puffer zu arbeiten, der sowohl Schätzungenauigkeiten als auch Anforderungsänderungen abfangen kann. Eine weitere Maßnahme ist die sogenannte Rückwärtsplanung von der Übergabe aus zurück ins Projekt, um zu erkennen, ab wann der kritische Pfad keine Parallelarbeit als Puffer mehr zulässt. Als Regel gilt, dass in der zweiten Projekthälfte nur noch sehr wichtige Änderungen ohne große Auswirkungen zugelassen werden. Eine dritte Maßnahme ist schließlich, Änderungen grundsätzlich nur zu diskutieren, wenn eine Analyse der Auswirkungen stattgefunden hat. Andernfalls verschwenden beide Seiten ihre Zeit. In diesem »Spiel« wird gern gepokert, nur um zu sehen, wie sich der Lieferant verhält. Oftmals genügt der Verweis auf die Einflüsse im Projektplan, um zu zeigen, dass die vorgeschlagene Änderung Kosten und Projektdauer unzulässig erhöhen wird.
Klären Sie frühzeitig und verbindlich Verantwortungen und Rollen der Kunden bei der Projektarbeit. Unzureichende Einbeziehung der Benutzer schafft viele Risiken. Oft werden Anforderungen interpretiert, ohne den Kunden direkt einzubeziehen. Dann entwickelt sich das Projekt in zwei getrennte Richtungen, denn sowohl die Projektmitarbeiter als auch der Kunde lernen ständig dazu. Da der Kunde allerdings nicht weiß, wie er damit umgehen soll, wartet er ab. So wachsen die Divergenzen an, statt aufgelöst zu werden. Daraus hat sich das agile Prinzip »Kunde an Bord« entwickelt. Das kann jedoch auch schwierig werden, wenn kundenseitig nicht abgestimmte Anforderungen als Versuchsballons lanciert werden. Und die haben die Tendenz zu platzen. Viele Kunden haben sich nie zu Verantwortungen Gedanken gemacht. Abgestimmte Inhalte werden von uninformierten Kundenvertretern ständig neu hinterfragt und geändert.
Projekte scheitern wegen unzureichender Anforderungen. Abbildung 1-5 zeigt diesen Effekt, wie wir ihn bei einem Kunden beobachtet haben. Unzureichende Anforderungsqualität brachte dort nicht nur das Projekt in Schieflage, sondern reduzierte auch die Mitarbeitermotivation dramatisch, denn viele wussten nicht mehr, wie sie die sich ständig ändernden Vorgaben meistern sollten.
Abb. 1-5Unzureichende Anforderungen und die Konsequenzen
Diese drei Risiken sind nicht softwarespezifisch und unterstreichen die breite Anwendbarkeit des Requirements Engineering – egal ob IT, Medizin oder Maschinenbau. Branchenübergreifend ähneln sich die Herausforderungen: Anforderungen fehlen, sind falsch und ändern sich während des Projekts.
Beispiel:
Die Qualität der Anforderungen ist ein wesentlicher Erfolgsfaktor beim Projekterfolg. Eines der ersten kommerziellen Düsenflugzeuge, die Comet 1, hatte keine Anforderungen zu dynamischen Spannungen der Fenster – und stürzte sehr häufig ab. Die Tacoma-Narrows-Brücke hatte unzureichende Anforderungen und Lösungsmodelle bei der Berücksichtigung der Windlast – und stürzte ein. Beim Therac-25-Bestrahlungsgerät war die Benutzerschnittstelle fehlerhaft spezifiziert – und verursachte mehrere Todesfälle. Beim Bau der Ariane-5-Rakete wurden Anforderungen außerhalb des erlaubten Kontexts von Ariane 4 wiederverwendet, und die Rakete stürzte auf dem Jungfernflug ab. Die Liste könnte beliebig verlängert werden. Sie selbst haben bestimmt eigene Beispiele unzureichender Anforderungen. Achten Sie auf hinreichend gute Anforderungen!
Die systematische Umsetzung von RE erfordert Aufwand in der Entwicklung und an den Schnittstellen im Produktmanagement, Produktmarketing und Vertrieb. Häufig wird dieser Aufwand als zu hoch und zu zeitraubend angesehen. Aus unserer Beratungspraxis kennen wir das Dilemma: Verbesserungen in Methodik, Ausbildung und Werkzeugen werden nicht angegangen, da der Anfangsaufwand, um diese Verbesserungen anzustoßen, als zu hoch betrachtet wird.
Systematisches RE hat einen klaren Nutzen und ROI, den wir hier zeigen. Einige dieser Faktoren, wie Termintreue oder weniger Nacharbeiten, schaffen einen unmittelbar greifbaren Nutzen. Andere, wie beispielsweise die Kundenzufriedenheit, werden in Form nachhaltig guter Kundenbeziehungen und weiterer Projekte greifbar Die folgenden Daten stammen aus der Vector Benchmark Datenbank sowie verschiedenen Metastudien zum Effekt von RE [Hussain2016, Standish2018, Gartner2018, Ebert2007, Standish2003, Terzakis2013]:
50 % aller Funktionen werden nie verwendet. Diese Zahl gilt branchenübergreifend als Richtwert. Wenn einige dieser sowieso eher unnötigen Funktionen frühzeitig erkannt und nicht entwickelt werden, reduziert das die Komplexität und Kosten. RE richtet den Fokus auf das Wesentliche, sorgt für eine klare Positionierung des Produkts und seiner Alleinstellungsmerkmale und schafft damit auch die Gewissheit, dass alle Anspruchsträger am gleichen Strang ziehen.
80 % der Fehler im Test und 43 % der Feldfehler resultieren aus unzureichendem RE. Diese Fehlerkosten werden durch ein besseres RE direkt reduziert – der Umfang hängt natürlich davon ab, wie Sie die Schwerpunkte setzen.
Typischerweise werden 2–5 % des Aufwands in das RE investiert. Eine Verdoppelung reduziert die Lebenszykluskosten um typischerweise 20–40 %. Die Gründe dafür sind frühe Fehlerentdeckung, frühe Korrektur unzureichender Anforderungen, Fokus auf Erweiterbarkeit etc. Werden die Anforderungen so umgesetzt, wie sie vom Kunden oder Benutzer beschrieben werden, reduziert das die Nacharbeiten, die im Schnitt 45 % des Projektaufwands ausmachen.
Typischerweise werden 30–50 % des Entwicklungsaufwands für die Fehlerbehebung und nicht entwicklungsbezogene Aktivitäten eingesetzt. Die Hälfte der Fehler ist das direkte Ergebnis unzureichender Anforderungen und unkontrollierter Änderungen. Im Systemtest sind es 80 % der Fehler, die aus unvollständigen (31 %) oder falschen (49 %) Anforderungen resultieren. Die Wiederverwendung von Anforderungen und davon abgeleiteten Arbeitsergebnissen (z.B. Mechanismen zur Systemsicherheit) schafft weitere Produktivitätsgewinne, insbesondere bei Produktvarianten.
Verbesserte Projektplanung und Ressourceneinteilung, weniger Verzögerungen vor dem Projektstart, eine schnellere Anlaufphase sowie Termintreue aufgrund von bekannten Anforderungen und klaren Verantwortungen im Projektteam und im Vertrieb reduzieren Wartezeiten sowie Terminverzug. Mehr Aufwand für die Entwicklung und die konsequente Umsetzung und das konsequente Testen der Anforderungen schaffen eine Verbesserung der Termintreue und reduzieren Verzögerungen auf unter 20 %.
Insgesamt zeigen unsere Erfahrungen, dass eine Verdoppelung des Aufwands für RE hin zu 10 % des Projektaufwands in den Bereichen Methodik, Prozesse, Training und Werkzeugunterstützung einen konkret realisierbaren Projektnutzen von über 20 % schafft. Das ist ein ROI von mehr als 4, und bei diesem Wert sind nur die direkt messbaren Vorteile berücksichtigt.
Abb. 1-6Effizienzpotenzial mit systematischem Requirements Engineering
Die umfassendste Untersuchung zum Nutzen von RE stammt von Alcatel (heute Nokia). Über mehrere Jahre hinweg wurden in einer longitudinalen Feldstudie unterschiedliche Projektdaten systematisch erfasst und analysiert (Abb. 1-7) [Ebert2006].
Gute Termintreue wird nur dann erreicht, wenn die vier folgenden Techniken gleichzeitig umgesetzt werden. Wurde nur einer dieser Faktoren vernachlässigt, führte das sofort zu Terminverzug:
Abb. 1-7Der gleichzeitige Einsatz von vier Requirements-Techniken verbessert den Projekterfolg.
Eine weitere umfassende Studie zum Nutzen von RE in Entwicklungsprojekten kommt von der NASA (Abb. 1-8) [Hooks2001]. Im Unterschied zu den beiden vorigen Studien wurde hier die Kosteneinhaltung in Abhängigkeit vom Aufwand für RE untersucht. Projekte mit 5 % Aufwand für RE führen zu einer Kostenüberschreitung von 80 % bis knapp 200 %. Wird dieser Aufwand in Richtung 8–14 % verdoppelt, liegt die Kostenüberschreitung bei unter 60 %. Offensichtlich sind IT-Projekte sehr anfällig für eine unzureichende Anforderungsanalyse und -spezifikation, denn die Anforderungen werden sich im Projektverlauf zunehmend ändern und zu beträchtlichen Zusatzaufwänden führen. Auch hier gilt, dass die absoluten Zahlen für Überschreitungen von Kosten natürlich durch viele Faktoren bestimmt werden. Aber ein unzureichendes RE hat einen starken Anteil an überbordenden Kosten. Intel hat in einer aktuellen Langzeitstudie gezeigt, dass systematisches RE die Zahl der Fehler im Produkt um 30–50 % senkt [Terzakis2013].
Abb. 1-8Kosteneinhaltung in Abhängigkeit vom Aufwand für das Requirements Engineering
Viele Projekte geraten in Schwierigkeiten, da anfangs zu wenig Energie investiert wird und später in der »heißen« Phase die Zeit fehlt, um nachzudenken. Aufwendige Nacharbeit ist nun nötig, um Fehler und Entscheidungen zu korrigieren, die in der Startphase des Projekts viel leichter aufzulösen gewesen wären. Andere müssen Kapazität abgeben, um die jetzt dringend nötige Überlast abzudecken. Dieser Teufelskreis lässt sich nur durch frühzeitige Planung und kontinuierliches Requirements Engineering durchbrechen. Das wird als »Frontloading« bezeichnet und bedeutet, dass Projektaufgaben frühestmöglich erledigt werden, um Nacharbeiten und damit Terminverzug zu vermeiden. Abbildung 1-9 zeigt in der oberen Hälfte ein typisches Projekt. Anfangs wird zu wenig Energie in Requirements Engineering und Planung investiert.
Abb. 1-9Frühzeitige Lastbalance durch Frontloading
Daraus resultieren Nacharbeiten und die Kannibalisierung nachfolgender Projekte. Zudem führt die kontinuierliche Überlast in der »heißen Phase« zu Demotivation der Mitarbeiter. Die untere Hälfte in der Abbildung zeigt den Effekt des »Frontloading« mit systematischem Requirements Engineering. Anforderungen werden frühzeitig ermittelt und das Projekt wird realistisch geplant. Aufwände werden über einen größeren Zeitraum verteilt und erlauben ein agiles Arbeiten mit inkrementellen Lieferungen. Auswirkungen auf Folgeprojekte werden vermieden.
Dies ist ein Buch für Einsteiger und Profis. Nach der Lektüre
Abbildung 1-10 zeigt die Struktur des Buches. Das Thema RE wird zunächst anhand verschiedener Übersichtskapitel eingeführt. Kapitel 2 führt kurz und knapp in das Requirements Engineering ein und zeigt den Nutzen in der Praxis, aber auch die Risiken, wenn es nicht ausreichend gelebt wird. Die Kapitel 3 bis 8 beleuchten die einzelnen Aktivitäten innerhalb des RE systematisch. Kapitel 3 beschreibt, wie Anforderungen ermittelt werden. Der Nutzen und Wert aus der Sicht desjenigen, der bezahlt, steht im Vordergrund, denn das ist die wesentliche Basis für jedes erfolgreiche Projekt. Kapitel 4 betrachtet die Dokumentation, also das Beschreiben von Anforderungen. Dabei geht es um die Verbesserung der Anforderungsqualität und verschiedene formale Arten der Beschreibung, die hinsichtlich ihrer Praktikabilität und Schwierigkeit in der Umsetzung diskutiert werden.
Die relevanten Analyse- und Modellierungstechniken werden in Kapitel 5 eingeführt. Ein durchgängiges Beispiel erlaubt eine gute Vergleichbarkeit der Techniken und ihres Nutzens. Kapitel 6 zeigt, wie qualitativ gute Anforderungen erreicht werden. Wir zeigen hier Techniken zu Reviews, Prüfungen und konkrete Checklisten, um die Anforderungsqualität zu verbessern. Kapitel 7 unterstreicht die Abstimmung von Anforderungen mit den verschiedenen Anspruchsträgern. Das Kapitel betrachtet auch rechtliche Zusammenhänge, beispielsweise Gewährleistungs- und Haftungsfragen. Schließlich beschreibt Kapitel 8 Techniken, um Anforderungen im Projekt zu kontrollieren und zu verwalten.
Abb. 1-10Das Buch im Kontext des Requirements Engineering (Schwarze Kreise sind Kapitelnummern.)
Kapitel 9 ist komplett neu und beschreibt agiles Requirements Engineering. Wir gehen auf Methoden wie Design Thinking, Planning Poker und testorientiertes RE ein. Werkzeuge werden in Kapitel 10 charakterisiert und bewertet. Wir beschreiben einige populäre RE-Werkzeuge ganz praxisnah in unterschiedlichen Szenarien. Die Praxis des RE wird in Kapitel 11 dargestellt. Damit sehen Sie den praktischen Nutzen und die Abhängigkeiten der einzelnen Schritte im RE. In Kapitel 12 möchte ich Ihnen zeigen, wie Sie Ihre eigene Kompetenz ausbauen können. Das umfasst fachliche Kompetenzen und Soft Skills. Das abschließende Kapitel 13 fasst den Stand der Technik zusammen und beleuchtet die wichtigsten Trends des RE in den nächsten Jahren. Hier werden auch die empirischen »Gesetzmäßigkeiten« des RE nochmals an einer Stelle zusammengefasst.
Abgerundet wird das Buch durch eine Zusammenstellung von Internetressourcen, also den wichtigsten URLs zum Thema RE. Alle Begriffe, die im Buch definiert werden oder auf deren Definitionen zurückgegriffen wird, sind im Glossar am Ende des Buches nochmals zusammengefasst. Eine Zusammenstellung der Literaturquellen sowie ein Index beschließen das Buch.
Jedes der Kapitel besitzt am Ende einige Checklisten sowie konkrete Fragen an die Praxis. Damit können Sie das gerade Gelesene in Ihrem eigenen Kontext reflektieren und leichter umsetzen. Es handelt sich hier nicht um die Art von Verständnisfragen, die Sie aus Lehrbüchern kennen, sondern um Fragen, die Ihren eigenen Horizont erweitern, um das gerade konsumierte Wissen verdauen und umsetzen zu können. Damit erhalten Sie unmittelbar nutzbare Impulse für Ihre eigenen Projekte. Praxisbeispiele und Tipps dazu sind direkt im Text eingebettet und farblich hervorgehoben:
Beispiel:
Konkrete Beispiele aus meiner Arbeit in ganz verschiedenen Unternehmen und Branchen zeigen, wie die Techniken des Requirements Engineering in die Praxis umgesetzt werden. Die meisten Beispiele sind zum Nachmachen gedacht. Manche dienen zur Abschreckung und sind dann auch so charakterisiert. Das Buch hat eine eigene Webseite www.requirements-excellence.com, die auch auf Vorlagen, White Papers und Fallstudien verweist.
Wenn Sie als Entwickler oder Ingenieur
