Requirements-Engineering und -Management - Aus der Praxis von klassisch bis agil

Christine Rupp, die SOPHISTen

Requirements-Engineering und -Management

Aus der Praxis von klassisch bis agil

2014

570 Seiten

Format: PDF, Online Lesen

E-Book: €  39,99

E-Book kaufen

E-Book kaufen

ISBN: 9783446443136

 

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-2018 ciando GmbH