Christine Rupp, die SOPHISTen
Requirements-Engineering und -Management
Aus der Praxis von klassisch bis agil
Requirements-Engineering und -Management - Aus der Praxis von klassich bis agil - 6., aktualisierte und erweiterte Auflage
4
Inhaltsverzeichnis
7
Einleitung
17
Was Sie in diesem Buch erwartet
17
Die SOPHISTen: Alt und Neu
19
Neue Erknenntisse und bewährtes Wissen
19
Das Team
19
Wissen erarbeiten: Selbsttest und Blended Learning mit ILIAS®
22
Wissen beschreiben: Kapitel für Kapitel zum RE-Leitfaden
22
TEIL I - Requirements- Engineering zum Erfolg bringen
23
1 In medias RE
25
1.1 Motivation für eine erfolgreiche Systemanalyse
26
1.2 Der Requirements-Engineer – Mittler zwischen den Welten
27
1.3 Das Requirementsgehirn
28
1.4 Die Disziplin Requirements-Engineering
29
1.5 Die Einteilung von Anforderungen
33
1.5.1 Einteilung von Anforderungen nach ihrer Art
33
1.5.2 Einteilung von Anforderungen nach ihrer rechtlichen Verbindlichkeit
34
1.6 Gründe für Dokumentation
35
1.6.1 Wissen verfällt bzw. diffundiert
35
1.6.2 Detailtiefe und Verständnis fehlt
37
1.6.3 Verlust des Gesamtüberblicks
38
1.6.4 Missverständnisse entstehen und bleiben
39
1.6.5 Abweichende Informationen verteilen s
39
1.7 Typische Probleme in der Anforderungsanalyse
40
1.8 Qualitätskriterien im Requirements-Engineering
42
1.8.1 Qualitätskriterien für jede einzelne Anforderung
42
1.8.2 Qualitätskriterien für die Anforderungsspezifikation
44
1.8.3 Pragmatische Aspekte von Anforderungen und Anforderungsspezifikationen
45
2 Das Bibliothekssystem – wie alles begann
47
3 Von der Idee zur Spezifikation
49
3.1 Von der richtigen Anforderungsmenge
50
3.2 Der Zusammenhang zwischen Anforderungen
52
3.2.1 Anforderungen und die Architektur
52
3.2.2 Anforderungen und deren Verfeinerungen
53
3.2.3 Detaillierungsebenen
54
3.3 Die Systemanalyse im Überblick
58
3.3.1 Anforderungen herleiten
62
3.3.2 Anforderungen zum richtigen Zeitpunkt
63
3.4 Das Vorgehen in der Projektpraxis
65
4 Agile und andere Vorgehensweisen
67
4.1 Konventionelle Vorgehensmodelle und Qualitätsstandards
68
4.2 Agile Vorgehensweisen
72
4.2.1 Kanban
73
4.2.2 Scrum
73
4.3 RE und Scrum
77
4.3.1 Integrationsmöglichkeiten von RE in Scrum
78
4.3.2 Dokumentieren von Anforderungen in Scrum
80
4.3.3 RE als Scrum-Projekt
81
4.3.4 RE ist immer agil
84
Teil II - Anforderungen ermitteln
87
5 Ziele, Informanten und Fesseln
89
5.1 Die wichtigsten Schritte vor dem Start in die Systemanalyse
91
5.1.1 Anforderungsquellen: Ausgangspunkt und Mittelpunkt
93
5.1.2 Die derzeitige Realität unter die Lupe nehmen
94
5.1.3 Probleme erkunden und Optimierungspotenziale beschreiben
94
5.1.4 Ziele definieren und bewerten
94
5.2 Der Stakeholder – das unbekannte Wesen
95
5.2.1 Die Notation von Stakeholdern
97
5.2.2 Stakeholder-Relationship-Management – die Pflegevon Stakeholdern
99
5.3 Ziele beschreiben
99
5.4 Umfang, Kontext und Grenzen des Systems festlegen
101
5.4.1 Die Kontextabgrenzung
101
5.4.2 System- und Kontextgrenzen bestimmen
102
6 Anforderungsermittlung – Hellsehen für Fortgeschrittene
105
6.1 Ran an die Kundenwünsche
106
6.1.1 Aller Anfang ist schwer
106
6.1.2 Kommunikationsmodelle
107
6.1.3 Repräsentationssysteme der Sprache
109
6.1.4 Die Qual der Wahl
110
6.2 Die entscheidenden Produktfaktoren
110
6.2.1 Basisfaktoren ausgraben
111
6.2.2 Leistungsfaktoren abholen
112
6.2.3 Begeisterungsfaktoren erarbeiten
113
6.3 Ermittlungstechniken
114
6.3.1 Kreativitätstechniken
115
6.3.2 Beobachtungstechniken
119
6.3.3 Befragungstechniken
121
6.3.4 Artefaktbasierte Techniken
126
6.3.5 Unterstützende Techniken
128
6.4 Anwendung in der Praxis
135
7 Das SOPHIST-REgelwerk – Psychotherapie für Anforderungen
139
7.1 Vom Phänomen der Transformation – sprachliche Effekte
140
7.2 Die Wurzeln – das Neurolinguistische Programmieren
141
7.2.1 Transformationsprozesse
141
7.2.2 Kategorien der Darstellungstransformation
144
7.3 Vom Umgang mit sprachlichen Effekten
147
7.4 Das Vorgehen beim SOPHIST-REgelwerk – Anforderungen auf die Couch gelegt
149
7.5 Prüfen der Satzbestandteile
151
7.5.1 Prüfen der Prozesse
152
7.5.2 Prüfen von Eigenschaften
160
7.5.3 Prüfen von Mengen und Häufigkeiten
164
7.5.4 Prüfen von Begriffen, die Möglichkeiten beschreiben
168
7.6 Prüfen des Satzes
170
7.7 Prüfen des Gesamtbilds
172
7.8 Anwendung des SOPHIST-REgelwerks
177
Teil III - Anforderungen formulieren
181
8 Grundlagen für die Systemanalyse dokumentieren
183
8.1 Ausgangssituation beschreiben? Ja bitte!
184
8.2 Geschäftsprozessbeschreibung
185
8.2.1 Business-Use-Cases
186
8.2.2 Ablaufdiagramme
188
8.2.3 Geschäftsregeln
193
8.3 Ziele dokumentieren
196
8.4 Kontextvisualisierung
197
8.4.1 Use-Case-Diagramm zur Kontextvisualisierung
198
8.4.2 Kontextdiagramm der Strukturierten Analyse
198
8.5 Begriffe und Definitionen
199
9 Systemanforderungen dokumentieren – malen oder schreiben?
201
9.1 Dokumentation? Ja bitte!
202
9.2 Anforderungen in Prosa beschreiben
203
9.3 Szenarien
203
9.4 Das System-Use-Case-Diagramm
205
9.5 Die Use-Case-Beschreibung
208
9.6 Das Aktivitätsdiagramm
211
9.7 Das Sequenzdiagramm
213
9.8 Zustandsdiagramm
215
9.9 Das Klassendiagramm als Begriffsmodell
217
9.10 Beschreibung von Systemregeln
219
9.11 Anforderungen verfeinern
222
9.11.1 Diagramme verfeinern/konkretisieren/detaillieren
222
9.11.2 Tipps zum Thema Detaillierung
224
9.12 Die Wahl der richtigen Dokumentationstechniken
224
9.12.1 Einflussfaktoren auf die Wahl der Dokumentationstechniken
226
9.12.2 Auswahlempfehlungen
227
9.12.3 Diagramm oder doch lieber natürliche Sprache?
228
10 Anforderungsschablonen – der MASTER-Plan für gute Anforderungen
231
10.1 Linguistische und philosophische Grundlagen
232
10.2 Der schablonenbasierte Ansatz
233
10.3 Schritt für Schritt zur Anforderung
235
10.4 Semantische Präzisierung der Anforderungsschablone
241
10.4.1 Rechtliche Verbindlichkeiten
242
10.4.2 Verben – Prozesswörter
243
10.4.3 Substantive – Akteure, Rollen, Objekte, Eigenschaftenund Abkürzungen
244
10.4.4 Bedingungen
245
10.5 Konstruieren in englischer Sprache
246
10.5.1 Der Syntaxbauplan im Englischen
246
10.5.2 Semantische Normierung im Englischen
247
10.6 Details für die Konstruktion
248
10.6.1 Präzisierung des Objekts
248
10.6.2 Konkretisierung des Prozessworts
249
10.6.3 Die Details in englischer Sprache
250
10.7 Nicht-funktionale Anforderungen
250
10.7.1 Eigenschaften
251
10.7.2 Umgebungen und Kontext
253
10.7.3 Prozesse
254
10.7.4 Konstruieren in englischer Sprache
255
10.8 Bedingungen in Anforderungen
256
10.8.1 Syntax für und Semantik in Bedingungen
256
10.8.2 Konstruieren in englischer Sprache
258
10.9 Auf die Sätze, fertig, los!
259
11 Dokumentation im agilen Umfeld
263
11.1 Artefakte – eine Übersicht
264
11.2 User-Storys
265
11.2.1 Aufbau einer User-Story
265
11.2.2 Das nehm‘ ich dir nicht ab! – Akzeptanzkriterien für User-Storys
266
11.2.3 Von Use-Cases, User-Storys und Story-Maps
268
11.3 Technical Storys
270
11.3.1 Aufbau von Technical Storys
271
11.3.2 Die Priorisierungsproblematik
271
11.4 User-Storys schneiden und verfeinern
272
11.4.1 Das Meta-Pattern
272
11.4.2 Der Minimal-Ansatz und der Reduktions-Ansatz
274
11.5 Wann ist fertig wirklich „fertig“? – Die Definition of Done (DoD)und die Definition of Ready (DoR)
276
11.5.1 Die Definition of Done – weil’s gut werden muss
276
11.5.2 Die Definition of Ready – das Quality-Gate für User-Storys
277
11.6 And all together now! – Wann setze ich welche Technik ein?
278
12 Nicht–funktionale Anforderungen – die heimlichen Stars
283
12.1 Definition, Bedeutung und Chancen
284
12.2 Ermitteln und Dokumentieren von NFAs
286
12.2.1 Vorbereitende Tätigkeiten
287
12.2.2 Durchzuführende Tätigkeiten
288
12.2.3 Best Practices
291
12.3 Technologische Anforderungen
293
12.3.1 Inhalte
293
12.3.2 Erfahrungen aus dem Projektalltag
294
12.4 Qualitätsanforderungen
296
12.4.1 Inhalte
297
12.4.2 Erfahrungen aus dem Projektalltag
299
12.5 Anforderungen an die Benutzungsoberfläche
302
12.5.1 Inhalte
303
12.5.2 Dokumentieren von Benutzungsoberflächen
305
12.5.3 Erfahrungen aus dem Projektalltag
308
12.6 Anforderungen an sonstige Lieferbestandteile
308
12.6.1 Inhalte
309
12.6.2 Erfahrungen aus dem Projektalltag
309
12.7 Anforderungen an durchzuführende Tätigkeiten
310
12.7.1 Inhalte
311
12.7.2 Erfahrungen aus dem Projektalltag
311
12.8 Rechtlich-vertragliche Anforderungen
311
12.8.1 Inhalte
312
12.8.2 Erfahrungen aus dem Projektalltag
314
Teil IV - Anforderungen prüfen und bewerten
315
13 Der Qualitätssicherungsprozess – Menetekel oder Wunderheilung?
317
13.1 Qualität ist das, was der Kunde braucht
318
13.1.1 Ziele in der Qualitätssicherung von Anforderungen
319
13.1.2 Konstuktive und analytische Qualitätssicherung vonAnforderungen
319
13.1.3 Vorgehen beim Prüfen von Anforderungen
321
13.2 Der Qualitätssicherungsleitfaden – damit Sie loslegen können
322
13.2.1 Qualitätsziele festlegen
323
13.2.2 Qualitätssicherungsmethoden auswählen
324
13.2.3 Prüfzeitpunkte definieren
324
13.2.4 Über die Auswahl geeigneter Prüfer
326
13.3 Plan - Qualitätsprüfung vorbereiten
328
13.3.1 Prüfbarkeit feststellen
328
13.3.2 Prüfgegenstand definieren
329
13.3.3 Prüfgegenstand extrahieren und dokumentieren
329
13.4 Do - Qualitätsprüfung durchführen
329
13.4.1 Spezifikationselement bewerten
330
13.4.2 Prüfbericht verfassen
330
13.5 Check – Ergebnisse beurteilen
330
13.6 Act – Maßnahmen initiieren
331
14 Prüftechniken für Anforderungen – ungeahntes Verbesserungspotenzial
333
14.1 Die Prüftechniken im Detail
334
14.1.1 Reviews
334
14.1.2 Prototyp/Simulationsmodell
338
14.1.3 Testfälle
339
14.1.4 Analysemodell
342
14.1.5 Hilfsmittel bei der Prüfung
344
14.2 Vom Durchblick im Dschungel der Prüftechniken
346
14.2.1 Einschätzung der Prüftechniken
347
14.2.2 Über die Auswahl geeigneter Prüftechniken
347
15 Qualitätsmetriken – drum messe, wer sich ewig bindet
349
15.1 Qualitätsmetriken – die Hüter der Anforderungsqualität
350
15.1.1 Qualitätsmetriken für Anforderungen
351
15.1.2 Ziele von Qualitätsmetriken – der Blick ins Unbekannte
352
15.1.3 Verwendung von Metriken – die erste Herausforderung
353
15.2 Vorbereitung der Messung mit Qualitätsmetriken
353
15.2.1 Qualitätsziele festlegen
354
15.2.2 Messleitfaden erweitern
354
15.2.3 Stichprobenumfang definieren
354
15.2.4 Stichproben festlegen und dokumentieren
356
15.3 Durchführung
358
15.3.1 Qualitätskennzahlen berechnen
359
15.3.2 Messergebnis dokumentieren
360
15.3.3 Qualitätskennzahlen beurteilen
361
16 Anforderungskonsolidierung – wider den Widerspruch
363
16.1 Was ist ein Konflikt?
364
16.2 Konfliktidentifikation
365
16.2.1 Konfliktindikatoren in der Kommunikation
365
16.2.2 Konfliktindikatoren in der Dokumentation
366
16.3 Konfliktanalyse
366
16.4 Konfliktauflösung
373
16.4.1 Stile und Verhaltensstrategien in der Konfliktauflösung
374
16.4.2 Konsolidierungstechniken
375
16.4.3 Auswahl der Konsolidierungstechniken
378
16.5 Dokumentation der Anforderungskonsolidierung
379
Teil V - Anforderungen verwalten
381
17 Requirements-Management – die Reise beginnt
383
17.1 Wider die Unordnung
384
17.1.1 Gründe für professionelles Requirements-Management
385
17.1.2 Der Requirements-Engineering-Leitfaden
386
17.1.3 Wann ist wie viel RM sinnvoll?
388
17.2 Die Aufgaben professionellen Requirements-Managements
388
17.2.1 Informationsaustausch – wer gibt wann wem was?
389
17.2.2 Ablaufsteuerung – wer darf wann was?
390
17.2.3 Verwaltung von Abhängigkeiten – was hängt wie mitwas zusammen?
391
17.2.4 Auswertung und Projektsteuerung – wie läuft‘s?
391
17.3 Was soll genau verwaltet werden? – Informationsarten
392
17.4 Gliederungsstrukturen – das Skelett des Requirements-Managements
395
17.5 Objekt-IDs – denn Namen sind Schall und Rauch
399
17.5.1 Wann ist eine Objekt-ID wirklich eindeutig?
399
17.5.2 Wie soll eine Objekt-ID aussehen?
399
18 Versionen und Zustände – das Leben einer Anforderung
403
18.1 Die Anforderung lebt!
404
18.2 Der Zustandsautomat einer Anforderung
405
18.2.1 Die Zustände einer Anforderung
406
18.2.2 Die Zustandsübergänge einer Anforderung
409
18.2.3 Den Zustandsautomaten dokumentieren
409
18.3 Detaillierungsebenen und Abhängigkeiten
410
18.4 Arbeitsabläufe im RM definieren
414
18.4.1 Rollen identifizieren
415
18.4.2 Rechte vergeben
416
18.5 Den Lebensweg dokumentieren
419
18.5.1 Die Historie einer Anforderung
419
18.5.2 Versionierung einer Anforderung
420
19 Strukturen und Mengen – das Chaos verhindern
423
19.1 Das Chaos verhindern
424
19.1.1 Attribute – alles, was man über seine Anforderungenwissen muss
425
19.1.2 Die Übersicht behalten – Filtern und Sichten bilden
434
19.2 Auswertungen
435
19.3 Traceability
437
19.3.1 Eltern-Kind-Verbindung
438
19.3.2 Verbindung von Anforderungen auf gleicher Ebene
441
19.3.3 Verbindung zwischen verschiedenen Informationsarten
441
19.3.4 Traces technisch realisieren
442
19.3.5 Definition eines Verfolgbarkeitsmodells
445
19.4 Anforderungen strukturieren
448
19.4.1 Strukturierung nicht-funktionaler Anforderungen
448
19.4.2 Strukturierung funktionaler Anforderungen
449
19.5 Anforderungen importieren und exportieren
458
20 Change- & Release-Management – die stabile Instabilität
461
20.1 Quellen und Typen von Änderungen – es kommt was auf Sie zu
463
20.1.1 Incident-Management – einer für alle und alles auf einmal
464
20.1.2 Fachbereich und Produkt-Management
464
20.1.3 Tester
464
20.1.4 Entwickler
465
20.1.5 Definitionen der Tickettypen
465
20.1.6 Sammeltopf für die Tickets
467
20.2 Change-Management
467
20.2.1 Priorisierung der Tickets
467
20.2.2 Änderung grob beschreiben und entscheiden
468
20.3 Tickets einplanen
468
20.4 Release-Management
469
20.4.1 Änderungen durchführen – die Stunde der Traceability
469
20.4.2 Konfigurationen und Basislinien
471
20.5 Der Zielspurt – Release ausrollen
472
20.6 Ausnahmesituation – das Emergency Release
474
21 Wiederverwendung – aus alt mach neu
475
21.1 Das Rad nicht immer neu erfinden
476
21.2 Die potenziellen Kandidaten
477
21.3 Regelgeleitete Wiederverwendung
478
21.3.1 Spezifikationslevel
478
21.3.2 Eingeschränkte Produktpalette
479
21.3.3 Einbindung in den Ablauf
479
21.3.4 Technologie
480
21.3.5 Zwischenfazit
480
21.4 Wiederverwendung in der Praxis
480
21.5 Auswahl der Vorgehensarten
481
21.5.1 Der Ansatz nach IVENA XT
481
21.5.2 Produktlinien
485
Teil VI - Spezialfälle meistern: Einführungsprojekte,Delta Anforderungen, und Usability Engineering
490
22 Einführungsstrategien – ein Ratgeber für die organisierte REorganisation
493
22.1 Gründe für eine gute Strategie
494
22.1.1 Einführung bedeutet Veränderung
494
22.1.2 Nichts ist beständiger als der Wandel
495
22.1.3 Veränderung bedeutet Lernen
496
22.2 Eine Einführung ist ein Projekt!
499
22.2.1 Den Grundstein legen – Erstellung des fachlichen Konzepts
499
22.2.2 Die Umsetzung vorbereiten
501
22.2.3 Umsetzen und anpassen
506
22.3 Arbeitspakete einer Einführung
507
22.3.1 Marketingkonzept
507
22.3.2 Konzept zur Wissensvermittlung
508
22.3.3 Pilotierungskonzept
514
22.3.4 Migrationskonzept
517
22.4 Aufbruch in ein agile(RE)s Leben
520
22.4.1 Vom Wasserfall zur Agilität
521
22.4.2 Der hybride Ansatz: klassisches RE & agile Entwicklung
522
22.4.3 Flexibel und adaptiv: agiles RE & agile Entwicklung
524
23 Der Delta-Ansatz – jenseits der grünen Wiese
529
23.1 Delta-Anforderungen – die machen den Unterschied!
530
23.2 Das Vorgehen beim Delta-Ansatz
531
23.3 Delta-Ansatz oder neue Spezifikation?
537
23.4 Delta-Spezifikation im agilen Kontext
537
24 Requirements und Usability – wie sich Anforderungen undBenutzerfreundlichkeit ergänzen
539
24.1 Requirements und Usability
540
24.2 Das Persona-Konzept im Requirements-Engineering
542
24.2.1 Der Persona-Steckbrief
542
24.2.2 Das Wichtigste zuerst: die Identität
542
24.2.3 Demografische Variablen
543
24.2.4 Verhaltensvariablen
543
24.3 Der Persona-Steckbrief als Anforderungsquelle
545
24.4 Verifizieren von RE-Artefakten
545
24.5 Modellieren aus Benutzersicht
548
24.5.1 Der Nutzungsablauf als Modell
548
24.5.2 Begriffe und Zustände
549
24.6 Qualitätssicherung und Übergabe an das Design
549
A – ILIAS® – die neue Art des Lernens
551
B – Literaturverzeichnis
553
C – Fotoverzeichnis
563
Index
565
© 2009-2024 ciando GmbH