Wer festlegt, was gebaut wird, bevor es gebaut wird
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.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
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
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.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Was in die erste Version gehört | Der Auftraggeber aus der Fachseite, der das Budget verantwortet | Der Requirements Engineer, der den Umfang schneidet und dokumentiert | Die Entscheidung wird nie ausgesprochen und fällt am Ende still im Entwicklungsteam, weil dort jemand anfangen muss. |
| Wie eine Anforderung formuliert ist | Der Requirements Engineer, weil Prüfbarkeit sein Handwerk ist | Die Fachseite, die den Inhalt liefert und die Formulierung bestätigt | Ein Wort wie benutzerfreundlich bleibt stehen, und die Auslegung übernimmt später die Person, die es umsetzt. |
| Nichtfunktionale Anforderungen | Betrieb, Informationssicherheit und Datenschutz gemeinsam mit der Fachseite | Die Architektur, weil Last, Verfügbarkeit und Betreibbarkeit dort entschieden werden | Sie kommen erst im Lasttest zur Sprache, wenn die Struktur der Anwendung nicht mehr verhandelbar ist. |
| Änderung nach der Freigabe | Der Auftraggeber, auf Basis von Aufwand und Auswirkung | Der Requirements Engineer, der Anforderung, Abnahmekriterien und Testfall nachzieht | Die Änderung wird direkt mit einem Entwickler besprochen und taucht in keiner Anforderung auf. |
| Abnahmekriterien | Die Fachseite, die später abnimmt | Anforderungsarbeit und Test gemeinsam | Sie entstehen erst im Abnahmetermin, und dann verhandelt jede Seite die Kriterien, die ihr gerade passen. |
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.
Fünf Prüfungen, die eine Anforderung bestehen muss
- 01 Der Zweck ist genannt, nicht nur die gewünschte Funktion.
- 02 Es steht genau eine Aussage darin, ohne verstecktes Und.
- 03 Jemand kann die Erfüllung nachweisen, ohne den Autor zu fragen.
- 04 Sie widerspricht keiner anderen Anforderung aus derselben Liste.
- 05 Eine benannte Person darf über Änderungen an ihr entscheiden.
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.
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.
Was die amtlichen Zahlen zu dieser Rolle sagen und was nicht
Für Anforderungserhebung gibt es in der Klassifikation der Berufe keine eigene Gattung. Die Tätigkeit verteilt sich auf IT-Systemanalyse und IT-Anwendungsberatung, und die beiden Zellen unten stehen zusätzlich auf verschiedenen Anforderungsniveaus. Ein Teil des Abstands zwischen ihnen ist deshalb ein Niveauunterschied und keine Aussage über die Rolle.
Anforderungsniveau heißt: Zuschnitt der Stelle, nicht Erfahrung der Person. Eine Stelle auf dem Niveau Experte verlangt einen größeren Entscheidungsspielraum, sie ist nicht automatisch mit jemandem besetzt, der länger dabei ist. Wer das als Karrierestufe liest, zieht aus der Statistik eine Aussage, die sie nicht enthält.
Zwei weitere Dinge gehören dazu. Es sind Bruttomonatsverdienste von Vollzeitbeschäftigten ohne Sonderzahlungen, Weihnachts- und Urlaubsgeld fehlen also, und der Jahresverdienst liegt entsprechend über dem Zwölffachen. Und der Median ist die belastbarere Zahl, weil einzelne sehr hohe Verdienste den Durchschnitt nach oben ziehen, während der Median den Wert in der Mitte zeigt.
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
Wie aus einer geprüften Anforderung ein Testfall wird, üben die Kurse zu Anforderungen, Testfällen und Abnahme .
Wenn du neben den Anforderungen auch Termine und Budget verantwortest, helfen Trainings für die Steuerung von IT-Vorhaben .
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. Anforderungsniveau beschreibt dabei den Zuschnitt der Stelle und nicht die Berufserfahrung der Person. 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 MonatStatistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.
KldB 43214, Durchschnitt 6.660 €, gerundet rund 78.000 € im Jahr ohne Sonderzahlungen
KldB 43223, Durchschnitt 5.886 €, gerundet rund 67.000 € im Jahr ohne Sonderzahlungen
- 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.
- 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 IT-Rollen steht deshalb nur eine Untergrenze.
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.
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Brauche ich ein Informatikstudium für die Rolle?
Ist Requirements Engineer dasselbe wie Business Analyst?
Lohnt sich die IREB-Zertifizierung?
Braucht es Anforderungsarbeit in agilen Projekten überhaupt noch?
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 .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Anforderungen sind Handwerk, kein Talent
Wie du Wünsche in prüfbare Anforderungen übersetzt, Abnahmekriterien schreibst und beides über die Projektlaufzeit sauber hältst, wird in den Kursen zu Requirements Engineering und Test geübt.
Passt dazu
- IT-Projektmanager: wofür du geradestehst, wenn das Projekt läuft
- Softwaretester werden: der Weg über ISTQB und die erste Testautomatisierung
- Scrum Master: keine Projektleitung, und genau daran hängt der Konflikt
- Quereinstieg in die Softwareentwicklung: was du wirklich können musst