Anforderungsmanagement: Prozess, Methoden und Tools verständlich erklärt

Warum Projekte selten an der Technik scheitern, sondern an unklaren Erwartungen, und wie ein geordneter Umgang mit Anforderungen das ändert

„Wir brauchen eine App wie Facebook, nur für unsere Kunden.“ Solche Sätze fallen in Projektauftakten häufiger, als man denkt. Jeder am Tisch nickt, und jeder stellt sich etwas anderes vor: die Geschäftsführung einen Newsfeed mit Produktneuheiten, der Vertrieb ein Kundenportal mit Bestellhistorie, die IT eine Chatfunktion. Drei Monate später liegt eine Software auf dem Tisch, die niemanden zufriedenstellt, obwohl alle fleißig waren.

Genau hier setzt Anforderungsmanagement an. Es sorgt dafür, dass aus vagen Wünschen überprüfbare Aussagen werden, dass Änderungen nicht im Flurfunk verloren gehen und dass am Ende jemand sagen kann, ob das Ergebnis den Erwartungen entspricht. Das klingt nach Bürokratie, ist aber in Wahrheit eine Abkürzung: Jede Stunde, die in Klarheit am Anfang fließt, spart später Nacharbeit.

Was Anforderungsmanagement ist und was es nicht ist

Eine Anforderung beschreibt, was ein System, ein Produkt oder eine Dienstleistung leisten oder erfüllen muss. Das kann eine Funktion sein („Kunden können Rechnungen als PDF herunterladen“), eine Eigenschaft („Die Seite lädt in unter zwei Sekunden“) oder eine Vorgabe von außen („Die Lösung erfüllt die Anforderungen der DSGVO“).

Anforderungsmanagement ist der geordnete Umgang mit diesen Anforderungen über die gesamte Lebensdauer eines Vorhabens: ermitteln, beschreiben, prüfen, abstimmen, priorisieren, verfolgen und ändern. Im Englischen spricht man von Requirements Management, die Fachdisziplin insgesamt heißt Requirements Engineering. Im deutschsprachigen Raum hat der Verband IREB (International Requirements Engineering Board) mit seiner Zertifizierung CPRE (Certified Professional for Requirements Engineering) viel dazu beigetragen, Begriffe und Vorgehen zu vereinheitlichen.

Was Anforderungsmanagement nicht ist: ein dickes Dokument, das einmal geschrieben und dann abgeheftet wird. Anforderungen ändern sich, weil Märkte sich ändern, weil Nutzer neue Ideen haben oder weil ein Gesetz kommt. Gutes Anforderungsmanagement rechnet damit.

Welche Arten von Anforderungen es gibt

Wer Anforderungen sortiert, übersieht weniger. Bewährt hat sich eine Einteilung in drei Gruppen:

• Funktionale Anforderungen: was das System tun soll. Beispiel: „Eine Sachbearbeiterin kann einen Antrag zur Prüfung an eine Kollegin weiterleiten.“
• Qualitätsanforderungen (oft „nicht funktionale Anforderungen“ genannt): wie gut es das tun soll, etwa Geschwindigkeit, Verfügbarkeit, Sicherheit, Bedienbarkeit oder Barrierefreiheit.
• Randbedingungen: Vorgaben, die den Lösungsraum einschränken, zum Beispiel Budget, Termin, vorgeschriebene Technik, Normen, Verträge oder Gesetze.

Gerade die zweite und dritte Gruppe werden gern vergessen. Ein Onlineshop kann alle Funktionen haben und trotzdem scheitern, weil er beim Weihnachtsgeschäft zusammenbricht oder weil die Barrierefreiheitsvorgaben nicht erfüllt sind. Hilfreich ist außerdem, zwischen Geschäftsanforderungen (Warum machen wir das überhaupt?), Nutzeranforderungen (Was wollen die Anwender erreichen?) und Systemanforderungen (Was muss die Software konkret können?) zu unterscheiden. So bleibt der Zusammenhang zwischen Ziel und Umsetzung sichtbar.

Der Prozess: vom ersten Gespräch bis zur Änderung im Betrieb

Der Anforderungsmanagement-Prozess lässt sich in fünf Tätigkeiten gliedern. In klassischen Projekten laufen sie eher nacheinander, in agilen Projekten immer wieder in kleinen Schleifen.

1. Ermitteln

Zuerst geht es darum, wer überhaupt etwas zu sagen hat. Diese Beteiligten, im Fachjargon Stakeholder, sind mehr als Auftraggeber und Nutzer: Datenschutz, Betriebsrat, IT-Betrieb, Kundenservice oder Wirtschaftsprüfung haben oft eigene Anforderungen. Eine Stakeholder-Liste zu Beginn verhindert, dass der Betriebsrat erst kurz vor dem Start ein Veto einlegt. Danach werden Anforderungen erhoben, mit Interviews, Workshops, Beobachtung am Arbeitsplatz oder der Auswertung vorhandener Dokumente.

2. Dokumentieren

Anforderungen werden so festgehalten, dass sie eindeutig, prüfbar und verständlich sind. Die Form hängt vom Vorgehen ab: In klassischen Projekten in Deutschland sind Lastenheft (Was will der Auftraggeber?) und Pflichtenheft (Wie setzt der Auftragnehmer es um?) verbreitet, in agilen Projekten User Stories im Product Backlog. Eine gute Anforderung hat eine eindeutige Kennung, eine Quelle, eine Priorität und Kriterien, an denen man erkennt, ob sie erfüllt ist.

3. Prüfen und abstimmen

Bevor gebaut wird, prüfen die Beteiligten, ob die Anforderungen vollständig, widerspruchsfrei und umsetzbar sind. Häufig zeigen sich hier Konflikte, etwa wenn der Vertrieb maximale Flexibilität will und die IT-Sicherheit strenge Freigaben verlangt. Diese Konflikte gehören in eine Abstimmung und nicht in den Code.

4. Priorisieren

Nicht alles kann in die erste Version. Priorisieren heißt entscheiden, was zuerst kommt und was wegfallen darf. Dafür gibt es Methoden, die weiter unten beschrieben sind.

5. Verfolgen und ändern

Jede Anforderung sollte nachvollziehbar mit ihrer Umsetzung und ihren Tests verbunden sein. Diese Verfolgbarkeit, englisch Traceability, beantwortet Fragen wie: Welche Tests decken diese Anforderung ab? Welche Funktionen sind betroffen, wenn sich eine Vorgabe ändert? Änderungen laufen über einen festen Weg: beantragen, Auswirkungen abschätzen, entscheiden, dokumentieren. In regulierten Branchen wie Medizintechnik, Automobilbau oder Luftfahrt verlangen die einschlägigen Normen und Zulassungsverfahren diese Nachweiskette, in allen anderen erspart sie zumindest viel Sucherei.

Methoden im Anforderungsmanagement, die sich bewährt haben

Es gibt keine Methode für alles. Die folgenden Werkzeuge aus dem Methodenkasten decken die meisten Situationen ab.

Methoden zum Ermitteln

• Interviews und Workshops: der Klassiker. Wichtig sind offene Fragen („Wie läuft das heute ab?“) statt Lösungsfragen („Brauchen Sie einen Button dafür?“).
• Beobachtung: Wer einer Sachbearbeiterin eine Stunde über die Schulter schaut, sieht Umwege und Zettelwirtschaft, die in keinem Interview erwähnt werden.
• Prototypen und Skizzen: Ein klickbarer Entwurf löst schneller Rückmeldungen aus als zehn Seiten Text. Menschen erkennen leichter, was sie nicht wollen, als zu formulieren, was sie wollen.
• Kano-Modell: unterscheidet Basisanforderungen (werden erwartet, fallen nur auf, wenn sie fehlen), Leistungsanforderungen (je mehr, desto besser) und Begeisterungsmerkmale (überraschen positiv). Das hilft, nicht nur Selbstverständliches zu sammeln.

Methoden zum Beschreiben

• User Stories: kurze Sätze nach dem Muster „Als Kundin möchte ich meine Rechnungen herunterladen, damit ich sie an die Buchhaltung weitergeben kann.“ Sie halten fest, wer etwas will und warum.
• Akzeptanzkriterien: machen eine Story prüfbar. Eine verbreitete Form ist „Gegeben … wenn … dann …“, die sich auch für automatisierte Tests nutzen lässt.
• Anwendungsfälle (Use Cases): beschreiben einen Ablauf Schritt für Schritt, einschließlich Fehlerfällen. Sie eignen sich für komplexe Abläufe besser als einzelne Stories.
• Satzschablonen: vorgegebene Satzmuster wie „Das System muss …“ zwingen zu eindeutigen Formulierungen und vermeiden Wörter wie „schnell“, „benutzerfreundlich“ oder „usw.“.
• Modelle: Prozessdiagramme, etwa in BPMN, oder Zustandsdiagramme zeigen Zusammenhänge, die im Fließtext untergehen.

Methoden zum Priorisieren

• MoSCoW: sortiert in Must have, Should have, Could have und Won't have (diesmal nicht). Einfach, aber nur wirksam, wenn „Must“ wirklich knapp bleibt.
• Nutzen gegen Aufwand: eine einfache Matrix, die schnelle Erfolge mit hohem Nutzen und geringem Aufwand sichtbar macht.
• Story Mapping: ordnet User Stories entlang des Nutzerablaufs und schneidet daraus sinnvolle erste Versionen.

Wer tiefer einsteigen will, wie man hinter einer geäußerten Lösung das eigentliche Problem findet, findet Techniken dazu im Beitrag Problemanalyse im Requirements Engineering.

Anforderungsmanagement in agilen Projekten

Ein verbreitetes Missverständnis lautet, agile Teams bräuchten kein Anforderungsmanagement. Das Gegenteil ist richtig: Es findet nur anders statt. Statt eines vollständigen Lastenhefts zu Beginn gibt es ein Product Backlog, eine geordnete Liste von Anforderungen, die laufend verfeinert wird. Verantwortlich dafür ist in Scrum der Product Owner. Was weit oben steht, ist genau beschrieben; was weit unten steht, darf noch grob sein.

Der Vorteil: Rückmeldungen aus jeder Iteration fließen direkt in die nächste Planung ein. Das Risiko: Wenn niemand den Überblick behält, zerfällt das Produkt in viele kleine Stories ohne gemeinsames Ziel, und Qualitätsanforderungen wie Sicherheit oder Barrierefreiheit gehen unter, weil sie in keine einzelne Story passen. Bewährt hat sich deshalb eine Mischung: ein knappes Produktziel und übergreifende Qualitätsanforderungen als Leitplanken, darunter das bewegliche Backlog. Wie das konkret aussieht, behandelt das Seminar Agiles Anforderungsmanagement.

In vielen Unternehmen läuft es in der Praxis hybrid: ein Lastenheft für die Ausschreibung oder den Vertrag, danach agile Umsetzung mit Backlog. Das funktioniert, wenn klar ist, welches Dokument im Zweifel gilt und wie Änderungen gegenüber dem Vertrag behandelt werden.

Werkzeuge für das Anforderungsmanagement: von der Tabelle bis zur Spezialsoftware

Welches Werkzeug passt, hängt vor allem von zwei Fragen ab: Wie viele Anforderungen gibt es, und wie streng muss nachgewiesen werden, dass sie umgesetzt und getestet sind?

• Tabellen und Textdokumente: Für kleine Vorhaben mit wenigen Dutzend Anforderungen reichen Excel oder ein gemeinsames Dokument, wenn Kennungen, Status und Verantwortliche gepflegt werden. Die Grenze ist erreicht, wenn mehrere Personen gleichzeitig ändern oder Versionen auseinanderlaufen.
• Aufgaben- und Entwicklungsplattformen: Jira mit Confluence oder Azure DevOps sind in Softwareteams weit verbreitet. Anforderungen stehen dort als Epics und Stories im Backlog, die Beschreibung im Wiki, die Verbindung zu Entwicklung und Tests ist direkt möglich.
• Spezialisierte Requirements-Management-Systeme: Werkzeuge wie IBM Engineering Requirements Management DOORS Next, Polarion von Siemens, Jama Connect oder Codebeamer von PTC sind auf große, regulierte Vorhaben ausgelegt: lückenlose Verfolgbarkeit, Freigabe-Workflows, Varianten und Austausch mit Zulieferern über das Format ReqIF.
• Modellierungswerkzeuge: etwa Enterprise Architect von Sparx Systems, wenn Anforderungen eng mit Architektur- und Prozessmodellen verbunden werden sollen.

Bei der Auswahl helfen diese Fragen: Lassen sich Anforderungen mit Aufgaben und Tests verknüpfen? Gibt es eine Änderungshistorie? Können Fachabteilungen ohne Schulung lesen und kommentieren? Lassen sich Berichte für Projektleitung oder Prüfer erzeugen? Und: Wo liegen die Daten, und passt das zu den Datenschutzvorgaben des Unternehmens?

Was KI im Anforderungsmanagement leisten kann

Sprachmodelle wie ChatGPT, Microsoft Copilot oder Rovo, die KI-Funktionen in Jira und Confluence, haben auch dieses Feld erreicht. Sinnvolle Einsatzgebiete gibt es einige: Interviewprotokolle zusammenfassen, aus Notizen erste User Stories formulieren, Akzeptanzkriterien vorschlagen, unklare Wörter in Anforderungen markieren oder Testfälle aus Anforderungen ableiten.

Die Einschätzung fällt trotzdem nüchtern aus. Eine KI kennt weder die Interessen der Beteiligten noch die ungeschriebenen Regeln eines Unternehmens. Sie formuliert flüssig, aber flüssig ist nicht gleich richtig: Erfundene Details oder Annahmen, die niemand geäußert hat, schleichen sich leicht ein. Jede KI-gestützte Anforderung braucht deshalb eine fachliche Prüfung. Zudem gilt: Vertrauliche Projektunterlagen gehören nur in KI-Dienste, die das Unternehmen dafür freigegeben hat. Richtig eingesetzt nimmt die KI Schreibarbeit ab, das Klären und Entscheiden bleibt Aufgabe der Menschen.

Typische Fehler und wie Sie sie vermeiden

• Lösungen statt Bedürfnisse: „Wir brauchen ein Dropdown-Menü“ ist eine Lösung. Fragen Sie nach dem Zweck, oft gibt es einen einfacheren Weg.
• Vage Begriffe: „schnell“, „intuitiv“, „flexibel“. Ersetzen Sie sie durch messbare Kriterien.
• Vergessene Beteiligte: Wer erst bei der Abnahme gefragt wird, hat dann meist viele Einwände.
• Keine Priorität: Wenn alles „Muss“ ist, entscheidet am Ende der Zeitdruck statt der Nutzen.
• Änderungen auf Zuruf: Eine Änderung per Mail an einen einzelnen Entwickler ist der Anfang vom Wildwuchs. Legen Sie einen festen Änderungsweg fest.
• Dokumentation ohne Leser: Ein Lastenheft, das niemand liest, ist verschwendete Zeit. Schreiben Sie für die, die damit arbeiten.

Was das für Ihre Projekte bedeutet

Anforderungsmanagement ist keine Spezialdisziplin für Großprojekte, sondern gesunder Menschenverstand mit Methode. Für die meisten Unternehmen lohnt es sich, klein anzufangen: eine Stakeholder-Liste, eine eindeutige Ablage für Anforderungen, Akzeptanzkriterien für jede wichtige Anforderung und ein fester Weg für Änderungen. Das allein verhindert einen großen Teil der Missverständnisse.

Spezialsoftware lohnt sich erst, wenn Umfang oder Nachweispflichten es verlangen. Überschätzt wird oft das Werkzeug, unterschätzt die Fähigkeit, gute Fragen zu stellen und Konflikte zwischen Beteiligten offen anzusprechen. Genau diese Fähigkeit macht gute Business-Analysten und Product Owner aus. Wer sie im Team aufbauen will, findet im Seminar Präzise Anforderungsanalyse und Anforderungsdokumentation einen strukturierten Einstieg.

Häufige Fragen zum Anforderungsmanagement

Was ist der Unterschied zwischen Anforderungsmanagement und Requirements Engineering?

Requirements Engineering ist der Oberbegriff für das Ermitteln, Beschreiben, Prüfen und Verwalten von Anforderungen. Anforderungsmanagement bezeichnet im engeren Sinn den Teil, der sich um Verwaltung, Verfolgbarkeit und Änderungen kümmert. Im Alltag werden beide Begriffe oft gleichbedeutend verwendet.

Wann sollte das Anforderungsmanagement beginnen?

Bereits in der Konzeptphase, bevor Budget und Termin festgelegt werden. Wer erst nach Vertragsschluss genauer hinschaut, verhandelt Änderungen unter Zeitdruck.

Wer ist im Unternehmen für Anforderungen zuständig?

Das hängt vom Vorgehen ab: In agilen Teams der Product Owner, in klassischen Projekten oft Business-Analysten oder Requirements Engineers in Abstimmung mit der Projektleitung. Wichtig ist, dass es eine klar benannte Person gibt.

Welches Tool ist für Anforderungsmanagement am besten geeignet?

Es gibt kein bestes Tool für alle. Für kleine Vorhaben reicht eine gepflegte Tabelle, Softwareteams arbeiten häufig mit Jira oder Azure DevOps, regulierte Branchen mit spezialisierten Systemen. Entscheidend ist, dass Fachabteilung und Entwicklung damit arbeiten können.