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 |