UEber den Autor 13
Einleitung 25
UEber dieses Buch 25
Konventionen in diesem Buch 26
Was Sie nicht lesen muessen 26
Toerichte Annahmen ueber 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
Moeglichkeiten 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 uebrigen Beteiligten 47
Die Kunden des Requirements Engineering 48
Wer sonst noch so wichtig ist: die Stakeholder 48
Die Basis vieler Anforderungen: die Geschaeftsprozesse 49
Das Anforderungsdokument: eines fuer 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 Missverstaendnisse 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 UEberblick 57
Kapitel 3 Fallstricke 59
Was wir von den Kunden erwarten duerfen - 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 AEnderungen 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 erklaert 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 fuer die Anforderungen zustaendig ist 89
Wenn mehrere Teams an einem System arbeiten 90
Fortwaehrende Analyse statt AEnderungsmanagement 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
Zusaetzliche Anforderungsquellen 111
Anforderungen ermitteln 112
Von geheimen und selbstverstaendlichen Anforderungen: das Kano-Modell 113
Wer fragt, gewinnt: die Befragungstechniken 115
Anforderungen gemeinsam erheben: Kooperationstechniken 121
Schauen Sie genau hin: Beobachtungstechniken 123
Systemarchaeologie und der Blick zurueck: 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 zusaetzlich unterstuetzen 134
Welche Technik Ihnen weiterhilft 135
Konflikte und der Umgang damit 138
Analyse von Konflikten 138
Aufloesung 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 Fahrstuhlgespraech 152
Den UEberblick gewinnen 153
Den Kontext des Systems verstehen 154
Wie das System verwendet werden soll: Anwendungsfaelle 156
Der UEberblick ueber die ganze Geschichte: Story Map 159
Releases schneiden 164
Werden Sie zum Minimalisten: das Minimale Marktfaehige Release 164
Von der Story Map zum Releaseplan 167
Kapitel 9 Funktionale Anforderungen verstehen und beschreiben 175
Die Systemverwendung mit Anwendungsfaellen beschreiben 176
Wer das System zu welchem Zweck verwendet: das Anwendungsfalldiagramm 178
Anwendungsfaelle Schritt fuer Schritt: Ablaeufe beschreiben 180
Anwendungsfaelle mit Anwendungsfaellen erweitern 192
Die Geschichten der Nutzer: User Stories 196
Die Akzeptanzkriterien einer User Story 198
Wie kleine User Stories grosse ersetzen 201
Anwendungsfaelle oder User Stories? 205
Anwendungsfaelle klassisch 205
Von der Story Map ueber Anwendungsfaelle 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 Gegenstaenden im Fachklassenmodell 212
Das sind ja Zustaende 220
Die Zustaende fachlicher Gegenstaende 220
Das System bekommt Zustaende 225
Wie das Geschaeft zu regeln ist 232
Prototypen 243
Die natuerliche Sprache 247
Man kann nicht alles verstehen 248
Tipps zum Umgang mit der Sprache 248
Ein Bausatz fuer Saetze: 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 pruefen 277
Was gibt es denn da zu pruefen? 278
Vorgehen im klassischen Requirements Engineering 279
Qualitaetskriterien zur Verifikation und Validierung 279
Vorgehen im agilen Requirements Engineering 281
Techniken fuer die Pruefung 282
Reviewtechniken 282
Explorative Validierungstechniken 284
Prinzipien der UEberpruefung 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 fuer 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 AEnderungen 341
Ganz normal und doch unbeliebt 341
Der AEnderungsprozess und seine Bestandteile 342
Kapitel 18 Werkzeuge im Requirements Engineering: Unterstuetzung 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
Einfuehrung 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 erfuellen 358
Gemeinsames Verstaendnis: Die Basis fuer erfolgreiche Systementwicklung 358
Kontext: Notwendig, um Systeme zu verstehen 359
Problem, Anforderung, Loesung: Eine untrennbare Verbindung 359
Validierung: Ungepruefte Anforderungen sind nutzlos 360
Evolution: AEnderungen 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
Loesungen beschreiben anstatt Probleme zu verstehen 364
Anforderungen einfach vom Altsystem uebernehmen 364
Die Nutzer beschreiben die Anforderungen 364
Wir arbeiten agil und dokumentieren nichts 365
Entweder keine oder unverstaendliche 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 laeuft nicht, also brauchen wir ein Tool 366
Kapitel 21 Zehn Online-Quellen 369
IREB-Lehrplaene, Handbuecher und Glossar 369
Requirements Engineering Magazine 369
Scrum-Guide 369
Online Browsing Platform der ISO 370
V-Modell 370
UML-Spezifikation 370
UML-UEbersicht 371
DMN-Spezifikation 371
UEbersicht ueber Requirements-Tools 371
UEbersicht ueber UML-Tools 371
Stichwortverzeichnis 375
