Management-Zusammenfassung dieses Beitrags:
Um → Requirements Engineering zu betreiben, muss der → Aufwand dafür berücksichtigt werden.
Dieser Beitrag beschäftigt sich mit “typischen” Aufwänden für das Requirements Engineering.
Der Aufwand zum Betreiben von Requirements Engineering (RE) sollte vor dem Start eines Requirements-Engineering-Vorhabens bestimmt werden. Hierüber kann verdeutlicht werden, wie viel Arbeitszeit für das gesamte → Vorhaben aufgewandt werden muss.
Generell unterteilt sich der Aufwand in zwei Kategorien (Abbildung 0.1):
- Zum einen der Aufwand, um überhaupt Requirements Engineering in einer Organisation betreiben zu können
- Zum anderen der Aufwand, um ein konkretes Requirements-Engineering-Vorhaben oder ‑Projekt umzusetzen
Abbildung 0.1: → Aufwände beim Requirements Engineering
In diesem Beitrag geht es in erster Linie um den Aufwand “für das RE” (linke Hälfte in Abbildung 0.2) und nicht um Aufwand “im RE” (rechte Hälfte in Abbildung 0.2).
Abbildung 0.2: Aufwand beim Requirements Engineering: Fokus Verankerung
Generell sollte jedoch der Aufwand beim Requirements Engineering dem Nutzen gegenübergestellt werden.
Wo kann ich Sie unterstützen?
Die Ermittlung von Aufwänden ist nicht einfach. Daher biete ich dazu → Dienstleistungen / Workshops an.
1. Einleitung und Grundlagen
Der Einsatz von Requirements Engineering erfordert einen Aufwand. In der Praxis wird dieser häufig unterschätzt, sodass dem Requirements Engineering nicht genügend Ressourcen zugeordnet werden. Hieraus resultieren dann in der Folge einige Missstände, so beispielsweise:
- Das Ergebnis des Requirements Engineerings ist unzureichend
- Die involvierten Mitarbeiter sind mit ihrer eigenen Arbeitsleistung unzufrieden
Abgrenzungen:
Generell wird in diesem Beitrag nur der Aufwand für das “reine” Requirements Engineering betrachtet, nicht jedoch der Test, nicht das vorgelagerte → Produktmanagement und nicht das → Projektmanagement. Es wird zudem angenommen, dass nur die Basisfunktionalität erfasst werden soll und dass diese zu Beginn der Umsetzung festliegt.
1.1 Eine einfache Abschätzung des Aufwands
In der Literatur wie auch in der Praxis wird häufig der Aufwand für das Requirements Engineering mit “5 bis 15 Prozent” vom Gesamtaufwand angegeben. Diese Aussage ist zunächst einmal sehr vage.
Merkregeln:
- Etwa 5 bis 15 % des Gesamtaufwands zur Herstellung eines Produkts muss für das → Anforderungsmanagement / Requirements Engineering aufgewendet werden.
- Die Basiszahl ist 10 % — in einer ersten Näherung kann man von 10 Prozent des Gesamtaufwands für das Requirements Engineering ausgehen
Fallstricke:
- Wenn diese Maßzahl unterschritten wird, heißt dies zunächst einmal nichts
- Wenn diese Maßzahl überschritten wird, heißt dies auch nichts
1.2 Die Kosten-Nutzen-Betrachtung
In Abbildung 1.1 ist eine Kosten-Nutzen-Betrachtung für den Einsatzgrad von Requirements Engineering zu sehen.
Abbildung 1.1: Die Balance zwischen Kosten und Nutzen beim Requirements Engineering
1.3 Ein einfaches Beispiel
In einem Projekt mit 10 Mitarbeitern soll eine Aufwandsabschätzung für das Requirements Engineering vorgenommen werden. Es soll dabei nur das Projekt betrachtet werden. Ein → RE-Prozess und ein → RE-Tool sind vorhanden und etabliert. Die Projektlaufzeit beträgt 3 Jahre.
| Was | Wert |
|---|---|
| Gesamtdauer | 3 Jahre |
| Mitarbeiterzahl (Fulltime) | 10 |
| Gesamtaufwand | 30 Personenjahre |
| Ansatz: 10 % des Gesamtvolumens für das RE | 3 Personenjahre |
In diesem einfachen Beispiel müssen 3 Personenjahre für das Requirements Engineering angesetzt werden. Zu beachten ist dabei, dass der “10-%-RE-Aufwand” nicht “nebenher” durch die Entwickler geleistet werden sollte, sondern dass sich separat zwei (zusätzliche) Mitarbeiter sich um das RE kümmern sollten.
2. Aspekte aus der Praxis
In der Praxis kann das Requirements Engineering effizienter gestaltet werden, indem die Aufwände reduziert, die “Zeitfresser” eliminiert oder Mehrwerte geschaffen werden.
2.1 Reduzierung der Aufwände
Um den Aufwand für das Requirements Engineering zu → reduzieren, können folgende Maßnahmen ergriffen werden:
- Verzicht auf das Requirements Engineering
- Nachqualifikation der Mitarbeiter
- Fokussierung auf wesentliche Aspekte
- (Starke) Wiederverwendung von bereits spezifizierten Elementen
- Zukauf von externen Dienstleistern für einzelne Elemente (wie beispielsweise → UI-Beschreibungen)
Generell sind alle Maßnahmen in Betracht zu ziehen. Wenn deutlich wird, dass das gewünschte Ziel im Requirements-Vorhaben nicht erreicht werden kann, so kann man auf Requirements Engineering verzichten.
2.2 Erkennen der “Zeitfresser”
Generell: Schlechte Prozesse und nicht ausreichend vorbereitete Mitarbeiter erhöhen den Aufwand / Zeitbedarf.
Typische zeitaufwendige Themen sind dabei:
- → Interviews: Werden diese unzureichend durchgeführt, so führt dies in der Regel zu erheblichen Mehraufwänden, die keinen Nutzen bringen
- Mangelhafte Toolunterstützung: Werden falsche Tools oder Tools falsch eingesetzt, so entstehen häufig Mehrarbeiten
2.3 Generierung von Mehrwerten
Der Aufwand für “gutes” Requirements Engineering kann innerhalb eines Projekts höher sein als der generierte Nutzen. Wenn die Anforderungen jedoch über das unmittelbare Projekt hinaus genutzt werden können, können Mehrwerte für die Organisation generiert werden.
Typische Mehrwerte entstehen durch:
- Impact Analysis: Hierüber werden Auswirkungen von Veränderungen an den Anforderungen sehr schnell sichtbar
- Verbindung mit Test Cases: Wenn die Anforderungen direkt mit den Test Cases / Testfällen verbunden werden, so entsteht schnell ein Mehrwert, da sich die Tests dann direkt aus den Anforderungen ergeben
- Verbindung mit der Produktdokumentation: Es ist sinnvoll, die Dokumentation direkt aus den erfassten Anforderungen abzuleiten.
2.4 Der RE-Teufelskreis
Wenn ein Unternehmen mit Requirements Engineering über ein RE-Pilotprojekt anfängt, so ist zu Beginn die Erwartungshaltung hoch und die Euphorie groß. Die ersten Anforderungen werden erfasst und die Abläufe klären sich. Doch häufig kommt es dann zu einer Bestandsaufnahme, bei der festgestellt wird, dass die gewünschten → Ziele nicht erreicht werden können, da Aufwand und Kosten höher als geplant oder gedacht werden und nicht getragen werden können. Also reduziert man typischerweise entweder die Anzahl der zu erfassenden Anforderungen oder man mindert die → Qualität (Abbildung 2.1). In beiden Fällen wird das Ergebnis sein, dass die entwickelten Anforderungen nicht die Akzeptanz finden, um sie in die Nutzung / Umsetzung gelangen zu lassen.
Abbildung 2.1: Maßnahmen zur Beschleunigung des Requirements-Engineering-Pilotprojekts
Dadurch gerät man in eine Art Teufelskreis (Abbildung 2.2): Wenn man gute Anforderungen haben möchte, um eine hohe Akzeptanz zu erreichen, so muss ein gewisser Aufwand dafür erbracht werden. Wird dann reduziert, so sinkt die Akzeptanz weiter, und die Anforderungen werden nicht genutzt. Also hätte man schon zu Beginn auf gute Anforderungen verzichten können.
Abbildung 2.2: Teufelskreis beim Requirements-Engineering-Pilotprojekt
3. Szenarien und Berechnungsbeispiele
Folgendes Szenario soll beispielhaft betrachtet werden: 20 Mitarbeiter in der Entwicklungsabteilung, Ziel: Längerfristiges Produktmanagement, Lebenszyklus: 2 Jahre Entwicklung, 10 Jahre im Feld, Service und Support ist notwendig.
| Was | Wert |
|---|---|
| Gesamtdauer | 12 Jahre, davon 2 Jahre Entwicklung und 10 Jahre im Feld (End-of-Live) |
| Mitarbeiterzahl Entwicklung (Fulltime) | 20 |
| Gesamtaufwand Entwicklung | 40 Personenjahre |
| Ansatz: 10 % des Gesamtvolumens für das RE in der Entwicklung | 4 Personenjahre |
| Mitarbeiterzahl Service und Support (Fulltime) | 100 |
| Unterstützungsleistung Service und Support (Personen Fulltime) | 2 |
| Gesamtaufwand Unterstützung Service und Support (Personen Fulltime) | 20 Personenjahre |
| Gesamtaufwand RE-Leistung | 24 Personenjahre |
In diesem Beispiel werden insgesamt 24 Personenjahre über eine Laufzeit von 12 Jahren angesetzt. Bei der Unterstützungsleistung Service und Support wird davon ausgegangen, dass das Produkt weiterentwickelt wird — und dass das Requirements Engineering die Schnittstelle zwischen Rückmeldungen aus dem Support und der Entwicklung bildet.
4. Häufig gestellte Fragen und Antworten (FAQ) zum Aufwand für das Requirements Engineering
Einige Fragen zum Aufwand für das Requirements Engineering werden häufig gestellt – diese werden hier wiedergegeben.
- F: Muss eine Aufwandsbetrachtung für das Requirements Engineering vorgenommen werden?
A: Dies ist sinnvoll. Da der Aufwand für das Requirements Engineering häufig unterschätzt wird, sehr groß werden kann und zudem die Ergebnisse des Einsatzes erst sehr spät sichtbar werden, ist eine Aufwandsbetrachtung sinnvoll. - F: Wann / zu welchem → Zeitpunkt sollte eine Aufwandsbetrachtung für das Requirements Engineering vorgenommen werden?
A: Sehr frühzeitig — und bevor mit dem Requirements Engineering begonnen wird, denn nur so können die Erwartungen den Aufwänden gegenübergestellt werden. - F: Wie kann der Aufwand für das Requirements Engineering minimiert / optimiert werden?
A: Dies kommt auf den Kontext an: Je nach Organisations- und Problemgröße muss dies einzelnen betrachtet werden.
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 Präsentationen
Die Aufwandsabschätzung für das Requirements Engineering wird (kurz) in der Präsentation zum Requirements Engineering beschrieben.
| Inhalt | Typ |
|---|---|
| Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) | 
|
A.2 Literatur
In folgenden Büchern wird als Aspekt der Aufwand für das Requirements Engineering erläutert:
- /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
- /Ebert19/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 6. Auflage 2019, ISBN 978–3‑86490–562‑9
- /Ebert22/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 7. Auflage 2022, ISBN 978–3‑86490–919‑1
- /Hruschka19/ Peter Hruschka: → Business Analysis und Requirements Engineering: Prozesse und Produkte nachhaltig verbessern, Hanser, München 2. Auflage 2019, ISBN 978–3‑446–45589‑4
- /IREB21/ siehe /Pohl21/
- /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
- /Wiegers05/ Karl E. Wiegers: Software-Requirements, Microsoft Press Deutschland, München 2005, ISBN 978–3‑860–63594‑0
A.3 Weblinks
Auf folgende Weblinks wird hier Bezug genommen:
- -
Letzte Aktualisierung: 22.01.2022 © Peterjohann Consulting, 2005–2025
