Management-Zusammenfassung dieses Beitrags:
Prozesse im → Requirements Engineering geben vor, in welcher Reihenfolge Anforderungen ermittelt, dokumentiert, validiert und bei Bedarf verwaltet werden.
In diesem Beitrag werden Prozesse und Vorgehensmodelle für das Requirements Engineering beschrieben.
Hinweis:
Grundsätzlich kann das Requirements Engineering über Prozesse gesteuert werden. Nach → IREB gibt es jedoch nur einen Requirements-Engineering-Prozess (RE-Prozess), der lediglich angepasst werden muss. Diese Sicht- und Sprechweise weicht von der Sichtweise im → Projektmanagement ab. In diesem Beitrag können Prozesse — abweichend von der IREB-Sicht — auch Teil eines Gesamt-RE-Prozesses sein.
1. Einleitung und Grundlagen
1.1 Definitionen
Im → Glossar des IREB steht zum Prozess /#IREB-Glossar-24/:
“A set of interrelated activities performed in a given order to process information or materials.“
Die deutsche Übersetzung lautet:
“Eine Reihe von zusammenhängenden Tätigkeiten, die in einer bestimmten Reihenfolge ausgeführt werden, um Informationen oder Materialien zu verarbeiten.”
Diese Definition lässt Spielräume, denn damit können sowohl umfangreiche als auch wenig aufwendige Themen gemeint sein.
Wesentlich ist, dass es keinen Universal-RE-Prozess für alle Arten von RE-→ Vorhaben gibt, sondern dass ein RE-Prozess vorab passend zusammengestellt werden muss.
1.2 Der RE-Prozess nach IREB
Der RE-Prozess des IREB unterteilt das Requirements Engineering in die Bereiche Anforderungsentwicklung (Requirements Development) und → Anforderungsverwaltung (→ Requirements Management), wobei diese wiederum in die vier Haupttätigkeiten (auch Hauptaktivitäten oder Prozessschritte) …
- Ermitteln (Eliciting),
- Dokumentieren (Documenting),
- Validieren (Validating) und
- Verwalten (Managing)
untergliedert werden können (Abbildung 1.1). Die Pfeile symbolisieren eine Abarbeitungsreihenfolge, wobei die gepunkteten Pfeile mögliche Rücksprünge aufzeigen.
Abbildung 1.1: Der Prozess für das Requirements Engineerings nach IREB
Das → Verwalten von Anforderungen ist nicht in eine Prozessreihung eingebunden und hier nur der Vollständigkeit halber dargestellt.
1.3 Der RE-Prozess nach Wiegers
Bei Wiegers findet sich ein RE-Prozess (nur für die Anforderungsentwicklung), der große Ähnlichkeiten mit dem IREB-Prozess aufweist (Abbildung 1.2). Das Documenting aus dem IREB-Prozess ist aufgeteilt in Analysis und Specification. Zudem werden bei den Rücksprüngen Tätigkeiten benannt.
Abbildung 1.2: Der RE-Prozess nach Wiegers /Wiegers23/
1.4 Die Einbettung des Requirements-Engineering-Prozesses
Ein Requirements-Engineering-Prozess ist immer in einen überspannenden Projekt- oder Produktprozess eingebunden (Abbildung 1.3). Zudem erfolgt die System- oder → Softwareentwicklung über den Systementwicklungsprozess in enger Abstimmung mit dem Requirements-Engineering-Prozess, zwischen beiden gibt es Rückkopplungen.
Abbildung 1.3: Die Einbettung des RE-Prozesses
2. Einflussfaktoren auf den Requirements-Engineering-Prozess
Das IREB benennt neun Einflussfaktoren auf den Requirements-Engineering-Prozess (Abbildung 2.1). Dies sind:
- Eignung im Gesamtprozess (englisch: Overall process fit): Der RE-Prozess muss zum Gesamtentwicklungsprozess passen
- Entwicklungskontext (Development context): Hierbei geht es in erster Linie um Art der Zusammenarbeit und Vertrauen zwischen den Beteiligten. Es muss beachtet werden, wie die Kunden-Lieferanten-Beziehung ist, wie ein Vertrag ausgestaltet ist und wer welche Tätigkeiten übernimmt
- Fähigkeit und Verfügbarkeit von Stakeholdern (Capability and availability of stakeholders): Ein zentraler Punkt ist die Fähigkeit und Verfügbarkeit der → Stakeholder. Wenn die Stakeholder nicht oder kaum verfügbar sind, so können entsprechend → Interviews nur eingeschränkt genutzt werden. Sind die Stakeholder in der Lage, in Requirements-Engineering-Strukturen zu denken, so kann dies das RE-Vorhaben beschleunigen
- Gemeinsames Verständnis (Shared understanding): Wenn es bereits ein gemeinsames Verständnis der Beteiligten über die Fachdomäne gibt, so können die Vorlauf- oder Einarbeitungsthemen kurz behandelt werden. Zudem kann ein leichtgewichtige Vorgehen gewählt werden
- → Komplexität und Kritikalität des zu entwickelnden Systems (Complexity and Criticality to be developed): Je komplexer oder kritischer das zu entwickelnde System ist, umso mehr muss detailliert spezifiziert werden. Ein System, welches ein hohes Maß an Sicherheit (“→ Safety und → Security”) verlangt, sollte eine andere Form des RE-Prozesses verwenden als einfache Systeme (wie beispielsweise eine Informations-Website)
- Randbedingungen (Constraints): Der RE-Prozess kann durch organisatorische Vorgaben eingeschränkt werden. Ebenso kann es von (außen kommende) regulatorische Vorgaben geben, wie beispielsweise einzuhaltende Gesetze, Normen oder Standards
- Verfügbare Zeit und Budget (Available time and budget): Die verfügbare Zeit und das verfügbare Budget haben Einfluss auf das RE-Vorhaben und damit auf den RE-Prozess. Aber Achtung: Dieser Einflussfaktor kann im Widerspruch zur Durchführbarkeit eines Vorhabens stehen: Wenn Zeit oder Budget nicht ausreichend zur Verfügung stehen, kann das RE-Vorhaben nicht erfolgreich abgeschlossen werden
- Volatilität von Anforderungen (Volatility of requirements): Wenn sich die Anforderungen im Laufe eines RE-Vorhabens oder RE-Projekts ändern können, so muss dies der RE-Prozess entsprechend berücksichtigen
- Erfahrungen der Requirements Engineers (Experience of requirements engineers): Wenn die Requirements Engineers passende Erfahrungen haben, so kann dies zur Verschlankung und Beschleunigung des RE-Prozesses führen
Abbildung 2.1: Einflussfaktoren auf den Requirements-Engineering-Prozess nach IREB /IREB-24/
3. Die Facetten des Requirements-Engineering-Prozesses
Das IREB definiert “drei Facetten” des Requirements-Engineering-Prozesses (Abbildung 3.1) die eine zielgerichtete Anpassung des Prozesses erleichtern sollen.
Die drei Facetten sind:
- Zeit: Ein RE-Prozess kann linear oder → iterativ sein. Ein lineares Vorgehen ist in der Regel “schwergewichtig”, während ein iteratives Vorgehen “leichtgewichtig” ist
- Ziel: Das RE-Produkt und damit ein RE-Prozess kann auf den Kunden oder auf den Markt ausgerichtet sein
- Zweck: Ein RE-Prozess kann präskriptiv oder explorativ sein. Bei einem präskriptiven werden die Anforderungen möglichst früh und umfassend beschrieben, um auf dieser Basis ein → Lastenheft mit einem Vertrag erstellen zu können
Abbildung 3.1: Die Facetten des Requirements-Engineering-Prozesses nach IREB /#IREB-CPRE-FL-Handbuch-24/
Die Bestimmung der Facetten sollte vor dem → Start eines RE-Projekts erfolgen. Im Zusammenspiel mit den Einflussfaktoren kann dann ein “maßgeschneiderter” RE-Prozess zusammengestellt werden. Dabei empfiehlt das IREB ein Vorgehen in fünf Schritten /#IREB-CPRE-FL-24, #IREB-CPRE-FL-Handbuch-24/ (Abbildung 3.2):
- Analysieren der Einflussfaktoren
- Beurteilen der Facettenkriterien
- Konfigurieren des Prozesses
- Arbeitsprodukte bestimmen
- Geeignete Praktiken auswählen
Abbildung 3.2: Fünf Schritte zur Zusammenstellung eines RE-Prozesses nach IREB /#IREB-CPRE-FL-24/
Hinweis:
Die Erstellung eines “maßgeschneiderten” RE-Prozesses ist nicht trivial, hat aber enorme Auswirkungen auf Kosten und Durchführbarkeit. Daher sollten Auswahl und Anpassung nur durch einen erfahrenen → Requirements Engineer oder Berater vorgenommen werden.
4. Der Einsatz von Prozessen im Requirements Engineering
Über Prozesse kann eine Zuordnung von Werkzeuge, Methoden, Aufgaben, Tätigkeiten, Arbeitsprodukten und Praktiken erfolgen. Hierbei können alle möglichen Elemente zusammengetragen und dann die nicht-benötigten “weggestrichen” werden.
5. Prozesse in der Business Analysis
Die Sicht auf Prozesse ist in der → Business Analysis nach → IIBA und → PMI eine andere: Dort wird der Ablauf über → Wissensgebiete (Knowledge Areas) gesteuert, die wiederum Prozesse oder Tasks beinhalten.
5.1 Die BA-Tasks beim IIBA
Das IIBA verwendet sechs Wissensgebiete zur Strukturierung des Vorgehens in der Business Analysis, denen wiederum 30 Aufgaben / Tasks zugeordnet sind. Der Begriff Prozesse wird in diesem Zusammenhang nicht verwendet.
Abbildung 5.1: Wissensgebiete und Aufgaben nach IIBA /BBG15, BBG17‑d/
Aufgaben / Tasks sind beispielsweise die fünf Elicitation-Tasks Prepare for Elicitation, Conduct Elicitation, Confirm Elicitation Results, Communicate Business Analysis Information und Manage Stakeholder Collaboration. Diesen Tasks können dann Methoden zugeordnet werden.
5.2 Die BA-Prozesse beim PMI
In Abbildung 5.2 sind die sechs Wissensgebiete (Knowledge Areas) und sechs Prozessgruppen (Business Analysis Groups) nach PMI gegenübergestellt, die Zahlangaben stellen die Anzahl der Prozesse dar. Ingesamt gibt es 35 Prozesse; die vier Prozesse zum → Wissensgebiet Elicitation heißen Determine Elicitation Appoach (gehört zur Process Group Planning), Prepare for Elicitation, Conduct Elicitation, Conduct Elicitation Results (alle drei gehören zu Executing). Den einzelnen Prozessen werden können dann Tools and Techniques (→ Werkzeuge und Methoden) zugeordnet werden.
Abbildung 5.2: Wissensgebiete, Prozessgruppen und Prozesse nach PMI /PMG-BA17/
6. Häufig gestellte Fragen und Antworten (FAQ) zu den Prozessen im Requirements Engineering
Einige Fragen zu den Prozessen im Requirements Engineering werden häufig gestellt – diese werden hier wiedergegeben und beantwortet.
- F: Müssen Prozesse für das Requirements Engineering benannt und beschrieben werden?
A: Ja und nein. Bei kleinen Vorhaben, die mit der Erstellung eines Lastenhefts beendet sind, werden nicht unbedingt Prozesse benötigt. - F: Wer ist für die Beschreibung von Prozessen im Requirements Engineering verantwortlich?
A: Der zentrale Ansprechpartner für die Prozesse im Requirements Engineering ist derjenige, der die Prozesse (für das Requirements Engineering) vorgeben darf.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
A.1 Meine öffentliche Präsentation zu den Prozessen im Requirements Engineering
Meine Präsentation zu den Werkzeugen und Methoden im Requirements Engineering enthält starke Bezüge zu den Prozessen im Requirements Engineering.
Inhalt | Typ |
---|---|
Requirements Engineering: Werkzeuge und Methoden – Eine Übersicht |
A.2 Literatur
- /BBG15/ IIBA: A Guide to the Business Analysis Body of Knowledge (BABOK Guide), International Institute of Business Analysis, Marietta, Georgia 3rd Edition 2015, ISBN 978–1‑927584–02‑6
- /BBG17‑d/ IIBA: BABOK v3: Leitfaden zur Business-Analyse BABOK Guide 3.0, Dr. Götz Schmidt, Wettenberg 2017, ISBN 978–3‑945997–03‑1
- /Ebert22/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 7. Auflage 2022, ISBN 978–3‑86490–919‑1
- /Hruschka23/ Peter Hruschka: → Business Analysis und Requirements Engineering. Prozesse und Produkte nachhaltig verbessern, Hanser, München 3. Auflage 2023, ISBN 978–3‑446–47692‑9
- /IREB21/ siehe /Pohl21/
- /PMG-BA17/ Project Management Institute: The PMI Guide to Business Analysis, Project Management Institute, Philadelphia, Pennsylvania 2017, ISBN 978–1‑62825–198‑2
- /PMG-BA23/ Project Management Institute: Business Analysis for Practitioners. A Practice Guide, Project Management Institute, Philadelphia, Pennsylvania 2nd Edition 2023, ISBN 978–1‑62825–808‑0
- /Pohl21/ auch /IREB21/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-→ Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt, Heidelberg 5. Auflage 2021, ISBN 978–3‑86490–814‑9
- /Robertson12/ Suzanne Robertson, James Robertson: Mastering the Requirements Process, Addison-Wesley Professional, Boston, Massachusetts 3rd Edition 2012, ISBN 978–0‑321–81574‑3
- /Rupp20/ Chris Rupp: Requirements-Engineering und ‑Management. Das Handbuch für Anforderungen in jeder Situation, Hanser, München 7. Auflage 2020, ISBN 978–3‑446–45587‑0
- /Wiegers13/ Karl E. Wiegers, Joy Beatty: Software Requirements, Microsoft Press, Redmond, Washington 3rd Edition 2013, ISBN 978–0‑7356–7966‑5
- /Wiegers23/ Karl Wiegers, Candase Hokanson: Software Requirements Essentials. Core Practices for Successful Business Analysis, Addison-Wesley Professional, Boston, Massachusetts 2023, ISBN 978–0‑13–819028‑6
A.3 Weblinks
- /IREB/ IREB – International Requirements Engineering Board: Website (deutsche Fassung)
- /IREB-24/, /#IREB-24/, /#IREB-CPRE-FL-24/ IREB – International Requirements Engineering Board: Lehrplan / Syllabus zum CPRE-FL, Version 3.2.0 vom Februar 2024 (deutsch, pdf-Datei, 51 Seiten)
- /#IREB-CPRE-FL-Handbuch-24/ IREB – International Requirements Engineering Board: Handbuch für das CPRE Foundation Level nach dem IREB-Standard, Version 1.2.0 vom Mai 2024 (deutsch, pdf-Datei, 174 Seiten)
- /#IREB-Glossar-24/ IREB – International Requirements Engineering Board: Glossar des IREB, Version 2.1.1 vom April 2024 (deutsch, englisch, pdf-Datei, 65 Seiten)
- /#Wiki-Anforderungsanalyse/ Anforderungsanalyse (Informatik) in der deutschen Wikipedia
- /#Wiki-Requirements-Analysis‑e/ Requirements Analysis in der englischen Wikipedia
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 02.10.2024 © Peterjohann Consulting, 2005–2024