Über den Autor 13
Einleitung 25
Über dieses Buch 25
Konventionen in diesem Buch 26
Was Sie nicht lesen müssen 26
Törichte Annahmen über die Leser 26
Wie dieses Buch aufgebaut ist 26
Teil I: Requirements Engineering verstehen 27
Teil II: Vorgehen im Requirements Engineering 27
Teil III: Anforderungsanalyse 27
Teil IV: Requirements Management 27
Teil V: Der Top-Ten-Teil 27
Symbole, die in diesem Buch verwendet werden 27
Wie es weitergeht 28
Teil I: Requirements Engineering verstehen 29
Kapitel 1 Das ist Requirements Engineering 31
Warum uns Requirements Engineering weiterhelfen kann 31
Aufgaben im Requirements Engineering 34
Wer das Requirements Engineering macht 36
Der Requirements Engineer 37
Wer sonst noch das Requirements Engineering macht 37
Viele Arten von Anforderungen 38
Funktionale Anforderungen 38
Nichtfunktionale Anforderungen 39
Randbedingungen 40
Abstraktionsstufen von Anforderungen 41
Möglichkeiten der Zertifizierung 42
Zertifikate des IREB 43
Zertifikate des IIBA 44
PMI Professional in Business Analysis (PMI-PBA) 45
Kapitel 2 Einbettung des Requirements Engineering 47
Das Zusammenspiel mit den übrigen Beteiligten 47
Die Kunden des Requirements Engineering 48
Wer sonst noch so wichtig ist: die Stakeholder 48
Die Basis vieler Anforderungen: die Geschäftsprozesse 49
Das Anforderungsdokument: eines für alle? 50
Requirements Engineering im klassischen Vorgehen: alles klar 52
Was zu erwarten ist 52
Was nicht zu erwarten ist 52
Requirements Engineering in agilen Projekten: just in time 53
Beliebte Missverständnisse beim agilen Requirements Engineering 53
Was agiles Vorgehen vom klassischen unterscheidet 54
Klassisch, agil, Festpreis, Aufwandspreis -nicht jede Kombination ist sinnvoll 56
Klassisch und Festpreis 56
Agil und Aufwandspreis 56
Agil und Festpreis 57
Klassisch und Aufwandspreis 57
Alles im Überblick 57
Kapitel 3 Fallstricke 59
Was wir von den Kunden erwarten dürfen - und sie von uns 59
Wer nimmt die Anforderungen auf? 60
Der Projektleiter als Requirements Engineer 60
Der Product Owner als Requirements Engineer 61
Entwickler als Requirements Engineers 61
Kunde und Nutzer als Requirements Engineers 62
Die richtige Detaillierung von Anforderung 63
Umgang mit Änderungen 64
Dokumentation von Anforderungen 66
Teil II: Vorgehen im Requirements Engineering 69
Kapitel 4 Vorgehen in klassischen Projekten 71
Einordnung in den Projektablauf 71
Der Ablauf 73
Kapitel 5 Vorgehen in agilen Projekten 77
Direkte Kommunikation statt Dokumentation 78
Der Wert gibt den Takt an 79
Das Ziel immer vor Augen 80
Die Vorbereitungsphase 80
Requirements Engineering in Scrum 82
Scrum kurz erklärt 82
Wo das Requirements Engineering in Scrum stattfindet 84
Das Product Backlog weiterentwickeln: Refinement 86
Fertig heisst fertig: die Definition of Done 88
Welche Rolle für die Anforderungen zuständig ist 89
Wenn mehrere Teams an einem System arbeiten 90
Fortwährende Analyse statt Änderungsmanagement 91
Die Unterschiede zwischen klassischem und agilem Requirements Engineering 92
Kapitel 6 Anpassung des Requirements-Engineering-Prozesses 93
Einflussfaktoren 93
Facetten des Requirements-Engineering-Prozesses 94
Zeitfacette 95
Zweckfacette 96
Zielfacette 96
Konfiguration des Prozesses 97
Teil III: Anforderungsanalyse 99
Kapitel 7 An die Anforderungen herankommen 101
Stakeholderanalyse 102
Stakeholder identifizieren 103
Stakeholder verstehen 105
Massnahmen zur Einbindung der Stakeholder 110
Zusätzliche Anforderungsquellen 111
Anforderungen ermitteln 112
Von geheimen und selbstverständlichen Anforderungen: das Kano-Modell 113
Wer fragt, gewinnt: die Befragungstechniken 115
Anforderungen gemeinsam erheben: Kooperationstechniken 121
Schauen Sie genau hin: Beobachtungstechniken 123
Systemarchäologie und der Blick zurück: artefaktbasierte Techniken 126
Recycling im Requirements Engineering: die Wiederverwendung von Anforderungen 127
Seien Sie kreativ: Entwurfs- und Ideenfindungstechniken 128
Hypothesen bilden und ausprobieren 133
Techniken, die Sie zusätzlich unterstützen 134
Welche Technik Ihnen weiterhilft 135
Konflikte und der Umgang damit 138
Analyse von Konflikten 138
Auflösung von Konflikten 139
Kapitel 8 Was uns zu Beginn klar sein sollte 145
Wohin soll die Reise gehen? Das Ziel klar vor Augen 145
Auf die Verpackung kommt es an: der Produktkarton 147
Alles auf einem Blick: das Product Vision Board 150
Auf die Schnelle: das Fahrstuhlgespräch 152
Den Überblick gewinnen 153
Den Kontext des Systems verstehen 154
Wie das System verwendet werden soll: Anwendungsfälle 156
Der Überblick über die ganze Geschichte: Story Map 159
Releases schneiden 164
Werden Sie zum Minimalisten: das Minimale Marktfähige Release 164
Von der Story Map zum Releaseplan 167
Kapitel 9 Funktionale Anforderungen verstehen und beschreiben 175
Die Systemverwendung mit Anwendungsfällen beschreiben 176
Wer das System zu welchem Zweck verwendet: das Anwendungsfalldiagramm 178
Anwendungsfälle Schritt für Schritt: Abläufe beschreiben 180
Anwendungsfälle mit Anwendungsfällen erweitern 192
Die Geschichten der Nutzer: User Stories 196
Die Akzeptanzkriterien einer User Story 198
Wie kleine User Stories grosse ersetzen 201
Anwendungsfälle oder User Stories? 205
Anwendungsfälle klassisch 205
Von der Story Map über Anwendungsfälle zu den User Stories 205
Kapitel 10 Weitere Aspekte funktionaler Anforderungen 209
Fachliche Begriffe begreifen 210
Alle wichtigen Begriffe auf einem Blick: das Glossar 210
Der Zusammenhang zwischen den fachlichen Gegenständen im Fachklassenmodell 212
Das sind ja Zustände 220
Die Zustände fachlicher Gegenstände 220
Das System bekommt Zustände 225
Wie das Geschäft zu regeln ist 232
Prototypen 243
Die natürliche Sprache 247
Man kann nicht alles verstehen 248
Tipps zum Umgang mit der Sprache 248
Ein Bausatz für Sätze: Satzschablonen 250
Die Sprache und nichts als die Sprache 254
Kapitel 11 Nichtfunktionale Anforderungen und Randbedingungen 257
Die Bedeutung der nichtfunktionalen Anforderungen 258
Nichtfunktionale Anforderungen verstehen 260
Nichtfunktionale Anforderungen ermitteln 265
Nichtfunktionale Anforderungen in der agilen Entwicklung 270
Was schon vorher feststeht: die Randbedingungen 273
Kapitel 12 Wer weiss, ob das auch so stimmt - Anforderungen prüfen 277
Was gibt es denn da zu prüfen? 278
Vorgehen im klassischen Requirements Engineering 279
Qualitätskriterien zur Verifikation und Validierung 279
Vorgehen im agilen Requirements Engineering 281
Techniken für die Prüfung 282
Reviewtechniken 282
Explorative Validierungstechniken 284
Prinzipien der Überprüfung 286
Kapitel 13 Anforderungen festhalten 289
Zweck der Dokumentation 289
Der richtige Zeitpunkt 292
Hilfreiche Regeln 294
Arten der Dokumentation 295
Dokumente 296
Modelle 302
Anforderungssammlungen im Requirements-Management-Tool 304
Product Backlog 305
Story Map 306
Formularvorlagen für Anforderungen 306
Teil IV: Requirements Management 309
Kapitel 14 Anforderungen organisieren 311
Requirements Management im agilen Vorgehen 312
Der Lebenszyklus einer Anforderung 314
Versionierung 316
Attribute einer Anforderung 317
Kann man so oder so sehen: Sichtweisen 318
Konfigurationen 320
Kapitel 15 Ist das wirklich wichtig? - Priorisierung von Anforderungen 323
Was wichtig ist 324
Ad-hoc-Priorisierungstechniken 325
Priorisierung mittels Stufen 325
Ranking 326
Top-Ten-Technik 326
Kauf dir ein Feature 326
Analytische Priorisierungstechniken 327
Wiegers'sche Priorisierungsmatrix 327
Kano-Modell 330
Vorgehen 330
Kapitel 16 Die Anforderungen verfolgen 333
Zweck der Verfolgbarkeit 333
Verfolgbarkeit darstellen 335
Methodisches Verfolgen 338
Kapitel 17 Umgang mit Änderungen 341
Ganz normal und doch unbeliebt 341
Der Änderungsprozess und seine Bestandteile 342
Kapitel 18 Werkzeuge im Requirements Engineering: Unterstützung und Last 347
Arten von Werkzeugen 348
Office-Tools 348
Requirements-Management-Tools 349
Modellierungstools 350
Was schon da ist: Bugtracker und Wiki 351
Lowtech-Tools 351
Kombinationen von Tools 352
Einführung von Werkzeugen 352
Teil V: Der Top-Ten-Teil 355
Kapitel 19 Zehn Prinzipien des Requirements Engineering 357
Zusammenarbeit: Requirements Engineering allein funktioniert nicht 357
Wertorientierung: Anforderungen sind kein Selbstzweck 358
Stakeholder: Es geht darum, ihren Bedarf zu erfüllen 358
Gemeinsames Verständnis: Die Basis für erfolgreiche Systementwicklung 358
Kontext: Notwendig, um Systeme zu verstehen 359
Problem, Anforderung, Lösung: Eine untrennbare Verbindung 359
Validierung: Ungeprüfte Anforderungen sind nutzlos 360
Evolution: Änderungen sind normal 360
Innovation: Mehr vom Gleichen reicht nicht 361
Systematische und disziplinierte Arbeit: Ohne geht es nicht 361
Kapitel 20 Zehn beliebte Fehler im Requirements Engineering 363
Die Suche nach dem Schuldigen 363
Lösungen beschreiben anstatt Probleme zu verstehen 364
Anforderungen einfach vom Altsystem übernehmen 364
Die Nutzer beschreiben die Anforderungen 364
Wir arbeiten agil und dokumentieren nichts 365
Entweder keine oder unverständliche Systemdokumentationen 365
User Stories sind allein dazu da, die bestehenden Anforderungen in das Backlog aufzunehmen 365
Agil und Modellierung geht nicht zusammen 366
Fachleute und Entwickler sprechen nicht miteinander 366
Das Requirements Engineering läuft nicht, also brauchen wir ein Tool 366
Kapitel 21 Zehn Online-Quellen 369
IREB-Lehrpläne, Handbücher und Glossar 369
Requirements Engineering Magazine 369
Scrum-Guide 369
Online Browsing Platform der ISO 370
V-Modell 370
UML-Spezifikation 370
UML-Übersicht 371
DMN-Spezifikation 371
Übersicht über Requirements-Tools 371
Übersicht über UML-Tools 371
Stichwortverzeichnis 375
