Das Handbuch für Anforderungen in jeder Situation
E-Book, Deutsch, 610 Seiten
ISBN: 978-3-446-46430-8
Verlag: Carl Hanser
Format: PDF
Kopierschutz: 1 - PDF Watermark
- Erlernen Sie das Ermitteln, Vermitteln, Herleiten und Verwalten von qualitativ hochwertigen Anforderungen.
- Meistern Sie Ihre Anforderungen in agilen Frameworks sowie in klassischen Vorgehensweisen.
- Tauchen Sie ein in die Welt der Smart Ecosystems.
- Lernen Sie das Zusammenspiel von Anforderungen und Architektur im Systems-Engineering kennen.
Der Erfolg von Systementwicklungen entscheidet sich bereits in der Anforderungsanalyse! Sie ist das Fundament für viele weitere Tätigkeiten.
Dieses Buch liefert Ihnen Hintergründe, Strategien, klare Konzepte und umfangreiche Praxistipps zur pragmatischen Umsetzung Ihrer Anforderungen – von der Erhebung bis hin zur Verwaltung.
Als neue Themen werden in der 7. Aufl age Requirements-Engineering im agilen Umfeld, Systems-Engineering und Smart Ecosystems betrachtet. Zusätzlich bietet diese Auflage Einblicke in den Einsatz von Videos im Requirements-Engineering, Crowd-RE und die Besonderheiten im Variantenmanagement.
Durch die Buchkapitel begleiten Sie ein durchgehendes Beispiel mit einer eigenen Rahmenhandlung und eine von Kapitel zu Kapitel aufbauende Bauanleitung für einen Requirements-Engineering-Leitfaden.
Im Internet finden Sie unter www.sophist.de/re7 zusätzliche Formulare, Checklisten, Hintergrundinformationen und vieles mehr.
AUS DEM INHALT //
Vorgehensweisen klassisch und agil/Anforderungsermittlung/SOPHIST-REgelwerk/Anforderungsschablonen/Anforderungsanalyse/Geschäftsprozesse/Systems-Engineering/Smart Ecosystems (Industrie 4.0)/Anforderungsdokumentation/klassisch und agil/Nichtfunktionale Anforderungen/Prüftechniken für Anforderungen/Anforderungskonsolidierung/Requirements-Management, Change- & Release-Management/Einführungsstrategien/Produktlinien und
Produktfamilien/Videos im Requirements-Engineering/Requirements-Engineering mit der Crowd
Autoren/Hrsg.
Fachgebiete
- Mathematik | Informatik EDV | Informatik Angewandte Informatik Wirtschaftsinformatik
- Wirtschaftswissenschaften Betriebswirtschaft Wirtschaftsinformatik, SAP, IT-Management
- Mathematik | Informatik EDV | Informatik Programmierung | Softwareentwicklung Software Engineering Modellierung, UML, SysML
- Wirtschaftswissenschaften Betriebswirtschaft Management Projektmanagement
Weitere Infos & Material
1;Inhaltsverzeichnis;2
2;Einleitung;18
3;Buchteil I - Einführung;24
3.1;Kapitel 1 - In medias RE - Grundlegendes zum Requirements-Engineering;26
3.1.1;1.1 Motivation für ein erfolgreiches Requirements-Engineering;27
3.1.1.1;1.1.1 Anforderungen an einen Requirements-Engineer;30
3.1.1.2;1.1.2 Der Wachstumsprozess eines Requirements-Engineers;31
3.1.2;1.2 Das Requirements-Gehirn – die Anforderungssammlung;33
3.1.3;1.3 Die Disziplin Requirements-Engineering;34
3.1.4;1.4 RE kompensiert die Beschränkung des menschlichenGehirns;37
3.1.4.1;1.4.1 Wissen verfällt bzw. diffundiert;38
3.1.4.2;1.4.2 Detailtiefe und Verständnis fehlt;39
3.1.4.3;1.4.3 Verlust des Gesamtüberblicks;40
3.1.4.4;1.4.4 Missverständnisse entstehen und bleiben;40
3.1.4.5;1.4.5 Abweichende Informationen verteilen sich;41
3.1.5;1.5 Typische Probleme im Requirements-Engineering;41
3.2;Kapitel 2 - Die Meyers und ihr Traum vom Smart Home;44
3.3;Kapitel 3 - Requirements-Engineering im Überblick - von der Idee zur Anforderung;46
3.3.1;3.1 Anforderungen ins Gesicht geschaut;47
3.3.1.1;3.1.1 Typen von Anforderungen;47
3.3.1.2;3.1.2 Zusammenhänge zwischen Anforderungen;52
3.3.1.3;3.1.3 Gute und perfekte klassische Anforderungen;55
3.3.1.4;3.1.4 Qualität von agilen Anforderungen;58
3.3.2;3.2 Requirements-Engineering aus der Vogelperspektive;60
3.3.2.1;3.2.1 Ursachen und Quellen von Anforderungen;60
3.3.2.2;3.2.2 Vom Wo und Wann des Requirements-Engineerings;64
3.3.2.3;3.2.3 Requirements-Engineering im Überblick;68
3.4;Kapitel 4 - RE ist nicht gleich RE - das richtige Maß finden;74
3.4.1;4.1 Requirements-Engineering in drei unterschiedlichenSzenarien;75
3.4.1.1;4.1.1 Szenario: Kundenanfrage bearbeiten;76
3.4.1.2;4.1.2 Szenario: Innovative Eigenentwicklung durchführen;77
3.4.1.3;4.1.3 Szenario: Subunternehmen beauftragen;78
3.4.2;4.2 So skalieren Sie RE;79
3.4.2.1;4.2.1 Einflussfaktoren;80
3.4.2.2;4.2.2 Variationspunkte im RE;85
3.4.3;4.3 RE in verschiedenen Vorgehensweisen;88
3.4.3.1;4.3.1 RE im Agilen;89
3.4.3.2;4.3.2 RE im klassischen Umfeld;93
4;Buchteil II - Wissen ermitteln;98
4.1;Kapitel 5 - Wegweiser: Wissen ermitteln;100
4.1.1;5.1 Die Grundlagen für eine Planung der Ermittlung;102
4.1.1.1;5.1.1 Ermittlungsgegenstand Ziele/Produktvision;102
4.1.1.2;5.1.2 Ermittlungsgegenstand Anforderungsquellen;103
4.1.1.3;5.1.3 Ermittlungsgegenstand Systemkontext;103
4.1.1.4;5.1.4 Ermittlungsgegenstand Anforderungen;103
4.1.1.5;5.1.5 Verknüpfung Ermittlungsgegenstand – Ermittlungstechnik;103
4.1.2;5.2 Das Vorgehen in der Planung der Ermittlung;104
4.1.2.1;5.2.1 Living Lab für eine kooperativ getriebene Ermittlung;104
4.2;Kapitel 6 - Ziele, Informanten und Fesseln - der erfolgreiche Start ins Requirements-Engineering;110
4.2.1;6.1 Ziele und Zielfindung oder Visionsbildung;111
4.2.1.1;6.1.1 Die derzeitige Realität unter die Lupe nehmen;113
4.2.1.2;6.1.2 Ziele definieren und bewerten;114
4.2.1.3;6.1.3 Arten von Zielen;114
4.2.1.4;6.1.4 Ziele beschreiben;115
4.2.1.5;6.1.5 Natürlichsprachliche Dokumentation mit Zielschablonen;116
4.2.1.6;6.1.6 Zieldokumentation als Produkt-/Projekt-Canvas;117
4.2.2;6.2 Anforderungsquellen ? Ausgangspunkt undMittelpunkt im RE-Universum;123
4.2.2.1;6.2.1 Der Stakeholder – das unbekannte Wesen;124
4.2.2.2;6.2.2 Das Persona-Konzept;128
4.2.3;6.3 Systemumfang und -kontext;130
4.2.3.1;6.3.1 Die Kontextabgrenzung;130
4.2.3.2;6.3.2 System- und Kontextgrenzen bestimmen;131
4.2.3.3;6.3.3 Dokumentation/Visualisierung des Systemumfangs und -kontext;133
4.3;Kapitel 7 - Geschäftsprozesse ermitteln und verfeinern - Einbettung in die Realität;136
4.3.1;7.1 Geschäftsprozessmanagementvs. Geschäftsprozessanalyse;137
4.3.2;7.2 Business-Use-Cases;138
4.3.2.1;7.2.1 Business-Use-Case-Diagramm;138
4.3.2.2;7.2.2 Business-Use-Case-Beschreibung;140
4.3.3;7.3 Business Process Model and Notation;141
4.3.4;7.4 Geschäftsregeln;143
4.3.4.1;7.4.1 Definition und Einsatzgebiete;143
4.3.4.2;7.4.2 Decision Model and Notation (DMN);143
4.4;Kapitel 8 - Anforderungsermittlung - Hellsehen für Fortgeschrittene;146
4.4.1;8.1 Ermittlung in der normalen und der smarten Welt;147
4.4.1.1;8.1.1 Vorbedingungen für eine gute Ermittlung;148
4.4.1.2;8.1.2 Kano-Modell;149
4.4.2;8.2 Kriterien für die Auswahl von Ermittlungstechniken;151
4.4.3;8.3 Ermittlungstechniken;157
4.4.3.1;8.3.1 Befragungstechniken;158
4.4.3.2;8.3.2 Beobachtungstechniken;164
4.4.3.3;8.3.3 Artefaktbasierte Techniken;170
4.4.3.4;8.3.4 Kreativitätstechniken;173
4.4.3.5;8.3.5 Co-Creation-Modelle, CrowdRE und Living Labs – neue Ansätze undFrameworks;175
4.4.4;8.4 SOPHIST-Ermittlungstechnikenauswahlmatrix;180
4.5;Kapitel 9 - Das SOPHIST-REgelwerk - Psychotherapie für Anforderungen;182
4.5.1;9.1 Vom Phänomen der Transformation – sprachliche Effekte;183
4.5.2;9.2 Die Wurzeln – das Neurolinguistische Programmieren;183
4.5.2.1;9.2.1 Transformationsprozesse;184
4.5.2.2;9.2.2 Kategorien der Darstellungstransformation;187
4.5.3;9.3 Der Umgang mit sprachlichen Effektenmit dem SOPHIST-REgelwerk;188
4.5.4;9.4 Die 17 Regeln des SOPHIST-REgelwerks;191
4.5.5;9.5 Anwendung des SOPHIST-REgelwerks;209
4.5.5.1;9.5.1 Anwendungsbeispiele;209
4.5.5.2;9.5.2 Sichten des REgelwerks;211
4.5.6;9.6 Wie erlerne ich das REgelwerk?;212
4.6;Kapitel 10 - CrowdRE - wenn die Masse Klasse bringt;214
4.6.1;10.1 Crowdsourcing;217
4.6.1.1;10.1.1 Der Crowdsourcing-Prozess;218
4.6.1.2;10.1.2 Crowdsourcing planen;218
4.6.1.3;10.1.3 Crowdsourcing durchführen;221
4.6.1.4;10.1.4 Crowdsourcing abschließen;222
4.6.2;10.2 Crowdsourcing leichtgemacht;223
5;Buchteil III - Gute Anforderungen herleiten;226
5.1;Kapitel 11 - Wegweiser: Gute Anforderungen herleiten;228
5.1.1;11.1 Was sind gute Anforderungen?;229
5.1.2;11.2 Der Prozess zur Herleitung guter Anforderungen;229
5.1.2.1;11.2.1 Die Vorbereitung – realistische Ziele setzen;231
5.1.2.2;11.2.2 Durchführung – ran an die Arbeit;234
5.1.2.3;11.2.3 Evaluierung;235
5.1.3;11.3 SHS-Szenarien;237
5.1.3.1;11.3.1 Szenario 1: Kundenanfrage bearbeiten;237
5.1.3.2;11.3.2 Szenario 2: Innovative Eigenentwicklung durchführen;238
5.1.3.3;11.3.3 Szenario 3: Subunternehmen beauftragen;239
5.2;Kapitel 12 - Anforderungen analysieren - vom Wunsch zur Absicht;240
5.2.1;12.1 Überblick über die Analyse von Anforderungen;241
5.2.1.1;12.1.1 Den Wald trotz vieler Bäume sehen;242
5.2.1.2;12.1.2 Der Ablauf bei der Anforderungsanalyse;243
5.2.2;12.2 Die Aufgaben im Detail;245
5.2.2.1;12.2.1 Anforderungen separieren;245
5.2.2.2;12.2.2 Notwendige Anforderungen extrahieren;247
5.2.2.3;12.2.3 Anforderungen abstrahieren;249
5.2.2.4;12.2.4 Fehlende Anforderungen ergänzen;250
5.2.2.5;12.2.5 Anforderungen verfeinern;252
5.2.2.6;12.2.6 Anforderungen verbessern;254
5.2.3;12.3 Angemessener Einsatz der Tätigkeiten;255
5.2.3.1;12.3.1 Die richtige Qualität erzeugen;256
5.2.3.2;12.3.2 Was wirklich benötigt wird;257
5.3;Kapitel 13 - Nicht-funktionale Anforderungen - die heimlichen Stars;260
5.3.1;13.1 Definition, Bedeutung und Chancen;261
5.3.2;13.2 Erhebungsprozess für NFAs;262
5.3.2.1;13.2.1 Vorbereitung;262
5.3.2.2;13.2.2 Ermitteln;263
5.3.2.3;13.2.3 Dokumentieren;265
5.3.2.4;13.2.4 Evaluierung;266
5.3.2.5;13.2.5 Best Practices;266
5.3.3;13.3 Steckbrief „Anforderungen an die Technologie“;267
5.3.4;13.4 Steckbrief „Qualitätsanforderungen“;269
5.3.5;13.5 Steckbrief „Anforderungen an dieBenutzungsoberfläche“;273
5.3.6;13.6 Steckbrief „Anforderungen an sonstigeLieferbestandteile“;275
5.3.7;13.7 Steckbrief „Anforderungen an durchzuführendeTätigkeiten“;276
5.3.8;13.8 Steckbrief „Rechtlich-vertragliche Anforderungen“;277
5.3.9;13.9 Fazit;279
5.4;Kapitel 14 - Prüftechniken für Anforderungen - ungeahntes Verbesserungspotential;280
5.4.1;14.1 Reviews;281
5.4.1.1;14.1.1 Stellungnahme;281
5.4.1.2;14.1.2 Walkthrough;282
5.4.1.3;14.1.3 Inspektion;284
5.4.2;14.2 Prototyp;285
5.4.3;14.3 Reverse Presentation;285
5.4.4;14.4 Metriken;286
5.4.5;14.5 Testfälle;287
5.4.6;14.6 Analysemodell;289
5.4.7;14.7 Hilfsmittel bei der Prüfung;291
5.4.7.1;14.7.1 Lesetechniken;291
5.4.7.2;14.7.2 Checklisten;291
5.4.7.3;14.7.3 SOPHIST-REgelwerk;292
5.4.7.4;14.7.4 Anforderungsschablone;292
5.4.8;14.8 Vom Durchblick im Dschungel der Prüftechniken:Die Auswahl geeigneter Prüftechniken;292
5.5;Kapitel 15 - Anforderungskonflikte - Gehasst? Geliebt? Gelöst!;294
5.5.1;15.1 Was ist ein Konflikt?;295
5.5.2;15.2 Konfliktidentifikation;296
5.5.2.1;15.2.1 Konfliktindikatoren in der Kommunikation;296
5.5.2.2;15.2.2 Konfliktindikatoren in der Dokumentation;297
5.5.3;15.3 Konfliktanalyse;297
5.5.3.1;15.3.1 Konfliktursachen;298
5.5.3.2;15.3.2 Konfliktentwicklung;299
5.5.3.3;15.3.3 Konfliktgegenstand/betroffene Anforderungen;299
5.5.3.4;15.3.4 Beteiligte Stakeholder;299
5.5.3.5;15.3.5 Konfliktpositionen;299
5.5.3.6;15.3.6 Konfliktarten;300
5.5.3.7;15.3.7 Konfliktfolgen;302
5.5.3.8;15.3.8 Konfliktrisiken;302
5.5.4;15.4 Konfliktauflösung;303
5.5.4.1;15.4.1 Konsolidierungstechniken;304
5.5.4.2;15.4.2 Auswahl der Konsolidierungstechniken;306
5.5.5;15.5 Dokumentation der Anforderungskonsolidierung;308
6;Buchteil IV - Anforderungen dokumentieren und vermitteln;310
6.1;Kapitel 16 - Wegweiser: Anforderungen dokumentieren und vermitteln;312
6.1.1;16.1 Anforderungen vermitteln;313
6.1.2;16.2 Wie plane ich die Vermittlung?;314
6.1.2.1;16.2.1 Vorbereitung;315
6.1.2.2;16.2.2 Durchführung;317
6.1.2.3;16.2.3 Evaluierung;317
6.1.3;16.3 Einflussfaktoren für die Vermittlung;318
6.1.3.1;16.3.1 Einflussfaktor: Ziel der Vermittlung/Inhalt;318
6.1.3.2;16.3.2 Einflussfaktor: Umfang des zu vermittelndenBetrachtungsgegenstandes;319
6.1.3.3;16.3.3 Einflussfaktor: Komplexität des Betrachtungsgegenstands;319
6.1.3.4;16.3.4 Einflussfaktor: Qualitätskriterien;320
6.1.3.5;16.3.5 Einflussfaktor: Vergessen und Wissensstabilität;320
6.1.3.6;16.3.6 Einflussfaktor: Wiederverwendung von Anforderungen;321
6.1.3.7;16.3.7 Einflussfaktor: Verfügbarkeit;322
6.1.3.8;16.3.8 Einflussfaktor: Normen, Standards und Vorgaben;322
6.1.3.9;16.3.9 Einflussfaktor: Sprache;322
6.1.3.10;16.3.10 Fazit;323
6.1.4;16.4 Anforderungen dokumentieren;323
6.1.4.1;16.4.1 Der Klassiker – die Anforderungsspezifikation;323
6.1.4.2;16.4.2 Die agile Welt – das Product-Backlog;324
6.2;Kapitel 17 - Storytelling, User-Storys und Co. - verschiedene Arten, Anforderungen zu vermitteln;326
6.2.1;17.1 Storytelling – Grimms Märchender Anforderungsvermittlung;327
6.2.1.1;17.1.1 Arten des Storytellings;328
6.2.1.2;17.1.2 Was macht gutes Storytelling aus?;329
6.2.1.3;17.1.3 Die irrelevanten Teile einer Story;330
6.2.1.4;17.1.4 Gute Geschichten für eine gute Vermittlung;331
6.2.2;17.2 User-Storys und Story Mapping;332
6.2.2.1;17.2.1 Verschiedene Detaillierungsebenen von User-Story –von Epics bis zu detaillierten User-Storys;333
6.2.2.2;17.2.2 Vermitteln mit User-Storys;333
6.2.2.3;17.2.3 Formulieren einer User-Story;334
6.2.2.4;17.2.4 Das Gespräch zu einer User-Story;335
6.2.2.5;17.2.5 Story Mapping – das Gesamtbild betrachten;336
6.2.2.6;17.2.6 Gute User-Storys für eine gute Vermittlung;337
6.2.3;17.3 Prototypen ? everybodys darling;337
6.2.3.1;17.3.1 Wireframe ? das Drahtmodell für den Bildschirm;337
6.2.3.2;17.3.2 Funktionaler Prototyp ? erlebte Funktion;339
6.2.3.3;17.3.3 Mock-up der Oberfläche ? das Designmodell;339
6.2.3.4;17.3.4 Gute Prototypen für eine gute Vermittlung;340
6.2.4;17.4 Bilder zur Vermittlung von Wissen;340
6.2.4.1;17.4.1 Definition der eigenen Bildsprache;342
6.2.4.2;17.4.2 Verbindliches von nicht Verbindlichem trennen;342
6.2.4.3;17.4.3 Kombination Bild mit anderen Techniken der Wissensvermittlung;343
6.2.4.4;17.4.4 Bilder für eine gute Vermittlung;344
6.2.5;17.5 Gemeinsam Artefakte erstellen;344
6.2.5.1;17.5.1 Vorbereitung;345
6.2.5.2;17.5.2 Überblick geben;345
6.2.5.3;17.5.3 Erstellen der Testfälle;346
6.2.5.4;17.5.4 Gemeinsam erstellte Artefakte für eine gute Vermittlung;347
6.3;Kapitel 18 - Anforderungen modellieren - malen statt schreiben;348
6.3.1;18.1 Modelle geben Struktur;349
6.3.2;18.2 Use-Case-basierte vs. zustandsbasierte Analyse;350
6.3.2.1;18.2.1 Use-Case-basierte Analyse;352
6.3.2.2;18.2.2 Zustandsbasierte Analyse;353
6.3.3;18.3 Use-Cases des Systems beschreiben;355
6.3.3.1;18.3.1 Das Use-Case-Diagramm;356
6.3.3.2;18.3.2 Die Use-Case-Beschreibung;358
6.3.4;18.4 Systemabläufe beschreiben;360
6.3.4.1;18.4.1 Systemabläufe in Aktivitäten beschreiben;361
6.3.4.2;18.4.2 Systemabläufe in Sequenzen beschreiben;363
6.3.5;18.5 System- und Objektzustände beschreiben;366
6.3.6;18.6 Begriffe und Informationsstrukturen beschreiben;368
6.3.6.1;18.6.1 Das Glossar;369
6.3.6.2;18.6.2 Das Informationsmodell ? Zusammenhänge von Fachbegriffen;370
6.4;Kapitel 19 - Schablonen für Anforderungen und User-Storys - MASTeR und andere Templates;374
6.4.1;19.1 Linguistische und philosophische Grundlagen;375
6.4.2;19.2 Der schablonenbasierte Ansatz;376
6.4.2.1;19.2.1 Der Bauplan einer Anforderung;376
6.4.2.2;19.2.2 AnwendungsgebieteWir;377
6.4.3;19.3 Schritt für Schritt zur Anforderung;378
6.4.3.1;19.3.1 Schritt 1: Betrachtungsgegenstand identifizieren;379
6.4.3.2;19.3.2 Schritt 2: Wichtigkeit festlegen;379
6.4.3.3;19.3.3 Schritt 3: Funktionalität identifizieren;379
6.4.3.4;19.3.4 Schritt 4: Art der Funktionalität festlegen;380
6.4.3.5;19.3.5 Schritt 5: Objekt identifizieren;382
6.4.3.6;19.3.6 Schritt 6: Bedingungen formulieren;382
6.4.3.7;19.3.7 Schritt 7: SOPHIST-REgelwerk anwenden;384
6.4.4;19.4 Semantische Präzisierung;384
6.4.4.1;19.4.1 Wichtigkeit definieren;385
6.4.4.2;19.4.2 Verben definieren;386
6.4.4.3;19.4.3 Substantive definieren;388
6.4.5;19.5 Details für die Konstruktion;390
6.4.5.1;19.5.1 Präzisierung des Objekts;391
6.4.5.2;19.5.2 Präzisierung des Verbs;391
6.4.6;19.6 Schnell und einfach zur User-Story;392
6.4.6.1;19.6.1 Aufbau und Inhalt einer User-Story;392
6.4.6.2;19.6.2 Aufbau und Inhalt von Akzeptanzkriterien für User-Storys;393
6.4.7;19.7 Nicht-funktionale Aspekte;394
6.4.7.1;19.7.1 Eigenschaften;395
6.4.7.2;19.7.2 Umgebungen und Kontext;396
6.4.7.3;19.7.3 Prozesse;399
6.4.8;19.8 Bedingungen;400
6.4.9;19.9 Schablonen innerhalb der Szenarien;403
6.4.9.1;19.9.1 Szenario 1 „Kundenanfrage bearbeiten“;403
6.4.9.2;19.9.2 Szenario 2 „Innovative Eigenentwicklung durchführen“;404
6.4.9.3;19.9.3 Szenario 3 „Subunternehmen beauftragen“;404
6.4.10;19.10 Auf die Sätze, fertig, los!;404
7;Buchteil V - Anforderungen verwalten;406
7.1;Kapitel 20 - Wegweiser: Anforderungen verwalten;408
7.1.1;20.1 Was ist Requirements-Management?;409
7.1.2;20.2 Grundannahmen für professionelles Requirements-Management – die drei Gebote;410
7.1.2.1;20.2.1 1. Grundannahme: Anforderungen ändern sich;411
7.1.2.2;20.2.2 2. Grundannahme: Anforderungen werden weiterverwendet;411
7.1.2.3;20.2.3 3. Grundannahme: Anforderungen sind nicht die einzige relevanteInformationsart für erfolgreiches Requirements-Engineering;411
7.1.3;20.3 Die Aufgaben professionellen Requirements-Managements;412
7.1.3.1;20.3.1 Informationsaustausch ? wer gibt wann wem was?;413
7.1.3.2;20.3.2 Ablaufsteuerung ? wer darf wann was?;413
7.1.3.3;20.3.3 Verwaltung von Abhängigkeiten und Nachvollziehbarkeit ?was hängt wie womit zusammen?;414
7.1.3.4;20.3.4 Auswertung und Projektsteuerung ? wie läuft’s?;414
7.1.4;20.4 Wie gestalte ich mein Requirements-Management?? Rahmenbedingungen, Einschränkungen undEinflussfaktoren;415
7.1.4.1;20.4.1 Wann ist wie viel Requirements-Management sinnvoll? –Rahmenbedingungen identifizieren;417
7.1.4.2;20.4.2 Das einzig Beständige ist der Wandel – Handlungsspielraumund -felder identifizieren;422
7.2;Kapitel 21 - Strukturen und Zustände - wider die Unordnung;424
7.2.1;21.1 Informationsarten definieren – was genausoll verwaltet werden?;425
7.2.2;21.2 Dokumentenlandschaft definieren;428
7.2.3;21.3 Anforderungssammlung strukturieren;431
7.2.3.1;21.3.1 Gliederungsstrukturen – das Skelett desRequirements-Managements;431
7.2.3.2;21.3.2 Standardgliederungen – das Rad nicht neu erfinden;432
7.2.3.3;21.3.3 Story Mapping – ein Product-Backlog strukturieren;435
7.2.4;21.4 Anforderungen strukturieren;436
7.2.4.1;21.4.1 Nicht-funktionale Anforderungen strukturieren;437
7.2.4.2;21.4.2 Funktionalitäten strukturieren;438
7.2.5;21.5 Zustände, Rechte und Rollen;440
7.2.5.1;21.5.1 Zustände einer Anforderung;440
7.2.5.2;21.5.2 Der Zustandsautomat einer Anforderung;441
7.2.5.3;21.5.3 Rollen identifizieren;448
7.2.5.4;21.5.4 Rechte vergeben;449
7.3;Kapitel 22 - Attribute, Traces, Historie - das Chaos verhindern;452
7.3.1;22.1 Attribuierung – Verwaltungsinformationenergänzen;453
7.3.1.1;22.1.1 Attributtypen definieren;454
7.3.1.2;22.1.2 Attribuierungsschema definieren;458
7.3.1.3;22.1.3 Die Objekt-ID – Anforderungen eindeutig identifizieren;460
7.3.2;22.2 Sichten bilden;461
7.3.2.1;22.2.1 Selektive Sichten – Informationen filtern, sortieren und gruppieren;461
7.3.2.2;22.2.2 Reporting – verdichtende Sichten;462
7.3.3;22.3 Anforderungen historisieren und versionieren;464
7.3.3.1;22.3.1 Anforderungen historisieren;464
7.3.3.2;22.3.2 Anforderungen versionieren;465
7.3.3.3;22.3.3 Konfigurationen und Basislinien;466
7.3.4;22.4 Verfolgbarkeit/Traceability herstellen;467
7.3.4.1;22.4.1 Die Eltern-Kind-Verbindung – Verfeinerungs- undAbleitungshierarchien abbilden;470
7.3.4.2;22.4.2 Verbindung von Informationen in gleichem Verfeinerungsgrad;471
7.3.4.3;22.4.3 Ein Verfolgbarkeitsmodell definieren;473
7.3.4.4;22.4.4 Umsetzung der Verfolgbarkeit;475
7.3.5;22.5 Change-Management –Anforderungsänderungen bearbeiten;476
7.3.5.1;22.5.1 Vom Änderungswunsch zur Umsetzung;478
7.3.5.2;22.5.2 Der Change-Management-Prozess;479
8;Buchteil VI - Weitere RE-Aspekte;482
8.1;Kapitel 23 - Systems-Engineering - Systemdenken und RE;484
8.1.1;23.1 Warum ein schnelleres Pferd noch kein Einhorn ist!;485
8.1.2;23.2 Das Twin-Peaks-Modell;487
8.1.3;23.3 Architektur im Systems-Engineering;488
8.1.3.1;23.3.1 Tätigkeiten in der Architektur;489
8.1.3.2;23.3.2 Black-Box-Sicht – technischer Kontext;489
8.1.3.3;23.3.3 White-Box-Sicht mit Blockdefinitionsdiagrammen;493
8.1.3.4;23.3.4 White-Box-Sicht mit dem Internen Blockdiagramm;493
8.1.4;23.4 Anforderung und Realisierung verbinden;495
8.1.4.1;23.4.1 Allokationssicht;495
8.1.4.2;23.4.2 Schnittstellen im Systems-Engineering;497
8.1.5;23.5 Mountain-View-Modell – Sichten im SE;498
8.1.5.1;23.5.1 Organisations-Peak;498
8.1.5.2;23.5.2 Testfall-Peak;499
8.1.5.3;23.5.3 Feature-Peak;499
8.1.5.4;23.5.4 Funktionale Wirkketten und weitere Sichten;500
8.1.6;23.6 Analysen und weitere Methoden;501
8.1.6.1;23.6.1 Quality Function Deployment;501
8.1.6.2;23.6.2 Hazard Analysis and Risk Assessment;503
8.1.6.3;23.6.3 Failure Mode and Effects Analysis;504
8.2;Kapitel 24 - Die digitale Revolution - Anforderungen an Smart Ecosystems und Industrie 4.0;506
8.2.1;24.1 Definition und Begriffsabgrenzung –„Smart Eco… was?“;507
8.2.1.1;24.1.1 Informations-, eingebettete und mobile Systeme –die Grundsystemarten;507
8.2.1.2;24.1.2 Emergente Systeme;508
8.2.1.3;24.1.3 Cyber-physische Systeme;509
8.2.1.4;24.1.4 Smarte Ökosysteme/Smart Ecosystems;509
8.2.2;24.2 Die digitale Transformation bzw. der digitaleWandel;511
8.2.3;24.3 Herausforderungen für die Entwicklung vonSystemen innerhalb eines Smart Ecosystems;512
8.2.3.1;24.3.1 Autonomie – jeder ist sich selbst der Nächste;512
8.2.3.2;24.3.2 Diversität – es lebe die Vielfalt;512
8.2.3.3;24.3.3 Komplexität – höher, schneller, weiter, größer;513
8.2.3.4;24.3.4 Selbstadaption – Maschinen als TÜV-Prüfer;513
8.2.3.5;24.3.5 Vernetzung – alles mit allem, jeder mit jedem;514
8.2.4;24.4 Einfluss der digitalen Transformation und SmartEcosystems auf das Requirements-Engineering;514
8.2.4.1;24.4.1 Auswirkungen der digitalen Transformation auf die Tätigkeiten desRequirements-Engineerings;514
8.2.4.2;24.4.2 Auswirkungen von Smart Ecosystems auf das Requirements-Engineering;516
8.2.5;24.5 Die Komplexität beherrschen – möglicheLösungsansätze zur Spezifikation im Rahmen vonSmart Ecosystems;519
8.2.5.1;24.5.1 Model-based Systems-Engineering;519
8.2.5.2;24.5.2 Künstliche Intelligenz;521
8.3;Kapitel 25 - RE für Produktlinien und -familien - auf dem Weg zum individuellen Massenprodukt;522
8.3.1;25.1 Von der Individualität der Masse;523
8.4;Kapitel 26 - Einführungsstrategien - ein Ratgeber für die organisierte REorganisation;540
8.4.1;26.1 Gründe für eine gute Strategie;541
8.4.1.1;26.1.1 Warum sollte ich mich ändern?;541
8.4.1.2;26.1.2 Und warum ist das nicht so einfach?;542
8.4.2;26.2 Eine Einführung ist ein Projekt!;543
8.4.3;26.3 Alle Wege führen nach …;544
8.4.3.1;26.3.1 Top-down-Einführung – alles Gute kommt von oben –Beschreibung der Enterprise-Transition-Community;545
8.4.3.2;26.3.2 Middle-out – Scrum-Software-Studio als Mittler zwischenden Welten;547
8.4.3.3;26.3.3 Bottom-up – teamweise, partiell oder unter der Tarnkappe;550
8.4.3.4;26.3.4 Best in Show – agiles Change-Management;552
8.4.4;26.4 Arbeitspakete einer Einführung;558
8.4.4.1;26.4.1 Marketingkonzept;558
8.4.4.2;26.4.2 Konzept zur Wissensvermittlung;559
8.4.4.3;26.4.3 Pilotierungskonzept;563
8.4.4.4;26.4.4 Migrationskonzept;565
8.5;Kapitel 27 - Videos im RE - Hollywood für Anforderungen;566
8.5.1;27.1 Warum Videos im RE?;567
8.5.2;27.2 Ein PILZ stellt sich vor;567
8.5.2.1;27.2.1 Phase;569
8.5.2.2;27.2.2 Inhalt;570
8.5.2.3;27.2.3 Lösungsbezug;570
8.5.2.4;27.2.4 Zeitbezug;571
8.5.2.5;27.2.5 PILZe sammeln in den Szenarien;571
8.5.2.6;27.2.6 Allgemeine Handlungsempfehlungen;573
8.5.2.7;27.2.7 Handlungsempfehlung Phase;573
8.5.2.8;27.2.8 Handlungsempfehlungen Inhalt;574
8.5.2.9;27.2.9 Handlungsempfehlungen Lösungsbezug;575
8.5.2.10;27.2.10 Handlungsempfehlungen Zeitbezug;576
8.5.3;27.3 Der Videoworkshop;577
8.5.4;27.4 Toll, ein Video … und jetzt?;578
9;Literaturverzeichnis;580
10;Video- und Animationsverzeichnis;1
11;Index;594
12;Werbeseiten;602
