Was macht ein Requirements Engineer?

Warum Requirements Engineering über Erfolg und Scheitern entscheidet

Wenn Softwareprojekte scheitern, lassen sich dafür viele Ursachen finden — unter ihnen spielen unklare, widersprüchliche oder lückenhafte Anforderungen eine häufige Rolle. Requirements Engineers sorgen dafür, dass Bedürfnisse von Fachbereichen in klare, testbare und umsetzbare Anforderungen übersetzt werden und dass diese über den gesamten Lebenszyklus gepflegt werden. Die zugrunde liegende Disziplin ist international standardisiert, etwa in der Norm ISO/IEC/IEEE 29148, die Prozesse, Informationsartefakte und Qualitätskriterien für Anforderungen definiert und deren Einbettung in den System‑ und Software‑Lebenszyklus beschreibt (ISO/IEC/IEEE 29148:2018).

Gleichzeitig zeigt aktuelle Empirie: In der Praxis dominieren natürlichsprachliche Anforderungen – oft in Word, Wikis oder einfachen Tools. Typische Stolpersteine bleiben Mehrdeutigkeit, Inkonsistenz und Unvollständigkeit; das bestätigt eine Interviewstudie in 12 Unternehmen, die gängige Artefakte, Strukturen und Tools ausgewertet hat (Springer‑Studie, 2023). Für Bewerber:innen heißt das: Erfolgreiche Requirements Engineers kombinieren methodische Klarheit mit pragmatischer Umsetzung im Alltag.

Was ein Requirements Engineer konkret tut

Die Kernthese: Ein Requirements Engineer verhindert teure Fehlentwicklungen, indem er Anforderungen strukturiert erhebt, dokumentiert, validiert und managt. Daraus ergeben sich fünf Tätigkeitsfelder, die sich – je nach Unternehmen – unterschiedlich gewichten:

Erheben: Stakeholder identifizieren, Interessen verstehen, Anforderungen gewinnen (Interviews, Workshops, Beobachtung, Dokumentenanalyse).
Analysieren: Anforderungen strukturieren, priorisieren, Konflikte sichtbar machen, Abhängigkeiten klären.
Dokumentieren/Spezifizieren: Anforderungen so festhalten, dass sie lesbar, eindeutig, testbar und verfolgbar sind (z. B. User Stories, Use Cases, SRS).
Validieren/Abstimmen: Gemeinsames Verständnis sicherstellen, Widersprüche auflösen, Akzeptanzkriterien und Abnahmekriterien schärfen.
Managen: Änderungen steuern, Versionen pflegen, Traceability sichern, Risiken adressieren.

Typische Artefakte und Deliverables

Die Norm 29148 beschreibt klar, welche Informationsobjekte im Lebenszyklus entstehen und wie sie strukturiert sein sollten. In der Praxis begegnen dir häufig:

Business‑ und Stakeholder‑Anforderungen (z. B. Business Requirements Specification, Stakeholder Requirements Specification)
System‑ und Software‑Anforderungen (SyRS/SRS); in agilen Umfeldern z. B. als User Stories, teils ergänzt um Epics/Features
Modelle und Sichten (z. B. Daten‑, Zustands‑ oder Prozessmodelle) als Ergänzung zur Sprache
Traceability‑Matrizen oder ‑Beziehungen zur Verknüpfung von Anforderungen mit Tests, Architekturkomponenten und Änderungen

Wichtig ist nicht das Etikett, sondern die Qualität: Kriterien wie Verständlichkeit, Eindeutigkeit, Konsistenz, Vollständigkeit und Prüfbarkeit – wie sie in Normen und Lehrwerken (u. a. ISO/IEC/IEEE 29148 sowie CPRE‑Lehrstoff) gefordert werden.

Schnittstellen im Unternehmen

Requirements Engineers arbeiten an den Nahtstellen von Business und Technik. Häufige Partner sind:

Produktmanagement und Fachbereiche (Ziele, Nutzen, Priorität)
Entwicklung/Architektur (Machbarkeit, Architektur‑Fit, Schnittstellen)
QA/Test (Ableitung testbarer Akzeptanzkriterien, Abdeckung)
Compliance/Legal (Regulatorik, Datenschutz)
Projekt-/Produktleitung (Roadmap, Release‑Planung, Change Control)

So sieht Requirements Engineering in der Praxis aus

Die 29148 gibt einen Referenzrahmen für Prozesse und Inhalte vor; sie ist anschlussfähig an weitere Lebenszyklus‑Normen und beschreibt Qualitätsmerkmale sowie Leitlinien für die Darstellung und Struktur von Anforderungen. In Projekten wird das jedoch häufig pragmatisch angepasst: Die genannte Studie zeigt, dass Teams meist mit natürlicher Sprache starten, ergänzt um Vorlagen (z. B. EARS‑ähnliche Satzmuster) und einfache Tools. Anforderungen werden typischerweise entlang von Funktionen, Domänenbereichen oder Systemteilen strukturiert. Die häufigsten Probleme:

Ambiguität (mehrdeutige, interpretationsoffene Formulierungen)
Inkonsistenz (Widersprüche zwischen Anforderungen/Sichten)
Unvollständigkeit (Lücken, fehlende Randfälle)

Für deine Bewerbung bedeutet das: Hebe Erfahrungen hervor, die zeigen, wie du genau diese Probleme präventiv adressierst – etwa durch präzise Formulierungsregeln, moderierte Reviews und durchgängige Nachverfolgbarkeit vom Business‑Ziel bis zum Testfall.

Welche Kompetenzen Arbeitgeber in Deutschland erwarten

Die Stellenprofile im deutschen Markt zeichnen ein konsistentes Bild: Gesucht wird die Kombination aus fachlicher Methodenkompetenz, Domänenverständnis und Kommunikationsstärke. Recruiting‑Profile beschreiben die Rolle als Bindeglied von Idee bis Umsetzung, inklusive Analyse, Dokumentation, Priorisierung und Stakeholder‑Abstimmung – teils mit Verweis auf rechtliche Rahmenbedingungen (Hays Jobprofil). Ergänzend positioniert das International Requirements Engineering Board (IREB) mit dem CPRE‑Programm eine in Deutschland verbreitete, oft zitierte Qualifizierungsoption zu Ermittlung, Dokumentation, Prüfung und Verwaltung von Anforderungen sowie zur Arbeit in klassischen wie agilen Umgebungen (IREB).

Fachliche Skills

Requirements‑Methoden: Elicitation‑Techniken, Konfliktauflösung, Priorisierung
Spezifikation: verständliche, testbare Formulierungen; User Stories/Use Cases; Qualitätskriterien
Modellierung: zweckmäßige UML/SysML‑Sichten für Daten, Verhalten und Prozesse
Traceability und Änderungsmanagement: Auswirkungen von Änderungen bewerten und steuern
Domänenverständnis: schnelle Einarbeitung in Fachlogik, Regulatorik und Prozesse

Soziale und methodische Kompetenzen

Moderation und Facilitation: Workshops ergebnisorientiert führen
Stakeholder‑Management: Interessen austarieren, Entscheidungen herbeiführen
Kommunikation: Brücken bauen zwischen Business, Entwicklung und Test
Agiles Arbeiten: Product‑Backlog‑Pflege, Refinements, Definition of Ready/Done

Zertifikate und Weiterbildung

CPRE/IREB ist im deutschsprachigen Raum eine weithin anerkannte Qualifizierungsoption für Requirements Engineering; das Foundation Level deckt die methodischen Grundlagen ab, Advanced‑Module vertiefen Spezialgebiete. In regulierten Domänen (z. B. Automotive, Medizintechnik) können zusätzliche Standardschulungen sinnvoll sein; die konkrete Auswahl hängt von der Domäne ab.

Stellenausschreibung lesen: Was drinsteht – und was wirklich zählt

Viele Anzeigen bündeln „Hard Skills“ (Methoden, Tools) und „Soft Skills“ (Moderation, Kommunikation). In der Praxis zählen vor allem nachweisbare Ergebnisse:

Wirkung vor Werkzeug: Ob Word, Jira oder ein RE‑Tool – wichtig ist, dass du Anforderungen konsistent, prüfbar und nachvollziehbar hältst.
Qualität sichtbar machen: Zeige, wie du Ambiguität reduzierst (z. B. definierte Satzmuster, Glossar), Widersprüche findest (Reviews) und Lücken schließt (Szenarien, Randfälle).
Traceability leben: Erkläre, wie du Business‑Ziele mit Anforderungen, Tests und Abnahmen verknüpfst.

Zu Gehältern kommunizieren Unternehmen selten konkret. Als grober, marktüblicher Referenzrahmen werden für Deutschland Einstiegsspannen um 48.000 Euro brutto, Durchschnittswerte um 62.000 Euro und Spitzen bis etwa 75.000 Euro genannt (laut Hays‑Profil). Deine tatsächliche Spanne hängt stark von Region, Branche, Projektverantwortung und Erfahrungsgrad ab.

Beispiele für Interviewfragen – und wie du souverän antwortest

Wie stellen Sie sicher, dass Anforderungen eindeutig und testbar sind?

Nenne eigene Qualitätskriterien (klar, konsistent, vollständig, prüfbar) und beschreibe konkrete Praktiken: definierte Satzmuster/Schablonen, Glossar, Akzeptanzkriterien, Vier‑Augen‑Reviews mit Entwicklung/Test, beispiel‑basierte Szenarien und Randfälle.

Beschreiben Sie Ihren Prozess vom Stakeholder‑Interview bis zur abgenommenen Anforderung.

Skizziere End‑to‑End: Stakeholder‑Map, Interviewleitfaden, Hypothesen, Konsolidierung, Konfliktklärung, Priorisierung, Formulierung (Story/Use Case/SRS), Review, Freigabe, Traceability zum Test.

Wie gehen Sie mit widersprüchlichen Anforderungen um?

Mache Konflikte transparent, liefere Entscheidungsgrundlagen (Impact, Risiken, Kosten/Nutzen), nutze Moderationstechniken, dokumentiere Entscheidungen und pflege die Traceability.

Welche Artefakte nutzen Sie in agilen Teams?

Nenne Product Goal/Outcome, Epics/Features/Stories, Akzeptanzkriterien, Definition of Ready/Done, Refinement‑Workshops; ergänzende Modelle bei Bedarf.

Nennen Sie ein Beispiel, in dem Sie Scope Creep eingehegt haben.

Beschreibe den Change‑Prozess: Impact‑Analyse, Rückbindung an Ziele/OKRs, Re‑Priorisierung im Backlog, transparente Kommunikation von Trade‑offs.

Wie verknüpfen Sie Anforderungen mit Tests?

Erkläre Prüfbare Akzeptanzkriterien, Ableitung von Testfällen, Traceability‑Matrix oder Tool‑gestützte Verknüpfung und Nutzung von Abdeckungsberichten.

Dos and Don’ts im Lebenslauf

Do: Ergebnisse quantifizieren – z. B. „Reduktion von Change Requests nach Sprint‑Review um X% durch Einführung von Story‑Templates und Review‑Checkliste“ (ohne vertrauliche Zahlen zu verraten).
Do: Artefakt‑Kompetenz benennen – SRS/Story‑Formate, Akzeptanzkriterien, Traceability‑Praxis, Review‑Mechanismen.
Do: Domänenkontext nennen – Regulatorik‑ oder Qualitätsanforderungen, die Sie adressiert haben.
Don’t: Tool‑Listen ohne Nutzenbezug. Statt „Jira, Confluence, Doors" besser „Backlog‑Definition mit klaren Ready‑Kriterien in Jira; Traceability vom Business‑Ziel zum Testfall”.
Don’t: Nur Prozessbegriffe. Zeigen Sie konkrete Beiträge zu Entscheidungen, Prioritäten und Produktnutzen.

Passt der Job zu mir? Karrierepfade und Trade‑offs

Requirements Engineering ist ideal, wenn du gerne moderierst, strukturierst und fachliche Komplexität in klare, prüfbare Schritte übersetzt. Mögliche Wege:

Specialist: Tiefe in RE‑Methoden, Qualitätskriterien, domänenspezifische Standards
Business Analyst/Product Owner: stärkere Produkt‑ und Outcome‑Verantwortung
Consulting/Coaching: Teams und Organisationen beim Aufbau von RE‑Praxis unterstützen
Management: fachliche Leitung, Governance, Skalierung von RE über Teams hinweg

Trade‑offs, die du realistisch einplanen solltest:

Tiefe vs. Breite: Detailtiefe in Anforderungen vs. Produkt‑ und Business‑Blick.
Normativ vs. agil: Dokumentationsrigor nach Standard vs. schlanke Artefakte im Flow; oft ist ein „just enough“‑Ansatz sinnvoll.
Werkzeug‑Fokus vs. Ergebnis‑Fokus: Tools helfen, ersetzen aber nicht Moderation, Klarheit und Entscheidungen.

Kurzcheckliste vor der Bewerbung

Kannst du deine Qualitätskriterien für „gute“ Anforderungen mit Beispielen belegen?
Hast du ein greifbares Beispiel für Konfliktlösung und priorisierte Entscheidungen?
Zeigst du Traceability vom Business‑Ziel bis zum Testfall?
Passt dein CV auf die Domäne (Regeln, Daten, Risiken) des Zielunternehmens?
Hast du zwei prägnante Stories zu „Fehler vermieden/korrigiert dank sauberer Anforderungen"?

Nächste Schritte zur Vorbereitung

Standard verstehen: Ein Blick in die Struktur und Begriffe der ISO/IEC/IEEE 29148:2018 hilft, Artefakte und Qualitätsmerkmale sauber einzuordnen.
Empirie kennen: Die Interviewstudie liefert Argumente für pragmatische, sprachnahe Spezifikation – und für systematische Gegenmaßnahmen gegen Ambiguität (Springer‑Studie, 2023).
Zertifizierbar werden: Prüfe, ob das CPRE Foundation Level von IREB für deine Zielrolle sinnvoll ist.
Üben: Schreibe 5–10 reale Anforderungen zu einem bekannten Produkt, versehe sie mit Akzeptanzkriterien und bitte eine:n Entwickler:in und Tester:in um Review – das liefert konkretes Interviewmaterial.

Fazit

Was macht ein Requirements Engineer? Kurz: Er oder sie sorgt dafür, dass aus Zielen lieferbare Lösungen werden – ohne teure Umwege. Wer Anforderungen präzise erhebt, klar dokumentiert, gemeinsam validiert und über den Lebenszyklus steuert, schafft messbaren Nutzen für Produkt, Team und Unternehmen. Bewerber:innen punkten, wenn sie diese Wirkung konkret belegen – weniger mit Tool‑Listen, mehr mit nachvollziehbaren Ergebnissen und einem klaren Qualitätsanspruch an jede einzelne Anforderung.