Requirements Engineering
Requirements Engineering ist die systematische Disziplin, Anforderungen an ein System zu ermitteln, zu dokumentieren, zu prüfen und über den gesamten Lebenszyklus zu verwalten. Ziel ist ein gemeinsames, prüfbares Verständnis davon, was das System leisten soll — zwischen Auftraggebern, Entwicklern, Testern und allen weiteren Beteiligten. Fehler in den Anforderungen sind erfahrungsgemäß besonders teuer: Je später sie entdeckt werden, desto mehr nachgelagerte Arbeit — Design, Implementierung, Tests — muss korrigiert werden.
Die vier Haupttätigkeiten
Requirements Engineering umfasst vier eng verzahnte Tätigkeiten, die iterativ und über die gesamte Projektlaufzeit ausgeführt werden — nicht als einmalige Phase am Anfang:
| Tätigkeit | Inhalt |
|---|---|
| Ermittlung (Elicitation) | Anforderungen aus Stakeholdern, Dokumenten, Altsystemen und Normen gewinnen — durch Interviews, Workshops, Beobachtung, Analyse |
| Dokumentation | Anforderungen festhalten: natürlichsprachlich, über Satzschablonen oder modellbasiert |
| Prüfung & Abstimmung | Anforderungen auf Qualität prüfen und Konflikte zwischen Stakeholdern auflösen |
| Verwaltung (Management) | Anforderungen versionieren, priorisieren, Änderungen steuern und Traceability herstellen |
Für die Disziplin existiert mit dem IREB (International Requirements Engineering Board) und dem CPRE-Zertifizierungsschema ein etabliertes, herstellerneutrales Ausbildungsfundament.
Was macht eine gute Anforderung aus?
Verbreitete Qualitätskriterien: Eine Anforderung soll eindeutig (nur eine Interpretation), prüfbar (Erfüllung objektiv feststellbar), atomar (ein Sachverhalt pro Anforderung), konsistent (widerspruchsfrei zu anderen Anforderungen) und notwendig sein. Der Unterschied zeigt sich am Beispiel:
- Schwach: „Das System muss schnell auf Bremsanforderungen reagieren."
- Prüfbar: „Das System muss nach Empfang einer Bremsanforderung innerhalb von 50 ms den Bremsdruckaufbau einleiten."
Die erste Formulierung lässt sich weder implementieren noch testen, ohne dass jemand die eigentliche Entscheidung stillschweigend nachholt — oft eine andere Person mit einer anderen Interpretation. Gerade bei höherer Kritikalität empfehlen Normen wie die ISO 26262 deshalb semi-formale Spezifikationsmethoden, die Mehrdeutigkeit von vornherein reduzieren.
Requirements Engineering und Traceability
Die vierte Tätigkeit — die Verwaltung — verbindet Requirements Engineering mit der Nachweisführung: Anforderungen sind kein statischer Bestand, sondern ändern sich über die gesamte Entwicklung. Jede Änderung wirft dieselben Fragen auf: Welche Architekturelemente, welche Implementierung, welche Testfälle sind betroffen? Beantwortbar sind diese Fragen nur mit gepflegter Traceability — den nachvollziehbaren Verknüpfungen von der Stakeholder-Anforderung über die Systemanforderung bis zu Umsetzung und Test. Prozessmodelle wie Automotive SPICE verlangen genau diese bidirektionale Nachverfolgbarkeit als Basispraktik.
Requirements Engineering in der Praxis: die Verwaltung entscheidet
In realen Projekten scheitert Requirements Engineering seltener an der Ermittlung als an der Verwaltung über Werkzeuggrenzen hinweg: Stakeholder-Anforderungen liegen im Requirements-Management-Werkzeug, abgeleitete Softwareanforderungen in einem zweiten System, Tests in einem dritten. Zwischen diesen Silos verlieren Anforderungen ihre Herkunft und ihre Wirkung — und bei jeder Änderung beginnt die manuelle Suche, was alles betroffen ist. Wer Requirements Engineering ernst nimmt, muss deshalb neben der Qualität einzelner Anforderungen auch die Durchgängigkeit der Kette organisieren: von der Quelle bis zum Testfall, über alle beteiligten Werkzeuge hinweg.