Führen Sie Ihre IT-Projekte zum Erfolg!
Die Anforderungsanalyse entscheidet über den Erfolg von Projekten oder Produkten. Sie nimmt die zentrale Stellung in der Systementwicklung ein. Dieses Buch beschreibt den Prozess, Anforderungen an Systeme zu erheben und ihre ständige Veränderung zu managen. Es liefert Strategien, klare Konzepte und Tipps zur pragmatischen Umsetzung und beantwortet die Fragen: Wie komme ich zu den richtigen Zielen und Anforderungen? Wie dokumentiere ich Anforderungen verständlich? Wie vermeide ich inkonsistente, unvollständige Anforderungen? Wie manage ich Änderungen der Ziele und Anforderungen? Welche Notationen eignen sich zur Dokumentation einer bestimmten Anforderungsart? Wie beschleunige ich mit Templates und Patterns den Prozess? Wie sichere ich die Testbarkeit der Anforderungen? Wie messe ich den Projektfortschritt? Welche Rolle spielt der Mensch im Analyseprozess? Wie verwalte ich Anforderungen? Zahlreiche Expertenboxen, Beispiele, Templates und Checklisten sichern den Know-how-Transfer in die Projektarbeit. Im Internet: Formulare, Checklisten, Hintergrundinformationen und vieles mehr
Inhalt:
Einleitung. 1
Liebe Leserin, lieber Leser, . 1
Ihre Reiseleitung: die SOPHISTen 4
Ihre Meinung ist uns wichtig 4
Danksagungen. 5
Die Autoren 6
1 Anforderungsqualität - der Maßstab Ihres Projekterfolges 9
1.1 Motivation für eine erfolgreiche Systemanalyse 10
1.1.1 Primäre Aufgaben einer Anforderung . 11
1.1.2 Sekundäre Aufgaben einer Anforderung 12
1.1.3 Warum benötigen Sie ein funktionierendes Requirements- .. Management? ..12
1.2 Typische Probleme in der Anforderungsanalyse16
1.2.1 Herausforderungen und Projektrisiken 16
1.3 Qualitätskriterien für jede einzelne Anforderung20
1.3.1 Merkmale exzellenter Anforderungen. 21
1.4 Qualitätskriterien für die Anforderungsspezifikation27
1.5 Qualitätsstandards . 33
1.6 Management-Zusammenfassung 34
1.7 Ausreichend motiviert für ein exzellentes Requirements-Engineering? 35
1.8 Weiterführende Literatur 35
2 Das Bibliothekssystem - Einführung in das durchgehende Beispiel..37
3 Von der Idee zum System ..39
3.1 Das Need-to-Know-Prinzip40
3.1.1 Der richtige Zeitpunkt . 40
3.1.2 Das akkumulierte Wissen41
3.1.3 Strukturierung des Wissens 41
3.1.4 Änderungstendenz von Anforderungen42
3.2 Vorgehensmodelle. 42
3.2.1 Konzepte der Vorgehensmodelle 43
3.2.2 Rational Unified Process 43
3.2.3 V- Modell 46
3.2.4 Agile Prozesse . 49
3.2.5 eXtreme Programming 51
3.2.6 Systemanalyse-Prozesse.53
3.2.7 Die Rolle des Systemanalytikers 54
3.3 Object Engineering 55
3.3.1 Ziele, Stakeholder, Randbedingungen. 56
3.3.2 Natürlichsprachliche Anforderungen ..57
3.3.3 Das Analysemodell58
3.3.4 Die Abnahmekriterien .60
3.3.5 Das Simulationsmodell (Prototyp) 61
3.3.6 Agiler Einsatz des Object Engineering 63
3.3.7 Abhängigkeiten der Artefakte . 67
3.4 Projektrandbedingungen. 67
3.4.1 Menschliche Einflussfaktoren . 68
3.4.2 Organisatorische Rahmenbedingungen71
3.4.3 Fachlicher Inhalt der Anforderungen 73
3.4.4 Die optimale Systemanalyse 76
3.5 Management-Zusammenfassung 77
3.6 Ist Ihr Vorgehen optimal für Ihre Problemstellung? 78
3.7 Weiterführende Literatur 78
4 Anforderungsermittlung - Hellsehen für Fortgeschrittene .81
4.1 Ran an die Kundenforderungen82
4.1.1 Die Informationsquellen. 82
4.1.2 Geeignete Ermittlungstechniken 82
4.1.3 Die Qual der Wahl. 83
4.1.4 Die Projektrandbedingungen 83
4.2 Die entscheidenden Faktoren Ihres Produkts . 85
4.2.1 Basisfaktoren ermitteln 86
4.2.2 Leistungsfaktoren abholen. 87
4.2.3 Unbewusste Wünsche finden 87
4.3 Ermittlungstechniken - Kristallkugeln und Kartenlegen 88
4.3.1 Kreativitätstechniken88
4.3.2 Beobachtungstechniken..92
4.3.3 Befragungstechniken 94
4.3.4 Vergangenheitsorientierte Techniken..97
4.3.5 Unterstützende Techniken.99
4.3.6 Manöver des letzten Augenblicks 106
4.4 Techniken erfolgreicher Hellseher . 107
4.4.1 Entwicklung eines Bibliothekssystems 107
4.4.2 Entwicklung eines neuartigen elektronischen Spielzeugs108
4.5 Management-Zusammenfassung. 109
4.6 Kennen Sie die Chancen und Risiken Ihres Projekts? . 109
4.7 Weiterführende Literatur. 110
5 Stakeholder, Ziele und der Systemkontext ..113
5.1 Ziele finden 115
5.1.1 Stakeholder: Ausgangspunkt und Mittelpunkt . 116
5.1.2 Die derzeitige Realität unter die Lupe nehmen 117
5.1.3 Probleme erkunden und Optimierungspotenziale beschreiben. 117
5.1.4 Ziele definieren. 118
5.1.5 Ziele bewerten und entscheiden 119
5.2 Stakeholder finden119
5.2.1 Rollen von Stakeholdern . 121
5.2.2 Die Notation von Stakeholdern 125
5.2.3 Stakeholder-Relationship-Management - Die Pflege von
Stakeholdern..125
5.3 Ziele klassifizieren . 127
5.3.1 Klassifizierung von Zielen nach der Reichweite und dem Inhalt ..127
5.4 Ziele beschreiben. 130
5.5 Festlegung des Systemumfangs, -kontexts und der Systemgrenzen 131
5.5.1 Der Systembegriff 131
5.5.2 Die Kontextabgrenzung 133
5.6 Management-Zusammenfassung. 135
5.7 Kennen Sie Ihre Ziele, Fesseln und Informanten? . 135
5.8 Weiterführende Literatur. 136
6 Anforderung oder Anforderung - der feine Unterschied 137
6.1 Unterschiedliche Anforderungen 138
6.1.1 Der Begriff der Anforderung. 138
6.1.2 Notwendige Unterscheidungen. 139
6.2 Gruppierung nach Art 140
6.2.1 Arten von Anforderungen 140
6.2.2 Merkmale der einzelnen Gruppen 140
6.2.3 Gründe für die Gruppierung nach Art 142
6.3 Gruppierung nach Detailebene. 143
6.3.1 Gründe für die Gruppierung nach Detailebenen. 144
6.3.2 Die Detailebenen 0 bis 4144
6.4 Gruppierung nach Priorität. 147
6.4.1 Allgemeines 147
6.4.2 Kritikalität 149
6.4.3 Rechtliche Verbindlichkeit . 149
6.5 Beispiele 150
6.6 Management-Zusammenfassung. 153
6.7 Kontrollfragen 153
6.8 Weiterführende Literatur. 153
7 Dokumentation von Anforderungen - ausgewählte Notationen im Überblick.155
7.1 Einleitung 156
7.2 Strukturierte Analyse 157
7.2.1 Das Kontextdiagramm158
7.2.2 Verfeinerte Datenflussdiagramme159
7.3 Use-Cases: Diagramm und Spezifikation . 161
7.4 Das UML2-Aktivitätsdiagramm . 166
7.5 Die Ereignisgesteuerte Prozesskette168
7.6 Der UML2-Zustandsautomat 171
7.7 Der Programmablaufplan 173
7.8 Das Petrinetz . 175
7.9 Szenarien . 177
7.10 Das UML2-Sequenzdiagramm. 178
7.11 Die Specification and Description Language (SDL). 181
7.12 Entity-Relationship-Modellierung/ER-Diagramm. 184
7.13 Das UML2-Klassendiagramm186
7.14 Das UML2-Objektdiagramm 188
7.15 Oberflächenmodelle und -dialoge . 189
7.16 Entscheidungstabellen189
7.17 Natürlichsprachliche Anforderungen 190
7.18 Die Wahl der richtigen Dokumentationstechniken 190
7.18.1 Einflussfaktoren bei der Wahl der Dokumentationstechniken.190
7.18.2 Auswahlempfehlungen. 192
7.19 Management-Zusammenfassung. 193
7.20 Haben Sie die passende Dokumentationstechnik gefunden? 194
7.21 Weiterführende Literatur. 194
8 Der lange Weg vom Satz zur Anforderung..197
8.1 Das SOPHIST REgelwerk . 198
8.1.1 Übertragung auf die Anforderungsanalyse 198
8.2 Sprachliche Effekte 202
8.2.1 Tilgungen. 204
8.2.2 Generalisierungen 214
8.2.3 Verzerrungen . 220
8.3 Weitere Aspekte der linguistischen Analyse. 225
8.3.1 Redundanz225
8.3.2 Nebensätze227
8.3.3 Definitionen 228
8.3.4 Kommentare 231
8.3.5 Grafische Elemente in Anforderungen. 232
8.4 Der Algorithmus zum SOPHIST REgelwerk234
8.4.1 Der Algorithmus235
8.5 Management-Zusammenfassung. 236
8.6 Haben Sie Ihre Anforderungen auf die Couch gelegt? 237
8.7 Weiterführende Literatur. 237
9 Anforderungsschablone - der Bauplan einer Anforderung .239
9.1 Linguistische und philosophische Grundlagen. 240
9.2 Der schablonenbasierte Ansatz 241
9.3 Anforderungen - Schritt für Schritt242
9.4 Semantische Präzisierung der Anforderungsschablone251
9.4.1 Semantische Definitionen 251
9.4.2 Logische Operatoren255
9.5 Fallbeispiel: Bibliothek 258
9.6 Konstruieren im Englischen 261
9.7 Erfahrungen aus der Praxis. 263
9.7.1 Effektivität durch Softwareeinsatz . 263
9.8 Management-Zusammenfassung. 267
9.9 Sind Sie reif für Schablonen und eine definierte Begriffswelt? 267
9.10 Weiterführende Literatur. 268
10 Die nicht-funktionalen Anforderungen in der Systementwicklung ..269
10.1 Einleitung 270
10.2 Chancen durch nicht-funktionale Anforderungen270
10.3 Besonderheiten beim Requirements Engineering 274
10.4 Handreichungen 276
10.4.1 Standard-Gliederungen. 276
10.4.2 Wiederverwendung mit IVENA283
10.5 Management-Zusammenfassung. 286
10.6 Kontrollfragen 287
10.7 Weiterführende Literatur. 287
11 Prüfen von Anforderungen - ungeahntes Verbesserungspotenzial ..289
11.1 Analytische Qualitätssicherung 290
11.1.1 Ziel guter Anforderungen 290
11.1.2 Mängel und Fehler291
11.1.3 Vorgehen . 291
11.2 Prüfen von Anforderungen. 294
11.2.1 Prüftechniken. 295
11.2.2 Hilfsmittel bei der Prüfung . 299
11.2.3 Auswahl einer Technik. 300
11.3 Fehlerkorrektur. 302
11.3.1 Beheben von Fehlern. 302
11.3.2 Konsolidierung divergierender Meinungen 302
11.3.3 Analytiker als Moderator. 303
11.4 Management-Zusammenfassung. 304
11.5 Stellen Sie die Qualität Ihrer Anforderungen sicher? 304
11.6 Weiterführende Literatur. 305
12 Abnahmekriterien - der Prüfstein für Ihre Anforderungen 307
12.1 Einleitung 308
12.2 Arten von Abnahmekriterien. 312
12.2.1 Natürlichsprachliche Abnahmekriterien..312
12.2.2 Formalisierte Abnahmekriterien..316
12.3 Die richtigen Abnahmekriterien finden: Methoden und Strategien . 319
12.3.1 Funktionsabdeckung..321
12.3.2 Äquivalenzklassenbildung..322
12.3.3 Grenzwertanalyse 324
12.3.4 Intuitive Abnahmekriterien-Ermittlung326
12.3.5 Abnahmekriterien für nicht-funktionale Anforderungen 327
12.4 Mittels Abnahmekriterien Anforderungen verbessern. 330
12.4.1 Mittels formalisierter Abnahmekriterien Anforderungen verbessern..330
12.4.2 Mittels natürlichsprachlicher Abnahmekriterien Anforderungen verbessern..333
12.5 Testszenarien - der rote Faden für Abnahmekriterien . 336
12.6 Empfehlungen und Erfahrungen . 341
12.6.1 Formulieren Sie die Abnahmekriterien während der Analyse! 341
12.6.2 Formulieren Sie die Abnahmekriterien zu mittelfeinen . Anforderungen! 342
12.6.3 Werden Sie sich über das Ziel klar, das Sie mit
Abnahmekriterien verfolgen! 343
12.6.4 Achten Sie auf eine präzise Abbildung zwischen
Anforderung und Abnahmekriterium!. 344
12.6.5 Passen Sie die Art des Abnahmekriteriums der Art der ..
Anforderung an! ..344
12.6.6 Je höher die Kritikalität einer Anforderung ist, desto mehr .
Abnahmekriterien sind notwendig! 345
12.6.7 Abnahmekriterien für eine Anforderung soll jemand schreiben, der nicht die Anforderung geschrieben hat! 345
12.6.8 Verwenden Sie die Abnahmekriterien als Vertragsbestandteil!346
12.7 Management-Zusammenfassung. 346
12.8 Kontrollfragen 347
12.9 Weiterführende Literatur. 348
13 Ordnung im Chaos - Requirements-Management .349
13.1 Einleitung 350
13.1.1 Herausforderungen . 350
13.1.2 Auf den Rahmen kommt es an . 353
13.2 Stakeholder und Prozess - individuell für jedes Projekt. 355
13.2.1 Stakeholder und warum sie was fordern . 355
13.2.2 Prozessfindung . 357
13.3 Was verwaltet Requirements-Management 361
13.3.1 Welche Informationen . 362
13.3.2 und was zu den Informationen dazu. 363
13.4 Was das Wiederfinden erleichtert 364
13.4.1 Gliedern und Strukturieren . 366
13.4.2 Filtern und Sortieren370
13.5 Spielzüge des Requirements-Managements375
13.5.1 Traceability. 375
13.5.2 Versionierung und Verfeinerung . 377
13.5.3 System Release, Baseline, Branch379
13.5.4 Produktlinien und -familien 383
13.5.5 Auswertungen 384
13.6 Am Simulator 389
13.7 Management-Zusammenfassung. 394
13.8 Kennen Sie Ihr Chaos 394
13.9 Weiterführende Literatur. 395
14 Ergänzende Kurzgeschichten - was Sie vielleicht nicht wissen müssen..397
14.1 Requirements-Engineering & Offshore Development . 398
14.1.1 Heilsversprechungen des Offshoring. 398
14.1.2 Wie funktioniert Offshoring? 398
14.1.3 Vorteile von Offshoring 402
14.1.4 Risiken beim Offshoring . 404
14.1.5 Der Offshore-Vertrag 405
14.1.6 RE in Offshore-Projekten 405
14.1.7 Fazit 406
14.2 Benutzerhandbuch als Anforderungsspezifikation 407
14.2.1 Doppelter Aufwand 407
14.2.2 Überschneidungen der Artefakte . 408
14.2.3 Ziele und Leser der Artefakte 410
14.2.4 Das Vorgehen 410
14.2.5 Tipps für die Umsetzung . 412
14.2.6 Diskussion 415
14.2.7 Fazit 416
14.3 Abnahmekriterien als Spezifikation . 417
14.3.1 Die Vorgehensweise418
14.3.2 Erfahrungswerte und Richtlinien. 420
14.3.3 Vor- und Nachteile des Ansatzes. 421
14.4 Requirements-Engineering im Projekt 422
14.4.1 Einleitung 422
14.4.2 Die Praxis zeigt 423
14.4.3 Die Anforderungen. 423
14.4.4 zurück zur Praxis 424
14.4.5 Persönliche Erfahrungen425
14.4.6 Fazit 426
14.5 Anforderungsmuster427
14.5.1 Einführung427
14.5.2 Grundlagen zu Anforderungsmustern 428
14.5.3 Anforderungsmuster am Beispiel 431
14.5.4 Fazit 439
14.6 Optik - Haptik - Akustik und deren Spezifikation 440
14.6.1 Stakeholder der HMI und ihrer Spezifikation . 441
14.6.2 Eingrenzen weiterer Inhalte 443
14.6.3 Welche Arten von HMI-Spezifikationen werden benötigt? 445
14.6.4 Projektaufstellung aus HMI-Sicht 450
1.4.6.5 Fazit 451
14.7 Weiterführende Literatur. 452
15 Und jetzt? Strategien zur Einführung ..455
15.1 Grundsätzliche Überlegungen456
15.1.1 Einführung heißt Veränderung . 456
15.1.2 Angst und Widerstand und was Sie dagegen tun können457
15.2 Aktivitäten der Einführung. 459
15.2.1 Vorbereiten. 459
15.2.2 Umsetzen und anpassen 467
15.3 Pilotprojekte 468
15.3.1 Was macht Projekte für eine Erprobung geeignet? 469
15.3.2 Was macht Projekte für eine Erprobung ungeeignet? 470
15.3.3 Kernfragen470
15.4 Management-Zusammenfassung. 471
15.5 Kontrollfragen 472
15.6 Weiterführende Literatur. 472
Anhang
A Informationsarten .473
A.1 Spielzüge . 473
A.2 Abhängigkeiten zwischen verschiedenen Informationsarten 475
A.3 Verwaltungsinformationen. 476
A.4 Bewertungsrahmen. 479
B Regelwerk und Algorithmus der linguistischen Analyse485
C Anforderungsschablonen489
C.1 EBNF 490
C.2 Anforderungsschablonen für die deutsche Sprache . 491
C.3 Anforderungsschablonen für die englische Sprache 493
D Unsere Ahnen - ein Streifzug durch die Linguistik und analytische Philosophie .495
E Glossar 497
Die Anforderungsanalyse entscheidet über den Erfolg von Projekten oder Produkten. Sie nimmt die zentrale Stellung in der Systementwicklung ein. Dieses Buch beschreibt den Prozess, Anforderungen an Systeme zu erheben und ihre ständige Veränderung zu managen. Es liefert Strategien, klare Konzepte und Tipps zur pragmatischen Umsetzung und beantwortet die Fragen: Wie komme ich zu den richtigen Zielen und Anforderungen? Wie dokumentiere ich Anforderungen verständlich? Wie vermeide ich inkonsistente, unvollständige Anforderungen? Wie manage ich Änderungen der Ziele und Anforderungen? Welche Notationen eignen sich zur Dokumentation einer bestimmten Anforderungsart? Wie beschleunige ich mit Templates und Patterns den Prozess? Wie sichere ich die Testbarkeit der Anforderungen? Wie messe ich den Projektfortschritt? Welche Rolle spielt der Mensch im Analyseprozess? Wie verwalte ich Anforderungen? Zahlreiche Expertenboxen, Beispiele, Templates und Checklisten sichern den Know-how-Transfer in die Projektarbeit. Im Internet: Formulare, Checklisten, Hintergrundinformationen und vieles mehr
Inhalt:
Einleitung. 1
Liebe Leserin, lieber Leser, . 1
Ihre Reiseleitung: die SOPHISTen 4
Ihre Meinung ist uns wichtig 4
Danksagungen. 5
Die Autoren 6
1 Anforderungsqualität - der Maßstab Ihres Projekterfolges 9
1.1 Motivation für eine erfolgreiche Systemanalyse 10
1.1.1 Primäre Aufgaben einer Anforderung . 11
1.1.2 Sekundäre Aufgaben einer Anforderung 12
1.1.3 Warum benötigen Sie ein funktionierendes Requirements- .. Management? ..12
1.2 Typische Probleme in der Anforderungsanalyse16
1.2.1 Herausforderungen und Projektrisiken 16
1.3 Qualitätskriterien für jede einzelne Anforderung20
1.3.1 Merkmale exzellenter Anforderungen. 21
1.4 Qualitätskriterien für die Anforderungsspezifikation27
1.5 Qualitätsstandards . 33
1.6 Management-Zusammenfassung 34
1.7 Ausreichend motiviert für ein exzellentes Requirements-Engineering? 35
1.8 Weiterführende Literatur 35
2 Das Bibliothekssystem - Einführung in das durchgehende Beispiel..37
3 Von der Idee zum System ..39
3.1 Das Need-to-Know-Prinzip40
3.1.1 Der richtige Zeitpunkt . 40
3.1.2 Das akkumulierte Wissen41
3.1.3 Strukturierung des Wissens 41
3.1.4 Änderungstendenz von Anforderungen42
3.2 Vorgehensmodelle. 42
3.2.1 Konzepte der Vorgehensmodelle 43
3.2.2 Rational Unified Process 43
3.2.3 V- Modell 46
3.2.4 Agile Prozesse . 49
3.2.5 eXtreme Programming 51
3.2.6 Systemanalyse-Prozesse.53
3.2.7 Die Rolle des Systemanalytikers 54
3.3 Object Engineering 55
3.3.1 Ziele, Stakeholder, Randbedingungen. 56
3.3.2 Natürlichsprachliche Anforderungen ..57
3.3.3 Das Analysemodell58
3.3.4 Die Abnahmekriterien .60
3.3.5 Das Simulationsmodell (Prototyp) 61
3.3.6 Agiler Einsatz des Object Engineering 63
3.3.7 Abhängigkeiten der Artefakte . 67
3.4 Projektrandbedingungen. 67
3.4.1 Menschliche Einflussfaktoren . 68
3.4.2 Organisatorische Rahmenbedingungen71
3.4.3 Fachlicher Inhalt der Anforderungen 73
3.4.4 Die optimale Systemanalyse 76
3.5 Management-Zusammenfassung 77
3.6 Ist Ihr Vorgehen optimal für Ihre Problemstellung? 78
3.7 Weiterführende Literatur 78
4 Anforderungsermittlung - Hellsehen für Fortgeschrittene .81
4.1 Ran an die Kundenforderungen82
4.1.1 Die Informationsquellen. 82
4.1.2 Geeignete Ermittlungstechniken 82
4.1.3 Die Qual der Wahl. 83
4.1.4 Die Projektrandbedingungen 83
4.2 Die entscheidenden Faktoren Ihres Produkts . 85
4.2.1 Basisfaktoren ermitteln 86
4.2.2 Leistungsfaktoren abholen. 87
4.2.3 Unbewusste Wünsche finden 87
4.3 Ermittlungstechniken - Kristallkugeln und Kartenlegen 88
4.3.1 Kreativitätstechniken88
4.3.2 Beobachtungstechniken..92
4.3.3 Befragungstechniken 94
4.3.4 Vergangenheitsorientierte Techniken..97
4.3.5 Unterstützende Techniken.99
4.3.6 Manöver des letzten Augenblicks 106
4.4 Techniken erfolgreicher Hellseher . 107
4.4.1 Entwicklung eines Bibliothekssystems 107
4.4.2 Entwicklung eines neuartigen elektronischen Spielzeugs108
4.5 Management-Zusammenfassung. 109
4.6 Kennen Sie die Chancen und Risiken Ihres Projekts? . 109
4.7 Weiterführende Literatur. 110
5 Stakeholder, Ziele und der Systemkontext ..113
5.1 Ziele finden 115
5.1.1 Stakeholder: Ausgangspunkt und Mittelpunkt . 116
5.1.2 Die derzeitige Realität unter die Lupe nehmen 117
5.1.3 Probleme erkunden und Optimierungspotenziale beschreiben. 117
5.1.4 Ziele definieren. 118
5.1.5 Ziele bewerten und entscheiden 119
5.2 Stakeholder finden119
5.2.1 Rollen von Stakeholdern . 121
5.2.2 Die Notation von Stakeholdern 125
5.2.3 Stakeholder-Relationship-Management - Die Pflege von
Stakeholdern..125
5.3 Ziele klassifizieren . 127
5.3.1 Klassifizierung von Zielen nach der Reichweite und dem Inhalt ..127
5.4 Ziele beschreiben. 130
5.5 Festlegung des Systemumfangs, -kontexts und der Systemgrenzen 131
5.5.1 Der Systembegriff 131
5.5.2 Die Kontextabgrenzung 133
5.6 Management-Zusammenfassung. 135
5.7 Kennen Sie Ihre Ziele, Fesseln und Informanten? . 135
5.8 Weiterführende Literatur. 136
6 Anforderung oder Anforderung - der feine Unterschied 137
6.1 Unterschiedliche Anforderungen 138
6.1.1 Der Begriff der Anforderung. 138
6.1.2 Notwendige Unterscheidungen. 139
6.2 Gruppierung nach Art 140
6.2.1 Arten von Anforderungen 140
6.2.2 Merkmale der einzelnen Gruppen 140
6.2.3 Gründe für die Gruppierung nach Art 142
6.3 Gruppierung nach Detailebene. 143
6.3.1 Gründe für die Gruppierung nach Detailebenen. 144
6.3.2 Die Detailebenen 0 bis 4144
6.4 Gruppierung nach Priorität. 147
6.4.1 Allgemeines 147
6.4.2 Kritikalität 149
6.4.3 Rechtliche Verbindlichkeit . 149
6.5 Beispiele 150
6.6 Management-Zusammenfassung. 153
6.7 Kontrollfragen 153
6.8 Weiterführende Literatur. 153
7 Dokumentation von Anforderungen - ausgewählte Notationen im Überblick.155
7.1 Einleitung 156
7.2 Strukturierte Analyse 157
7.2.1 Das Kontextdiagramm158
7.2.2 Verfeinerte Datenflussdiagramme159
7.3 Use-Cases: Diagramm und Spezifikation . 161
7.4 Das UML2-Aktivitätsdiagramm . 166
7.5 Die Ereignisgesteuerte Prozesskette168
7.6 Der UML2-Zustandsautomat 171
7.7 Der Programmablaufplan 173
7.8 Das Petrinetz . 175
7.9 Szenarien . 177
7.10 Das UML2-Sequenzdiagramm. 178
7.11 Die Specification and Description Language (SDL). 181
7.12 Entity-Relationship-Modellierung/ER-Diagramm. 184
7.13 Das UML2-Klassendiagramm186
7.14 Das UML2-Objektdiagramm 188
7.15 Oberflächenmodelle und -dialoge . 189
7.16 Entscheidungstabellen189
7.17 Natürlichsprachliche Anforderungen 190
7.18 Die Wahl der richtigen Dokumentationstechniken 190
7.18.1 Einflussfaktoren bei der Wahl der Dokumentationstechniken.190
7.18.2 Auswahlempfehlungen. 192
7.19 Management-Zusammenfassung. 193
7.20 Haben Sie die passende Dokumentationstechnik gefunden? 194
7.21 Weiterführende Literatur. 194
8 Der lange Weg vom Satz zur Anforderung..197
8.1 Das SOPHIST REgelwerk . 198
8.1.1 Übertragung auf die Anforderungsanalyse 198
8.2 Sprachliche Effekte 202
8.2.1 Tilgungen. 204
8.2.2 Generalisierungen 214
8.2.3 Verzerrungen . 220
8.3 Weitere Aspekte der linguistischen Analyse. 225
8.3.1 Redundanz225
8.3.2 Nebensätze227
8.3.3 Definitionen 228
8.3.4 Kommentare 231
8.3.5 Grafische Elemente in Anforderungen. 232
8.4 Der Algorithmus zum SOPHIST REgelwerk234
8.4.1 Der Algorithmus235
8.5 Management-Zusammenfassung. 236
8.6 Haben Sie Ihre Anforderungen auf die Couch gelegt? 237
8.7 Weiterführende Literatur. 237
9 Anforderungsschablone - der Bauplan einer Anforderung .239
9.1 Linguistische und philosophische Grundlagen. 240
9.2 Der schablonenbasierte Ansatz 241
9.3 Anforderungen - Schritt für Schritt242
9.4 Semantische Präzisierung der Anforderungsschablone251
9.4.1 Semantische Definitionen 251
9.4.2 Logische Operatoren255
9.5 Fallbeispiel: Bibliothek 258
9.6 Konstruieren im Englischen 261
9.7 Erfahrungen aus der Praxis. 263
9.7.1 Effektivität durch Softwareeinsatz . 263
9.8 Management-Zusammenfassung. 267
9.9 Sind Sie reif für Schablonen und eine definierte Begriffswelt? 267
9.10 Weiterführende Literatur. 268
10 Die nicht-funktionalen Anforderungen in der Systementwicklung ..269
10.1 Einleitung 270
10.2 Chancen durch nicht-funktionale Anforderungen270
10.3 Besonderheiten beim Requirements Engineering 274
10.4 Handreichungen 276
10.4.1 Standard-Gliederungen. 276
10.4.2 Wiederverwendung mit IVENA283
10.5 Management-Zusammenfassung. 286
10.6 Kontrollfragen 287
10.7 Weiterführende Literatur. 287
11 Prüfen von Anforderungen - ungeahntes Verbesserungspotenzial ..289
11.1 Analytische Qualitätssicherung 290
11.1.1 Ziel guter Anforderungen 290
11.1.2 Mängel und Fehler291
11.1.3 Vorgehen . 291
11.2 Prüfen von Anforderungen. 294
11.2.1 Prüftechniken. 295
11.2.2 Hilfsmittel bei der Prüfung . 299
11.2.3 Auswahl einer Technik. 300
11.3 Fehlerkorrektur. 302
11.3.1 Beheben von Fehlern. 302
11.3.2 Konsolidierung divergierender Meinungen 302
11.3.3 Analytiker als Moderator. 303
11.4 Management-Zusammenfassung. 304
11.5 Stellen Sie die Qualität Ihrer Anforderungen sicher? 304
11.6 Weiterführende Literatur. 305
12 Abnahmekriterien - der Prüfstein für Ihre Anforderungen 307
12.1 Einleitung 308
12.2 Arten von Abnahmekriterien. 312
12.2.1 Natürlichsprachliche Abnahmekriterien..312
12.2.2 Formalisierte Abnahmekriterien..316
12.3 Die richtigen Abnahmekriterien finden: Methoden und Strategien . 319
12.3.1 Funktionsabdeckung..321
12.3.2 Äquivalenzklassenbildung..322
12.3.3 Grenzwertanalyse 324
12.3.4 Intuitive Abnahmekriterien-Ermittlung326
12.3.5 Abnahmekriterien für nicht-funktionale Anforderungen 327
12.4 Mittels Abnahmekriterien Anforderungen verbessern. 330
12.4.1 Mittels formalisierter Abnahmekriterien Anforderungen verbessern..330
12.4.2 Mittels natürlichsprachlicher Abnahmekriterien Anforderungen verbessern..333
12.5 Testszenarien - der rote Faden für Abnahmekriterien . 336
12.6 Empfehlungen und Erfahrungen . 341
12.6.1 Formulieren Sie die Abnahmekriterien während der Analyse! 341
12.6.2 Formulieren Sie die Abnahmekriterien zu mittelfeinen . Anforderungen! 342
12.6.3 Werden Sie sich über das Ziel klar, das Sie mit
Abnahmekriterien verfolgen! 343
12.6.4 Achten Sie auf eine präzise Abbildung zwischen
Anforderung und Abnahmekriterium!. 344
12.6.5 Passen Sie die Art des Abnahmekriteriums der Art der ..
Anforderung an! ..344
12.6.6 Je höher die Kritikalität einer Anforderung ist, desto mehr .
Abnahmekriterien sind notwendig! 345
12.6.7 Abnahmekriterien für eine Anforderung soll jemand schreiben, der nicht die Anforderung geschrieben hat! 345
12.6.8 Verwenden Sie die Abnahmekriterien als Vertragsbestandteil!346
12.7 Management-Zusammenfassung. 346
12.8 Kontrollfragen 347
12.9 Weiterführende Literatur. 348
13 Ordnung im Chaos - Requirements-Management .349
13.1 Einleitung 350
13.1.1 Herausforderungen . 350
13.1.2 Auf den Rahmen kommt es an . 353
13.2 Stakeholder und Prozess - individuell für jedes Projekt. 355
13.2.1 Stakeholder und warum sie was fordern . 355
13.2.2 Prozessfindung . 357
13.3 Was verwaltet Requirements-Management 361
13.3.1 Welche Informationen . 362
13.3.2 und was zu den Informationen dazu. 363
13.4 Was das Wiederfinden erleichtert 364
13.4.1 Gliedern und Strukturieren . 366
13.4.2 Filtern und Sortieren370
13.5 Spielzüge des Requirements-Managements375
13.5.1 Traceability. 375
13.5.2 Versionierung und Verfeinerung . 377
13.5.3 System Release, Baseline, Branch379
13.5.4 Produktlinien und -familien 383
13.5.5 Auswertungen 384
13.6 Am Simulator 389
13.7 Management-Zusammenfassung. 394
13.8 Kennen Sie Ihr Chaos 394
13.9 Weiterführende Literatur. 395
14 Ergänzende Kurzgeschichten - was Sie vielleicht nicht wissen müssen..397
14.1 Requirements-Engineering & Offshore Development . 398
14.1.1 Heilsversprechungen des Offshoring. 398
14.1.2 Wie funktioniert Offshoring? 398
14.1.3 Vorteile von Offshoring 402
14.1.4 Risiken beim Offshoring . 404
14.1.5 Der Offshore-Vertrag 405
14.1.6 RE in Offshore-Projekten 405
14.1.7 Fazit 406
14.2 Benutzerhandbuch als Anforderungsspezifikation 407
14.2.1 Doppelter Aufwand 407
14.2.2 Überschneidungen der Artefakte . 408
14.2.3 Ziele und Leser der Artefakte 410
14.2.4 Das Vorgehen 410
14.2.5 Tipps für die Umsetzung . 412
14.2.6 Diskussion 415
14.2.7 Fazit 416
14.3 Abnahmekriterien als Spezifikation . 417
14.3.1 Die Vorgehensweise418
14.3.2 Erfahrungswerte und Richtlinien. 420
14.3.3 Vor- und Nachteile des Ansatzes. 421
14.4 Requirements-Engineering im Projekt 422
14.4.1 Einleitung 422
14.4.2 Die Praxis zeigt 423
14.4.3 Die Anforderungen. 423
14.4.4 zurück zur Praxis 424
14.4.5 Persönliche Erfahrungen425
14.4.6 Fazit 426
14.5 Anforderungsmuster427
14.5.1 Einführung427
14.5.2 Grundlagen zu Anforderungsmustern 428
14.5.3 Anforderungsmuster am Beispiel 431
14.5.4 Fazit 439
14.6 Optik - Haptik - Akustik und deren Spezifikation 440
14.6.1 Stakeholder der HMI und ihrer Spezifikation . 441
14.6.2 Eingrenzen weiterer Inhalte 443
14.6.3 Welche Arten von HMI-Spezifikationen werden benötigt? 445
14.6.4 Projektaufstellung aus HMI-Sicht 450
1.4.6.5 Fazit 451
14.7 Weiterführende Literatur. 452
15 Und jetzt? Strategien zur Einführung ..455
15.1 Grundsätzliche Überlegungen456
15.1.1 Einführung heißt Veränderung . 456
15.1.2 Angst und Widerstand und was Sie dagegen tun können457
15.2 Aktivitäten der Einführung. 459
15.2.1 Vorbereiten. 459
15.2.2 Umsetzen und anpassen 467
15.3 Pilotprojekte 468
15.3.1 Was macht Projekte für eine Erprobung geeignet? 469
15.3.2 Was macht Projekte für eine Erprobung ungeeignet? 470
15.3.3 Kernfragen470
15.4 Management-Zusammenfassung. 471
15.5 Kontrollfragen 472
15.6 Weiterführende Literatur. 472
Anhang
A Informationsarten .473
A.1 Spielzüge . 473
A.2 Abhängigkeiten zwischen verschiedenen Informationsarten 475
A.3 Verwaltungsinformationen. 476
A.4 Bewertungsrahmen. 479
B Regelwerk und Algorithmus der linguistischen Analyse485
C Anforderungsschablonen489
C.1 EBNF 490
C.2 Anforderungsschablonen für die deutsche Sprache . 491
C.3 Anforderungsschablonen für die englische Sprache 493
D Unsere Ahnen - ein Streifzug durch die Linguistik und analytische Philosophie .495
E Glossar 497