0800 71 20000
Kontakt
...
Berufsbild Requirements Engineering

Was ein Requirements Engineer im Projekt verantwortet

Die teuersten Fehler in Softwareprojekten entstehen nicht beim Programmieren, sondern in dem Gespräch, in dem niemand gefragt hat, wozu eine gewünschte Funktion gut sein soll.

Passende Kurse ansehen Persönlich beraten lassen
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Kleine Gruppen Präsenz und Live-Online Zertifizierte Trainer

Kurz gesagt

Ein Requirements Engineer klärt vor der Umsetzung, was gebaut werden soll und woran alle erkennen, dass es fertig ist. Dazu gehört, die Anforderungen bei allen Beteiligten abzuholen, Widersprüche zwischen ihnen aufzulösen und sie so aufzuschreiben, dass ein Entwicklungsteam sie umsetzen und ein Test sie nachweisen kann. In deutschen Stellenausschreibungen steht für diese Arbeit mal Requirements Engineer, mal Business Analyst und mal Product Owner.

Stand dieser Seite: 16.08.2026

01 Worum es geht

Falsch verstandene Anforderungen fallen erst bei der Abnahme auf

Der übliche Ablauf: Die Fachabteilung beschreibt, was sie braucht, das Entwicklungsteam hört zu und baut. Beide sind sicher, dasselbe gemeint zu haben. Der Unterschied fällt bei der Abnahme auf, also an der Stelle, an der eine Änderung am meisten kostet, weil Entwurf, Umsetzung, Test und Dokumentation schon daran hängen.

Die häufigste Ursache ist nicht Nachlässigkeit, sondern eine Formulierung, die niemand prüfen kann. Sätze wie „die Oberfläche soll übersichtlich sein“ oder „die Suche muss schnell antworten“ klingen nach Anforderung, enthalten aber keine Aussage, gegen die sich testen ließe. Wer sie stehen lässt, überlässt die Entscheidung der Person, die den Code schreibt, und die entscheidet nach anderen Kriterien als die Fachabteilung.

Der zweite teure Fehler ist die Anforderung, die als Lösung daherkommt. „Wir brauchen ein zusätzliches Feld für die Kundennummer“ ist kein Bedarf, sondern ein Vorschlag. Dahinter könnte stehen, dass ein Auftrag ohne gültige Kundenzuordnung nicht freigegeben werden darf, und dafür gibt es womöglich eine Lösung, die niemand einbauen muss.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

02 Wer entscheidet was

Wer entscheidet was, wenn Anforderungen entstehen

Die meisten Konflikte im Anforderungsprozess sind keine fachlichen Streitfragen, sondern ungeklärte Zuständigkeiten. Diese Übersicht ordnet die typischen Themen den Stellen zu, die tatsächlich darüber befinden.

Was in die erste Version gehört

Wer entscheidet
Der Auftraggeber aus der Fachseite, der das Budget verantwortet
Wer setzt um
Der Requirements Engineer, der den Umfang schneidet und dokumentiert
Stolperfalle
Die Entscheidung wird nie ausgesprochen und fällt am Ende still im Entwicklungsteam, weil dort jemand anfangen muss.

Wie eine Anforderung formuliert ist

Wer entscheidet
Der Requirements Engineer, weil Prüfbarkeit sein Handwerk ist
Wer setzt um
Die Fachseite, die den Inhalt liefert und die Formulierung bestätigt
Stolperfalle
Ein Wort wie benutzerfreundlich bleibt stehen, und die Auslegung übernimmt später die Person, die es umsetzt.

Nichtfunktionale Anforderungen

Wer entscheidet
Betrieb, Informationssicherheit und Datenschutz gemeinsam mit der Fachseite
Wer setzt um
Die Architektur, weil Last, Verfügbarkeit und Betreibbarkeit dort entschieden werden
Stolperfalle
Sie kommen erst im Lasttest zur Sprache, wenn die Struktur der Anwendung nicht mehr verhandelbar ist.

Änderung nach der Freigabe

Wer entscheidet
Der Auftraggeber, auf Basis von Aufwand und Auswirkung
Wer setzt um
Der Requirements Engineer, der Anforderung, Abnahmekriterien und Testfall nachzieht
Stolperfalle
Die Änderung wird direkt mit einem Entwickler besprochen und taucht in keiner Anforderung auf.

Abnahmekriterien

Wer entscheidet
Die Fachseite, die später abnimmt
Wer setzt um
Anforderungsarbeit und Test gemeinsam
Stolperfalle
Sie entstehen erst im Abnahmetermin, und dann verhandelt jede Seite die Kriterien, die ihr gerade passen.

03 Was du mitnimmst

Was du mitnimmst

Du bekommst das Handwerkszeug, um aus Wünschen prüfbare Anforderungen zu machen, und die Kriterien, an denen du merkst, dass eine Anforderung noch nicht fertig ist.

Fünf Prüfungen, die eine Anforderung bestehen muss

  1. 01 Der Zweck ist genannt, nicht nur die gewünschte Funktion.
  2. 02 Es steht genau eine Aussage darin, ohne verstecktes Und.
  3. 03 Jemand kann die Erfüllung nachweisen, ohne den Autor zu fragen.
  4. 04 Sie widerspricht keiner anderen Anforderung aus derselben Liste.
  5. 05 Eine benannte Person darf über Änderungen an ihr entscheiden.

Hinter den Wunsch schauen

Du fragst bei jeder gewünschten Funktion nach dem Zweck und trennst so die vorgeschlagene Lösung von dem Problem, das sie lösen soll.

Prüfbar formulieren

Du ersetzt Adjektive wie übersichtlich, schnell oder flexibel durch eine Aussage, die sich messen oder beobachten lässt.

Die Stillen im Projekt finden

Du erfasst auch die Beteiligten, die nie im Workshop sitzen: Betrieb, Support, Datenschutz und die Leute, die das Ergebnis später bedienen.

Nichtfunktionale Anforderungen früh stellen

Du klärst Last, Verfügbarkeit, Betrieb, Datenschutz und die Übernahme der Altdaten, bevor die Architektur steht, weil sie sich danach nur teuer ändern lassen.

Anforderungen nachvollziehbar halten

Du hältst fest, welche Anforderung zu welchem Ziel gehört, damit bei einer Streichung sichtbar wird, was mit ihr wegfällt.

Abnahme vorher verabreden

Du schreibst die Abnahmekriterien auf, bevor gebaut wird, damit die Abnahme keine Verhandlung mehr ist.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Requirements Engineer, Business Analyst, Product Owner: wo die Grenze verläuft

Product Owner ist die einzige der drei Bezeichnungen, die aus einem festen Regelwerk stammt. Der Scrum Guide beschreibt sie als Verantwortung für den Wert des Produkts und für die Reihenfolge im Product Backlog, und dazu gehört ausdrücklich die Befugnis, Nein zu sagen. Business Analyst kommt aus der Prozesswelt und fragt zuerst, ob der Ablauf selbst richtig geschnitten ist, bevor über Software gesprochen wird. Requirements Engineer meint die Arbeit an den Anforderungen selbst: erheben, ordnen, prüfbar formulieren und über die Laufzeit nachvollziehbar halten.

In mittelständischen Häusern erledigt eine Person alle drei Aufgaben, und der Titel im Arbeitsvertrag entscheidet nichts. Die Frage, an der sich die Rolle tatsächlich klärt, lautet: Wer legt die Reihenfolge fest, und wer trägt das Budget? Wo jemand priorisiert, ohne über Geld zu verfügen, entstehen Entscheidungen, die sich nicht durchsetzen lassen, und die Fachabteilung geht am Ende doch direkt zur Entwicklung.

Falsch ist die Erwartung, die Rolle sei eine Schreibaufgabe. Der größere Teil des Tages besteht aus Gesprächen, in denen widersprüchliche Wünsche aufeinandertreffen, und aus dem Aushandeln dessen, was zuerst kommt. Die zweite falsche Erwartung betrifft die Menge: Ein vollständiges Dokument, das alles festhält, ist kein Ziel, sondern ein Warnzeichen, weil es niemand liest und es beim ersten Änderungswunsch veraltet.

Erheben, prüfen, formulieren: die Arbeit zwischen Wunsch und Anforderung

Die üblichen Techniken sind Interview, Workshop, Dokumentenanalyse, Prototyp und Beobachtung am Arbeitsplatz. Die letzte ist die unbequemste und die ergiebigste. Menschen beschreiben ihren Ablauf so, wie er gedacht ist, nicht so, wie er läuft. Die Tabelle neben dem System, in der die eigentliche Arbeit passiert, taucht in keinem Interview auf, sondern nur, wenn du daneben sitzt.

Beim Formulieren hilft eine einfache Prüfung: Wenn du eine Anforderung liest und nicht sagen kannst, mit welcher Beobachtung du sie widerlegen würdest, ist sie noch nicht fertig. „Der Bericht soll schnell erscheinen“ wird prüfbar, sobald jemand entscheidet, ob es um zwei Sekunden oder um zwei Minuten geht und für welchen Datenumfang. Diese Entscheidung trifft die Fachseite, nicht die IT, und genau deshalb muss die Frage gestellt werden, solange noch jemand zuhört.

In agilen Vorhaben verschwindet die Anforderungsarbeit nicht, sie verteilt sich über die Zeit. Ein Backlog-Eintrag ist der Platzhalter für ein Gespräch, das noch geführt wird. Die Abnahmekriterien werden trotzdem aufgeschrieben, sonst gibt es im Review nichts zu prüfen, und niemand kann sagen, ob der Eintrag erledigt ist.

Der Weg hinein und die Nachweise, die zählen

Der häufigste Einstieg führt nicht über ein Studium mit diesem Namen, sondern über eine der beiden Seiten: aus der Fachabteilung, wo jemand den Ablauf kennt und ihn erklären kann, oder aus der Entwicklung, wo jemand weiß, was eine schwammige Anforderung anrichtet. Beide bringen die Hälfte mit. Aus der Fachabteilung fehlt meist das Gefühl dafür, was technisch teuer ist, aus der Entwicklung die Geduld für ein Gespräch, das dreimal um dieselbe Frage kreist.

Als Nachweis hat sich das Zertifizierungsschema von IREB durchgesetzt. Es ist vierstufig aufgebaut: Foundation, darüber Practitioner mit den Modulen Elicitation, Management, Modeling und RE@Agile, darüber Specialist und Expert, dazu kompakte Micro-Credentials wie AI4RE für den Einsatz von KI in der Anforderungsarbeit. Was so ein Zertifikat leistet, solltest du nüchtern sehen: Es belegt ein gemeinsames Vokabular, keine Erfahrung. In einem Workshop mit zwölf Beteiligten ist ein gemeinsames Vokabular allerdings mehr wert, als es klingt.

Was im Bewerbungsgespräch wirklich zieht, ist ein Beispiel: eine Anforderung, die du erst missverstanden und dann geklärt hast, samt der Frage, die den Unterschied gemacht hat.

Woran du wächst und wohin die Rolle führt

Zwei Leute mit derselben Berufsdauer unterscheiden sich vor allem in einem Punkt: ob sie eine Anforderung zurückweisen können, ohne das Gespräch zu beenden. Wer jeden Wunsch aufnimmt, produziert eine Liste, die niemand umsetzen kann, und verschiebt die Priorisierung auf den, der zuletzt anfasst. Wer pauschal ablehnt, wird umgangen.

Das zweite Unterscheidungsmerkmal ist der Umgang mit dem Aufhören. Erfahrene Leute merken, wann eine Anforderung genau genug ist, weil weitere Präzision nur noch Aufwand erzeugt und die Umsetzung ohnehin Fragen zurückspielt.

Von hier führen mehrere Wege weiter. Wer Verantwortung für Reihenfolge und Wert übernimmt, geht Richtung Product Owner oder Produktverantwortung. Wer Nachvollziehbarkeit über viele Projekte hinweg verantwortet, landet im Anforderungsmanagement größerer Programme oder in regulierten Bereichen, in denen jede Anforderung bis zum Testfall belegbar sein muss. Und wer nah an der Umsetzung bleiben will, wechselt ins Testmanagement oder in die Lösungsarchitektur.

Dazu passende Kurse

Die Zertifizierung nach IREB und der Weg von der geprüften Anforderung zum Testfall liegen bei cmt im selben Bereich, in den IREB- und Testkursen.

Wenn du neben den Anforderungen auch Termine und Budget verantwortest, helfen Trainings für die Steuerung von IT-Vorhaben.

04 Was verdient man

Die amtlichen Zahlen zu dieser Rolle

Eine eigene Berufsgattung für Anforderungserhebung gibt es in der amtlichen Systematik nicht, die Tätigkeit verteilt sich auf IT-Systemanalyse und IT-Anwendungsberatung. Die beiden Zellen stehen außerdem auf verschiedenen Anforderungsniveaus, Experte und Spezialist, ein Teil des Abstands zwischen ihnen ist also ein Niveauunterschied und keine Aussage über die Rolle. Eine Stelle auf dem Niveau Experte verlangt einen größeren Entscheidungsspielraum, sie ist keine Karrierestufe, die man mit den Jahren automatisch erreicht. Liegt dein eigener Verdienst deutlich darunter oder darüber, hängt das meist an Branche und Betriebsgröße, denn beide Zellen mischen Konzernprojekte mit Mittelstand.

Amtliche Medianverdienste, April 2025

Brutto im Monat

Statistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.

IT-Systemanalyse Experte 6.500 €

KldB 43214. Median mal 12 rund 78.000 € im Jahr ohne Sonderzahlungen, Durchschnitt 6.660 € im Monat

IT-Anwendungsberatung Spezialist 5.568 €

KldB 43223. Median mal 12 rund 67.000 € im Jahr ohne Sonderzahlungen, Durchschnitt 5.886 € im Monat

02k4k6k8k
  • Vollzeitbeschäftigte, Bruttomonatsverdienst ohne Sonderzahlungen. Weihnachts- und Urlaubsgeld, Prämien und Boni sind nicht enthalten, der Jahresverdienst liegt also über dem Zwölffachen.
  • Das Anforderungsniveau beschreibt den Zuschnitt der Stelle, nicht die Berufserfahrung. Fachkraft, Spezialist und Experte sagen etwas über die Komplexität der Tätigkeit aus, nicht über Dienstjahre. Aufsicht und Führung bezeichnen Stellen mit Aufsichts- oder Leitungsverantwortung, auch das ist ein Zuschnitt der Stelle.
  • Die Erhebung geht regional nur bis auf die Bundeslandebene. Für einzelne Städte gibt es keine amtlichen Zahlen, weil der Zufallsfehler zu groß wäre.

Quelle: Statistischer Bericht Verdienste, Statistisches Bundesamt (Destatis). Den eigenen Fall prüfst du im Entgeltatlas der Bundesagentur für Arbeit . Beachte dort: Entgelte oberhalb der Beitragsbemessungsgrenze sind der Statistik nicht bekannt, bei gut bezahlten Rollen steht deshalb nur eine Untergrenze.

Wissen prüfen

Wie sicher bist du beim Thema wirklich?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Wissenstest PRINCE2 Foundation QuizTeste dein Wissen zu Prinzipien, Practices, Prozessen, Rollen, Business Case und Toleranzen. Quiz starten

05 Konkrete Kurse

Wo du genau das übst

Weitere Kurse aus diesem Bereich

Preise, Orte und Buchung für alle Kurse des Bereichs findest du im Katalog: Alle Kurse und Termine: Software Testing Seminare und Zertifizierungen.

Stimmen aus den Kursen

Was Teilnehmende über die Kurse in diesem Bereich sagen

Intensiv und kompakt! Inhalte passgenau! Vorschlag: Eine Seminarvariante mit 3 Tagen zur Ermöglichung inhaltlicher Vertiefungen halte ich für empfehlenswert!
Effektive KI Software-Tests mit LLMs
Sympathischer, freundlicher und kompetenter Dozent, Inhalte wurden gut eingeteilt und vermittelt.
pytest Einführungskurs – Testgetriebene Entwicklung von Python-Code
War super. Super ausführlich wurde Wissen über folgende Themen vermittelt: go multithreading, rest, mongodb Anbindung, so wie Desktop Apps (CLI und GUI) und noch weitere Themen.
Go Programmierung - Aufbaukurs (Golang)

06 Fragen

Häufige Fragen

Deine Frage ist nicht dabei? Stell sie uns direkt, wir antworten dir persönlich.

Brauche ich ein Informatikstudium für die Rolle?
Nein. Verlangt wird die Fähigkeit, einen Fachprozess zu verstehen und ihn so aufzuschreiben, dass ein Entwicklungsteam damit arbeiten kann. Der häufigste Einstieg kommt aus einer Fachabteilung, der zweithäufigste aus der Entwicklung. Technisches Verständnis hilft beim Einschätzen von Aufwand, ersetzt aber nicht die Bereitschaft, im Zweifel dreimal nachzufragen.
Ist Requirements Engineer dasselbe wie Business Analyst?
In vielen Stellenanzeigen ja, in der Sache nicht ganz. Business Analyse setzt beim Geschäftsprozess an und fragt, ob der Ablauf selbst stimmt. Anforderungsarbeit setzt bei der Lösung an und sorgt dafür, dass die Anforderungen daran vollständig, widerspruchsfrei und prüfbar sind. Wenn du eine Anzeige liest, achte weniger auf den Titel als darauf, wer die Reihenfolge festlegt und wer das Budget verantwortet.
Lohnt sich die IREB-Zertifizierung?
Sie lohnt sich dort, wo mehrere Beteiligte über Anforderungen sprechen müssen, also in Projekten für Kunden und in größeren Häusern. Der Nutzen liegt im gemeinsamen Vokabular und in einer sortierten Vorstellung davon, was zur Arbeit gehört. Ein Projekt ersetzt sie nicht, und in einem Gespräch wird nach Beispielen gefragt, nicht nach Prüfungsergebnissen.
Braucht es Anforderungsarbeit in agilen Projekten überhaupt noch?
Ja, nur anders verteilt. Statt eines Dokuments am Anfang entstehen Anforderungen fortlaufend, dafür sind sie kleiner geschnitten und werden häufiger überprüft. Die Arbeit an Erhebung, Widerspruchsfreiheit und Abnahmekriterien bleibt dieselbe, und IREB führt dafür mit RE@Agile ein eigenes Modul.

Passt thematisch dazu

Nichtfunktionale Anforderungen wie Verfügbarkeit und Antwortzeit landen später in einer Servicevereinbarung, deshalb hilft es beim Formulieren zu sehen, wie aus einer Zusage eine Kennzahl mit Messverfahren wird.

Quellen

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.

0800 71 20000 E-Mail

Anforderungen sind Handwerk, kein Talent

Wie du Wünsche in prüfbare Anforderungen übersetzt, Abnahmekriterien schreibst und beides über die Projektlaufzeit sauber hältst, übst du in den IREB-Kursen bei cmt.

Alle Kurse und Termine Frage stellen

Verwandte Themen

Alle Themen zu IT-Berufe