Was ist Requirements Engineering?
Requirements Engineering, auf Deutsch auch Anforderungsmanagement oder Anforderungsanalyse genannt, ist die Disziplin, die klärt, was ein System leisten soll, bevor und während es entsteht. Der IREB-Lehrplan beschreibt das Ziel so: Anforderungen an Systeme sind so zu spezifizieren und zu verwalten, dass die umgesetzten und eingesetzten Systeme die Wünsche und Bedürfnisse ihrer Stakeholder erfüllen [1]. Ein System kann dabei vieles sein: ein Produkt, eine Dienstleistung, eine Software, ein Prozess oder ein Werkzeug, das Menschen und Organisationen hilft, ein Ziel zu erreichen.
Requirements Engineering ist keine Phase, die einmal zu Beginn eines Projekts stattfindet, sondern eine laufende Tätigkeit. In plangetriebenen Projekten liegt der Schwerpunkt am Anfang, in agilen Vorhaben verteilt er sich über die ganze Laufzeit. In beiden Fällen gilt: Wer Anforderungen nicht systematisch erhebt und abstimmt, baut mit hoher Wahrscheinlichkeit am Bedarf vorbei. Der Lehrplan nennt als typische Symptome mangelhafter Arbeit fehlende, unklare oder falsche Anforderungen und als häufige Ursachen den überstürzten Beginn der Umsetzung, Kommunikationsprobleme, die Annahme, Anforderungen seien offensichtlich, sowie fehlende Ausbildung [1].
Welche Arten von Anforderungen gibt es?
| Art | Bedeutung | Beispiel |
|---|---|---|
| Funktionale Anforderung | Ergebnis oder Verhalten, das eine Funktion des Systems liefern soll, einschliesslich Daten und Interaktion mit der Umgebung | Das System erstellt aus erfassten Zeiten eine Monatsauswertung pro Projekt. |
| Qualitätsanforderung | Qualitätsaspekt, der nicht durch funktionale Anforderungen abgedeckt ist, etwa Leistung, Verfügbarkeit, Sicherheit, Zuverlässigkeit | Die Monatsauswertung steht bei bis zu 10 000 Einträgen innerhalb von drei Sekunden bereit. |
| Randbedingung | schränkt den Lösungsraum über das hinaus ein, was funktionale und Qualitätsanforderungen verlangen | Personendaten werden ausschliesslich in Rechenzentren in der Schweiz gespeichert. |
Diese Einteilung stammt aus dem IREB-Lehrplan [1]. Im Alltag werden Qualitätsanforderungen und Randbedingungen oft unter dem Begriff nicht-funktionale Anforderungen zusammengefasst. Die Unterscheidung lohnt sich trotzdem, weil Randbedingungen nicht verhandelbar sind, Qualitätsanforderungen dagegen oft abgewogen werden müssen. Wie Qualitätsanforderungen messbar formuliert werden, zeigt der Beitrag Funktionale und nicht-funktionale Anforderungen.
Anforderungen entstehen zudem auf unterschiedlichen Ebenen: Geschäftsanforderungen beschreiben Ziele einer Organisation, Stakeholder- und Benutzeranforderungen beschreiben, was Beteiligte aus ihrer Sicht erwarten, Systemanforderungen beschreiben, was das System leisten muss. Der Lehrplan empfiehlt, Anforderungen unterschiedlicher Abstraktionsebenen nicht zu vermischen und grosse Dokumente entsprechend zu gliedern.
Welche Aufgaben umfasst Requirements Engineering?
| Aufgabe | Inhalt | Vertiefung |
|---|---|---|
| Ermitteln | Quellen identifizieren, Wünsche und Bedürfnisse erheben, implizite Erwartungen explizit machen, Konflikte lösen | Anforderungen erheben |
| Dokumentieren | Anforderungen in natürlicher Sprache, mit Schablonen oder in Modellen festhalten | Anforderungen formulieren |
| Validieren | prüfen, ob Anforderungen die tatsächlichen Bedürfnisse treffen und abgestimmt sind | Anforderungen validieren |
| Verwalten | Status, Versionen, Baselines, Attribute, Traceability, Änderungen und Prioritäten führen | Requirements Management |
Ergänzt werden diese Aufgaben durch Werkzeugunterstützung und durch die Wahl eines passenden Prozesses [1]. Die Ermittlung beginnt mit dem Verständnis des Systemkontexts: Was gehört zum System, was zur Umgebung, und welche Schnittstellen gibt es? Dieser Schritt wird oft übersprungen und ist eine der häufigsten Ursachen für Missverständnisse, siehe Systemkontext und Abgrenzung. Die einzelnen Techniken der Ermittlung beschreibt der Beitrag Anforderungen erheben.
Welche Prinzipien leiten gutes Requirements Engineering?
| Nr. | Prinzip | Kernaussage |
|---|---|---|
| 1 | Wertorientierung | Anforderungen sind Mittel zum Zweck, kein Selbstzweck |
| 2 | Stakeholder | Es geht darum, Wünsche und Bedürfnisse der Stakeholder zu erfüllen |
| 3 | Gemeinsames Verständnis | Erfolgreiche Systementwicklung ist ohne gemeinsame Basis unmöglich |
| 4 | Kontext | Systeme lassen sich nicht isoliert verstehen |
| 5 | Problem, Anforderung, Lösung | Die drei sind unvermeidlich miteinander verflochten |
| 6 | Validierung | Nicht validierte Anforderungen sind nutzlos |
| 7 | Evolution | Sich ändernde Anforderungen sind kein Unfall, sondern der Normalfall |
| 8 | Innovation | Mehr vom Gleichen genügt nicht |
| 9 | Systematische und disziplinierte Arbeit | Ohne sie geht es im Requirements Engineering nicht |
Das erste Prinzip ist für die Praxis besonders wichtig. Der Lehrplan definiert den Wert einer Anforderung als ihren Nutzen abzüglich der Kosten für Ermittlung, Dokumentation, Validierung und Verwaltung [1]. Daraus folgt: Nicht jede Anforderung muss gleich gründlich beschrieben werden. Kritische Anforderungen mit hohem Risiko verdienen mehr Aufwand als Details, die sich im Gespräch schnell klären lassen. Diese Wertorientierung verbindet klassisches Requirements Engineering mit agilen Ansätzen, die bewusst nur so viel dokumentieren wie nötig.
Wie werden Anforderungen dokumentiert?
Der Lehrplan unterscheidet drei Formen von Arbeitsprodukten: natürlichsprachliche, schablonenbasierte und modellbasierte, ergänzt um Glossare und Prototypen [1]. Natürliche Sprache ist flexibel und für alle verständlich, aber mehrdeutig. Schablonen geben Sätzen oder Formularen eine feste Struktur, etwa für einzelne Anforderungen, User Stories oder Use Cases. Modelle wie Kontextdiagramme, Aktivitätsdiagramme oder Klassendiagramme schaffen Überblick über Zusammenhänge, eignen sich aber vor allem für funktionale Anforderungen. In der Praxis werden die Formen kombiniert.
Arbeitsprodukte reichen von flüchtigen Skizzen über wachsende Sammlungen von User Stories bis zu vertraglich verbindlichen Spezifikationen mit Hunderten Seiten. Verbreitete Dokumente sind Stakeholder-Anforderungsspezifikation, Systemanforderungsspezifikation, Geschäftsanforderungsspezifikation und Visionsdokument; alternative Strukturen sind Product Backlog, Sprint Backlog und Story Map. Im deutschsprachigen Raum sind zudem Lastenheft und Pflichtenheft verbreitet. Wie gute Anforderungen formuliert werden, zeigt der Beitrag Anforderungen formulieren; der Vergleich zweier verbreiteter Formen findet sich unter Use Case vs. User Story.
Woran erkennt man gute Anforderungen?
| Für einzelne Anforderungen | Für Arbeitsprodukte mit mehreren Anforderungen |
|---|---|
| adäquat: beschreibt tatsächliche, abgestimmte Bedürfnisse | konsistent: keine Widersprüche |
| notwendig | nicht redundant |
| eindeutig | vollständig: keine bekannte relevante Anforderung fehlt |
| vollständig in sich | änderbar |
| verständlich | verfolgbar |
| prüfbar | konform zu Vorgaben |
Adäquatheit und Verständlichkeit gelten laut Lehrplan als die wichtigsten Kriterien; ohne sie ist eine Anforderung nutzlos oder sogar schädlich, unabhängig davon, wie gut sie die übrigen erfüllt [1]. Gleichzeitig betont der Lehrplan die Wertorientierung: Je höher der Wert einer Anforderung, desto wichtiger ist es, die Kriterien zu erfüllen. Wie Anforderungen geprüft werden, beschreibt der Beitrag Anforderungen validieren und abnehmen.
Welcher Requirements-Engineering-Prozess passt?
Einen Prozess, der für alle Situationen passt, gibt es nicht. Der Lehrplan beschreibt drei Facetten, nach denen ein Prozess konfiguriert wird: zeitlich linear oder iterativ, im Zweck präskriptiv oder explorativ und im Ziel kundenspezifisch oder marktorientiert [1]. Daraus ergeben sich drei typische Konfigurationen.
| Konfiguration | Facetten | Typischer Einsatz | Typische Arbeitsprodukte |
|---|---|---|---|
| Partizipativ | iterativ, explorativ, kundenspezifisch | Lieferant und Kunde arbeiten eng zusammen | Product Backlog mit User Stories, Prototypen |
| Vertragsbasiert | meist linear, präskriptiv, kundenspezifisch | Spezifikation als Vertragsgrundlage für Dritte | Systemanforderungsspezifikation mit Text und Modellen |
| Produktorientiert | iterativ, explorativ, marktorientiert | Software als Produkt für einen Markt | Product Backlog, Prototypen |
Für die Wahl empfiehlt der Lehrplan fünf Schritte: Einflussfaktoren analysieren, Facettenkriterien bewerten, Prozess konfigurieren, Arbeitsprodukte festlegen und passende Praktiken auswählen. Regulatorische Vorgaben können zudem einen normkonformen Prozess verlangen, etwa nach ISO/IEC/IEEE 29148, die Prozesse und Inhalte der Anforderungsdokumente über den Lebenszyklus spezifiziert [2]. Die Norm wurde 2024 bestätigt und befindet sich in Überarbeitung.
Requirements Engineering in agilen Vorhaben
Agile Vorgehen machen Requirements Engineering nicht überflüssig, sondern verteilen es über die Laufzeit. Der Product Backlog ist eine geordnete, sich entwickelnde Liste dessen, was das Produkt verbessern soll, und wird laufend verfeinert [3]. Die Tätigkeiten bleiben dieselben: Anforderungen werden ermittelt, als User Stories mit Akzeptanzkriterien dokumentiert, im Review validiert und im Backlog verwaltet. Die Rolle des Requirements Engineers übernimmt häufig der Product Owner, oft unterstützt durch Business Analysts. Wie Backlog-Einträge formuliert werden, beschreibt der Beitrag User Stories schreiben im Hub Agil.
Anforderungen in HERMES und in öffentlichen Projekten
In der Schweizer Bundesverwaltung strukturiert HERMES die Projektarbeit über Ergebnisse. Zu den Ergebnissen gehören unter anderem Stakeholderinteressen, Lösungsanforderungen und Detailspezifikationen [4]. Bei Beschaffungen bilden die Anforderungen die Grundlage für das Pflichtenheft und die Zuschlagskriterien; Unklarheiten führen zu Rückfragen, Nachträgen und Streit über den Leistungsumfang. Vorlagen dazu bietet flenio.ch etwa unter HERMES Lösungsanforderungen und Lastenheft.
Wer macht Requirements Engineering?
Requirements Engineer ist laut Lehrplan meist kein Jobtitel, sondern eine Rolle von Personen, die Anforderungen ermitteln, dokumentieren, validieren oder verwalten, vertieftes Wissen im Requirements Engineering haben und die Lücke zwischen Problem und möglichen Lösungen schliessen [1]. In der Praxis übernehmen Business Analysts, Fachspezialisten, Product Owner, Systemingenieure und sogar Entwickler diese Rolle. Die bekannteste Zertifizierung dafür ist der Certified Professional for Requirements Engineering des IREB, siehe IREB CPRE Foundation Level.
Welche Werkzeuge unterstützen Requirements Engineering?
Werkzeuge unterstützen etwa das Verwalten von Attributen, Prioritäten, Versionen und Traceability, die Modellierung, die Zusammenarbeit und das Berichtswesen. Der Lehrplan empfiehlt, ein Werkzeug erst einzuführen, wenn Vorgehen und Techniken geklärt sind, die gesamten Lebenszykluskosten zu berücksichtigen, mit Pilotprojekten zu beginnen und Mitarbeitende zu schulen [1]. In Flenio lassen sich Anforderungen als Aufgaben mit Beschreibung, Checklisten, Status und Prioritäten führen und mit Projekten, Meilensteinen und Zeiterfassung verbinden. Wie Status, Versionen und Änderungen gesteuert werden, beschreibt der Beitrag Requirements Management.
Wie werden Anforderungen priorisiert?
Nicht alle Anforderungen sind gleich wichtig. Priorisierung bestimmt, welche Anforderungen für das nächste Release oder Inkrement am relevantesten sind, meist anhand mehrerer Kriterien wie Geschäftswert, Dringlichkeit, Aufwand und Abhängigkeiten. Der Lehrplan unterscheidet Ad-hoc-Techniken und analytische Techniken und beschreibt sechs Schritte von der Zielklärung bis zur Festlegung der Prioritäten [1]. Ein Beispiel mit gewichteter Bewertung zeigt der Beitrag Anforderungen priorisieren.
Typische Fehler im Requirements Engineering
- Lösungen statt Anforderungen beschreiben: «Ein Dropdown mit allen Projekten» statt «Die Person wählt das Projekt, auf das sie Zeit bucht».
- Nur Endnutzende befragen und andere Stakeholder wie Betrieb, Datenschutz oder Buchhaltung vergessen.
- Qualitätsanforderungen und Randbedingungen vernachlässigen, weil sie in Workshops selten von selbst zur Sprache kommen.
- Systemgrenze nicht klären und später über Schnittstellen streiten.
- Anforderungen nicht validieren und erst bei der Abnahme feststellen, dass sie falsch verstanden wurden.
- Änderungen ohne Prozess zulassen und den Überblick über den gültigen Stand verlieren.
Wie detailliert müssen Anforderungen sein?
Eine der häufigsten Fragen in der Praxis lautet: Wie genau müssen wir Anforderungen beschreiben? Der IREB-Lehrplan nennt dafür mehrere Einflussfaktoren: den Problem- und Entwicklungskontext, den Grad des gemeinsamen Verständnisses, den Gestaltungsspielraum für Entwicklung und Design, die Verfügbarkeit schneller Rückmeldungen der Stakeholder während der Umsetzung, das Verhältnis von Kosten und Nutzen einer detaillierten Spezifikation sowie vorgeschriebene Normen und regulatorische Vorgaben. Je detaillierter Anforderungen spezifiziert sind, desto geringer ist das Risiko unerwarteter Ergebnisse, desto höher aber auch der Aufwand.
| Situation | Detailtiefe |
|---|---|
| Team und Fachbereich arbeiten eng zusammen, schnelle Rückmeldung möglich | gering: Ziel, User Story, wenige Akzeptanzkriterien |
| Umsetzung durch externen Lieferanten mit Festpreis | hoch: vollständige Spezifikation mit messbaren Kriterien |
| Regulierte Umgebung, Nachweispflichten | hoch: normkonforme Dokumentation, Traceability |
| Neues Produkt mit unsicherem Markt | gering bis mittel: Hypothesen, Prototypen, iterative Validierung |
| Ablösung eines kritischen Systems | mittel bis hoch: Verhalten des Altsystems, Schnittstellen, Datenmigration |
Die richtige Detailtiefe ist damit keine Frage des Geschmacks, sondern eine bewusste Entscheidung, die zu Beginn eines Vorhabens getroffen und dokumentiert werden sollte. Der Lehrplan empfiehlt, früh festzulegen, in welchen Arbeitsprodukten welche Anforderungen auf welcher Abstraktionsebene und mit welcher Detailtiefe dokumentiert werden. Das erleichtert die Planung von Aufwand und Ressourcen und vermeidet aufwendige Nacharbeit am Ende.
Wie hängen Requirements Engineering und Projektmanagement zusammen?
Requirements Engineering und Projektmanagement greifen eng ineinander. Anforderungen bestimmen den Umfang eines Projekts und damit Aufwand, Kosten und Termine. Änderungen an Anforderungen sind zugleich Änderungen am Projektumfang und müssen über ein Änderungsverfahren gesteuert werden. Umgekehrt setzt das Projektmanagement Rahmenbedingungen wie Budget und Termine, die zu Randbedingungen für die Anforderungen werden. In klassischen Projekten verantwortet die Projektleitung den Umfang, in agilen Vorhaben der Product Owner den Backlog.
Für die Priorisierung nutzen beide Welten ähnliche Techniken. Verbreitet ist etwa MoSCoW mit den Kategorien Must Have, Should Have, Could Have und Won't Have this time, die aus dem DSDM-Rahmenwerk stammt [7]. Wie Projektumfang und Änderungen klassisch gesteuert werden, beschreibt der Beitrag Scope-Management und Änderungskontrolle im Hub Projektplanung.
Anforderungen in Verträgen und Ausschreibungen
Wird ein System extern entwickelt, werden Anforderungen zur Vertragsgrundlage. Der IREB-Lehrplan beschreibt für diesen Fall den vertragsbasierten Prozess: meist linear und präskriptiv, mit einer klassischen Systemanforderungsspezifikation aus natürlichsprachlichen Anforderungen und Modellen. Weil die Rückkopplung lang ist, müssen die Anforderungen besonders gründlich validiert werden. In öffentlichen Beschaffungen kommen vergaberechtliche Vorgaben hinzu: Anforderungen müssen neutral, nachvollziehbar und prüfbar formuliert sein, damit Angebote vergleichbar werden und Zuschlagskriterien angewendet werden können.
Typische Probleme in Verträgen entstehen durch mehrdeutige Anforderungen, fehlende Qualitätsanforderungen und unklare Abnahmekriterien. Jede dieser Lücken wird später zum Streitpunkt über Mehrleistungen. Eine Checkliste für das Review von Anforderungen bietet flenio.ch unter Anforderungsreview, eine weitere für Ausschreibung und Angebot.
Wie lernt man Requirements Engineering?
Der Lehrplan des IREB für den Foundation Level liegt in der Version 3.2.0 vor, gültig seit dem 26. Februar 2024, und wird zusammen mit Handbuch und Probeprüfung zum Download angeboten [6]. Er umfasst sieben Lerneinheiten von den Grundlagen über Dokumentation und Ermittlung bis zu Prozess, Management und Werkzeugen. Die Prüfung zum Certified Professional for Requirements Engineering besteht laut Prüfungsordnung aus etwa 45 Multiple-Choice-Fragen in 75 Minuten und setzt keine formalen Voraussetzungen voraus [5]. Details zu Aufbau und Vorbereitung beschreibt der Beitrag zur IREB-Zertifizierung.
Wertvoller als jede Zertifizierung ist allerdings die Anwendung in echten Vorhaben: Interviews führen, Workshops moderieren, Anforderungen formulieren und mit Stakeholdern validieren. Wer die Prinzipien kennt und bewusst anwendet, verbessert die Qualität seiner Projekte unabhängig davon, ob er klassisch oder agil arbeitet.
Welchen Nutzen bringt systematisches Requirements Engineering?
Der IREB-Lehrplan nennt vier zentrale Beiträge von angemessenem Requirements Engineering: Es senkt das Risiko, das falsche System zu entwickeln, verbessert das Verständnis des Problems, schafft eine Grundlage für die Schätzung von Aufwand und Kosten und ist Voraussetzung dafür, das System testen zu können [1]. Jeder dieser Punkte ist im Projektalltag spürbar: Ohne klare Anforderungen sind Schätzungen Vermutungen, Tests prüfen gegen Annahmen statt gegen vereinbarte Kriterien, und Abnahmen werden zu Verhandlungen.
Der Aufwand für Requirements Engineering wird oft als Verzögerung empfunden, besonders zu Beginn eines Vorhabens, wenn alle mit der Umsetzung beginnen möchten. Die Erfahrung zeigt jedoch, dass Fehler in Anforderungen umso teurer werden, je später sie entdeckt werden. Ein Missverständnis, das in einem einstündigen Gespräch geklärt wird, kostet nach der Umsetzung Tage oder Wochen an Nacharbeit. Die Wertorientierung des Lehrplans gibt dabei das richtige Mass vor: so viel Requirements Engineering wie nötig, um Risiken zu beherrschen, nicht so viel wie möglich.
Für die Praxis bedeutet das: Zu Beginn eines Vorhabens wird bewusst geklärt, welche Anforderungen besonders kritisch sind, welche Stakeholder unbedingt beteiligt werden müssen und wie Anforderungen dokumentiert, validiert und verwaltet werden. Diese Entscheidungen gehören in den Projektauftrag oder das Projekthandbuch und werden im Verlauf überprüft. Wer so vorgeht, braucht weniger Aufwand für Nacharbeit, Streit und Änderungsanträge und schafft gleichzeitig die Grundlage für verlässliche Schätzungen und Abnahmen.
Die Beiträge dieses Leitfadens folgen der Struktur des IREB-Lehrplans und ergänzen sie um Beispiele, Vorlagen und Hinweise für Projekte in der Schweiz, in Deutschland und in Österreich. Jeder Beitrag nennt seine Quellen mit Abrufdatum und wird jährlich fachlich überprüft.
Requirements Engineering im DACH-Raum
Im DACH-Raum ist Requirements Engineering stark durch den IREB mit Sitz in Karlsruhe geprägt, dessen Lehrplan in vielen Sprachen vorliegt; die Version 3 wurde von Stan Bühne, Martin Glinz, Hans van Loenhoud und Stefan Staal verfasst und deckt agile und plangetriebene Ansätze gleichermassen ab [1]. Lastenheft und Pflichtenheft sind im deutschsprachigen Raum verbreitete Dokumenttypen, und in öffentlichen Beschaffungen der Schweiz bilden HERMES-Ergebnisse häufig den Rahmen. Die folgenden Beiträge vertiefen Ermittlung, Formulierung, Qualitätsanforderungen, Kontext, Use Cases und User Stories, Priorisierung, Validierung, Requirements Management und die IREB-Zertifizierung.