Requirements Engineering für Dummies

Für den Erfolg von Softwareprojekten ist es entscheidend, sich erstmal klar zu machen, wozu das System überhaupt dienen soll und wie es dafür beschaffen sein muss. Klingt eigentlich selbstverständlich, und doch scheitern Projekte oft gerade an der Anforderungsanalyse. Das Buch "Requirements Engineering für Dummies" beschreibt verständlich und pragmatisch, wie Sie vorgehen sollten - und zwar sowohl für klassische als auch für agile Projekte. Es liefert Ihnen Techniken, wie Sie Ziele bestimmen und Releases sinnvoll zusammenstellen, wie Sie Anforderungen erheben und verstehen, wie Sie mit Änderungen umgehen und wie Sie Fallstricke vermeiden. Das Buch ist auch geeignet zur Vorbereitung auf die CPRE-FL-Prüfung.

Autorentext
Dr. Marcus Winteroll ist Mitglied der oose Innovative Informatik eG, einem Anbieter von Schulungen und Workshops zu Software & Systems Engineering in Hamburg. Als Trainer und Berater beschäftigt er sich mit der Analyse sowie Verbesserung von Geschäfts- und Entwicklungsprozessen. Dazu setzt er auf agile Methoden; aber auch die klassischen Vorgehensweisen sind ihm aus seiner langjährigen Erfahrung als Requirements Engineer, Projektleiter, Prozessmanager, Qualitätssicherer und Entwickler vertraut. Seine gesammelten Erfahrungen teilt er auf Konferenzen und als Autor von Fachartikeln.

Inhalt

Ü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 heißt 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

Maßnahmen 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 große 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 weiß, ob das auch so stimmt - Anforderungen prüfen 277

Was gibt es denn da …