Requirements-Engineering und -Management

Requirements-Engineering und -Management - Aus der Praxis von klassich bis agil - 6., aktualisierte und erweiterte Auflage

Inhaltsverzeichnis

Einleitung

Was Sie in diesem Buch erwartet

Die SOPHISTen: Alt und Neu

Neue Erknenntisse und bewährtes Wissen

Das Team

Wissen erarbeiten: Selbsttest und Blended Learning mit ILIAS®

Wissen beschreiben: Kapitel für Kapitel zum RE-Leitfaden

TEIL I - Requirements- Engineering zum Erfolg bringen

1 In medias RE

1.1 Motivation für eine erfolgreiche Systemanalyse

1.2 Der Requirements-Engineer – Mittler zwischen den Welten

1.3 Das Requirementsgehirn

1.4 Die Disziplin Requirements-Engineering

1.5 Die Einteilung von Anforderungen

1.5.1 Einteilung von Anforderungen nach ihrer Art

1.5.2 Einteilung von Anforderungen nach ihrer rechtlichen Verbindlichkeit

1.6 Gründe für Dokumentation

1.6.1 Wissen verfällt bzw. diffundiert

1.6.2 Detailtiefe und Verständnis fehlt

1.6.3 Verlust des Gesamtüberblicks

1.6.4 Missverständnisse entstehen und bleiben

1.6.5 Abweichende Informationen verteilen s

1.7 Typische Probleme in der Anforderungsanalyse

1.8 Qualitätskriterien im Requirements-Engineering

1.8.1 Qualitätskriterien für jede einzelne Anforderung

1.8.2 Qualitätskriterien für die Anforderungsspezifikation

1.8.3 Pragmatische Aspekte von Anforderungen und Anforderungsspezifikationen

2 Das Bibliothekssystem – wie alles begann

3 Von der Idee zur Spezifikation

3.1 Von der richtigen Anforderungsmenge

3.2 Der Zusammenhang zwischen Anforderungen

3.2.1 Anforderungen und die Architektur

3.2.2 Anforderungen und deren Verfeinerungen

3.2.3 Detaillierungsebenen

3.3 Die Systemanalyse im Überblick

3.3.1 Anforderungen herleiten

3.3.2 Anforderungen zum richtigen Zeitpunkt

3.4 Das Vorgehen in der Projektpraxis

4 Agile und andere Vorgehensweisen

4.1 Konventionelle Vorgehensmodelle und Qualitätsstandards

4.2 Agile Vorgehensweisen

4.2.1 Kanban

4.2.2 Scrum

4.3 RE und Scrum

4.3.1 Integrationsmöglichkeiten von RE in Scrum

4.3.2 Dokumentieren von Anforderungen in Scrum

4.3.3 RE als Scrum-Projekt

4.3.4 RE ist immer agil

Teil II - Anforderungen ermitteln

5 Ziele, Informanten und Fesseln

5.1 Die wichtigsten Schritte vor dem Start in die Systemanalyse

5.1.1 Anforderungsquellen: Ausgangspunkt und Mittelpunkt

5.1.2 Die derzeitige Realität unter die Lupe nehmen

5.1.3 Probleme erkunden und Optimierungspotenziale beschreiben

5.1.4 Ziele definieren und bewerten

5.2 Der Stakeholder – das unbekannte Wesen

5.2.1 Die Notation von Stakeholdern

5.2.2 Stakeholder-Relationship-Management – die Pflegevon Stakeholdern

5.3 Ziele beschreiben

5.4 Umfang, Kontext und Grenzen des Systems festlegen

5.4.1 Die Kontextabgrenzung

5.4.2 System- und Kontextgrenzen bestimmen

6 Anforderungsermittlung – Hellsehen für Fortgeschrittene

6.1 Ran an die Kundenwünsche

6.1.1 Aller Anfang ist schwer

6.1.2 Kommunikationsmodelle

6.1.3 Repräsentationssysteme der Sprache

6.1.4 Die Qual der Wahl

6.2 Die entscheidenden Produktfaktoren

6.2.1 Basisfaktoren ausgraben

6.2.2 Leistungsfaktoren abholen

6.2.3 Begeisterungsfaktoren erarbeiten

6.3 Ermittlungstechniken

6.3.1 Kreativitätstechniken

6.3.2 Beobachtungstechniken

6.3.3 Befragungstechniken

6.3.4 Artefaktbasierte Techniken

6.3.5 Unterstützende Techniken

6.4 Anwendung in der Praxis

7 Das SOPHIST-REgelwerk – Psychotherapie für Anforderungen

7.1 Vom Phänomen der Transformation – sprachliche Effekte

7.2 Die Wurzeln – das Neurolinguistische Programmieren

7.2.1 Transformationsprozesse

7.2.2 Kategorien der Darstellungstransformation

7.3 Vom Umgang mit sprachlichen Effekten

7.4 Das Vorgehen beim SOPHIST-REgelwerk – Anforderungen auf die Couch gelegt

7.5 Prüfen der Satzbestandteile

7.5.1 Prüfen der Prozesse

7.5.2 Prüfen von Eigenschaften

7.5.3 Prüfen von Mengen und Häufigkeiten

7.5.4 Prüfen von Begriffen, die Möglichkeiten beschreiben

7.6 Prüfen des Satzes

7.7 Prüfen des Gesamtbilds

7.8 Anwendung des SOPHIST-REgelwerks

Teil III - Anforderungen formulieren

8 Grundlagen für die Systemanalyse dokumentieren

8.1 Ausgangssituation beschreiben? Ja bitte!

8.2 Geschäftsprozessbeschreibung

8.2.1 Business-Use-Cases

8.2.2 Ablaufdiagramme

8.2.3 Geschäftsregeln

8.3 Ziele dokumentieren

8.4 Kontextvisualisierung

8.4.1 Use-Case-Diagramm zur Kontextvisualisierung

8.4.2 Kontextdiagramm der Strukturierten Analyse

8.5 Begriffe und Definitionen

9 Systemanforderungen dokumentieren – malen oder schreiben?

9.1 Dokumentation? Ja bitte!

9.2 Anforderungen in Prosa beschreiben

9.3 Szenarien

9.4 Das System-Use-Case-Diagramm

9.5 Die Use-Case-Beschreibung

9.6 Das Aktivitätsdiagramm

9.7 Das Sequenzdiagramm

9.8 Zustandsdiagramm

9.9 Das Klassendiagramm als Begriffsmodell

9.10 Beschreibung von Systemregeln

9.11 Anforderungen verfeinern

9.11.1 Diagramme verfeinern/konkretisieren/detaillieren

9.11.2 Tipps zum Thema Detaillierung

9.12 Die Wahl der richtigen Dokumentationstechniken

9.12.1 Einflussfaktoren auf die Wahl der Dokumentationstechniken

9.12.2 Auswahlempfehlungen

9.12.3 Diagramm oder doch lieber natürliche Sprache?

10 Anforderungsschablonen – der MASTER-Plan für gute Anforderungen

10.1 Linguistische und philosophische Grundlagen

10.2 Der schablonenbasierte Ansatz

10.3 Schritt für Schritt zur Anforderung

10.4 Semantische Präzisierung der Anforderungsschablone

10.4.1 Rechtliche Verbindlichkeiten

10.4.2 Verben – Prozesswörter

10.4.3 Substantive – Akteure, Rollen, Objekte, Eigenschaftenund Abkürzungen

10.4.4 Bedingungen

10.5 Konstruieren in englischer Sprache

10.5.1 Der Syntaxbauplan im Englischen

10.5.2 Semantische Normierung im Englischen

10.6 Details für die Konstruktion

10.6.1 Präzisierung des Objekts

10.6.2 Konkretisierung des Prozessworts

10.6.3 Die Details in englischer Sprache

10.7 Nicht-funktionale Anforderungen

10.7.1 Eigenschaften

10.7.2 Umgebungen und Kontext

10.7.3 Prozesse

10.7.4 Konstruieren in englischer Sprache

10.8 Bedingungen in Anforderungen

10.8.1 Syntax für und Semantik in Bedingungen

10.8.2 Konstruieren in englischer Sprache

10.9 Auf die Sätze, fertig, los!

11 Dokumentation im agilen Umfeld

11.1 Artefakte – eine Übersicht

11.2 User-Storys

11.2.1 Aufbau einer User-Story

11.2.2 Das nehm‘ ich dir nicht ab! – Akzeptanzkriterien für User-Storys

11.2.3 Von Use-Cases, User-Storys und Story-Maps

11.3 Technical Storys

11.3.1 Aufbau von Technical Storys

11.3.2 Die Priorisierungsproblematik

11.4 User-Storys schneiden und verfeinern

11.4.1 Das Meta-Pattern

11.4.2 Der Minimal-Ansatz und der Reduktions-Ansatz

11.5 Wann ist fertig wirklich „fertig“? – Die Definition of Done (DoD)und die Definition of Ready (DoR)

11.5.1 Die Definition of Done – weil’s gut werden muss

11.5.2 Die Definition of Ready – das Quality-Gate für User-Storys

11.6 And all together now! – Wann setze ich welche Technik ein?

12 Nicht–funktionale Anforderungen – die heimlichen Stars

12.1 Definition, Bedeutung und Chancen

12.2 Ermitteln und Dokumentieren von NFAs

12.2.1 Vorbereitende Tätigkeiten

12.2.2 Durchzuführende Tätigkeiten

12.2.3 Best Practices

12.3 Technologische Anforderungen

12.3.1 Inhalte

12.3.2 Erfahrungen aus dem Projektalltag

12.4 Qualitätsanforderungen

12.4.1 Inhalte

12.4.2 Erfahrungen aus dem Projektalltag

12.5 Anforderungen an die Benutzungsoberfläche

12.5.1 Inhalte

12.5.2 Dokumentieren von Benutzungsoberflächen

12.5.3 Erfahrungen aus dem Projektalltag

12.6 Anforderungen an sonstige Lieferbestandteile

12.6.1 Inhalte

12.6.2 Erfahrungen aus dem Projektalltag

12.7 Anforderungen an durchzuführende Tätigkeiten

12.7.1 Inhalte

12.7.2 Erfahrungen aus dem Projektalltag

12.8 Rechtlich-vertragliche Anforderungen

12.8.1 Inhalte

12.8.2 Erfahrungen aus dem Projektalltag

Teil IV - Anforderungen prüfen und bewerten

13 Der Qualitätssicherungsprozess – Menetekel oder Wunderheilung?

13.1 Qualität ist das, was der Kunde braucht

13.1.1 Ziele in der Qualitätssicherung von Anforderungen

13.1.2 Konstuktive und analytische Qualitätssicherung vonAnforderungen

13.1.3 Vorgehen beim Prüfen von Anforderungen

13.2 Der Qualitätssicherungsleitfaden – damit Sie loslegen können

13.2.1 Qualitätsziele festlegen

13.2.2 Qualitätssicherungsmethoden auswählen

13.2.3 Prüfzeitpunkte definieren

13.2.4 Über die Auswahl geeigneter Prüfer

13.3 Plan - Qualitätsprüfung vorbereiten

13.3.1 Prüfbarkeit feststellen

13.3.2 Prüfgegenstand definieren

13.3.3 Prüfgegenstand extrahieren und dokumentieren

13.4 Do - Qualitätsprüfung durchführen

13.4.1 Spezifikationselement bewerten

13.4.2 Prüfbericht verfassen

13.5 Check – Ergebnisse beurteilen

13.6 Act – Maßnahmen initiieren

14 Prüftechniken für Anforderungen – ungeahntes Verbesserungspotenzial

14.1 Die Prüftechniken im Detail

14.1.1 Reviews

14.1.2 Prototyp/Simulationsmodell

14.1.3 Testfälle

14.1.4 Analysemodell

14.1.5 Hilfsmittel bei der Prüfung

14.2 Vom Durchblick im Dschungel der Prüftechniken

14.2.1 Einschätzung der Prüftechniken

14.2.2 Über die Auswahl geeigneter Prüftechniken

15 Qualitätsmetriken – drum messe, wer sich ewig bindet

15.1 Qualitätsmetriken – die Hüter der Anforderungsqualität

15.1.1 Qualitätsmetriken für Anforderungen

15.1.2 Ziele von Qualitätsmetriken – der Blick ins Unbekannte

15.1.3 Verwendung von Metriken – die erste Herausforderung

15.2 Vorbereitung der Messung mit Qualitätsmetriken

15.2.1 Qualitätsziele festlegen

15.2.2 Messleitfaden erweitern

15.2.3 Stichprobenumfang definieren

15.2.4 Stichproben festlegen und dokumentieren

15.3 Durchführung

15.3.1 Qualitätskennzahlen berechnen

15.3.2 Messergebnis dokumentieren

15.3.3 Qualitätskennzahlen beurteilen

16 Anforderungskonsolidierung – wider den Widerspruch

16.1 Was ist ein Konflikt?

16.2 Konfliktidentifikation

16.2.1 Konfliktindikatoren in der Kommunikation

16.2.2 Konfliktindikatoren in der Dokumentation

16.3 Konfliktanalyse

16.4 Konfliktauflösung

16.4.1 Stile und Verhaltensstrategien in der Konfliktauflösung

16.4.2 Konsolidierungstechniken

16.4.3 Auswahl der Konsolidierungstechniken

16.5 Dokumentation der Anforderungskonsolidierung

Teil V - Anforderungen verwalten

17 Requirements-Management – die Reise beginnt

17.1 Wider die Unordnung

17.1.1 Gründe für professionelles Requirements-Management

17.1.2 Der Requirements-Engineering-Leitfaden

17.1.3 Wann ist wie viel RM sinnvoll?

17.2 Die Aufgaben professionellen Requirements-Managements

17.2.1 Informationsaustausch – wer gibt wann wem was?

17.2.2 Ablaufsteuerung – wer darf wann was?

17.2.3 Verwaltung von Abhängigkeiten – was hängt wie mitwas zusammen?

17.2.4 Auswertung und Projektsteuerung – wie läuft‘s?

17.3 Was soll genau verwaltet werden? – Informationsarten

17.4 Gliederungsstrukturen – das Skelett des Requirements-Managements

17.5 Objekt-IDs – denn Namen sind Schall und Rauch

17.5.1 Wann ist eine Objekt-ID wirklich eindeutig?

17.5.2 Wie soll eine Objekt-ID aussehen?

18 Versionen und Zustände – das Leben einer Anforderung

18.1 Die Anforderung lebt!

18.2 Der Zustandsautomat einer Anforderung

18.2.1 Die Zustände einer Anforderung

18.2.2 Die Zustandsübergänge einer Anforderung

18.2.3 Den Zustandsautomaten dokumentieren

18.3 Detaillierungsebenen und Abhängigkeiten

18.4 Arbeitsabläufe im RM definieren

18.4.1 Rollen identifizieren

18.4.2 Rechte vergeben

18.5 Den Lebensweg dokumentieren

18.5.1 Die Historie einer Anforderung

18.5.2 Versionierung einer Anforderung

19 Strukturen und Mengen – das Chaos verhindern

19.1 Das Chaos verhindern

19.1.1 Attribute – alles, was man über seine Anforderungenwissen muss

19.1.2 Die Übersicht behalten – Filtern und Sichten bilden

19.2 Auswertungen

19.3 Traceability

19.3.1 Eltern-Kind-Verbindung

19.3.2 Verbindung von Anforderungen auf gleicher Ebene

19.3.3 Verbindung zwischen verschiedenen Informationsarten

19.3.4 Traces technisch realisieren

19.3.5 Definition eines Verfolgbarkeitsmodells

19.4 Anforderungen strukturieren

19.4.1 Strukturierung nicht-funktionaler Anforderungen

19.4.2 Strukturierung funktionaler Anforderungen

19.5 Anforderungen importieren und exportieren

20 Change- & Release-Management – die stabile Instabilität

20.1 Quellen und Typen von Änderungen – es kommt was auf Sie zu

20.1.1 Incident-Management – einer für alle und alles auf einmal

20.1.2 Fachbereich und Produkt-Management

20.1.3 Tester

20.1.4 Entwickler

20.1.5 Definitionen der Tickettypen

20.1.6 Sammeltopf für die Tickets

20.2 Change-Management

20.2.1 Priorisierung der Tickets

20.2.2 Änderung grob beschreiben und entscheiden

20.3 Tickets einplanen

20.4 Release-Management

20.4.1 Änderungen durchführen – die Stunde der Traceability

20.4.2 Konfigurationen und Basislinien

20.5 Der Zielspurt – Release ausrollen

20.6 Ausnahmesituation – das Emergency Release

21 Wiederverwendung – aus alt mach neu

21.1 Das Rad nicht immer neu erfinden

21.2 Die potenziellen Kandidaten

21.3 Regelgeleitete Wiederverwendung

21.3.1 Spezifikationslevel

21.3.2 Eingeschränkte Produktpalette

21.3.3 Einbindung in den Ablauf

21.3.4 Technologie

21.3.5 Zwischenfazit

21.4 Wiederverwendung in der Praxis

21.5 Auswahl der Vorgehensarten

21.5.1 Der Ansatz nach IVENA XT

21.5.2 Produktlinien

Teil VI - Spezialfälle meistern: Einführungsprojekte,Delta Anforderungen, und Usability Engineering

22 Einführungsstrategien – ein Ratgeber für die organisierte REorganisation

22.1 Gründe für eine gute Strategie

22.1.1 Einführung bedeutet Veränderung

22.1.2 Nichts ist beständiger als der Wandel

22.1.3 Veränderung bedeutet Lernen

22.2 Eine Einführung ist ein Projekt!

22.2.1 Den Grundstein legen – Erstellung des fachlichen Konzepts

22.2.2 Die Umsetzung vorbereiten

22.2.3 Umsetzen und anpassen

22.3 Arbeitspakete einer Einführung

22.3.1 Marketingkonzept

22.3.2 Konzept zur Wissensvermittlung

22.3.3 Pilotierungskonzept

22.3.4 Migrationskonzept

22.4 Aufbruch in ein agile(RE)s Leben

22.4.1 Vom Wasserfall zur Agilität

22.4.2 Der hybride Ansatz: klassisches RE & agile Entwicklung

22.4.3 Flexibel und adaptiv: agiles RE & agile Entwicklung

23 Der Delta-Ansatz – jenseits der grünen Wiese

23.1 Delta-Anforderungen – die machen den Unterschied!

23.2 Das Vorgehen beim Delta-Ansatz

23.3 Delta-Ansatz oder neue Spezifikation?

23.4 Delta-Spezifikation im agilen Kontext

24 Requirements und Usability – wie sich Anforderungen undBenutzerfreundlichkeit ergänzen

24.1 Requirements und Usability

24.2 Das Persona-Konzept im Requirements-Engineering

24.2.1 Der Persona-Steckbrief

24.2.2 Das Wichtigste zuerst: die Identität

24.2.3 Demografische Variablen

24.2.4 Verhaltensvariablen

24.3 Der Persona-Steckbrief als Anforderungsquelle

24.4 Verifizieren von RE-Artefakten

24.5 Modellieren aus Benutzersicht

24.5.1 Der Nutzungsablauf als Modell

24.5.2 Begriffe und Zustände

24.6 Qualitätssicherung und Übergabe an das Design

A – ILIAS® – die neue Art des Lernens

B – Literaturverzeichnis

C – Fotoverzeichnis

Index