Was ist Requirements Management?
Requirements Management ist laut IREB-Lehrplan der Prozess, bestehende Anforderungen zu verwalten, die in verschiedenen Arbeitsprodukten festgehalten sind; dazu gehören insbesondere Ablage, Änderungen und Traceability. Unabhängig von den Umständen besteht die Aufgabe darin, Anforderungen so zu pflegen, dass alle Rollen in einem Projekt wirksam und effizient arbeiten können [1]. Der Lehrplan behandelt dabei Lebenszyklus, Versionierung, Konfigurationen und Baselines, Attribute und Sichten, Traceability, Änderungsmanagement und Priorisierung.
In kleinen Vorhaben mit wenigen Anforderungen genügt oft ein gut geführter Backlog. In grossen, regulierten oder vertraglich gebundenen Vorhaben wird Requirements Management dagegen zur eigenen Disziplin, weil Hunderte oder Tausende Anforderungen über Jahre gepflegt, geändert und nachgewiesen werden müssen. Die Norm ISO/IEC/IEEE 29148 beschreibt die dafür nötigen Prozesse und Informationsobjekte über den gesamten Lebenszyklus [2].
Welchen Lebenszyklus durchläuft eine Anforderung?
Jede dokumentierte Anforderung hat ihren eigenen Lebenszyklus: Sie wird erstellt, bewertet und verfeinert, geprüft, überarbeitet, konsolidiert und freigegeben. Damit erkennbar ist, welches Arbeitsprodukt sich in welchem Zustand befindet, braucht es laut Lehrplan ein Lebenszyklusmodell, das jeden Status und jeden erlaubten Übergang definiert; der tatsächliche Status muss jederzeit klar sein, in der Regel einschliesslich der Historie [1].
| Status | Bedeutung | Erlaubte Übergänge |
|---|---|---|
| Neu | erfasst, noch nicht bewertet | in Klärung, verworfen |
| In Klärung | wird mit Stakeholdern präzisiert | zur Prüfung, verworfen |
| Zur Prüfung | Review oder Inspektion geplant | freigegeben, in Klärung |
| Freigegeben | validiert und Teil der Baseline | in Umsetzung, geändert |
| In Umsetzung | wird realisiert | umgesetzt |
| Umgesetzt | realisiert und verifiziert | abgenommen |
| Abgenommen | vom Auftraggeber bestätigt | keine, Änderungen erzeugen eine neue Version |
| Verworfen | wird nicht umgesetzt, mit Begründung | in Klärung (bei Wiederaufnahme) |
Wie werden Versionen, Konfigurationen und Baselines geführt?
Versionierung verfolgt Arbeitsprodukte über ihre Entwicklung: Jede Änderung führt zu einer neuen Version, die Geschichte ist bis zum Ursprung nachvollziehbar, und frühere Versionen lassen sich wiederherstellen. Der Lehrplan nennt drei Voraussetzungen: eine Versionsnummer, meist aus Version und Inkrement, eine Änderungshistorie und ein Ablagekonzept [1]. Eine Konfiguration ist eine konsistente Menge von Arbeitsprodukten mit Anforderungen für einen bestimmten Zweck, die höchstens eine Version je Arbeitsprodukt enthält. Eine Baseline ist eine stabile, kontrollierte Konfiguration, die für Release-Planung oder andere Liefermeilensteine verwendet wird.
Baselines sind in der Praxis zentral, weil sich Planung, Schätzungen und Verträge auf einen bestimmten Stand beziehen müssen. Wird eine Spezifikation ausgeschrieben, ist die publizierte Fassung eine Baseline. Spätere Änderungen werden gegen diese Baseline beurteilt: Ist es eine Präzisierung im Rahmen des Vereinbarten oder eine Änderung des Leistungsumfangs? Ohne Baseline ist diese Frage kaum zu beantworten.
Welche Attribute braucht eine Anforderung?
| Attribut | Zweck |
|---|---|
| Kennung | eindeutige Referenz für Verweise, Traceability und Gespräche |
| Name | kurze, sprechende Bezeichnung |
| Beschreibung | die Anforderung selbst, etwa in Satzschablone |
| Art | funktional, Qualitätsanforderung oder Randbedingung |
| Quelle | Stakeholder, Dokument oder System, aus dem sie stammt |
| Priorität | relative Bedeutung nach vereinbarten Kriterien |
| Status | Position im Lebenszyklus |
| Version | aktueller Stand mit Historie |
| Verantwortlich | Person, die die Anforderung pflegt |
| Abnahmekriterium | Bedingung, unter der die Anforderung als erfüllt gilt |
Attribute dokumentieren laut Lehrplan wichtige Metadaten und dienen dazu, dass Teammitglieder und andere Stakeholder jederzeit die Informationen erhalten, die sie brauchen. Welche Attribute sinnvoll sind, hängt vom Informationsbedarf der Beteiligten ab; Normen wie ISO/IEC/IEEE 29148 geben einen Überblick über die relevantesten [1]. Sichten zeigen jeweils nur den gerade interessierenden Ausschnitt. Der Lehrplan unterscheidet selektive Sichten, die bestimmte Anforderungen herausfiltern, projektive Sichten, die nur bestimmte Attribute zeigen, und aggregierende Sichten, die Kennzahlen zusammenfassen.
Was ist Traceability und wie wird sie umgesetzt?
Traceability ist die Fähigkeit, eine Anforderung mit ihrer Herkunft zu verbinden, also mit Stakeholdern, Dokumenten und Begründungen, mit nachfolgenden Arbeitsprodukten wie Testfällen sowie mit anderen Anforderungen, von denen sie abhängt. Sie ist Voraussetzung für Requirements Management und wird oft von Normen, Gesetzen und Vorschriften ausdrücklich verlangt. Der Lehrplan unterscheidet implizite Traceability, die durch Struktur und Normierung der Arbeitsprodukte entsteht, und explizite Traceability, die Arbeitsprodukte über eindeutige Kennungen verknüpft; verbreitete Darstellungen sind Hyperlinks, Verweise, Matrizen, Tabellen und Graphen [1].
| Anforderung | Quelle | abhängig von | Use Case | Testfall |
|---|---|---|---|---|
| F-12 Monatsauswertung | Workshop Projektleitende | F-03 Zeiterfassung | UC-04 | T-31, T-32 |
| F-15 Export Buchhaltung | Interview Buchhaltung | F-12, F-20 Monatsabschluss | UC-06 | T-40 |
| QA-07 Antwortzeit Auswertung | Workshop Projektleitende | F-12 | UC-04 | T-55 (Lasttest) |
| RB-02 Datenhaltung Schweiz | Datenschutzgesetz, Vorgabe Rechtsdienst | keine | alle | T-60 (Architekturprüfung) |
Mit einer solchen Matrix lassen sich wichtige Fragen schnell beantworten: Welche Tests sind betroffen, wenn sich F-12 ändert? Gibt es Anforderungen ohne Testfall? Woher stammt eine Anforderung, wenn ihre Notwendigkeit bezweifelt wird? Der Aufwand für Traceability soll dabei dem Nutzen entsprechen: In regulierten Umgebungen ist sie Pflicht, in kleinen agilen Vorhaben genügt oft implizite Traceability über die Struktur des Backlogs.
Wie werden Änderungen an Anforderungen gesteuert?
Anforderungen sind nicht statisch; das siebte Prinzip des IREB-Lehrplans nennt Änderungen den Normalfall. Änderungen werden über einen formalen Änderungsantrag oder als neuer Eintrag im Product Backlog erfasst. In einem linearen Vorgehen entscheidet oft ein Change Control Board in Projekten oder ein Change Advisory Board im Betrieb; in einem iterativen Vorgehen nimmt der Product Owner die Änderung in den Backlog auf und priorisiert sie [1]. Der Scrum Guide hält dazu fest, dass der Product Backlog sich laufend entwickelt und der Product Owner für seine Ordnung verantwortlich ist [3].
- 1Änderung erfassen: was, warum, von wem, wie dringend.
- 2Auswirkungen analysieren: betroffene Anforderungen, Tests, Aufwand, Termine, Kosten, mithilfe der Traceability.
- 3Entscheiden: annehmen, ablehnen oder verschieben, durch die zuständige Stelle.
- 4Umsetzen: Anforderungen anpassen, neue Version, Baseline aktualisieren.
- 5Kommunizieren: Beteiligte über die Entscheidung und die neue Version informieren.
Wie Änderungen am Projektumfang klassisch gesteuert werden, beschreibt der Beitrag Scope-Management und Änderungskontrolle im Hub Projektplanung. Wie Prioritäten nach einer Änderung neu bewertet werden, zeigt der Beitrag Anforderungen priorisieren.
Welche Werkzeuge unterstützen Requirements Management?
Der Lehrplan nennt Werkzeuge für das Verwalten von Anforderungen, für die Steuerung des Requirements-Engineering-Prozesses, für die Dokumentation und gemeinsame Nutzung von Wissen, für die Modellierung, für die Zusammenarbeit sowie für Test und Simulation. Bürowerkzeuge oder Ticketsysteme werden ebenfalls verwendet, haben aber Grenzen und eignen sich laut Lehrplan vor allem dann, wenn der Prozess unter Kontrolle ist und die Anforderungen abgestimmt und recht stabil sind [1]. Bei der Einführung zählen die gesamten Lebenszykluskosten, Pilotprojekte und Schulungen.
In Flenio lassen sich Anforderungen als Aufgaben mit Kennung, Status, Priorität, Verantwortlichen und Verknüpfungen zu Meilensteinen und Dokumenten führen; Änderungen werden in der Historie nachvollziehbar. Für stark regulierte Umgebungen mit formaler Traceability bis zu Testfällen sind spezialisierte Werkzeuge verbreitet. Wie gute Anforderungen formuliert werden, zeigt der Beitrag Anforderungen formulieren.
Typische Fehler im Requirements Management
| Fehler | Folge | Gegenmittel |
|---|---|---|
| Kein definierter Status | unklar, was gilt | Lebenszyklusmodell mit Status und Übergängen |
| Keine Baseline | Streit über Leistungsumfang | Baselines zu Meilensteinen und Verträgen |
| Änderungen per Zuruf | Überblick geht verloren, Termine rutschen | Änderungsverfahren mit Auswirkungsanalyse |
| Zu viele Attribute | Pflegeaufwand, veraltete Daten | nur Attribute mit klarem Informationsbedarf |
| Traceability nachträglich | aufwendig, lückenhaft | Verknüpfungen beim Erfassen anlegen |
Requirements Management in agilen Teams
In agilen Teams übernimmt der Product Backlog viele Aufgaben des Requirements Management. Status ergeben sich aus der Position im Backlog und auf dem Board, Prioritäten aus der Reihenfolge, Änderungen erfolgen durch neue oder angepasste Einträge, und das Increment am Ende jedes Sprints bildet eine Art laufende Baseline des Erreichten. Traceability entsteht oft implizit, etwa über Epics und untergeordnete Stories oder über Verknüpfungen zwischen Stories und Testfällen.
Grenzen zeigen sich, wenn Nachweise verlangt werden, etwa in regulierten Umgebungen, oder wenn mehrere Teams über längere Zeit am selben Produkt arbeiten. Dann lohnt es sich, zusätzliche Elemente einzuführen: eindeutige Kennungen, ausdrückliche Verknüpfungen zu Testfällen und Quellen, Baselines zu Releases und ein dokumentiertes Verfahren für grössere Änderungen. Der IREB-Lehrplan betont, dass Requirements Management je nach Entwicklungsprozess und Kontext unterschiedlich ausgeprägt sein kann.
Wie führen Sie Requirements Management schrittweise ein?
- 1Eindeutige Kennungen für alle Anforderungen einführen.
- 2Ein einfaches Lebenszyklusmodell mit wenigen Status festlegen.
- 3Wenige, klar begründete Attribute definieren, etwa Quelle, Priorität, Status und Verantwortlich.
- 4Baselines zu wichtigen Meilensteinen festhalten.
- 5Ein schlankes Änderungsverfahren mit Auswirkungsanalyse einführen.
- 6Traceability dort ergänzen, wo sie Nutzen stiftet oder verlangt wird.
Requirements Management in Normen und Praxis
ISO/IEC/IEEE 29148 beschreibt Requirements Management als Teil der Anforderungsprozesse und legt fest, welche Informationen über Anforderungen geführt werden. In regulierten Branchen wie Medizintechnik, Bahn oder Finanzdienstleistungen ist nachweisbare Traceability häufig Voraussetzung für Zulassungen und Audits. Für die meisten Projekte im DACH-Raum genügt ein schlankes, aber konsequentes Vorgehen: eindeutige Kennungen, klare Status, Baselines zu Meilensteinen und ein einfaches Änderungsverfahren. Den Gesamtzusammenhang zeigt der Leitfaden Requirements Engineering.