Requirements Engineering (RE) ist die systematische Ermittlung, Analyse, Dokumentation, Validierung und Verwaltung von Anforderungen an Systeme und Software. Ziel ist, Stakeholder-Bedürfnisse und den beabsichtigten Systemzweck so zu verstehen und zu konkretisieren, dass daraus eine belastbare Grundlage für Entwicklung und Entscheidung entsteht.
Was ist Requirements Engineering?
Requirements Engineering beschäftigt sich mit der Frage, was ein System leisten soll, für wen und unter welchen Randbedingungen. Es verbindet Fachseite, Nutzer, technische Architektur und Projektziele.
Nuseibeh und Easterbrook formulierten 2000 eine prägende Einordnung: Der Erfolg eines Softwaresystems bemisst sich wesentlich daran, wie gut es den Zweck erfüllt, für den es vorgesehen ist. Requirements Engineering dient dazu, diesen Zweck über Stakeholder und ihre Bedürfnisse zu entdecken und zu konkretisieren.
Fachliche Grundlage: Forschung und ISO/IEC/IEEE 29148
Das Feld umfasst deutlich mehr als das Schreiben einer Liste von Features. Der internationale Standard ISO/IEC/IEEE 29148:2018 beschreibt Prozesse und Informationsartefakte für Requirements Engineering über den Lebenszyklus von Systemen und Software. Er behandelt unter anderem Eigenschaften guter Anforderungen und die iterative Anwendung von Anforderungsprozessen.
Wichtig: Ein Standard ersetzt keine Kommunikation. Er bietet Struktur und Qualitätskriterien, muss aber zum Projektkontext passen.
Die zentralen Tätigkeiten
1. Ermittlung (Elicitation)
Stakeholder, Geschäftsziele, bestehende Prozesse, Probleme und Randbedingungen werden erfasst. Interviews, Workshops, Beobachtung, Dokumentanalyse oder Prototypen können dafür eingesetzt werden.
2. Analyse und Aushandlung
Anforderungen werden auf Widersprüche, Abhängigkeiten, Prioritäten und Machbarkeit geprüft. Unterschiedliche Stakeholder-Ziele müssen häufig ausgehandelt werden.
3. Spezifikation
Ergebnisse werden in geeigneter Form dokumentiert – beispielsweise als strukturierte Anforderungen, User Stories, Use Cases, Modelle, Akzeptanzkriterien oder Datenbeschreibungen.
4. Validierung
Es wird geprüft, ob die beschriebenen Anforderungen tatsächlich den beabsichtigten Bedarf treffen. „Korrekt formuliert“ ist nicht dasselbe wie „das richtige Problem gelöst“.
5. Management
Anforderungen ändern sich. Versionen, Entscheidungen, Abhängigkeiten und Auswirkungen müssen nachvollziehbar bleiben.
Funktionale und nicht-funktionale Anforderungen
Funktionale Anforderungen beschreiben Verhalten oder Fähigkeiten. Nicht-funktionale beziehungsweise Qualitätsanforderungen betreffen Eigenschaften wie Performance, Sicherheit, Verfügbarkeit, Bedienbarkeit oder Wartbarkeit.
Ein Projekt kann alle gewünschten Funktionen besitzen und trotzdem scheitern, wenn beispielsweise Antwortzeiten unbrauchbar, Rollen falsch modelliert oder Datenschutzanforderungen übersehen wurden.
User Story, Use Case und Requirement sind nicht dasselbe
Eine User Story ist ein leichtgewichtiges Kommunikationsartefakt aus agilen Kontexten. Ein Use Case beschreibt Interaktionen zwischen Akteur und System zur Erreichung eines Ziels. Eine formale Requirement-Aussage kann deutlich atomarer und prüfbarer formuliert sein.
Je nach Projekt können diese Artefakte gemeinsam genutzt werden. Wichtig ist nicht die Methode als Selbstzweck, sondern ob Stakeholder ein gemeinsames, überprüfbares Verständnis erreichen.
Requirements Engineering in agilen Projekten
Agile Entwicklung hebt Requirements Engineering nicht auf. Wagner et al. untersuchten Praktiken in 92 Organisationen und fanden unter anderem freie Textdokumentation, unterschiedliche Ermittlungstechniken und eine enge Verbindung zu Tests. Unklare Anforderungen und Kommunikationsprobleme blieben relevante Herausforderungen.
Der Unterschied liegt häufig in der Taktung: Anforderungen werden iterativer verfeinert statt vollständig zu Projektbeginn eingefroren.
Typische Fehler
- Technische Lösung wird festgelegt, bevor das Problem verstanden ist.
- Nur Management-Perspektive wird aufgenommen, reale Nutzer fehlen.
- Ausnahmen im Prozess werden ignoriert.
- Qualitätsanforderungen bleiben implizit.
- „Muss intuitiv sein“ wird nicht operationalisiert.
- Änderungen werden nicht auf Auswirkungen geprüft.
Wann ist eine Anforderung „gut genug“?
Eine gute Anforderung ist nicht einfach möglichst lang. Sie sollte für ihren Zweck eindeutig, notwendig, realisierbar und überprüfbar sein. Auf Systemebene braucht es außerdem Nachverfolgbarkeit zu Zielen, Risiken und Tests. ISO/IEC/IEEE 29148 liefert dafür einen formalen Referenzrahmen.
Die notwendige Dokumentation hängt vom Risiko ab: Eine kleine interne Komfortfunktion benötigt weniger Formalität als eine sicherheitskritische Schnittstelle. Professionelles RE skaliert die Präzision mit Konsequenz und Unsicherheit.
Fazit
Requirements Engineering reduziert nicht jede Unsicherheit, macht sie aber sichtbar und bearbeitbar. Besonders bei individuellen Software- und Integrationsprojekten ist es die Grundlage dafür, dass Entwicklungsbudget auf ein fachlich verstandenes Ziel ausgerichtet wird.
Passende Leistungen von Wils Solutions
Häufige Fragen
Was gehört zum Requirements Engineering?
Typisch sind Anforderungsermittlung, Analyse, Spezifikation, Validierung und laufendes Requirements Management.
Ist Requirements Engineering nur für Wasserfallprojekte?
Nein. Auch agile Projekte benötigen Requirements Engineering, häufig iterativer und mit leichtgewichtigeren Artefakten.
Was ist ISO/IEC/IEEE 29148?
Ein internationaler Standard für Prozesse und Informationsartefakte des Requirements Engineering in Systemen und Software.
Was ist der Unterschied zwischen User Story und Requirement?
Eine User Story ist ein agiles Kommunikationsformat und nicht automatisch eine vollständige, formale Requirement-Spezifikation.