Systematisches Requirements Engineering E-Book

Christof Ebert

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2022

Seitenzahl: 645

Beschreibung

Das umfassende Handbuch zum Requirements Engineering

• eingeführtes Standardwerk nun in 7. Auflage!
• hoher Praxisbezug
• direkt anwendbare Checklisten und Praxistipps

Dieses Buch beschreibt praxisorientiert und systematisch das Requirements Engineering vom Konzept über Analyse und Realisierung bis zur Wartung und Evolution eines Produkts.

Requirements Engineering mit seinen Methoden, Modellen, Notationen und Werkzeugen wird eingeführt. Ein durchgängiges Beispiel sowie viele industrielle Praxiserfahrungen illustrieren die Umsetzung. Direkt anwendbare Checklisten und Praxistipps runden jedes Kapitel ab. Lesen Sie das Buch, um

– Requirements Engineering kennenzulernen,
– Ihre Projekte und Produkte erfolgreich zu liefern,
– agile Entwicklung beispielsweise mit testorientierten Anforderungen umzusetzen,
- industrieerprobte Techniken des Requirements Engineering produktiv zu nutzen.

Diese 7. Auflage wurde in vielen Aspekten aktualisiert und berücksichtigt den aktuellen Lehrplan des IREB®-Zertifizierungsprogramms.

Leseprobe

Christof Ebert ist Gründer und Geschäftsführer von Vector Consulting Services. Er unterstützt Unternehmen bei Strategie, Technologie und agiler Transformation. Zuvor war er zwölf Jahre bei einem IT-Konzern in weltweiten Führungsaufgaben tätig. Er arbeitet in Aufsichtsgremien von Unternehmen und stimuliert Start-ups als Business Angel. An der Universität Stuttgart und der Sorbonne in Paris ist er Professor und hält Patente in Softwaretechnik und AI. Er wirkt in den Herausgeber-Komitees von IEEE Software, Software Quality Journal und dem Journal of Systems and Software. In seiner Freizeit spielt er als Musiker Keyboard und Kirchenorgel und engagiert sich im sozialen Bereich.

Folgen Sie ihm auf Twitter und LinkedIn: @ChristofEbert.

Kontakt: [email protected], www.christofebert.de

Homepage des Buches: www.requirements-excellence.com

Copyright und Urheberrechte:Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Christof Ebert

SystematischesRequirementsEngineering

Anforderungen ermitteln, dokumentieren, analysieren und verwalten

7., überarbeitete und aktualisierte Auflage

Christof Ebert

[email protected], www.christofebert.de

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Layout & Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.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:

Print

978-3-86490-919-1

PDF

978-3-96910-768-3

ePub

978-3-96910-769-0

mobi

978-3-96910-770-6

7., überarbeitete und aktualisierte Auflage 2022

Copyright © 2022 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

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.

Vorwort zur 7. Auflage

Wer immer tut, was er schon kann, bleibt immer das, was er schon ist.

Henry Ford

Wie kaum ein anderer reüssierte Henry Ford als Ingenieur und Unternehmer. Er rüttelt uns mit seinem Weckruf auf – gerade jetzt im neuen Normal. Viele haben die Pandemie als willkommene Entschuldigung benutzt, sich zu Hause einzuigeln und zu stagnieren. Manche hoffen selbst heute noch auf die Rückkehr in frühere Zeiten. Damit sind wir gerade in einem Hochlohnland nicht wettbewerbsfähig. In den Worten des großen Aufklärers Immanuel Kant müssen wir heraus aus der selbstverschuldeten Unmündigkeit. Das Buch zeigt, wie Sie Anforderungen setzen und verfolgen. Denn im neuen Normal ist Neues normal. Anforderungen sind dafür die Basis.

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. 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.

Mit diesem Buch bekommen Sie alles für gutes Requirements Engineering. Branchenübergreifend – von der Konzeption bis zur Evolution. Es ist aus der Praxis für die Praxis geschrieben und zeigt Ihnen, wie Sie Wert für sich und Ihr Unternehmen schaffen – und erhalten. Es adressiert Requirements Engineering für unterschiedliche Anwendungsbereiche, sei es agile Entwicklung versus formale Vorgehensweise für komplexe Projekte.

Diese 7. Auflage unterstreicht agiles Requirements Engineering, testorientierte Anforderungen, Systems Engineering und aktuelle Trends. Sie enthält viele neue Abbildungen und ein komplett überarbeitetes Glossar. Mit aktualisierten Beispielen wird die Rolle des Requirements Engineering im Projekt gezeigt. Das Buch berücksichtigt den aktuellen Lehrplan des IREB-Zertifizierungsprogramms. Die URL-Verweise sind aktualisiert. Alle Templates sind online verfügbar. So bleibt diese Neuauflage für alle Lesenden eine wichtige Referenz auf dem Schreibtisch.

Die meisten Projekte umfassen Änderungen existierender Systeme. Das Buch adressiert diese Situation und bewegt sich nicht akademisch auf der »grünen Wiese«. 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 können Sie zielorientiert eigene Herausforderungen adressieren. 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 Mitarbeitende und Kundenunternehmen von Vector Consulting, mit denen wir die genannten Praktiken umsetzen und ständig verbessern. Hervorheben möchte ich Frank Kirschke-Biller und Arnold Rudorfer, die mich in den Fallstudien bei Ford und Siemens unterstützten. Immer wieder erhalte ich Verbesserungsvorschläge von Lesenden. Danke dafür! Für bessere Lesbarkeit verwende ich dudengerechte Formen. Danke schließlich an Christa Preisendanz und den dpunkt.verlag für die gewohnte Professionalität.

Mein Freund Al Davis hatte mich als damaliger Chefredakteur von IEEE Software dazu angeregt, Requirements Engineering systematisch und dennoch agil (!) in der Industrie zu verankern. Dank an Al und die vielen, die dieses Thema in der Praxis antreiben, wie Ian Alexander, Anthony Finkelstein, Don Gause, Michael Goedicke, Martin Glinz, Matthias Jarke, Neil Maiden, Barbara Paech, Klaus Pohl, Mary Popendieck, Charles Symons, Suzanne Robertson, Ian Sommerville und Karl Wiegers.

Ihnen, liebe Leserinnen und Leser, wünsche ich viel Erfolg bei allem, was Sie neu anpacken! Dieses Buch gibt Ihnen mit lösungsorientiertem Denken die nötigen Impulse, um Ziele richtig offensiv anzugehen.

Christof EbertStuttgart, 22.2.22

Stimmen zum Buch

»… 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 ProfessorUniversity of Colorado, Colorado Springs

»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 MackChief Technology Officer, Vodafone

»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 RobertsonGründerin und Principal. The Atlantic Systems Guild Ltd.

»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 Leibbrandehem. 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 LiggesmeyerDirektor Fraunhofer IESE, ehem. Vorsitzender der Gesellschaft für Informatik

Inhaltsübersicht

1Motivation

2Requirements Engineering – kurz und knapp

3Anforderungen ermitteln

4Anforderungen dokumentieren

5Anforderungen modellieren und analysieren

6Anforderungen prüfen

7Anforderungen abstimmen

8Anforderungen verwalten

9Agiles Requirements Engineering

10Werkzeuge

11Requirements Engineering leben

12Soft Skills und persönliche Entwicklung

13Stand der Technik und Trends

Anhang

AInternetressourcen

BGlossar

CLiteratur

Index

Inhaltsverzeichnis

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.6Terminologie

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.3Stakeholder 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.3Systems Engineering und Architektur

5.4UML, 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.4Test-Driven Requirements Engineering (TDRE)

6.5Kriterien für Testende und Abnahme

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.3Verfolgbarkeit (Traceability)

8.4Wartung und Altsysteme

8.5Versionierung und Varianten von Anforderungen

8.6Kennzahlen und KPI

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: Agiles Systems Engineering bei Ford

9.7Fallstudie: Agiles RE bei Siemens

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.5Serviceorientiertes RE

11.6Fallstudie: Funktionsmodellierung und Produktlinien

11.7Fallstudie: Besseres RE in 10 Schritten

11.8Tipps für die Praxis

11.9Fragen und Impulse

12Soft Skills und persönliche Entwicklung

12.1Aufgaben des »Requirements Engineer«

12.2IREB und Zertifizierung

12.3Soft Skills

12.4Konflikte lösen

12.5Tipps für Ihre persönliche Entwicklung

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 Software

13.5Trends im Requirements Engineering

13.6Top-10-Tipps

Anhang

AInternetressourcen

BGlossar

CLiteratur

Index

1Motivation

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.

1.1Warum ein Buch über Requirements Engineering?

Das Problem vieler Unternehmen ist, dass zu viele Funktionen verkauft werden, und zu wenig Wert. Oft zerbrechen wir uns 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 und können deren Wert nicht darstellen. Wir optimieren und bemühen uns ständig, bessere Produkte zu entwickeln – und fühlen uns doch 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.

Zeig mir deine Anforderungen und ich sage dir, wie dein Projekt endet. So lautet eine alte Weisheit, und wir wollen sie hier gleich mal anwenden.

Abbildung 1–1 zeigt ein typisches Beispiel einer Anforderung. Sie ist in Prosa, weil das vermeintlich verständlicher ist, und wirft mehr Fragen auf, als sie beantwortet:

Wie hängen diese unstrukturierten Funktionen zusammen?

Bringt die Anforderung Kundennutzen und damit Profit?

Kann die Anforderung umgesetzt werden?

Wie ist der Status der Anforderung?

Wer ist für die Anforderung verantwortlich?

Wie wird die Anforderung validiert?

Wie wird die Anforderung umgesetzt?

Abb. 1–1Eine Anforderung – so viele Fragen

Software wird 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 Beispiel für hausgemachte Komplexität sind IT-Migrationsprojekte. Die Stakeholder, manchmal eingedeutscht als »Interesseneigner«, sind sich oft schnell darin einig, dass alle Funktionen des existierenden Altsystems übertragen werden müssen. Das ist ein großer 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. Komplexität ist der Feind jeder Innovation. Neues entsteht nur durch Weglassen von Ballast, wie wir von Unternehmen wie Apple oder Tesla lernen können. 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.

1.2Projekte scheitern wegen unzureichender Anforderungen

Zu viele Projekte scheitern, und Produkte erreichen die Marktziele nicht. Unzureichendes Requirements Engineering ist immer unter den Top-3-Ursachen. Die 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) [Standish2021]. RE erhält im Schnitt nur 2–5 % des Projektaufwands, aber Fehler in den Anforderungen haben die größten Effekte [Gartner2022, Lauesen2020, Standish2021, Charette2018, Garousi2019, Ebert2014a, Ebert2007].

Abb. 1–3Unzureichendes Requirements Engineering reduziert den Projekterfolg.

Ein wesentlicher Grund für Projektscheitern sind unklare Ziele. 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 offensichtliche Allgemeinplätze.

Beispiel:

Viele Projekte scheitern, weil man versucht, die Interessen aller Stakeholder zu berücksichtigen, statt klare Ziele und Führung einzusetzen [Lauesen2020]. Aktuelle Beispiele sind die elektronische Patientenakte in Deutschland (ePA) oder die amerikanische Gesundheitsversicherung. 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, regte aber politische Gegner an, das gesamte Programm zu hinterfragen. Die Mehrkosten der IT lagen im Bereich von knapp 500 Mrd. US$. Die Gründe für das Scheitern waren zu viele Stakeholder, die mitwirkten, sich starkändernde Anforderungen, eine unzureichende Validierungsstrategie und ein monolithisches System, das ungeeignet für Teillösungen und inkrementelle Änderungen war.

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:

Unbrauchbare Lastenhefte und Ausschreibungen (z.B. oberflächlich und missverständlich beschriebene Anforderungen)

Implizite Anforderungen (Beispiel: Kunde erwähnt Funktionen nicht, da sie für ihn selbstverständlich sind, aber der Lieferant weiß das nicht.)

Fehlende Anforderungen (z.B. schwammige Anforderungen, die zwar nötig sind, aber nicht geklärt werden, da sie teuer werden könnten; unklare Ausrichtung des Projekts: Was wird nicht geliefert?)

Unsicherheiten und Unklarheiten (Beispiel: Schätzungen und Pläne basieren auf nicht verstandenen Risiken und oberflächlich dokumentierten Anforderungen.)

Unzureichendes Änderungsmanagement (Beispiel: Kunde meldet sich beim Projektmanager oder Entwickler: »Wir brauchen das und das noch.«)

Inkonsistente Dokumentation (Beispiel: Testfälle setzen auf einer anderen Basis auf als die Entwicklung.)

Varianz und Komplexität (z.B. Mehrfachentwicklungen, die in der Codebasis später inkonsistent werden und einzeln verfolgt werden müssen)

Fehlendes Wissensmanagement (Beispiel: Projektmanager übernimmt neues Kundenprojekt und hat nicht das implizite Wissen zum Kunden und dessen Hintergrund.)

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:

Ergebnisorientierte Vorgaben

Zielorientierte Prozesse

Kompetentes Produkt- und Projektmanagement

Standardisierte und optimierte Infrastruktur

Agile Entwicklung

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 ist bis heute gültig und nur inhaltlich etwas aktualisiert.

Risiko 1: Fehlende Anforderungen

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 Stakeholder 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.

Risiko 2: Falsche Anforderungen

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 [Pendo2019]. 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–4Klasse statt Masse: Häufigkeit der Nutzung von Requirements

Risiko 3: Sich ändernde Anforderungen

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 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. 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 Motivation 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!

1.3Wirtschaftlicher Nutzen und Return on Investment (ROI)

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 sichtbar. Die folgenden Daten stammen aus der Benchmark-Datenbank von Vector sowie verschiedenen Metastudien zum Effekt von RE [Hussain2016, Standish2021, Gartner2022, Ebert2007, Standish2003, Terzakis2013]:

Wertorientierung

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 Stakeholder am gleichen Strang ziehen.

Qualität

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.

Kostenreduzierung

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.

Produktivitätsverbesserung

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.

Kürzere Durchlaufzeiten

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 (Abb. 1–6). 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) [Ebert 2006].

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:

Ein verantwortliches Kernteam, bestehend aus Produktmanagement, Marketing, Entwicklung und Produktion, das das gesamte Projekt (oder das Produktrelease) steuert

Konsequente Nutzung eines definierten Lebenszyklus mit Meilensteinen, Checklisten etc.

Transparenz aller Projektvereinbarungen (z.B. Anforderungen) im Intranet

Gemeinsame Anforderungsanalyse durch das Kernteam mit Produktmanagement, Marketing, Entwicklung und Produktion

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) [Hooks2000]. 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. 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.

1.4Wie Sie von diesem Buch profitieren

Dies ist ein Buch für Einsteiger und Profis. Nach der Lektüre

haben Sie einen Überblick über Theorie und Praxis des Requirements Engineering;

verstehen Sie, wie moderne Werkzeuge und Notationen Sie beim Requirements Engineering praktisch unterstützen können;

können Sie die wichtigen Elemente des Requirements Engineering in Ihren Projektalltag übertragen und dort produktiv einsetzen.

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 beteiligten Gruppen. 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 beinhaltet 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 aufgeführt. 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 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.

Entwicklern, IT-Spezialisten und Ingenieuren gibt dieses Buch einen guten Überblick zu den relevanten Fragestellungen und Lösungen des Requirements Engineering. Praktische Tipps am Ende jedes Kapitels helfen Ihnen dabei, essenzielle Vorgehensweisen schnell und »leicht verdaulich« zu extrahieren. Die Techniken sind praxiserprobt und leicht umsetzbar.

Selbstständige und Freelancer lernen praxisnah die wichtigsten Grundlagen, die eine oft überlebensnotwendige Rolle spielen. Beispielsweise braucht auch ein kleines Projekt ein funktionierendes Änderungsmanagement, um zu verfolgen, welche Anforderungen im Moment akzeptiert sind und welche sich noch in der Pipeline befinden.

Als Projektmanager und Qualitätsmanager finden Sie eine Menge wertvoller Tipps und lernen, wie Requirements Engineering konkret implementiert wird und wie Risiken und typische Schwierigkeiten im Requirements Engineering gehandhabt werden können.

Sind Sie kreativ in anderen Branchen, ohne überhaupt Software zu betrachten, beispielsweise als Bauingenieur? Das Buch hilft überall dort, wo Anforderungen systematisch ermittelt und umgesetzt werden sollen. Die hier vorgestellten Methoden und Prozesse sind nicht spezifisch für Software und IT, sondern universell für Produkte und Dienstleistungen einsetzbar.

Als Requirements-Ingenieur, Analyst, Systemanalyst oder Produktmanager zeigt Ihnen das Buch, wie Sie erfolgreich eine Brücke zwischen den unterschiedlichen Sichtweisen verschiedener Stakeholder bauen können. Zielkonflikte sind normal und tragen zu besseren Lösungen bei. Wir unterstützen Sie mit Methoden und Tipps, um Ziele und Perspektiven herauszuarbeiten und auf Grundlage dieser Erkenntnisse die richtige Balance von Anforderungen umzusetzen.

Agile Coaches und Berater lernen aus dem Buch, sowohl methodisch als auch in Praxisbeispielen und Fallstudien, wie agile Methoden im Requirements Engineering erfolgreich umgesetzt werden.

Neulinge und Studierende werden von den ersten Kapiteln stark profitieren, denn dort verknüpfen wir das Requirements Engineering mit der Softwaretechnik. Fragen am Ende jedes Kapitels helfen dabei, sich selbst zu prüfen und zu erkennen, ob die relevanten Themen auch im Kontext verstanden wurden.

Forschende finden viele aktuelle Herausforderungen aus der Praxis – und die passenden Ansätze zu möglichen Lösungen. Zudem liefert das Buch eine Menge Praxiserfahrungen, die bei der Gestaltung empirischer Studien helfen. Sauber dokumentierte Quellen, die in der aktuellen Neuauflage komplett überarbeitet wurden, machen das Buch als Referenz wertvoll.

Einsteiger und erfahrene Praktiker finden sich durch die klare Struktur sofort zurecht. In jedem Kapitel werden zu Beginn wichtige Themen zusammengefasst. So wissen Einsteiger, was gemeint ist, und können sich orientieren, während Profis sofort in die Tiefe gehen und das finden können, was ihre derzeitige Situation gerade verlangt.

1.5Selbsttest

Der folgende Test hilft Ihnen, Risiken im Requirements Engineering zu erkennen, zu bewerten und zu konkretisieren. Die Messlatte ist Ihr Erfolg mit Projekten, Produkten und Kunden. Das Ergebnis ist ein detailliertes Stärken- und Schwächenprofil, das anzeigt, auf was Sie sich im Requirements Engineering konzentrieren sollten. Damit haben Sie einen Startpunkt für eigene Verbesserungen. Sie müssen entscheiden, was für Sie wichtig ist, und dann mit den Änderungen beginnen.

Führen Sie den Test allein und für Ihre eigene spezielle derzeitige Situation durch. Nehmen Sie relevante aktuelle Projekte, um eine repräsentative Antwort zu erhalten. Beantworten Sie alle Fragen aus der Perspektive des Projektmanagers. Bitte geben Sie auf alle Fragen die aktuelle Situation an, keinen Sollzustand oder kein Wunschdenken. Falls das Projekt gerade erst aufgesetzt wurde, beantworten Sie die Fragen basierend auf Ihrer Erfahrung und Intuition.

Der Test besteht aus verschiedenen Fragen, die Sie anhand einer Punkteskala bewerten:

3 Punkte: Ja, vollständig, da bin ich mir sicher.

2 Punkte: Davon gehe ich doch aus, und ich habe es bereits gesehen.

1 Punkt: Fragwürdig, das kann ich mir nicht richtig vorstellen.

0 Punkte: Nein, gar nicht!

Zählen Sie nun die Punkte zusammen. Falls Sie <30 Punkte haben, ist Ihre wesentliche Herausforderung, ein Projekt abschließen zu können und am Markt wettbewerbsfähig zu bleiben. Zwischen 30 und 50 Punkten liegen durchschnittliche Projekte mit durchschnittlichen Ergebnissen. Das heißt, Sie werden zu spät und über Budget liefern. Sie haben einiges Potenzial für Verbesserungen. Falls Sie auf über 50 Punkte kommen, haben Sie das Requirements Engineering im Griff – oder vielleicht doch Wunsch und Realität etwas vermischt. Sie sollten nun auf Optimierung schauen, beispielsweise um Kosten zu reduzieren, Qualität zu verbessern und Komplexität zu beherrschen. Der Test gibt Ihnen Ansatzpunkte und Impulse, um sofort zielorientiert durchzustarten.

1.6Ein Blick über den Tellerrand

Dieses Buch unterstützt die systematische und zielorientierte Umsetzung von RE in der Praxis. Es ist kein theoretisches Grundlagenwerk. Wir empfehlen daher zur Vertiefung einige weitere Bücher.

Die Softwaretechnik, deren Vorgehensweisen und Managementprinzipien sind im Buch von Helmut Balzert beschrieben [Balzert2023]. Das Buch stellt die relevanten Managementtechniken und Vorgehensmodelle vor und beschreibt, wie verschiedene Modelle in der Praxis eingesetzt werden. Verschiedene Schwerpunktthemen, wie strategisches Management in der IT und globale Softwareentwicklung, verdeutlichen die heutige Ausrichtung der Softwaretechnik.

Die formalen Grundlagen des RE beschreibt Klaus Pohl sehr ausführlich [Pohl2008]. Für die Praxis des Requirements Engineering mit Beispielen und Fallstudien empfehle ich die Bücher von Suzanne Robertson und Karl Wiegers [Robertson2012, Wiegers2013]. Eine Vertiefung der Notationen UML und SysML ist in [Weilkiens2014] zu finden. Agiles Requirements Engineering hat Al Davis übersichtlich und praxisnah dargestellt [Davis2005]. Er beschreibt eindrucksvoll, wie man Projekte und Produkte so anpackt, dass »hinreichend gute« Ergebnisse erzielt werden, ohne viel Overhead zu erzeugen.

An verschiedenen Stellen des Buches unterstreichen wir, dass RE als Disziplin so spannend und in der praktischen Software- und Systementwicklung so ungemein wichtig ist, weil man mit Menschen arbeitet und gemeinsam zielorientiert die Grundlagen für immer wieder neue Produkte und Geschäftserfolge schafft. Dazu braucht es sehr viel mehr als die Beherrschung von Notationen und Werkzeugen. Es geht um die Fähigkeit, mit anderen Menschen gemeinsam erfolgreich zu sein. Dazu gehören »Soft Skills für Softwareentwickler«, die im Buch von Vigenschow und Kollegen [Vigenschow2019] dargestellt sind. Ebenso empfehlen möchte ich das Buch von Elisabeth Schick zum »Ich-Faktor«. Es ist flott und einprägsam geschrieben und zeigt, wie man auf andere wirkt und wie man diese Wirkung selbst verbessern kann [Schick2010]. Nutzen Sie das Buch, um sich selbst ganz gezielt weiterzuentwickeln.

2Requirements Engineering – kurz und knapp

Ihr Nutzen aus diesem Kapitel:

»It isn’t that they can’t see the solution. It is that they can’t see the problem.« Der berühmte Autor Gilbert Keith Chesterton adressierte damit eine wesentliche Herausforderung. Requirements Engineering identifiziert systematisch Probleme und Ziele – bevor Lösungen vorschnell entwickelt werden. Was sollten Sie für die eigene Praxis direkt übernehmen? Welche Faustregeln helfen, um das Requirements Engineering richtig zu justieren? Worauf sollten Sie in Ihren Projekten achten? In diesem Kapitel fasse ich kurz die wichtigsten Gesetzmäßigkeiten des Requirements Engineering zusammen. Systematik heißt nicht Formalismus oder gar Dogmatismus, sondern muss sich pragmatisch auf vorliegende Probleme einstellen. Zunehmend arbeiten wir im RE agil, also flexibel und situativ. Daher zeige ich hier die Essenz des Requirements Engineering. Sie lernen, was Anforderungen sind, wie verschiedene Typen von Anforderungen ganz verschieden auf das Projekt wirken und wie Sie Requirements Engineering leben können. Ein durchgängiges Beispiel transportiert das Vorgehen immer wieder in der Praxis.

2.1Was ist eine Anforderung?

Eine Anforderung beschreibt, was der Kunde oder Benutzer vom Produkt erwartet, also Bedingungen, Attribute, Ziele und vor allem Nutzen. Anforderungen sind definiert als:

Eine Eigenschaft oder Bedingung, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.

Eine Eigenschaft oder Bedingung, die ein System oder eine Systemkomponente erfüllen muss, um einen Vertrag, eine Norm oder andere, formell vorgegebene Dokumente zu erfüllen.

Eine dokumentierte Repräsentation einer Eigenschaft oder Bedingung wie in den ersten beiden Punkten beschrieben.

Wenn wir hier von Produkt sprechen, umfasst dies Anwendungen, IT-Systeme, eingebettete Software bis hin zu großen IT-Lösungen. Auch Dienstleistungen sind Produkte. Die Benutzer oder Anwender des Produkts sind diejenigen, die nach der Auslieferung damit in irgendeiner Form in Berührung kommen. Wir wollen dieses »in Berührung kommen« später nochmals aufgreifen (siehe Kap. 3), denn es ist bei der Ermittlung von Anforderungen wichtig, hier die Basis nicht zu sehr einzuschränken. Beispielsweise ist es relevant, zu unterscheiden, wer exakt Kunde ist (also vertraglich in die Entstehung eingebunden ist und dafür bezahlt) und wer das Produkt später nutzt.

Wert ist, wofür ein Kunde zahlt, und keine lange Funktionsliste. RE fokussiert Anforderungen auf den zu liefernden Wert und erreichbare Ziele. Anforderungen können mehrdeutig sein, sie können überspezifiziert sein, sie können unvollständig sein, sie können kontextspezifisch sein, sie können sich widersprechen, sie können nicht machbar oder schlichtweg falsch sein. In aller Regel jedoch sind es zu viele, um unter gegebenen Randbedingungen realisiert werden zu können. Das kommt deutlich am Beispiel eines Wunschzettels zum Ausdruck (Abb. 2–1).

Abb. 2–1Anforderungen sind der »Wunschzettel« des Kunden.

Das Problem in vielen Unternehmen ist, dass zu oft Funktionen und zu selten Träume adressiert werden. Als Ingenieure sind wir darauf geeicht, Lösungen zu finden. Wir definieren Funktionen und implementieren sie. Allerdings führen solche – angenommenen – Lösungen nicht immer zum Markterfolg und zu zufriedenen Kunden. Das überrascht uns, wo doch die Lösung so viele interessante Funktionen hat. Aber hatten wir wirklich ein Problem und einen Bedarf adressiert? Werden durch unser Produkt eine Vision und ein Traum wahr oder ersticken die Benutzer in Komplexität?

Wir stürzen uns viel zu schnell auf eine Lösung, weil es das ist, was wir dank Ausbildung und unter Projektdruck als Ergebnis sehen wollen. Ein Projekt, das von einer – angenommenen – Lösung aus startet, führt dazu, dass man einer Fata Morgana nachläuft, die sich ständig ändert. Wenn es uns gelingt, die Ziele und Anforderungen zu verstehen und systematisch umzusetzen, dann können wir jedes Projekt beherrschen.

Ein Produkt ist dann erfolgreich, wenn es den Bedürfnissen seiner Benutzer und seiner Umgebung gerecht wird. Anforderungen kommunizieren diese Bedürfnisse, und Requirements Engineering ist die Disziplin, die die Behandlung von Anforderungen über den gesamten Lebenszyklus des Produkts hinweg umfasst.

Beispiel:

Apple unter Steve Jobs zeigte, wie man mit wertorientiertem Requirements Engineering hervorragende Produkte macht. Steve Jobs gelang es, Träume zu verkaufen und diese Träume in Funktionen zu übersetzen. Er schockierte seine Ingenieure regelmäßig mit der einfachen Frage: Kann man im Design noch etwas weglassen? Unnötige Funktionen sind Ballast und verursachen Kosten im gesamten Lebenszyklus. Ein Produkt war für Steve Jobs erst gut genug, wenn jede Funktion einen Wert lieferte – und die Komplexität auf ein Minimum reduziert war.

Wir trennen daher klar zwischen Anforderung und Lösung. Eine Anforderung beschreibt ein Bedürfnis oder einen Nutzen, der erreicht werden soll. Sie beschreibt nicht, wie dieser Nutzen zu realisieren ist. Diese Implementierungssicht wird durch die Lösung beschrieben. Abbildung 2–2 veranschaulicht diesen Unterschied durch die Trennung zwischen Problemraum (oberer Teil: Marktanforderungen, Lastenheft etc.) und Lösungsraum (unterer Teil: Lösungsspezifikation, Pflichtenheft, Design, Fachkonzept etc.). Der Problemraum ist zunächst immer nur unscharf umrissen und wird im Verlauf der Lösungskonzeption eingeschränkt. Wert existiert nur im Auge des Betrachters. Daher sind Lösungen oftmals am erfolgreichsten, wenn sie nicht alle Anforderungen des Kunden adressieren. Der Erfinder und Unternehmer Henry Ford hat das früh begriffen und festgestellt: »Wenn ich die Leute gefragt hätte, was sie wollen, hätten sie gesagt: schnellere Pferde.« Steve Jobs hat Apple damit erfolgreich gemacht, dass er innovative Lösungen lieferte und Altlasten rigoros hinterfragt und reduziert hat. Legendär sind die frühen iPhone-Telefone, die zwar kaum telefonieren konnten, aber sich hervorragend verkauften, weil sie ganz andere neue Bedürfnisse adressierten.

Abb. 2–2Anforderungen und Lösungen

Es gibt nicht die »Anforderung« schlechthin. Zu einer Anforderung gehört immer die Perspektive, aus der sie beschrieben wird. Eine Anforderung ist eine Bedingung oder eine Fähigkeit, die ein Benutzer benötigt, um ein Problem zu lösen oder um ein Ziel zu erreichen. Das heißt, sie hängt von der Perspektive ab. Ein Benutzer kann der Kunde sein, der für die Lösung bezahlt, aber es kann auch ein Entwickler sein, der daraus eine Architektur ableitet. Entsprechend unterschiedlich sind die Schwerpunkte und Inhalte, die durch diese Anforderung beschrieben werden. Was dem einen die Anforderung ist, ist dem anderen die Lösung. Man trennt daher in der Praxis unterschiedliche Arten von »Anforderungen«, beispielsweise Marktanforderungen oder Komponentenanforderungen, und vermeidet, von einer »Anforderung« ohne Präzisierung zu sprechen.

2.2Perspektiven: vom Markt zur Realisierung

Drei verschiedene Sichten auf Anforderungen werden im Laufe der Lösungskonzeption unterschieden (Abb. 2–2):

Marktanforderungen

Produktanforderungen

Komponentenanforderungen

Diese drei Sichten entstehen durch Verfeinerung bzw. Abstraktion. Offensichtlich ist diese Dreiteilung rekursiv: Eine Komponentenanforderung an einen Lieferanten ist dort wiederum eine Marktanforderung.

Marktanforderungen

Marktanforderungen beschreiben Anforderungen an ein Produkt aus der Sicht des Kunden. Sie werden daher oft auch als Kunden-, Benutzer- oder Geschäftsanforderungen oder als Bedürfnisse bezeichnet. Sie beschreiben den Nutzen und die Erfahrungen mit dem Produkt in der Sprache des Kunden oder Benutzers, also warum ein Projekt überhaupt durchgeführt wird. Einziger Maßstab an Wert und Erfüllungsgrad ist daher die Wahrnehmung oder Spezifikation des Kunden. Marktanforderungen werden im Lastenheft dokumentiert.

Beispiel:

Marktanforderung_1:

Der Datentransfer muss geschützt erfolgen, um Missbrauch zu verhindern.

Viele Projekte umfassen Änderungen an Bestehendem. Marktanforderungen adressieren gerade auch solche Änderungen und nicht nur Projekte und Produkte auf der »grünen Wiese«. Änderungen verlangen eine genaue Abstimmung der Bedürfnisse und Nutzen mit den jeweiligen Zielgruppen oder Marktsegmenten. Häufig realisieren wir Funktionen oder Änderungen, die interessant scheinen, deren Markt aber zu klein ist. Hier ist eine Priorisierung aus betriebswirtschaftlicher Sicht wichtig.

Marktanforderungen sind Bestandteil von Verträgen, Entwicklungsaufträgen, Projektplänen, Teststrategien etc. Sie dienen als Basis für Abschätzung, Planung, Durchführung und Verfolgbarkeit der Projekttätigkeiten. Sie sind in der Sprache und im Kontext des Kunden formuliert. Wenn wir bei der Ermittlung der Marktanforderungen nicht aufpassen, haben wir die gleichen Schwierigkeiten, mit denen auch Eltern sich auseinandersetzen müssen, die einen Wunschzettel ihres Sprösslings in der Hand halten (Abb. 2–1). Es gibt Widersprüche, Inkonsistenzen und verborgene Prioritäten. Die Anforderungen sind zu umfangreich, und das Budget ist limitiert.

Marktanforderungen machen Wünsche erfüllbar und erlebbar. Das Ziel der Anforderungsermittlung ist es, aus verschiedenen Perspektiven möglicher Stakeholder und deren Vorgaben eine tragfähige Basis realisierbarer Anforderungen zu entwickeln. Abbildung 2–3 zeigt exemplarisch drei Benutzergruppen und deren Wünsche, Bedürfnisse und Geschäftsvorgaben als Punkte. Gutes RE schafft gemeinsam mit dem Produktmanagement einen Schnitt dergestalt, dass einige wesentliche Funktionen so ausgewählt werden, dass möglichst viel Wert erreicht wird, bei gleichzeitiger Optimierung der Kosten. Das erfordert Verhandlungsgeschick und Durchsetzungskraft, denn wir können es nicht jedem Beteiligten recht machen. Wesentlich ist, dass wir dabei klar trennen, was unrealistische Wünsche sind, die oftmals nur als Testballons platziert werden, was tatsächliche Bedürfnisse sind und was die Geschäftsvorgaben sind. Letztere sind Pflicht, Bedürfnisse werden priorisiert und gegenübergestellt, und Wünsche fallen in der Regel heraus, wenn kein Business Case nachvollziehbar ist. Wir sprechen im Requirements Engineering von einer Kundenbeziehung. Dabei kann der Kunde ein externer Benutzer sein oder eine interne Abteilung.

Beispiel:

Marktanforderungen im Consumer-Bereich, wie bei einer digitalen Kamera, gehen sehr konkret auf Benutzungsaspekte ein, also auf die Lebensdauer der Akkus oder die Pixelzahl und damit auf die Bildschärfe und -auflösung. Diese Anforderungen an die digitale Kamera werden im Unternehmen, das sie herstellt, in Produktanforderungen übersetzt, die dann die Sprache des internen Produktmarketings oder Produktmanagements sprechen. Schließlich werden sie in Anforderungen an Komponenten übersetzt und sprechen die Sprache von Entwicklungsingenieuren oder Einkäufern, die diese Komponenten entwickeln oder beschaffen. Änderungen der Anforderungen werden hinsichtlich ihres potenziellen Einflusses auf bestehende Pläne und Produkte abgeschätzt, geprüft und in die bestehenden Anforderungen aufgenommen. Anforderungen werden durch das ganze Projekt hindurch kontrolliert, um ihren Status zu kennen und um beurteilen zu können, wie weit das Projekt – aus Kundensicht – fortgeschritten ist.

Abb. 2–3Aus verschiedenen Perspektiven belastbare Geschäftsanforderungen entwickeln

Produktanforderungen

Produktanforderungen beschreiben Anforderungen an ein Produkt aus der Sicht der Realisierung einer späteren Lösung. Produktanforderungen beschreiben, was verschiedene Benutzer mit dem Produkt machen können und wie Marktanforderungen und Kundenbedürfnisse in ein Produkt umgesetzt werden. Sie beschreiben eine Eigenschaft in der Sprache des Produkts und werden daher auch als Funktionen, Eigenschaften oder Systemanforderungen bezeichnet. Sie definieren den Lösungsraum und die Prioritäten. Produktanforderungen werden im Pflichtenheft dokumentiert.

Beispiel:

Produktanforderung_1:

Jede einzelne Transaktion zwischen baulich getrennten Komponenten wird individuell verschlüsselt.

Produktanforderungen betrachten das Softwareprodukt oder den Dienst innerhalb eines größeren Kontextes, also der Umgebung, in der das System einmal arbeiten muss. Das kann ein PC sein, vor dem ein einzelner Benutzer sitzt (z.B. bei einem Computerspiel), eine Rechnerumgebung mit verschiedenen Benutzern (z.B. bei einem Ressourcenplanungssystem in einem Unternehmen), eine interaktive Online-Umgebung mit sehr vielen unbekannten Benutzern (z.B. bei einem Online-Buchungssystem), ein gemischtes Hardware-Software-System (z.B. bei einer Gebäudeautomatisierung) oder auch ein eingebettetes System, bei dem man kaum noch an Software denkt (z.B. ein Getränkeautomat, der in die Logistikkette eines Getränkelieferanten eingebaut ist).

Komponentenanforderungen

Komponentenanforderungen beschreiben Anforderungen an eine Komponente eines Produkts. Sie erläutern aus der Sicht der Realisierung und der späteren Lösung, wie Produktanforderungen durch eine Komponente des Produkts (z.B. Benutzerschnittstelle, Betriebssystem) adressiert werden.

Beispiel:

Komponentenanforderung_1:

Der Datenaustausch an der externen Schnittstelle xyz wird mit 128 Bit PGP-verschlüsselt.

Komponentenanforderungen dienen zur rekursiven Verfeinerung einer Produktanforderung oder eines Systems in handhabbare Teile. Aus der Sicht eines Lieferanten, der diese Komponente liefert, ist dies wiederum eine Marktanforderung. Komponentenanforderungen werden wie die Produktanforderungen auch im Pflichtenheft (in IT-Projekten oftmals auch Fachkonzept genannt) spezifiziert.

Viele Komponenten, wie Hardware und externe Software-Stacks, werden zugekauft. Das reduziert Kosten, verbessert die Qualität und erlaubt, sich auf den eigenen Wertbeitrag zu fokussieren. Daher müssen diese Anforderungen an externe Komponenten frühzeitig präzise spezifiziert werden, um danach die Entwicklungsarbeit verteilen und später die Ergebnisse integrieren zu können.

Die drei Sichten von Markt, Produkt und Komponenten sind nicht im Voraus oder von außen definiert, sondern hängen von der Lösungsstruktur ab.

Beispiel:

Der Benutzer oder Kunde stellt die folgende Anforderung:

M-Req-1:

Das System verwaltet die Kundendaten im Format Name, Vorname, Adresse.

Der Requirements-Ingenieur spezifiziert dazu eine Lösung mit der folgenden Komponentenanforderung:

K-Req-1:

Die Datenbank zur Verwaltung der Kundendaten wird mit Oracle 10 realisiert.

Offensichtlich sind dies zwei Anforderungen an die Datenhaltung, die aus verschiedenen Perspektiven beschrieben sind, nämlich Nutzung und Realisierung. Nun könnte aber auch der Kunde bereits eine technische Anforderung zur Realisierung haben, da er eine mySQL-Umgebung einsetzt und Kompatibilität sowie günstigere Lizenzkosten will. Er spezifiziert:

M-Req-2:

Die Datenbank zur Verwaltung der Kundendaten wird mit mySQL realisiert.

Nun wird aus der bisherigen Komponentenanforderung (K-Req-1) eine Marktanforderung (M-Req-2). Ebenso gibt es Situationen, in denen das Lastenheft und die Geschäftsanforderungen so vage sind, dass das Pflichtenheft auch als Problembeschreibung fungiert. Anstatt über solche Feinheiten zu debattieren, ist es wichtig, dass die Anforderungen immer mit ihrer jeweiligen Quelle spezifiziert werden. Dann ist zu jedem Zeitpunkt klar, wie es zur Anforderung kam und welche Freiheitsgrade für eine Änderung bestehen, was die Realisierung erleichtert. M-Req-2 lässt sich sehr viel schwerer beeinflussen als die konzeptionell gleiche K-Req-1, da die M-Req-2 direkt vom Kunden stammt und daher die Lösung bereits definiert.

Anforderungen und Lösungen bedingen sich gegenseitig, und dürfen nicht vermischt werden. Die zwei Sichten auf Anforderungen und Lösungen sind in Abbildung 2–4 anhand typischer Arbeitsergebnisse konkretisiert. Horizontal sind Funktionen und Ziele aus Sicht des Markts (in B2C) oder eines Auftraggebers (in B2B) beschrieben. Vertikal ist die Lösung als spätere Realisierung dargestellt. Verschiedene Komponenten tragen dazu bei, dass Funktionen umgesetzt werden. Offensichtlich ist das keine 1:1-Beziehung, sondern eine bunt gemischte n:m-Darstellung.

Werden diese beiden sehr verschiedenen Sichten vermischt, führt das zu einem Strukturbruch (siehe auch Abb. 5). Dieser Strukturbruch ist einer der häufigsten Gründe für verkorkste Projekte und inflationäre Komplexität. Bereits in den späten Jahrzehnten des vergangenen Jahrhunderts war das als »Softwarekrise« bekannt. Aufgelöst wurde diese Krise erst durch modernes Requirements Engineering, das es mit seinen Perspektiven und der Verfolgbarkeit ermöglichte, eine Sicht in eine andere zu übertragen. Modelle helfen dabei, den Strukturbruch zu beherrschen und Konsistenz zwischen den Sichten (Problem vs. Lösung) zu erreichen (siehe Kap. 5). Beispielsweise muss die Systemumgebung sehr frühzeitig definiert werden. Ein Architekturmodell wiederum hilft bei der Identifizierung von Komponentenanforderungen.

Abb. 2–4Komponentenanforderungen werden aus Produktanforderungen abgeleitet.

Die hier beschriebene Systematik und Methodik gilt für jede Art von Produkten: Software, Services, Hardware, Mechatronik, künstliche Intelligenz – oder auch für ganz banale Konsumgüter und moderne Bauwerke. Wir unterscheiden kein Requirements Engineering anhand von Branchen oder Produkten. Requirements Engineering hat sich aus einem interdisziplinären Diskurs entwickelt, beispielsweise aus Patterns von (Gebäude-)Architekten und aus der Serviceorientierung in der Medizin. Insofern wollen wir hier auch keine künstlichen Gräben zwischen greifbaren Systemen und virtuellen Diensten aufreißen. Aus der Sicht des Requirements Engineering ist die Vorgehensweise identisch. Und Hand aufs Herz: Wo ist die Trennung in der Lösung? Die enge Verknüpfung von Systementwicklung und Dienstentwicklung, die gerade im Requirements Engineering explizit adressiert werden muss, zeigt Abbildung 2–5.

Beispiel: Serviceorientierung

Viele heutigen Dienste bestanden früher aus Hardware oder Software. Betrachten wir multimodale Transportlösungen, die verschiedene Verkehrsträger verschmelzen: Bis vor einigen Jahren standen an den Haltestellen von Bussen und Bahnen Telefonzellen, damit man anrufen konnte, um sich abholen zu lassen oder um ein Taxi zu bestellen. Heute nutzt man einen Mobilitätsservice, der einem die beste Verbindung von A nach B mit unterschiedlichen Verkehrsträgern darstellt. Das verknüpft Hardware (Zugsignalisierung) und Software (Apps und Betriebsleitzentralen) zu Diensten – mit einem serviceorientierten Requirements Engineering (siehe auch Abschnitt 11.5).

Abb. 2–5Requirements Engineering für Systeme und Dienste

2.3Arten von Anforderungen

Man unterscheidet drei Arten von Anforderungen (Abb. 2–6):

Funktionale Anforderungen

Qualitätsanforderungen

Randbedingungen

Abb. 2–6Unterschiedliche Typen von Produktanforderungen

Funktionale Anforderung

Eine funktionale Anforderung beschreibt eine vom System oder einer Systemkomponente bereitzustellende Funktion des betrachteten Systems. Sie erläutert in der Sprache des Systems, was das System tun soll, beispielsweise die Berechnung einer Ausgangsgröße aus Eingangsgrößen durch Anwendung eines Algorithmus.

Beispiel:

Der Datenaustausch an der externen Schnittstelle xyz wird mit 128 Bit PGP-verschlüsselt.

Funktionale Anforderungen beschreiben funktionsorientiert und in der Sprache des Produkts, was das Produkt tut. Sie lassen sich in der Entwicklung verfolgen und auch validieren. Man kann für eine bestimmte Funktion einen Testfall schreiben, der später in verschiedenen Testphasen geprüft wird.

Beispiele für solche funktionalen Anforderungen sind Funktionen, Ablaufbeschreibungen und Szenarien, die angeben, wie ein System auf bestimmte Eingangsgrößen oder Eingaben zu reagieren hat (Abb. 2–7). Dazu gehören auch Datenoder Schnittstellenanforderungen, die nötig sind, um das zu entwickelnde System in einer bestimmten Umgebung einsetzen zu können. Geschäftsprozesse und Workflows sind ebenfalls funktionale Anforderungen.

Ein Geschäftsprozess beschreibt eine Folge zusammengehöriger Aktivitäten, die schrittweise ausgeführt werden, um ein geschäftliches oder betriebliches Ziel zu erreichen. Er beschreibt als Anforderung, wie das System intern operiert, um die Anforderungen der Umwelt zu erfüllen. Zur Vereinfachung werden Geschäftsvorfälle genutzt, die den Geschäftsprozess als Instanz konkretisieren. Geschäftsvorfälle sind Vorgänge, die die Vermögenszusammensetzung in einem Unternehmen beeinflussen oder verändern.

Workflows als Anforderungen beschreiben eine inhaltlich abgeschlossene, zeitlich zusammenhängende Folge von Aktivitäten, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objekts notwendig sind und deren Funktionsübergänge von einem Informationssystem gesteuert werden. Der Workflow beschreibt eine Prozesssicht, während der Geschäftsprozess die Sicht auf betriebswirtschaftliche Faktoren betrachtet.

Ein Anwendungsfall oder Use Case