Zu Hanser-Fachbuch.de
Warenkorb
Peter Hruschka
Business Analysis und Requirements Engineering
Produkte und Prozesse nachhaltig verbessern
Inhalt
6
Vorwort
10
1 Probleme, Ziele, Ideen und Visionen
12
1.1? Wovon sprechen wir?
12
1.2? Quantitative Gründe
13
1.3? Qualitative Gründe
14
1.4? Warum macht es nicht jeder richtig?
15
1.5? Standardisierung und Zertifizierung
16
1.6? Drei Säulen erfolgreicher Projekte
16
1.7? Definition: Business Analysis und Requirements Engineering
18
1.8? Definition: Requirement
22
1.9? Arten von Anforderungen
23
1.10? Vier Hauptaufgaben eines Analytikers
25
1.11? Benötigte Fähigkeiten
26
1.12? Aufgabenverteilung im Team
28
1.13? Der Aufwand für die Analyse
30
1.14? Was erleichtert die Analyse?
32
1.15? Verschiedene Vorgehensweisen
34
1.16? Zusammenfassung
37
2 Erfolgreich starten
40
2.1? Drei Zutaten zu einem erfolgreichen Projektstart
40
2.2? Ziele
41
2.3? Ziele spezifizieren
43
2.4? Stakeholder
45
2.5? Stakeholder finden
47
2.6? Die wichtigsten Stakeholder: die Nutzer
50
2.7? Weitere Quellen für Anforderungen
52
2.8? Scope und Kontext
53
2.9? Scope und Analytiker
57
2.10? Umgang mit Grauzonen
59
2.11? Darstellung der System-/Produktgrenze
61
2.12? Alternative Notationen
66
2.13? Die drei Erfolgszutaten (nochmals)
68
2.14? Zusammenfassung
70
3 Geschäftsprozesse und Produktfunktionalität
72
3.1? Anforderungen unterschiedlicher Granularität
72
3.2? Funktionale Anforderungen gliedern und strukturieren
74
3.3? Use Cases: die Grundidee
76
3.4? Use Cases: Formalien
78
3.5? Use Cases strukturieren
84
3.6? Use Cases und natürliche Sprache: ein Vergleich
87
3.7? Business Use Cases und Product Use Cases
89
3.8? Use Cases finden
89
3.9? Die Anzahl von Use Cases
94
3.10? Drei Tricks zur Vereinfachung
96
3.11? Use Cases beschreiben
99
3.11.1? Beschreibung auf Drachenniveau
101
3.11.2? Beschreibung auf Wellenniveau
102
3.11.3? Beschreibung auf Fischniveau
104
3.11.4? Der Stil auf Wellenniveau
105
3.12? Empfehlungen und Warnungen
108
3.13? Zusammenfassung
110
4 Funktionen genauer betrachtet
112
4.1? Wenn die Use-Case-Spezifikation nicht ausreicht …
112
4.2? Regeln für Aktivitätsdiagramme
114
4.3? Aktivitäten zerlegen
118
4.4? Swimlanes und Daten
119
4.5? Malen oder schreiben?
122
4.6? Wo hört man auf?
123
4.7? Top-down oder bottom-up?
127
4.8? Die Alternative: Datenflussdiagramme
131
4.9? Zusammenfassung
133
5 Anforderungen in Umgangssprache
134
5.1? IEEE-Forderungen an Anforderungen
134
5.2? Zwischen Wahrnehmung und Niederschrift
136
5.3? Satzschablonen zur Fehlerminimierung
140
5.4? Generelle Stilvorgaben
144
5.5? Zusammenfassung
146
6 Der Umgang mit Dingen
148
6.1? Eine kleine Geschichte
148
6.2? Das Glossar
151
6.3? Gute Definitionen
152
6.4? Vorgehensweise bei Glossareinträgen
154
6.5? Ein strukturiertes Glossar
155
6.6? (Entity-)Klassen und Objekte
158
6.7? Entity-Klassen-Modelle
162
6.8? Beziehungen
163
6.9? Spezielle Beziehungen
169
6.10? Malen oder schreiben?
171
6.11? Noch drei Beispiele
173
6.12? Abläufe und Daten
178
6.13? Ein Ausblick auf die Erstellung von Klassenmodellen
179
6.14? Zusammenfasssung
186
7 Verhaltensmodelle
188
7.1? Warum noch ein Modell?
188
7.2? Grundlagen von Zustandsmodellen
189
7.3? Aktionen und Aktivitäten
194
7.4? Zustandsmodelle erstellen und prüfen
197
7.5? Komplexe Zustandsmodelle
198
7.6? Ein Beispiel
203
7.7? Malen oder schreiben?
206
7.8? Zustandsmodelle und Aktivitätsdiagramme
207
7.9? Use Cases und Zustandsmodelle
209
7.10? Zusammenfassung
212
8 Qualitätseigenschaften und Randbedingungen
214
8.1? Was sind nichtfunktionale Anforderungen?
214
8.2? Kategorien nichtfunktionaler Anforderungen
218
8.3? Nichtfunktionale Anforderungen finden und zuordnen
222
8.4? Beispiele für äußere Qualitäten
225
8.5? Beispiele für innere Qualitäten
233
8.6? Beispiele für Randbedingungen
234
8.7? Messbarkeit von Anforderungen
238
8.8? Zusammenfassung
240
Intermezzo
242
9 Anforderungsdokumente
246
9.1? Viele Namen und mehrere Dokumente?
246
9.2? Warum überhaupt Dokumente?
247
9.3? Anforderungen an Requirements?Dokumente
249
9.4? Beispiele für die Struktur von Requirements-Dokumenten
251
9.5? Mindestinhalte
257
9.6? Zusammenfassung
258
10 Anforderungen ermitteln
260
10.1? Das Kano-Modell
260
10.2? Arten von Erhebungsmethoden
264
10.3? Was beeinflusst die Auswahl?
265
10.4? Beispiele für Frage-Antwort-Techniken
267
10.5? Beispiele für Beobachtungstechniken
272
10.6? Beispiele für vergangenheitsorientierte Techniken
273
10.7? Beispiele für Kreativitätstechniken
275
10.8? Erhebungstechniken und Hilfsmittel
276
10.9? Noch eine Kreativitätstechnik
281
10.10? Überblick (Reprise)
284
10.11? Zusammenfassung
284
11 Anforderungen prüfen und abstimmen
286
11.1? Quality Gates
287
11.2? Ziele der Prüfung
289
11.3? Arten der Prüfung
290
11.4? Wer sollte beteiligt sein?
293
11.5? Was wird geprüft?
294
11.6? Checklisten für inhaltliche Prüfungen
296
11.7? Was tun bei Mängeln?
300
11.8? Konfliktmanagement
301
11.9? Zusammenfassung
303
12 Requirements-Management
306
12.1? Definition: Requirements-Management
306
12.2? Vorbereitende Tätigkeiten
309
12.3? Der Requirements-Prozess
310
12.4? Rollen
313
12.5? Laufende Tätigkeiten
315
12.6? Attributierung von Requirements
316
12.7? Sichtenbildung
321
12.8? Priorisierung
322
12.9? Baselines und Releases
325
12.10? Change Management
326
12.11? Traceability
329
12.12? Zusammenfassung
333
13 Requirements-Werkzeuge
334
13.1? Kategorien von Werkzeugen
334
13.2? Leistungen von Werkzeugen
335
13.3? Stärken und Schwächen der Kategorien
337
13.4? Werkzeugauswahl
338
13.5? Einführung von Werkzeugen
339
13.6? Zusammenfassung
340
Literatur
342
Stichwortverzeichnis
344
© 2009-2024 ciando GmbH