Requirements Engineering für Dummies E-Book

Marcus Winteroll

• Herausgeber: Wiley-VCH GmbH
• Kategorie: Wissenschaft und neue Technologien
• Serie: ...für Dummies
• Sprache: Deutsch
• Veröffentlichungsjahr: 2021

Seitenzahl: 502

Beschreibung

Für den Erfolg von Softwareprojekten ist es entscheidend, sich erstmal klar zu machen, wozu das System überhaupt dienen soll und wie es dafür beschaffen sein muss. Klingt eigentlich selbstverständlich, und doch scheitern Projekte oft gerade an der Anforderungsanalyse. Das Buch "Requirements Engineering für Dummies" beschreibt verständlich und pragmatisch, wie Sie vorgehen sollten - und zwar sowohl für klassische als auch für agile Projekte. Es liefert Ihnen Techniken, wie Sie Ziele bestimmen und Releases sinnvoll zusammenstellen, wie Sie Anforderungen erheben und verstehen, wie Sie mit Änderungen umgehen und wie Sie Fallstricke vermeiden. Das Buch ist auch geeignet zur Vorbereitung auf die CPRE-FL-Prüfung.

Leseprobe

Requirements Engineering für Dummies

Schummelseite

FUNKTIONALE ANFORDERUNGEN

Funktionale Anforderungen beschreiben, was das System leisten soll. Wichtige Eigenschaften:

Interaktion mit den Nutzern oder anderen Systemen oder automatisiertlassen sich als Ablauf beschreiben oder Folge von Systemzuständenverarbeiten in der Regel Daten

Typische Techniken der Beschreibung:

Anwendungsfälle (Use Cases)User StoriesAblaufdiagramme (UML-Aktivitätsdiagramme, BPMN-Prozessdiagramme)Text

NICHTFUNKTIONALE ANFORDERUNGEN

Nichtfunktionale Anforderungen beschreiben, wie das System etwas leisten soll. Typische Kategorien hierfür sind:

EffizienzBenutzbarkeitWartbarkeitSicherheitZuverlässigkeitÜbertragbarkeitKompatibilität

Meist werden sie einfach mit Text beschrieben. Beim International Requirements Engineering Board (IREB) werden die nichtfunktionalen Anforderungen auch Qualitätsanforderungen genannt.

RANDBEDINGUNGEN

Randbedingungen sind Festlegungen zu Beginn der Entwicklung, welche die Möglichkeiten der Anforderungen und der Umsetzung einschränken. Beispiele für Randbedingungen:

Vorgehensmodell (agil oder klassisch)regulatorische Vorgaben wie Datenschutz oder BarrierefreiheitProgrammierspracheZeit und Budget

Randbedingungen werden vom IREB als dritte Anforderungsart neben funktionalen und Qualitätsanforderungen eingruppiert.

REQUIREMENTS ENGINEERING IN SCRUM

Alle bekannten Anforderungen sind im Product Backlog enthalten, beispielsweise als User Story.

Vorbereitungsphase: Produktvision entwickeln, Überblick über Anforderungen, nächstes Release planen, Product Backlog befüllen, ersten Sprint vorbereiten gemäß »Definition of Ready«Sprint: Letzte Anforderungsdetails für die Umsetzung klärenReview: Fortschritt im Hinblick auf das Releaseziel begutachten und bei Bedarf Anforderungen anpassen und neue hinzufügenRefinement: Anforderungen für den nächsten Sprint vorbereiten gemäß »Definition of Ready« und Anforderungen für nachfolgende Sprints grob vorbereiten

REQUIREMENTS ENGINEERING IN KLASSISCHEN PROJEKTEN

Der generelle Ablauf in klassischen Projekten ist planbasiert und lässt sich mit einem Wasserfall vergleichen.

STAKEHOLDERANALYSE

Vorgehen:

Identifizieren Sie die Stakeholder.Ermitteln Sie die Ziele und Interessen der Stakeholder.Priorisieren Sie die Stakeholder.Ermitteln Sie ergänzende Informationen wie Kontaktdaten, Erreichbarkeit und bei Gruppen den Ansprechpartner.Entwickeln Sie Maßnahmen zur Einbindung der Stakeholder.Wiederholen Sie die Stakeholderanalyse regelmäßig.

Priorisierung:

Typische Stakeholder:

AnwenderKunden, intern oder externzuständige FachabteilungenEntwickler des abzulösenden AltsystemsBetriebsratDatenschutzbeauftragteUnternehmensführungManagementdie Leute, die später Schulungen zum System durchführen sollendie Leute, die später den Support übernehmenMarketing oder VertriebUmfeld der Organisation (Außenwahrnehmung)

ANWENDUNGSFÄLLE (USE CASES)

Anwendungsfälle helfen, die funktionalen Anforderungen zu beschreiben.

Anwendungsfälle beschreiben Verwendungen eines Systems. Beispiel: »Geld abheben« benennt eine Verwendung eines Geldautomaten.Kein Anwendungsfall wäre »Als Kunde autorisieren«! Niemand geht zum Geldautomaten, nur um sich zu autorisieren.Anwendungsfalldiagramme geben einen Überblick über die geplante Verwendung des Systems.

Beschreibung eines Anwendungsfalles

Name

Geld abheben

Kurzbeschreibung

Ein Bankkunde hebt Bargeld von seinem Konto ab. Dabei muss der Geldautomat ein generelles Tageslimit beachten.

Fachlicher Auslöser

Der Bankkunde benötigt Bargeld.

Fachliches Ergebnis

Der Bankkunde verfügt über Bargeld.

Beteiligte Akteure

Bankkunde, Autorisierungssystem

Vorbedingungen

Der Geldautomat verfügt über eine Mindestmenge Bargeld und hat eine Verbindung zum Autorisierungssystem.

Nachbedingungen

Jede Abhebung ist verbucht.

Essenzschritte

Bankkunde autorisieren

Geldbetrag auswählen

Bargeldbestand prüfen

Verfügungsrahmen prüfen

Auszahlung buchen

Geld auszahlen

NICHTFUNKTIONALE ANFORDERUNGEN ERMITTELN

Vorgehen:

Vorstellungen der Stakeholder zu den nichtfunktionalen Anforderungen unstrukturiert erheben.Die Ergebnisse in einen Qualitätsbaum einordnen.Den Qualitätsbaum nutzen, um weitere nichtfunktionale Anforderungen zu identifizieren.Die nichtfunktionalen Anforderungen priorisieren.Die wichtigsten nichtfunktionalen Anforderungen mittels Qualitätsszenarien konkretisieren und ergänzen.Die Priorisierung im Lichte der Qualitätsszenarien noch einmal überprüfen.Auswirkung auf die Architektur bewerten (durch Architekturverantwortliche).Zuordnung der nichtfunktionalen Anforderungen zu den funktionalen.

Ausschnitt aus einem Qualitätsbaum mit Qualitätsszenarien:

USER STORIES ZERLEGEN

ÜBERBLICK ÜBER ERMITTLUNGSTECHNIKEN

Einordnung nach dem Kano-Modell

Geeignet für viele Stakeholder

Verteilte Stakeholder

Gemeinsam oder einzeln

Überblick oder Details

Top-Down oder Bottom-Up

Befragungstechniken

Interview

Basismerkmale: o

Leistungsmerkmale: +

Begeisterungsmerkmale: -

Einzelne Personen oder kleine Gruppen

Erhöhter Aufwand

Mit wenigen Stakeholdern

Überblick und Details

Top-Down-Vorgehen

Fragebogen

Basismerkmale: o

Leistungsmerkmale: +

Begeisterungsmerkmale: -

Für sehr große Anzahl an Stakeholdern

Gut geeignet

Mit einzelnen Stakeholdern

Überblick und Details

Top-Down-Vorgehen

Workshop

Basismerkmale: o

Leistungsmerkmale: +

Begeisterungsmerkmale: -

Für mittelgroße Gruppen

Erhöhter Aufwand

Stakeholder arbeiten gemeinsam

Überblick

Top-Down- und Bottom-Up-Vorgehen

Beobachtungstechniken

Feldbeobachtung

Basismerkmale: +

Leistungsmerkmale: o

Begeisterungsmerkmale: -

Für mittelgroße Gruppen

Erhöhter Aufwand

Mit einzelnen Stakeholdern

Details

Bottom-Up-Vorgehen

Apprenticing

Basismerkmale: +

Leistungsmerkmale: +

Begeisterungsmerkmale: -

Für wenige Stakeholder

Erhöhter Aufwand

Mit einzelnen Stakeholdern

Details

Bottom-Up-Vorgehen

Ohne Stakeholder

Systemarchäologie

Basismerkmale: +

Leistungsmerkmale: o

Begeisterungsmerkmale: -

—

—

—

Details

Bottom-Up-Vorgehen

Wiederverwendung

Basismerkmale: +

Leistungsmerkmale: +

Begeisterungsmerkmale: -

—

—

—

Überblick und Details

Top-Down-Vorgehen

Entwurfs- und Ideenfindungstechniken

Brainstorming

Basismerkmale: o

Leistungsmerkmale: o

Begeisterungsmerkmale: +

Für mittelgroße Gruppen

Erhöhter Aufwand

Stakeholder arbeiten gemeinsam

Grobe Ideen erarbeiten, nicht für Details

Top-Down-Vorgehen

Analogietechniken

Basismerkmale: o

Leistungsmerkmale: +

Begeisterungsmerkmale: +

Für mittelgroße Gruppen

Erhöhter Aufwand

Stakeholder arbeiten gemeinsam

Ideen erarbeiten, nicht für Details

Top-Down-Vorgehen

Perspektivwechsel

Basismerkmale: o

Leistungsmerkmale: +

Begeisterungsmerkmale: +

Für mittelgroße Gruppen

Erhöhter Aufwand

Stakeholder arbeiten gemeinsam

Ideen erarbeiten, nicht für Details

Top-Down-Vorgehen

Design Thinking

Basismerkmale: o

Leistungsmerkmale: +

Begeisterungsmerkmale: +

Für mittelgroße Gruppen

Erhöhter Aufwand

Stakeholder arbeiten gemeinsam

Ideen erarbeiten und prüfen, nicht für Details

Top-Down-Vorgehen

Requirements Engineering für Dummies

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

© 2021 WILEY-VCH GmbH, Weinheim

Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries. Used by permission.

Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc., USA, Deutschland und in anderen Ländern.

Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung.

Coverfoto: © EtiAmmos – stock.adobe.comKorrektur: Matthias Delbrück, Dossenheim/Bergstraße

Print ISBN: 978-3-527-71635-7ePub ISBN: 978-3-527-82393-2

Über den Autor

Marcus Winteroll studierte Philosophie in Hamburg mit Informatik und Linguistik als Nebenfächern. Anschließend promovierte er im Graduiertenkolleg »Kognitionswissenschaften« an der Universität Hamburg. Bereits neben dem Studium arbeitete er als Entwickler für einen bekannten internationalen Konzern. Nach der Promotion machte er die Arbeit rund um die Software zu seinem Hauptberuf und ging zunächst als Entwickler nach Frankfurt am Main. Weitere Stationen dort waren Qualitätssicherung, Projektleiter und Prozessmanager. Das Thema »Requirements Engineering« begleitete ihn auf all diesen Stationen. Nachdem er bereits 2003 sein erstes agiles Projekt durchführte, ließ ihn auch das Thema »Agilität« nicht mehr los.

2007 begann er als Trainer und Berater bei der oose Innovative Informatik in Hamburg und gründete gemeinsam mit einigen Kollegen 2014 die oose-Genossenschaft, die seitdem als selbstorganisiertes Unternehmen durch die Mitarbeiter geführt wird.

Er berät große und kleine Unternehmen aus allen Branchen und gibt Trainings zu den Themen »Requirements Engineering«, »Agilität« und »Geschäftsprozessmanagement«. Daneben ist er Dozent für die Masterlehrgänge »Software Engineering Leadership« und »Systems Engineering Leadership«. Auf Konferenzen ist er häufig mit Vorträgen vertreten und in Fachzeitschriften als Autor von Artikeln rund um das Thema Systementwicklung. Zudem arbeitet er bei der Standardisierungsorganisation »Object Management Group (OMG)« mit.

Inhaltsverzeichnis

Cover

Titelblatt

Impressum

Über den Autor

Einleitung

Über dieses Buch

Konventionen in diesem Buch

Was Sie nicht lesen müssen

Törichte Annahmen über die Leser

Wie dieses Buch aufgebaut ist

Symbole, die in diesem Buch verwendet werden

Wie es weitergeht

Teil I: Requirements Engineering verstehen

Kapitel 1: Das ist Requirements Engineering

Warum uns Requirements Engineering weiterhelfen kann

Aufgaben im Requirements Engineering

Wer das Requirements Engineering macht

Viele Arten von Anforderungen

Möglichkeiten der Zertifizierung

Kapitel 2: Einbettung des Requirements Engineering

Das Zusammenspiel mit den übrigen Beteiligten

Requirements Engineering im klassischen Vorgehen: alles klar

Requirements Engineering in agilen Projekten: just in time

Klassisch, agil, Festpreis, Aufwandspreis – nicht jede Kombination ist sinnvoll

Kapitel 3: Fallstricke

Was wir von den Kunden erwarten dürfen – und sie von uns

Wer nimmt die Anforderungen auf?

Die richtige Detaillierung von Anforderung

Umgang mit Änderungen

Dokumentation von Anforderungen

Teil II: Vorgehen im Requirements Engineering

Kapitel 4: Vorgehen in klassischen Projekten

Einordnung in den Projektablauf

Der Ablauf

Kapitel 5: Vorgehen in agilen Projekten

Direkte Kommunikation statt Dokumentation

Der Wert gibt den Takt an

Das Ziel immer vor Augen

Die Vorbereitungsphase

Requirements Engineering in Scrum

Fortwährende Analyse statt Änderungsmanagement

Die Unterschiede zwischen klassischem und agilem Requirements Engineering

Kapitel 6: Anpassung des Requirements-Engineering-Prozesses

Einflussfaktoren

Facetten des Requirements-Engineering-Prozesses

Konfiguration des Prozesses

Teil III: Anforderungsanalyse

Kapitel 7: An die Anforderungen herankommen

Stakeholderanalyse

Zusätzliche Anforderungsquellen

Anforderungen ermitteln

Konflikte und der Umgang damit

Kapitel 8: Was uns zu Beginn klar sein sollte

Wohin soll die Reise gehen? Das Ziel klar vor Augen

Den Überblick gewinnen

Releases schneiden

Kapitel 9: Funktionale Anforderungen verstehen und beschreiben

Die Systemverwendung mit Anwendungsfällen beschreiben

Die Geschichten der Nutzer: User Stories

Anwendungsfälle oder User Stories?

Kapitel 10: Weitere Aspekte funktionaler Anforderungen

Fachliche Begriffe begreifen

Das sind ja Zustände

Wie das Geschäft zu regeln ist

Prototypen

Die natürliche Sprache

Kapitel 11: Nichtfunktionale Anforderungen und Randbedingungen

Die Bedeutung der nichtfunktionalen Anforderungen

Nichtfunktionale Anforderungen verstehen

Nichtfunktionale Anforderungen ermitteln

Nichtfunktionale Anforderungen in der agilen Entwicklung

Was schon vorher feststeht: die Randbedingungen

Kapitel 12: Wer weiß, ob das auch so stimmt – Anforderungen prüfen

Was gibt es denn da zu prüfen?

Vorgehen im klassischen Requirements Engineering

Vorgehen im agilen Requirements Engineering

Techniken für die Prüfung

Kapitel 13: Anforderungen festhalten

Zweck der Dokumentation

Der richtige Zeitpunkt

Hilfreiche Regeln

Arten der Dokumentation

Teil IV: Requirements Management

Kapitel 14: Anforderungen organisieren

Requirements Management im agilen Vorgehen

Der Lebenszyklus einer Anforderung

Versionierung

Attribute einer Anforderung

Kann man so oder so sehen: Sichtweisen

Konfigurationen

Kapitel 15: Ist das wirklich wichtig? – Priorisierung von Anforderungen

Was wichtig ist

Ad-hoc-Priorisierungstechniken

Analytische Priorisierungstechniken

Vorgehen

Kapitel 16: Die Anforderungen verfolgen

Zweck der Verfolgbarkeit

Verfolgbarkeit darstellen

Methodisches Verfolgen

Kapitel 17: Umgang mit Änderungen

Ganz normal und doch unbeliebt

Der Änderungsprozess und seine Bestandteile

Kapitel 18: Werkzeuge im Requirements Engineering: Unterstützung und Last

Arten von Werkzeugen

Einführung von Werkzeugen

Teil V: Der Top-Ten-Teil

Kapitel 19: Zehn Prinzipien des Requirements Engineering

Zusammenarbeit: Requirements Engineering allein funktioniert nicht

Wertorientierung: Anforderungen sind kein Selbstzweck

Stakeholder: Es geht darum, ihren Bedarf zu erfüllen

Gemeinsames Verständnis: Die Basis für erfolgreiche Systementwicklung

Kontext: Notwendig, um Systeme zu verstehen

Problem, Anforderung, Lösung: Eine untrennbare Verbindung

Validierung: Ungeprüfte Anforderungen sind nutzlos

Evolution: Änderungen sind normal

Innovation: Mehr vom Gleichen reicht nicht

Systematische und disziplinierte Arbeit: Ohne geht es nicht

Kapitel 20: Zehn beliebte Fehler im Requirements Engineering

Die Suche nach dem Schuldigen

Lösungen beschreiben anstatt Probleme zu verstehen

Anforderungen einfach vom Altsystem übernehmen

Die Nutzer beschreiben die Anforderungen

Wir arbeiten agil und dokumentieren nichts

Entweder keine oder unverständliche Systemdokumentationen

User Stories sind allein dazu da, die bestehenden Anforderungen in das Backlog aufzunehmen

Agil und Modellierung geht nicht zusammen

Fachleute und Entwickler sprechen nicht miteinander

Das Requirements Engineering läuft nicht, also brauchen wir ein Tool

Kapitel 21: Zehn Online-Quellen

IREB-Lehrpläne, Handbücher und Glossar

Requirements Engineering Magazine

Scrum-Guide

Online Browsing Platform der ISO

V-Modell

UML-Spezifikation

UML-Übersicht

DMN-Spezifikation

Übersicht über Requirements-Tools

Übersicht über UML-Tools

Stichwortverzeichnis

End User License Agreement

Tabellenverzeichnis

Kapitel 2

Tabelle 2.1: Kombinationsmöglichkeiten von Vorgehensweise und Preismodell

Kapitel 5

Tabelle 5.1: Klassisches und agiles Requirements Engineering im Vergleich

Kapitel 6

Tabelle 6.1: Typische Konfigurationen des Requirements-Engineering-Prozesses

Kapitel 7

Tabelle 7.1: Überblick über Ermittlungstechniken

Tabelle 7.2: Entscheidungsmatrix

Kapitel 11

Tabelle 11.1: Die Kategorien für nichtfunktionale Anforderungen in ISO 25010

Tabelle 11.2: Eigenschaften von Verwendungs- und Änderungsszenarien

Kapitel 15

Tabelle 15.1: Beispiel für eine Wiegers'sche Priorisierungsmatrix mit Anwendungsf...

Kapitel 16

Tabelle 16.1: Verfolgbarkeitstabelle mit vorgegebener Struktur

Tabelle 16.2: Verfolgbarkeitstabelle mit flexibler Struktur

Tabelle 16.3: Verfolgbarkeitstabelle mit funktionalen und nichtfunktionalen Anfor...

Kapitel 17

Tabelle 17.1: Inhalte eines Änderungsantrags (Change Request)

Illustrationsverzeichnis

Kapitel 1

Abbildung 1.1: Kategorien nichtfunktionaler Anforderungen nach ISO 25010

Kapitel 3

Abbildung 3.1: Bekannten, unklare und unbekannte Anforderungen

Kapitel 4

Abbildung 4.1: Klassische Projektphasen als Wasserfall

Abbildung 4.2: Übersicht der Vorgehensweise im klassischen Requirements Engineeri...

Kapitel 5

Abbildung 5.1: Zielhierarchie mit Beispielen

Abbildung 5.2: Scrum im Überblick

Abbildung 5.3: Scrum-Rollen und ihre Verantwortlichkeiten

Abbildung 5.4: Requirements Engineering in Scrum

Kapitel 7

Abbildung 7.2: Einfache Priorisierung der Stakeholder

Abbildung 7.3: Priorisierung der Stakeholder in zwei Dimensionen

Abbildung 7.4: Politische Stakeholdermap

Abbildung 7.5: Kano-Modell

Abbildung 7.6: Phasen des Design-Thinking-Prozesses

Abbildung 7.7: Gelegenheiten, um Rückmeldungen zu Anforderungen mit einem lauffäh...

Kapitel 8

Abbildung 8.1: Vorderseite Produktkarton

Abbildung 8.2: Rückseite Produktkarton

Abbildung 8.3: Product Vision Board von Roman Pichler

Abbildung 8.4: Erweitertes Product Vision Board mit Beispiel

Abbildung 8.6: Anwendungsfälle eines Geldautomaten

Abbildung 8.7: Einfache Beschreibung des Anwendungsfalls »Geld abheben«

Abbildung 8.5: Systemkontext am Beispiel eines Geldautomaten

Abbildung 8.8: Personas

Abbildung 8.9: Zusammenfassung von Detailschritten in einer Story Map

Abbildung 8.10: Ausschnitt aus der Story Map für »Fahrzeug mieten«

Abbildung 8.11: Releaseplanung mit Minimal Marktfähigem Release und Puffer

Abbildung 8.12: Für die Releaseplanung vorbereitete Story Map

Abbildung 8.13: Zwischenstand der Releaseplanung

Abbildung 8.14: Die Story Map als Release-Roadmap

Kapitel 9

Abbildung 9.2: Anwendungsfälle eines Geldautomaten

Abbildung 9.3: Anwendungsfall mit aktive und passiven Akteuren

Abbildung 9.4: Ebenen der Anwendungsfallbeschreibung

Abbildung 9.6: Aktivitätsdiagramm für den Anwendungsfall »Geld abheben«

Abbildung 9.7: Aktivitätsdiagramm für den Anwendungsfall »Bankkunde autorisieren«

Abbildung 9.8: Aktivitätsdiagramm für »Reise buchen«

Abbildung 9.9: Alternative Darstellung der Aktivität »Reise buchen«

Abbildung 9.10: Die wichtigsten Elemente des Aktivitätsdiagramms

Abbildung 9.11: Aktivität mit Objektfluss

Abbildung 9.12: Anwendungsfälle mit Include-Beziehungen

Abbildung 9.13: Ein Beispiel, wie Sie es nicht machen sollten: funktionale Zerleg...

Abbildung 9.14: Anwendungsfall mit Extend-Beziehung

Abbildung 9.15: Die wichtigsten Zerlegungstechniken für User Stories

Abbildung 9.16: Das Zusammenspiel der Story Map mit dem Product Backlog

Kapitel 10

Abbildung 10.2: Ein einfaches Fachklassendiagramm für ein Bestellsystem

Abbildung 10.3: Die wichtigsten Elemente eines Klassendiagramms

Abbildung 10.4: Fachklassendiagramm mit Aggregation und Komposition

Abbildung 10.5: Fachklassendiagramm mit Generalisierung

Abbildung 10.6: Zustände einer Bestellung

Abbildung 10.7: Zuordnung der Zustände zu den Anwendungsfällen, die sie herstelle...

Abbildung 10.8: Beispiel für Bedingungen und Verhalten an Transitionen

Abbildung 10.9: Zustände einer einfachen Heizung

Abbildung 10.10: Fehlerzustand mit Diagrammrahmen und inneren Ereignissen

Abbildung 10.11: Zustände einer einfachen Klimaanlage

Abbildung 10.12: Die wichtigsten Elemente des Zustandsdiagramms

Abbildung 10.13: Überblick über sämtliche UML-Diagramme als Klassendiagramm

Abbildung 10.14: Decision Requirement Diagram (DRD) zur Rabattentscheidung

Abbildung 10.15: Entscheidungstabelle zu Rabattentscheidung in horizontaler Ausri...

Abbildung 10.16: Entscheidungstabelle zu Rabattentscheidung in vertikaler Ausrich...

Abbildung 10.17: Entscheidungstabelle zur Kundenbewertung

Abbildung 10.18: Decision Requirements Diagram (DRD) mit Wissensmodell

Abbildung 10.19: Die wichtigsten Elemente im Decision Requirements Diagram (DRD)

Abbildung 10.20: Ein Low-Fidelity-Prototyp

Abbildung 10.21: Satzschablone mit Bedingung

Abbildung 10.22: Satzschablone ohne Bedingung

Kapitel 11

Abbildung 11.1: Bauplan für Qualitätsszenarien mit Beispielen

Abbildung 11.2: Ausschnitt aus Qualitätsbaum mit den Kategorien der ISO 25010

Kapitel 13

Abbildung 13.1: Mögliche Gliederung des Anforderungsdokuments

Abbildung 13.2: Volere-Gliederung des Anforderungsdokuments

Abbildung 13.3 Nichtfunktionale Anforderungen im UML-Modell

Kapitel 14

Abbildung 14.1: Status im Lebenszyklus einer Anforderung als Zustandsdiagramm

Abbildung 14.2: Verschiedene Arten von Sichten

Abbildung 14.3: Die beiden Dimensionen der Konfigurationen

Kapitel 16

Abbildung 16.1: Verfolgbarkeitsgraph in der UML

Kapitel 17

Abbildung 17.1: Beispiel für einen Änderungsprozess

Orientierungspunkte

Cover

Inhaltsverzeichnis

Fangen Sie an zu lesen

Seitenliste

1

2

3

4

5

6

7

8

11

12

13

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

59

60

61

62

63

64

65

66

67

69

70

71

72

73

74

75

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

309

310

311

312

313

314

315

316

317

318

319

320

321

323

324

325

326

327

328

329

330

331

333

334

335

336

337

338

339

341

342

343

344

345

347

348

349

350

351

352

353

355

356

357

358

359

360

361

362

363

364

365

366

367

369

370

371

375

376

377

378

379

Einleitung

Wenn man ein System entwickeln möchte, ist es schon mal keine schlechte Idee, sich beizeiten mit der Frage zu beschäftigen, wozu das Ganze gut sein soll. Zumindest wenn man der Entwicklung eine Richtung geben und nicht nur so vor sich hin entwickeln möchte, von den Launen der Beteiligten mal in diese, mal in jene Richtung getrieben.

Es ist allerdings eine Herausforderung, die Frage nach dem Wozu schlüssig und zufriedenstellend zu beantworten. Das geht schon damit los, dass die Antwort verschiedene Ebenen hat: Wo liegt der Nutzen des Systems? Bei welchen Aufgaben soll es den Nutzern helfen? Wie muss es dafür beschaffen sein? Welche Vorgaben sind dabei einzuhalten? Und noch einiges mehr. Hinzu kommt: es ist meist gar nicht so einfach, an diese Informationen heranzukommen. Und dann erscheint das Ziel häufig auch noch allzu beweglich, sodass sich die Anforderungen immer wieder ändern.

Es ist also kein Wunder, dass sich eine ganze Disziplin um das Thema »Anforderungen« entwickelt hat, das Requirements Engineering. Aber kaum begann sich diese Disziplin zu etablieren, wurde sie auch gleich wieder herausgefordert durch das agile Vorgehen, das die Vorgehensweisen und Techniken des Requirements Engineering in Frage stellte. Auf der anderen Seite hat man dann auch in agilen Projekten festgestellt, dass es doch nicht so leicht ist, der vielfältigen Anforderungen mal so nebenbei Herr zu werden und dass Agilität allein auch nicht alle Probleme löst. Was ist also das richtige Vorgehen, welches sind die richtigen Techniken und was ist das richtige Maß an Requirements Engineering?

Über dieses Buch

Natürlich werden Sie in diesem Buch konkrete Vorgehensweisen und Techniken zum Requirements Engineering kennenlernen. Aber es geht hier auch darum, dass Sie beurteilen können, welches Vorgehen und welche Technik in welchem Kontext und in welcher Situation sinnvoll und effektiv sind. Denn die eine richtige Vorgehensweise gibt es nicht. Vielmehr müssen Sie als Requirements Engineer die spezifische Entwicklungssituation und das Umfeld berücksichtigen, um Techniken und Vorgehen darauf anzupassen. Hier gibt es so viele Möglichkeiten wie es unterschiedlichen Entwicklungsprozesse in der Praxis gibt – also gewissermaßen unendliche Welten.

Kurz: Sie lernen in diesem Buch viele bewährte Techniken und Vorgehensweisen kennen, aber Sie werden auch darin unterstützt, das richtige Beurteilungsvermögen über das angemessene Vorgehen zu entwickeln, egal ob Sie agil, klassisch oder sonst wie vorgehen.

Konventionen in diesem Buch

In der Praxis lässt sich das tatsächliche Vorgehen nicht immer klar unter agil oder klassisch einordnen. Darüber hinaus lassen sich viele Requirements-Engineering-Techniken im klassischen wie im agilen Vorgehen sinnvoll einsetzen. Daher trennt dieses Buch nicht strikt zwischen beiden Ansätzen. Wo es jedoch eindeutige Unterschiede gibt, wird selbstverständlich darauf eingegangen.

Was Sie nicht lesen müssen

Wenn Sie neu in das Thema »Requirements Engineering« einsteigen wollen, lesen Sie das Buch am besten einfach von vorne bis hinten – danach haben Sie einen guten Überblick. Und wenn Sie dann noch die Prüfung zum Certified Professional for Requirements Engineering – Foundation Level des International Requirements Engineering Board (IREB) in der aktuellen Version 3 anstreben, sind Sie auch darauf bestens vorbereitet.

Aber natürlich können Sie abhängig von Ihrem Vorwissen einzelne Abschnitte überspringen und sich auf die Themen konzentrieren, die Sie gerade interessieren. Die Kapitel sind so aufgebaut, dass sie jeweils für sich stehen; wobei ein gewisses Grundwissen meist vorausgesetzt wird, das Sie sich mithilfe des Buches aneignen können oder schon mitbringen. In dem Fall können Sie es auch als Nachschlagewerk nutzen: Mithilfe des Inhaltsverzeichnisses, des Stichwortverzeichnisses und der Querverweise können Sie die für Sie interessanten Inhalte direkt ansteuern, ohne das Buch von vorne bis hinten zu lesen beziehungsweise durchblättern zu müssen.

Törichte Annahmen über die Leser

Requirements-Engineering-Wissen müssen Sie nicht mitbringen, um dieses Buch zu verstehen, schließlich soll das Buch das ja vermitteln – nur neugierig auf das Thema müssten Sie sein. Vieles werden Sie aber besser einordnen können, wenn Sie bereits Erfahrungen in der Systementwicklung haben, egal ob Software- oder Hardwareentwicklung, egal in welcher Rolle, egal ob agil oder klassisch. Das Buch ist also genauso für Entwickler geeignet, die selbst Anforderungen erheben möchten, wie für Produktmanager, die ihre Anforderungen für das Entwicklungsteam besser strukturiert formulieren wollen.

Wie dieses Buch aufgebaut ist

Die Themen des Requirements Engineering sind in vier Teile gruppiert, die um den Top-Ten-Teil ergänzt werden.

Teil I: Requirements Engineering verstehen

Zunächst geht es darum, zu verstehen, wozu Requirements Engineering überhaupt gut ist, wer es macht und mit wem dabei zusammenzuarbeiten ist – welche Arten von Anforderungen es gibt. Zudem werden einige Fallstricke beschrieben. Ergänzend finden Sie in diesem Teil eine Übersicht über gängige Zertifizierungen.

Teil II: Vorgehen im Requirements Engineering

Wie der grundsätzliche Ablauf im Requirements Engineering aussieht, ist Thema im zweiten Teil. Hier unterscheidet sich natürlich das klassische vom agilen Vorgehen. Beides werden Sie dort kennenlernen. Letztlich müssen Sie aber Ihr Vorgehen an Ihr spezifisches Umfeld anpassen. Auch hierzu finden sie einige Hinweise.

Teil III: Anforderungsanalyse

Hier geht es um eine der zentralen Aufgaben des Requirements Engineering: Wie Sie an die Anforderungen herankommen. Dazu müssen Sie die Quellen für Anforderungen kennen, Sie benötigen Techniken, um Anforderungen zu ermitteln, und andere Techniken, um die Anforderungen besser zu verstehen und festzuhalten. Ergänzend hierzu werden Verfahren vorgestellt, mit denen Sie die Anforderungen auf ihre Eignung prüfen können, und erklärt, wie sie sich dokumentieren lassen.

Teil IV: Requirements Management

Anforderungen müssen auch organisiert werden. Wie das funktioniert, ist Thema dieses Teils. Am Ende erfahren Sie auch, inwieweit elektronische Werkzeuge Sie bei dieser Aufgabe unterstützen können und wo deren Grenzen liegen.

Teil V: Der Top-Ten-Teil

Der Top-Ten-Teil stellt Ihnen zehn grundlegende Prinzipien des Requirements Engineering vor. Dazu erfahren Sie, was alles zum Scheitern Ihres Projekts beitragen kann. Zu guter Letzt finden Sie dort zehn interessante Quellen zum Thema »Requirements Engineering«, auf die Sie einfach über das Internet zugreifen können.

Symbole, die in diesem Buch verwendet werden

Um bestimmte Informationen hervorzuheben, werden in diesem Buch die folgenden Symbole eingesetzt:

Dieses Symbol hebt Hinweise hervor, die für Ihre Arbeit als Requirements Engineer oder für das grundsätzliche Verständnis besonders hilfreich sind.

Mit diesem Symbol wird auf Zusammenhänge verwiesen, die bereits an einer früheren Stelle des Buches erklärt wurden. Manchmal wird auch nur daran erinnert, was einem der gesunde Menschenverstand ohnehin sagt.

Hier geht es um mögliche Stolpersteine im Requirements Engineering. Wenn sie diese Hinweise beherzigen, könnte Ihnen dadurch das eine oder andere Problem oder Missverständnis erspart bleiben.

Informationen, die eher zur Vertiefung dienen und nicht unbedingt für das grundlegende Verständnis notwendig sind, werden mit diesem Symbol gekennzeichnet.

Wie es weitergeht

Wenn Sie alles über Requirements Engineering wissen wollen, fangen Sie einfach mit dem ersten Teil an und bauen Ihr Wissen Kapitel für Kapitel auf. Wenn Sie selektiver vorgehen möchten, lassen Sie sich von den Themen im Inhaltsverzeichnis inspirieren und springen einfach an die Stelle, die Sie gerade am meisten interessiert – oder Sie lassen sich von Ihren Fragen entlang der vielen Querverweise durch die Themenpalette treiben.

Teil I

Requirements Engineering verstehen

IN DIESEM TEIL …

Das Ziel des Requirements Engineerings kennenZentrale Begriffe wie »Requirements Engineering« und »Anforderung« verstehenWie sich das Requirements Engineering in Entwicklungsvorhaben einbettetTypische Fallstricke des Requirements Engineering und wie man ihnen entgeht

Kapitel 1

Das ist Requirements Engineering

IN DIESEM KAPITEL

Inwiefern uns Requirements Engineering hilftErläuterung der zentralen BegriffeAufgaben eines Requirements EngineersWelche Zertifizierungen angeboten werden

Für den Erfolg von Entwicklungsvorhaben – egal ob Projekt oder kontinuierliche Produktentwicklung – ist es entscheidend, sich erst mal klarzumachen, wozu das System überhaupt dienen soll und wie es dafür beschaffen sein muss. Das klingt erst mal selbstverständlich, wird aber trotzdem immer wieder vernachlässigt. Requirements Engineering ist die Disziplin, die sich damit beschäftigt, wann und wie diese Fragen zu beantworten sind.

In diesem Kapitel geht es darum, zu verstehen, was Requirements Engineering genau ist und warum es hilfreich sein kann. Hierzu bietet es sich an, als Erstes ein paar zentrale Begriffe zu klären und die Aufgaben besser zu kennen.

Warum uns Requirements Engineering weiterhelfen kann

Viele typische Projekte laufen so: Der Kunde – das kann auch ein interner Kunde sein, etwa eine Fachabteilung – beschreibt zu Beginn, wie er sich das neu- oder weiterzuentwickelnde System vorstellt. Bei Softwaresystemen geschieht das meist, indem er die gewünschten Bildschirmmasken beschreibt oder welche Informationen er einzugeben wünscht, um etwa Aufträge zu erfassen, und wie er diese Informationen beispielsweise in Reports aufbereitet sehen möchte. Diese Beschreibungen sind dabei schon sehr detailliert und es ist von »Knöpfen«, »Auswahlfeldern« und »Flags« die Rede.

Diese Beschreibungen der Wünsche der Kunden werden dann mit ein paar Erläuterungen an das Projektteam übergeben, welches das Ganze umsetzt. Zwischendurch wird es ein paar Rückfragen an den Kunden geben und gegen Ende wird es zeitlich eng, weshalb einige der Kundenwünsche zusammengestrichen werden. Wenn am Ende das fertige System vorgestellt wird, geht dann der große Streit los, ob das Projektteam wirklich das umgesetzt hat, was der Kunde zu Beginn beschrieben hatte. Wie immer der Streit ausgeht, es ist schon klar, es braucht ein Anschlussprojekt, um das System so anzupassen, dass die Nutzer vernünftig damit arbeiten können.

Hier stellt sich die Frage: müssen Projekte so laufen? Natürlich nicht! Schauen wir uns an, was in dem beschriebenen Szenario alles falsch gelaufen ist:

Niemand hat sich Gedanken gemacht, welchen Nutzen das System erzielen soll. Oder – genauso schlecht – jeder hat sich seine eigenen Gedanken gemacht, aber es gibt kein gemeinsames Ziel.

Die Kunden haben beschrieben, wie das System aussehen soll, aber nicht warum.

Kunde und Projektteam arbeiten mehr nebeneinander her als miteinander. Jeder verlässt sich darauf, dass der andere schon weiß, was er tut, und konzentriert sich auf

seine

Aufgaben.

Durch das erstgenannte Problem gibt es beim Entwicklungsvorhaben keine klaren Schwerpunkte und keine Zielrichtung. Jeder wirft seine Wünsche in den Anforderungstopf, aus dem sich das Projektteam so lange bedient, bis der Topf leer oder die verfügbare Zeit abgelaufen ist – wobei Letzteres leider der Normalfall ist.

Am Beginn eines jeden Entwicklungsvorhaben sollte das Ziel klar herausgearbeitet und insbesondere durch den zu erwartenden Nutzen beschrieben werden.

Das zweite Problem offenbart, dass wir gewohnt sind, sehr schnell über Lösungen nachzudenken. Lösungen sind ja durchaus positiv, aber um zu wirklich guten Lösungen zu kommen, muss zuerst das Problem richtig verstanden werden.

Um die Anforderungen des Kunden zu verstehen, sollte immer die Frage im Vordergrund stehen, was das System leisten soll, um welche Aufgaben zu lösen. Es geht nicht darum, wie das System etwas leisten soll – im Sinne einer Lösung.

Wenn der Kunde also seine Wünsche in Form von Bildschirmmaskenbeschreibungen äußert, dann ist eben nicht klar, was das System leisten soll und wozu, sondern nur wie das System etwas machen soll.

Ein anderes Problem, das in dem beschriebenen Szenario zutage tritt: Der Kunde und das Projektteam haben es nicht als gemeinsame Aufgabe betrachtet, wirklich zu verstehen, was der Kunde braucht, um einen Nutzen zu haben, und was unter den gegeben Rahmenbedingungen machbar ist.

Um die Anforderungen des Kunden zu verstehen, muss das Projektteam eng mit dem Kunden zusammenarbeiten. Es reicht nicht aus, wenn der Kunde seine Wünsche einfach aufschreibt und das Dokument dem Projektteam überreicht.

Schlechte Anforderungen bremsen Innovationen aus

Legen die Anforderungen genau fest, wie das System sich verhalten soll und wie es auszusehen hat, bleibt dem Umsetzungsteam wenig Spielraum. Das bedeutet, dass dessen Kenntnisse und Kreativität für die Entwicklung guter Systeme nicht genutzt werden. Ob das System am Ende dem Kunden tatsächlich einen Nutzen bringt, kann das Umsetzungsteam schließlich nicht beurteilen, wenn es den Nutzen nicht kennt und nicht weiß, welche Aufgaben damit gelöst werden sollen.

Wenn die Anforderungen dagegen beschreiben, was das System im Einzelnen leisten soll und wie das übergeordnete Ziel aussieht, dann kann das Umsetzungsteam überlegen, wie nach ihrer Einschätzung das System beschaffen sein sollte, um den gewünschten Nutzen zu erbringen. Ein qualifiziertes Umsetzungsteam kennt die aktuellen technischen Möglichkeiten am besten. Selbstverständlich sollte es seine Umsetzungsideen erst mal mit dem Kunden diskutieren, bevor es sie umsetzt, um sicherzugehen, dass es einerseits die Probleme des Kunden richtig verstanden hat, und anderseits zu prüfen, ob die Lösungsideen auch passen.

Dieses Vorgehen eröffnet den Spielraum, um auch über ganz neue Lösungsideen nachzudenken, auf die der Kunde selbst nie gekommen wäre, und bildet die Basis, um innovative Ideen zu entwickeln. Also bremsen Sie als Requirements Engineer bitte keine innovativen Lösungen aus, indem Sie mit den Anforderungen bereits die Lösung für die Aufgaben und Probleme des Kunden vorgeben, sondern beschreiben Sie mit den Anforderungen, welche Aufgaben und Probleme er mit dem System lösen will.

Gutes Requirements Engineering trägt wesentlich dazu bei, all diese Probleme zu vermeiden, denn es bietet die Methoden und Techniken, um besser zu verstehen, was der Kunde wirklich braucht.

»Der Kunde hat immer Recht« heißt es. Aber nehmen Sie das nicht zu wortwörtlich, denn der Kunde ist sich häufig nicht im Klaren, was er wirklich braucht. Hinterfragen Sie also, was er als Anforderung beschreibt, und nutzen Sie die Methoden des Requirements Engineering, um herauszufinden, was er wirklich braucht.

Am Ende sollte das Requirements Engineering dazu beitragen, folgende Fragen zu beantworten:

Was ist der erwartete Nutzen des Systems?

Wer ist der Kunde? Wer sind die Nutzer?

Welche Aufgaben wollen sie mit dem System lösen?

Welche Fähigkeiten des Systems werden dafür benötigt?

Die Ausdrücke »Requirements Engineering« und »Anforderungsmanagement« beziehungsweise »Requirements Management« werden nicht immer einheitlich gebraucht. In diesem Buch ist Requirements Engineering der Oberbegriff und Requirements Management ein Teil davon. Dies entspricht einer im deutschsprachigen Raum verbreiteten Sichtweise, die auch vom International Requirements Engineering Board (IREB) geteilt wird.

Allerdings werden auch häufig Requirements Engineering und Anforderungsmanagement als unterschiedliche Disziplinen angesehen, denn in dieser Sichtweise umfasst das Requirements Engineering nur die Ermittlung und Dokumentation von Anforderungen, nicht aber das Organisieren.

Um die Verwirrung komplett zu machen: Es gibt auch die Lesart, dass Requirements Management der Oberbegriff ist, der alle Tätigkeiten rund um Anforderungen umfasst. Dieses Begriffsverständnis ist vor allem im angelsächsischen, aber eben auch im deutschsprachigen Raum anzutreffen.

Fragen Sie also im Zweifelsfalle einfach nach, was Ihr Gegenüber meint, wenn er einen dieser Begriffe benutzt.

Aufgaben im Requirements Engineering

Grob gesprochen bestehen die Aufgaben im Requirements Engineering aus vier Haupttätigkeiten:

Anforderungen ermitteln,

Anforderungen kommunizieren und festhalten,

Anforderungen validieren,

Anforderungen organisieren.

Beim ersten Punkt geht es darum, erst mal herauszubekommen, welche Anforderungen die Kunden, Nutzer und andere Stakeholder sich so vorstellen und dann gemeinsam mit ihnen zu erarbeiten, was sie tatsächlich brauchen, um den angestrebten Nutzen zu erreichen.

Beim zweiten Punkt geht es darum, die so erarbeiteten Anforderungen an diejenigen zu kommunizieren, die sie für ihre Arbeit benötigen, beispielsweise die Entwickler, Tester und Projektplaner. Ob wir das mit umfangreichen Anforderungsdokumenten bewerkstelligen, mit Anforderungsmodellen oder überwiegend mündlich, hängt von der Vorgehensweise ab; also ob wir klassisch oder agil arbeiten. In irgendeiner Form sollten die Anforderungen aber immer festgehalten werden, allein schon, um deren Umsetzung planen zu können, aber auch als Basis der Kommunikation.

Wovon die Anforderungen handeln: das System

Wenn es darum ging, wovon die Anforderungen handeln, war bisher hier einfach von Systemen die Rede. Das ist natürlich ein recht allgemeiner Begriff, denn es gibt sehr unterschiedliche Arten von Systemen wie zum Beispiel

Softwaresysteme,Hardwaresysteme,Softwareservices,verteilte Systeme,Gesamt- und Teilsysteme.

Diese Begriffe sind nicht gegeneinander abgegrenzt, vielmehr kann ein Gesamtsystem aus sämtlichen der genannten Arten von Systemen bestehen. Ein Mobiltelefon beispielsweise besteht aus Hardware, auf der unterschiedliche Software läuft, die wiederum auf unterschiedliche Services zurückgreifen, die auf mehreren Servern laufen, weshalb man das Ganze auch als verteiltes System betrachten kann.

In der agilen Welt ist auch häufig von Produkten die Rede. So können wir das Mobiltelefon als Kombination von Hard- und Software betrachten, was der Produktsicht des Geräteherstellers entspricht, während die Anbieter von Apps die Software für diese Geräte als Produkt verkaufen.

Der System-Begriff ist also sehr vielfältig. Da aber das Requirements Engineering auch sehr vielfältig ist und für alle der genannten Systeme, von ganzen Produkten bis hin zu den Teilsystemen, Anforderungen formuliert, wird hier einfach von Systemen die Rede sein; so hält es auch das International Requirements Engineering Board (IREB).

Da Anforderungen also für sehr unterschiedliche Systeme formuliert werden können, ist es wichtig, auch klar zu machen, um welches System es genau geht. Hierzu dienen Werkzeuge wie der Systemkontext, der im Abschnitt »Den Kontext des Systems verstehen« in Kapitel 8 vorgestellt wird.

Diese vier Grundaufgaben werden selten getrennt voneinander durchgeführt. Gerade die ersten beiden sind üblicherweise ineinander verwoben: Wenn wir zum Beispiel mit Stakeholdern über deren Anforderungen sprechen, ist es häufig hilfreich, uns etwas aufzuschreiben oder Abläufe in irgendeiner Form aufzuzeichnen. Das hilft uns in der Kommunikation, wenn wir gemeinsam mit dem Stakeholder darauf schauen, es hilft uns zu einem klareren Verständnis und es kann anschließend in eine Dokumentation einfließen. (Und es ist jetzt völlig egal, ob Sie hier beispielsweise an User Stories oder etwa an UML-Aktivitätsdiagramme denken.)

Der dritte Punkt, validieren, dreht sich darum, sich bei den Stakeholdern, vor allem Kunden und Nutzern, zu versichern, dass die Anforderungen auch wirklich die richtigen sind. Sie müssen also für jede Anforderung folgende Fragen beantworten:

Benötigt überhaupt jemand die Anforderung?

Ist die Anforderung richtig beschrieben?

Entspricht die Beschreibung der Anforderung den bestehenden Vorgaben?

Passt die Anforderung zu den übrigen oder gibt es Widersprüche?

Sind die Anforderungen vollständig?

Sind die Anforderungen im gegebenen Rahmen überhaupt zu erfüllen?

Diese Fragen können Sie auf sehr unterschiedliche Weise beantworten: Sie können beispielsweise umfangreiche Anforderungsdokumente einem Review unterziehen oder eng mit dem Kunden zusammenarbeiten und ihm Zwischenergebnisse in Form von lauffähiger Software präsentieren. In diesem Fall wird das Validieren in das Ermitteln, Kommunizieren und Festhalten integriert.

Beim vierten Punkt, dem Organisieren der Anforderungen, geht es um so unterschiedliche Aufgaben wie

Änderungen von Anforderungen,

Priorisierung,

Verfolgbarkeit (Traceability) und

Versionierung.

Für all diese Punkte werden sehr unterschiedliche Techniken eingesetzt, die Sie in dem Teil »IV Requirements Management« kennenlernen werden.

Die Reihenfolge der eingangs genannten vier Haupttätigkeiten ist durch das Requirements Engineering nicht starr festgelegt, sondern hängt von der Vorgehensweise und den eingesetzten Methoden ab. Gerade bei agilen Ansätzen werden die Tätigkeiten parallel ausgeführt.

Wer das Requirements Engineering macht

Wenn wir an die Aufgaben des Requirements Engineering denken, stellt sich auch die Frage, wer sie übernehmen soll. Eine naheliegende Möglichkeit: jemand im Projekt ist dafür und nur dafür zuständig. Das heißt, wir haben einen Requirements Engineer. In der Praxis ist diese Rolle mittlerweile häufig anzutreffen, aber das bedeutet natürlich nicht, dass es nicht auch anderen Möglichkeiten gibt und die Aufgaben von anderen Rollen miterledigt oder auf mehrere Rollen verteilt werden. Verbreitet ist zum Beispiel, dass die Entwickler oder die Projektleiter sich nebenbei um das Requirements Engineering kümmern.

Der Requirements Engineer

Gibt es eine oder mehrere Personen, die sich ausschließlich um die Anforderungen kümmern und dafür auch ausgebildet sind, können diese sich ganz darauf konzentrieren, mit den einschlägigen Methoden die Anforderungen handwerklich sauber zu ermitteln und zu organisieren. Darüber hinaus wird in dieser Konstellation der Aufwand für das Requirements Engineering seltener unterschätzt.

Der Requirements Engineer übernimmt im Entwicklungsvorhaben eine Schnittstellenfunktion zwischen dem Kunden und den übrigen Rollen, welche die Anforderungen benötigen, wie die Entwickler, die Tester oder die Projektmanager. Der Requirements-Engineering-Spezialist agiert hier gewissermaßen als Anwalt des Kunden und vertritt dessen Bedürfnisse.

Dafür sollte er auch einige Fähigkeiten mitbringen:

Kommunikationsfähigkeit,

analytisches Denken,

Abstraktionsvermögen,

Einfühlungsvermögen,

Moderationsfähigkeit,

Teamfähigkeit,

Konfliktlösungsfähigkeit.

Wer sonst noch das Requirements Engineering macht

Häufig wird das Requirements Engineering von anderen Rollen miterledigt, beispielsweise von

den Entwicklern,

dem Product Owner,

dem Projektleiter,

den zukünftigen Nutzern oder Kunden.

Das kann durchaus auch Vorteile haben, denn dadurch erfahren diejenigen, die mit den Anforderungen arbeiten müssen, was vor allem für die Entwickler gilt, von diesen Anforderungen aus erster Hand.

Praktisch bringt es aber häufig die Herausforderung mit sich, dass die Leute, die diese Rollen innehaben, den Schwerpunkt ihrer Arbeit in den rollenspezifischen Aufgaben sehen und daher für das Requirements Engineering über

zu wenig Zeit und

nicht das richtige Handwerkszeug verfügen.

Zu den spezifischen Herausforderungen der einzelnen Rollen können Sie im Abschnitt »Wer nimmt die Anforderungen auf?« in Kapitel 3 mehr erfahren.

Viele Arten von Anforderungen

Wenn Sie die Kunden nach ihren Anforderungen fragen, erklären diese entweder, was das System machen soll. In diesem Fall wird von funktionalen Anforderungen gesprochen. Oder sie erzählen – gerade wenn es darum geht, ein altes durch ein neues System zu ersetzen –, wie das System arbeiten soll, also schnell, zuverlässig, sicher und Ähnliches. Solche Arten von Anforderungen werden Nichtfunktionale oder Qualitätsanforderungen genannt.

Darüber hinaus wird häufig noch eine dritte Art von Anforderung unterschieden: die Rand- oder Rahmenbedingung. Allerdings geht es hier nicht nur um Anforderungen im eigentlichen Sinne, also etwas, was das Projektteam irgendwie umsetzen muss, das heißt eine Eigenschaft oder Fähigkeit des Systems. Bei den Randbedingungen geht es auch um Einschränkungen für die Realisierung des Systems wie: es soll eine bestimmte Datenbank verwendet werden oder das Ganze darf nicht teurer als eine bestimmte Summe werden.

Funktionale Anforderungen

Wenn Sie im Requirements Engineering beschreiben, was das System leisten soll, dann beschreiben Sie die funktionalen Anforderungen an das System. Funktionale Anforderungen können Sie als eine Abfolge von Schritten spezifizieren, die das System ausführen soll. Es gibt auch noch weitere Möglichkeiten, die in bestimmten Fällen auch vorzuziehen sind, aber um zu entscheiden, ob Sie es mit einer funktionalen Anforderung zu tun haben, überlegen Sie sich einfach, ob die Anforderungen als eine Abfolge von Schritten darstellbar sind.

Wenn Sie eine funktionale Anforderung beschreiben, dann werden Sie in der Regel nicht nur einen, sondern mehrere Abläufe zu einer Anforderung beschreiben, da es meist verschiedene Varianten gibt, wie das System etwas erledigen soll, und zudem auch die Fälle zu berücksichtigen sind, in denen etwas schief läuft. Neben den Ablaufschritten können Sie auch die Informationen nennen, die das System benötigt, sowie die Ergebnisse, die dabei herauskommen. Darüber hinaus kann es auch hilfreich sein, Voraussetzungen zu beschreiben.

Um funktionale Anforderungen zu verstehen und zu beschreiben, ist es hilfreich, wenn Sie den Blick vom System zum Benutzer wenden und aus dessen Sicht schildern, wie die Benutzer das System verwenden wollen. Techniken hierzu sind Anwendungsfälle und User Stories.

Nichtfunktionale Anforderungen

Kunden und Nutzer haben nicht nur Erwartungen, was das System leisten soll, sondern auch darüber, wie es etwas leisten soll. Dazu gehören unter anderem solche Fragen:

Wie schnell soll es eine bestimmte Aufgabe erledigen?

Wie sicher soll es hinsichtlich Missbrauch sein?

Wie einfach soll die Erledigung einer Aufgabe für die Nutzer sein?

Wie einfach soll es für die Entwickler sein, neue Anforderungen in das System zu integrieren?

Wie aufwendig darf es für die Entwickler sein, das System auf ein anderes Betriebssystem zu portieren?

Das Problem mit den nichtfunktionalen Anforderungen: Die Kunden und späteren Anwender sind sich häufig selbst nicht darüber im Klaren, welche Erwartungen sie eigentlich haben. Die werden ihnen erst dann klar, wenn sie mit dem System arbeiten und es sich nicht so verhält, wie sie es sich wünschen. Oder wenn die Integration neuer Anforderungen viel komplizierter und teurer wird, als sie es sich vorstellen. Einfacher ist es daher bezüglich der nichtfunktionalen Anforderungen, wenn es darum geht, ein bestehendes durch ein neues System zu ersetzen. Dann gibt es konkrete Erwartungen, die sich daraus ableiten, was in dem Altsystem nicht funktioniert.

Nichtfunktionale Anforderungen werden häufig übersehen und nur unvollständig erkannt. Viele dieser Anforderungen können die Entwickler aber nur umsetzen, indem sie das System entsprechend strukturieren, also die Systemarchitektur passend gestalten. Dies nachträglich zu machen, ist sehr aufwendig und führt daher zu unbefriedigenden Kompromissen. Warten Sie also nicht ab, bis die Nutzer am fertigen System merken, welche nichtfunktionalen Anforderungen sie eigentlich haben, sondern kümmern Sie sich frühzeitig darum.

Um Ihnen einen Überblick darüber zu geben, was möglicherweise für Ihr System an nichtfunktionale Anforderungen infrage kommt, seien in Abbildung 1.1 die Kategorien des einschlägigen ISO-Standards 25010 zur Softwarequalität genannt.

Abbildung 1.1: Kategorien nichtfunktionaler Anforderungen nach ISO 25010

Randbedingungen

Wenn Sie den Auftrag erhalten, ein System zu entwickeln, heißt das selten, dass jetzt alles erlaubt ist, um die gegebenen Anforderungen umzusetzen. Bestimmt gibt es Erwartungen, was das System höchstens kosten darf oder bis wann das Ganze in Betrieb gehen soll. Häufig wird Ihnen auch die Vorgehensweise vorgegeben, also ob zum Beispiel agil oder eher klassisch zu entwickeln ist.

Durch Vorgaben dieser Art sind Sie nicht mehr ganz so frei, was die Umsetzung der Anforderungen betrifft, denn alle Varianten, die teurer werden oder länger brauchen, scheiden schon mal aus. Die Vorgaben schränken also die Vielfalt der möglichen Lösungen stark ein. Genau genommen nicht nur der Lösungen, sondern auch der Anforderungen, denn Anforderungen, zu denen es keine Lösungen gibt, die zu den Vorgaben passen, lassen sich natürlich auch nicht umsetzen.

Solche Einschränkungen für mögliche Anforderungen und Lösungen werden Randbedingungen oder Rahmenbedingungen genannt.

Die genannten Beispiele für Randbedingungen schränken den Raum der Möglichkeiten in organisatorischer Hinsicht ein. Daneben gibt es aber auch technische Randbedingungen, wenn etwa vorgegeben wird, dass eine bestimmte Programmiersprache, eine bestimmte Datenbank oder ein bestimmtes Framework zu verwenden ist.

Manches steht schon zu Beginn eines Projekts als Randbedingung fest, zum Beispiel welches Datenbanksystem erlaubt ist. Möglicherweise darf das Projektteam dies auch nach eigener Einschätzung frei entscheiden, was die Anforderungen am besten erfüllt. Je nachdem spielt die Festlegung auf ein Datenbanksystem also die Rolle einer Randbedingung oder eines Lösungsansatzes.

Der Unterschied liegt darin, ob die Festlegung schon vor dem Projekt erfolgt, und daher aus Gründen, die außerhalb des Projekts zu suchen sind; hier etwa: wir haben bereits dieses Datenbanksystem bei uns und kennen uns daher damit schon gut aus. Im anderen Fall erfolgt die Festlegung erst auf dem Weg zur Lösung und ergibt sich aus den Anforderungen.

Daneben können die Randbedingungen auch echte Anforderungen enthalten, zum Beispiel Barrierefreiheit. Diese Anforderung kann sowohl die Rolle einer nichtfunktionalen Anforderung spielen als auch die einer Randbedingung, beispielsweise wenn dies aus einer verbindlichen Unternehmensvorgabe folgt.

Man kann sich darüber streiten, ob Randbedingungen überhaupt Anforderungen sind, aber zumindest das International Requirements Engineering Board (IREB) sieht es so. Mehr zu dieser Frage im Kasten »Sind Randbedingungen Anforderungen?« in Kapitel 11.

Abstraktionsstufen von Anforderungen

Eine ganz andere Art der Unterscheidung von Anforderungen geht von einer Hierarchie der Perspektiven aus, die von der geschäftlichen Sicht über die Stakeholder- und die Nutzer- bis hin zur Systemsicht geht. So etwas findet sich beispielsweise in dem ISO-Standard 29148 »Systems and software engineering – Life cycle processes – Requirements engineering«. Dort werden folgende Abstraktionsstufen von Anforderungen definiert.

Business Requirements:

Geschäftliche Anforderungen, die eine Organisation mit dem System erfüllen will. Verortet das zu entwickelnde System (oder die Systeme) im Geschäftsmodell und beschreibt den Nutzen aus geschäftlicher Sicht.

Stakeholder Requirements:

Anforderungen an das System aus Sicht der Stakeholder. Hier wird die gewünschte Unterstützung der Geschäftsprozesse durch das System konkretisiert.

User Requirements:

Beschreiben die vorgesehenen Nutzungen des Systems in ihrem Nutzungskontext, aber auch die zugehörigen nichtfunktionalen Anforderungen. Die User Requirements sind Teil der Stakeholder Requirements.

System Requirements:

Definiert den Systemkontext, die funktionalen und nichtfunktionalen Anforderungen für das gesamte System, einschließlich der Verifikation.

Software Requirements:

Funktionen und nichtfunktionalen Anforderungen für ein Softwaresystem, einschließlich der Verifikation. Ist die Software Teil eines größeren Systems, werden die Rolle der Software und die Schnittstellen zu dem System beschrieben.

Das International Requirements Engineering Board (IREB) nimmt diese Unterscheidung der ISO auf und fügt ihr noch eine weitere Kategorie zu:

Domain Requirements:

Anforderungen an die organisatorische oder technische Umgebung des Systems.

Diese sehr feingranulare Unterscheidung von Anforderungen schlägt sich in der ISO 29148 auch in der Dokumentation von Anforderungen nieder, die eine Business Requirements Specification, eine Stakeholder Requirements Specification, eine System Requirements Specification und eine Software Requirements Specification vorsieht. Mehr zu den Arten der Dokumentation können Sie im Abschnitt »Gliederung von Anforderungsdokumenten« in Kapitel 13 nachlesen.

Dies ist natürlich mit einem beträchtlichen Aufwand verbunden und in der Praxis selten anzutreffen. Allenfalls bei sehr komplexen Systemen wie Flugzeugen kann das in dieser Ausführlichkeit angemessen sein.

Die Unterscheidung von funktionalen und nichtfunktionalen Anforderungen sowie Randbedingungen auf der einen Seite und die hier vorgestellten Abstraktionsstufen schließen sich nicht gegenseitig aus, sondern verlaufen gewissermaßen quer zueinander. In den verschiedenen hierarchischen Kategorien finden sich sowohl funktionale als auch nichtfunktionale Anforderungen.

Möglichkeiten der Zertifizierung

Wenn Sie Ihr Wissen im Requirements Engineering nachweisen wollen, können Sie eines der folgenden Zertifikate erwerben:

Certified Professional for Requirements Engineering

(CPRE) vom International Requirements Engineering Board (IREB), dies gibt es für Einsteiger, Fortgeschrittene und Experten.

Certified Business Analysis Professional

(CBAP) und weitere Zertifikate des International Institute of Business Analyses (IIBA)

PMI Professional in Business Analysis

(PMI-PBA) vom Projektmanagement Institute (PMI)

Im Folgenden werden diese genauer beschrieben.

Zertifikate des IREB

Im deutschsprachigen Raum sind die Zertifizierungen des International Requirements Engineering Board (IREB) am verbreitetsten, insbesondere das Grundlagenzertifikat Certified Professional for Requirements Engineering – Foundation Level (CPRE FL).

Den inhaltliche Anspruch, den das IREB mit dem Foundation Level verbindet, besteht darin, die grundlegenden Techniken des Requirements Engineering unabhängig von der Vorgehensweise nachzuweisen; also unabhängig davon, ob Sie klassisch wasserfallmäßig oder agil vorgehen. Der Schwerpunkt liegt dabei eher auf den klassischen Techniken, aber es werden dort auch spezifisch agile Methoden behandelt. Vieles können Sie auch in beiden Vorgehensweisen einsetzen.

Alles, was Sie an Wissen über Requirements Engineering benötigen, um das Zertifikat CPRE FL zu erwerben, finden Sie hier im Buch.

Für das Foundation Level müssen Sie keine Voraussetzungen erfüllen und lediglich eine Multiple-Choice-Prüfung ablegen, die Sie in zahlreichen Sprachen durchführen können, unter anderem in Deutsch und Englisch.

Neben dem Foundation Level bietet das IREB aber auch unterschiedliche Zertifikate im sogenannten Advanced- beziehungsweise Expert-Level an.

Mit den vier Varianten des Advanced-Zertifikats können Sie folgende Themen vertiefen:

Requirements Elicitation:

Methoden und Techniken, um Anforderungen zu ermitteln.

Requirements Modeling:

Grafische Beschreibung funktionaler Anforderungen.

Requirements Management:

Methoden und Techniken, um Anforderungen zu verwalten.

RE@Agile:

Die Einbettung klassischer und agiler Techniken des Requirements Engineering in ein agiles Vorgehen.

Die Hürde für die Advanced-Zertifikate ist naturgemäß etwas höher als beim Foundation Level: Zum einen müssen Sie bereits über das Foundation-Zertifikat verfügen. Zum anderen erwartet das IREB neben dem Multiple-Choice-Test auch noch eine Hausarbeit von Ihnen.

Richtig schwierig wird es dann beim Expert-Level: Als Voraussetzung verlangt das IREB von Ihnen drei Advanced-Zertifikate (oder vergleichbare Nachweise), drei Jahre Praxis im Requirements Engineering sowie Erfahrungen als Trainer oder Coach. In einer schriftlichen Bewerbung müssen Sie belegen, dass Sie die genannten Voraussetzungen erfüllen. Anschließend ist hier eine Hausarbeit fällig, die Sie später in einer mündlichen Prüfung vorstellen und verteidigen. In der mündlichen Prüfung werden Sie aber auch noch allgemein zum Requirements Engineering befragt – und das alles auf Englisch.

Außerhalb der Foundation-Advanced-Expert-Einordnung bietet das IREB auch noch ein Zertifikat speziell für das agile Requirements Engineering an, das sogenannte RE@Agile-Primer-Zertifikat. Hier geht es um einschlägige agile Requirements Engineering-Techniken wie User Stories oder Product Backlog und inwieweit das mit den eher klassischen Techniken kombiniert werden kann. Vom Umfang des Stoffes und der Prüfung ist dieses Zertifikat noch unterhalb des Foundation Levels einzuordnen.

Überraschenderweise ist das RE@Agile-Primer-Zertifikat nicht die Voraussetzung für das RE@Agile-Advanced-Zertifikat – hierfür benötigen Sie das Foundation-Zertifikat.

Hier noch mal der Überblick über alle Zertifikate des International Requirements Engineering Board (IREB):

Foundation Level:

Hier müssen Sie nachweisen, dass Sie die grundlegenden Techniken des Requirements Engineering kennen und einige davon anwenden können.

Advanced Level:

Um Ihre fortgeschrittenen Kenntnisse nachzuweisen, bietet das IREB vier Zertifikate an:

Elicitation

,

Requirements Modeling

,

Requirements Management

und

RE@Agile

.

Expert Level:

Damit können Sie Ihr Expertenwissen auf höchstem Niveau nachweisen.

RE@Agile Primer:

Hier geht es um die Grundlagen des Requirements Engineerings im agilen Vorgehen.

Praktisch für Sie: die Zertifikate des IREB haben eine unbegrenzte Dauer und müssen nicht erneuert werden.

Zertifikate des IIBA

Vom inhaltlichen Anspruch sehr umfassend sind die Zertifikate des International Institute of Business Analyses (IIBA). Dies liegt auch daran, dass das Konzept der Business Analysis in der Sicht des IIBA umfassender ist als das des Requirements Engineering: Während dieses erst mit dem Beginn eines Projekts einsetzt und mit diesem auch beendet wird, geht es bei der Business Analysis auch darum, wie zuvor überhaupt der Bedarf festgestellt und anschließend der Nutzen überprüft wird.

Das IIBA bietet ebenfalls ein dreistufiges Zertifizierungsverfahren an:

Entry Certificate in Business Analysis (ECBA):

Wie der Name schon sagt, das Einsteigerzertifikat vom IIBA, mit dem Sie Ihr Basiswissen in den vom IIBA vorgesehenen Bereichen der Business Analysis nachweisen.

Certificate of Capability in Business Analysis (CCBA):

Hiermit weisen Sie nach, dass Sie in der Lage sind, die Methoden der Business Analysis selbständig anzuwenden.

Certified Business Analysis Professional (CBAP):

Durch dieses Zertifikat können Sie zeigen, dass Sie ein tiefes Verständnis der Methoden des Business Analysis haben, das Sie selbständig auf unterschiedlichste Situationen anwenden können.

Entsprechend dem recht hohen Anspruch des IIBA benötigen Sie auch ein umfangreiches Wissen an Business-Analysis- beziehungsweise Requirements-Engineering-Methoden, um die Prüfung zum Zertifikat zu bestehen. Darüber hinaus müssen Sie auch noch einige formale Voraussetzungen erfüllen:

Sie müssen für die letzten vier Jahren mindestens einundzwanzig Stunden, für den CPAB sogar 35 Stunden Weiterbildung in der Business Analysis nachweisen,

Sie haben umfangreiche praktische Erfahrungen in der Business Analysis gesammelt (nur CCBA und CBAP) und

Sie können Führungskräfte oder Kunden als Referenzen angeben (nur CCBA und CBAP).

Außerdem gibt es noch ein Zertifikat für die Business Analysis im agilen Umfeld, die Agile Analysis Certification (AAC). Hierfür müssen Sie keine formalen Voraussetzungen erfüllen, aber es werden zwei bis drei Jahre einschlägige Erfahrungen erwartet. Von daher entspricht dies in etwa dem Niveau des CCBA.

Das IIBA hat seinen Hauptsitz in Kanada, ist aber weltweit verbreitet und auch in Deutschland, Österreich und der Schweiz vertreten. Entsprechend der Herkunft des IIBA finden die Prüfungen auf Englisch statt. Die Zertifikate sind global gesehen bekannter als die des IREB, aber im deutschsprachigen Raum hat das IREB beim Bekanntheitsgrad klar die Nase vorn.

Die fortgeschrittenen Zertifikate des IIBA, also CCBA und CBAP, müssen Sie regelmäßig erneuern, indem Sie nachweisen, dass Sie sich fortwährend weiterbilden, beispielsweise durch den Besuch von Seminaren oder Konferenzen.

PMI Professional in Business Analysis (PMI-PBA)

Eine weitere Möglichkeit der Zertifizierung bietet das Projekt Management Institut (PMI) an. Das PMI ist in den USA beheimatet, aber weltweit verbreitet. Bekannt ist es vor allem für sein Zertifikat »Project Management Professional (PMP)«, das zweifellos zu den führenden im Bereich Projektmanagement gehört. Mit der Zeit hat das PMI weitere Zertifizierungsmöglichkeiten geschaffen, darunter auch PMI Professional in Business Analysis (PMI-PBA). Mehrere Stufen der Zertifizierung sind hier – anders als beim IREB oder IIBA – nicht vorgesehen, es geht hier recht anspruchsvoll los. Der PMI-PBA ist praktisch das Konkurrenzprodukt des PMI zum CBAP des IIBA.

Entsprechend der Herkunft vom Projekt Management Institut wird hier die Business Analysis vor allem als Teil eines Projekts betrachtet und kommt damit der IREB-Sicht näher als der IIBA-Sicht, welche die Business Analysis auch projektübergreifend betrachtet.

Wie das IIBA formuliert auch das PMI ein paar Voraussetzungen, die erfüllt sein müssen, bevor Sie überhaupt zur Prüfung zugelassen werden:

Sie müssen belegen, dass Sie in den letzten vier Jahren Trainings zur Business Analysis im Umfang von mindestens fünfunddreißig Stunden besucht haben, und

Sie haben bereits umfangreiche praktische Erfahrungen in der Business Analysis gesammelt.

Auch die Prüfung zum PMI-PBA findet auf Englisch statt und auch hier müssen Sie das Zertifikat regelmäßig erneuern, indem Sie nachweisen, dass Sie sich fortwährend weiterbilden, beispielsweise durch den Besuch von Seminar oder Konferenzen.

Kapitel 2

Einbettung des Requirements Engineering

IN DIESEM KAPITEL

Wann Requirements Engineering stattfindetDie Kunden des Requirements EngineeringUnterschiede zwischen agilen und klassischen EntwicklungsvorhabenWann Festpreis und wann Aufwandspreis sinnvoll ist

Das Requirements Engineering spielt in jedem Entwicklungsvorhaben eine zentrale Rolle – ganz gleich, ob es um zeitlich begrenzte Projekte geht oder es sich um fortdauernde Produktentwicklungen handelt. Schließlich geht es darum, herauszubekommen, was das zu entwickelnde System leisten soll. Da jedes Entwicklungsvorhaben letztlich zum Ziel hat, die Anforderungen umzusetzen, benötigen auch die übrigen beteiligten Disziplinen wie zum Beispiel Entwicklung, Projektmanagement oder Testen die Ergebnisse des Requirements Engineering.

Wann Sie sich in einem Entwicklungsvorhaben um die Anforderungen kümmern müssen, kann sehr unterschiedlich sein: Mal müssen sämtliche Anforderungen bereits zu Beginn erhoben werden, mal ist es eine laufende Aufgabe über ein ganzes Projekt. Mal betrachtet das Projektteam Änderungen und neue Anforderungen als eine Selbstverständlichkeit, mal als Störung.

In diesem Kapitel gewinnen Sie einen Überblick, wie das Requirements Engineering mit den weiteren Disziplinen zusammenarbeitet und wie die unterschiedlichen Vorgehensweisen und andere Einflussfaktoren auf das Requirements Engineering zurückwirken.

Das Zusammenspiel mit den übrigen Beteiligten

Die Einbettung des Requirements Engineering ist bestimmt durch das Zusammenspiel mit den weiteren an der Entwicklung beteiligten Disziplinen wie auch mit den Stakeholdern und durch die Verankerung in die Geschäftsprozesse. In diesem Zusammenspiel wird der Dokumentation der Anforderungen häufig eine zentrale Rolle zugedacht.

Die Kunden des Requirements Engineering

Das Requirements Engineering muss liefern – und zwar an seine Kunden. Also werfen wir einen Blick auf die Kunden und darauf, was sie erwarten; das ist nämlich je nach Kunde sehr unterschiedlich. Und bei »Kunde« sollten wir nicht nur an diejenigen denken, die am Ende ein System oder Produkt erhalten, sondern auch an die internen Kunden innerhalb des Projekts. Die wichtigsten Kunden des Requirements Engineering sind:

Der

Endkunde:

Er will wissen, was er geliefert bekommt.

Die

Entwickler:

Sie müssen wissen, was der Nutzer braucht.

Die

Architekten:

Sie müssen das System so gestalten, dass es (auch) die nichtfunktionalen Anforderungen erfüllt.

Die

Tester:

Auf Grundlage der Anforderungen erarbeiten sie die Testfälle.

Die

Projektmanager:

Auf Grundlage der Anforderungen planen sie die Umsetzung.

Diese Liste ließe sich noch fortsetzen, aber die wichtigsten Kunden des Requirements Engineering haben wir damit schon mal benannt.

Nicht immer gibt es die hier genannten Rollen. So kennt zum Beispiel Scrum keine Projektmanager, trotzdem bleiben die Projektmanagementaufgaben weiter zu erledigen, nur machen das hier halt andere Rollen, wie Product Owner und Development Team. Und diese benötigen dafür ebenfalls das Wissen um die Anforderungen.

Wer sonst noch so wichtig ist: die Stakeholder

Ein Begriff, der im Zusammenhang mit Projekten immer wieder fällt, ist »Stakeholder«. Sie scheinen überall mitzumischen und auf jeden Fall sehr wichtig zu sein. Wer sind also diese Stakeholder und welche Rolle spielen sie im Requirements Engineering?

Eine gängige und verbreitete Definition lautet: Stakeholder sind Personen oder Gruppen von Personen, die ein Interesse (einen »Stake«) an einem Projekt oder an dessen Ergebnissen haben. Das kann beispielsweise sein:

Kunde oder Auftraggeber,

Nutzer,

Management,

Tester,

Entwickler,

Betriebsrat,

Gesetzgeber.

Stakeholder können also sowohl Einzelpersonen sein als auch Gruppen von Personen oder Institutionen wie der Gesetzgeber, hinter denen ja am Ende auch wieder Personengruppen stecken.

Aus Sicht des Requirements Engineering sind Stakeholder interessant und wichtig, weil sie Anforderungen an das System haben können. Oder andersherum betrachtet: Wenn wir Stakeholder übersehen, übersehen wir wahrscheinlich auch Anforderungen.

Aus der genannten Definition von Stakeholdern ergibt sich eine sehr große Gruppe von Stakeholdern, die sowohl die Mitarbeiter eines Entwicklungsprojekts umfasst als auch Leute im direkten Umfeld wie die Kunden oder Nutzer bis hin zum Gesetzgeber. Praktisch werden aber meist nur diejenigen als Stakeholder bezeichnet, die nicht zum Projektteam gehören, also der Kunde da draußen, der Betriebsrat oder der Gesetzgeber. In diesem Sinne wird der Begriff in der Regel auch in diesem Buch verwendet.

Die Basis vieler Anforderungen: die Geschäftsprozesse

Viele Systeme werden entwickelt, um geschäftliche Abläufe zu unterstützen, etwa um Bestellprozesse abzuwickeln, den Warenumschlag in einem Hafen zu lenken oder Produktionsprozesse zu steuern. Um die Anforderungen für solche Systeme abzuleiten, müssen die Geschäftsprozesse auch bekannt sein. Das Wissen um die Geschäftsprozesse ist in diesen Fällen eine wesentliche Grundlage des Requirements Engineering. Dieses Wissen kann durch Geschäftsprozessbeschreibungen etwa mit BPMN (Business Process Model and Notation) zur Verfügung gestellt werden oder mündlich durch Stakeholder.