Die Dokumentation der Anforderungen beschreibt, wie einzelne Anforderungen den geschäftlichen Bedarf des Projekts erfüllen sollen. Sie hält fest, was das Produkt leisten muss und warum, und zwar so präzise, dass jemand danach bauen und jemand anderes danach prüfen kann.
Anforderungen sind zunächst meist allgemein formuliert und werden detaillierter, je mehr über sie bekannt ist. Das ist normal. Nicht verhandelbar ist der Zustand, den sie erreicht haben müssen, bevor sie als Baseline festgelegt werden: Anforderungen müssen eindeutig (messbar und testbar), nachverfolgbar, vollständig, einheitlich und für wichtige Stakeholder akzeptabel sein. Diese fünf Kriterien sind der Abnahmetest für das Dokument selbst. Eine Anforderung, die niemand messen kann, ist eine Meinung. Eine, der niemand zugestimmt hat, ist eine Vermutung.
Arten von Anforderungen
Viele Organisationen unterscheiden nur zwischen geschäftlichen und technischen Anforderungen. Der PMBOK Guide klassifiziert feiner, und das lohnt sich, weil die meisten Streitigkeiten über Anforderungen sich als Gespräch über zwei verschiedene Kategorien entpuppen:
- Geschäftliche Anforderungen. Die strategischen Ziele und übergeordneten Bedürfnisse der Organisation, ausgerichtet auf die allgemeineren Organisationsziele.
- Stakeholder-Anforderungen. Die Bedürfnisse einer bestimmten Person oder Gruppe.
- Lösungsanforderungen. Features, Funktionen und Merkmale, die die geschäftlichen und die Stakeholder-Bedürfnisse erfüllen. Sie teilen sich weiter auf in funktionale Anforderungen (das Verhalten des Produkts: Aktionen, Prozesse, Daten, Interaktionen) und nichtfunktionale Anforderungen (Leistungs-, Sicherheits- und Betriebskriterien wie Zuverlässigkeit, Servicelevel, Unterstützungsfähigkeit, Aufbewahrung und Löschung).
- Übergangs- und Bereitschaftsanforderungen. Temporäre Fähigkeiten für den Weg vom Ist- zum Soll-Zustand: Datenumwandlung, Schulung, Parallelbetrieb.
- Projektanforderungen. Bedingungen, die das Projekt selbst erfüllen muss: Meilensteintermine, vertragliche Verpflichtungen, Einschränkungen.
- Qualitätsanforderungen. Bedingungen oder Kriterien, um den erfolgreichen Abschluss eines Liefergegenstands zu überprüfen: Tests, Zertifizierungen, Validierungen.
Vergessen werden regelmäßig die nichtfunktionalen und die Übergangsanforderungen, und genau die kippen Inbetriebnahmen. Ein System, das alles kann, was die Funktionsliste verlangt, dabei aber die Hälfte des nötigen Durchsatzes schafft und keinen Migrationsplan hat, erfüllt seine Anforderungsdokumentation und scheitert am Projekt.
Form, und was es nicht ist
Das Format kann von einem einfachen Dokument, das alle Anforderungen nach Stakeholder und Priorität kategorisiert, bis zu komplexen Dokumenten mit Zusammenfassung für die Geschäftsleitung, detaillierten Beschreibungen und Anhängen reichen. Auch statische oder dynamische grafische Informationen sind zulässig: Bildschirmabläufe, Zustandsdiagramme, Mockups. Eine Pflichtvorlage gibt es nicht. Der ehrliche Test lautet deshalb: Würden eine Entwicklerin und ein Tester, die denselben Eintrag lesen, dasselbe bauen und dasselbe prüfen?
Die Dokumentation der Anforderungen ist weder der Anforderungsmanagementplan (der beschreibt, wie Anforderungen analysiert, dokumentiert und verwaltet werden) noch die Anforderungsrückverfolgungsmatrix (die jede Anforderung von ihrem Ursprung bis zum erfüllenden Liefergegenstand verknüpft) noch die Beschreibung des Projektinhalts und -umfangs. Letztere arbeitet das aus, was im Projektauftrag und in der Dokumentation der Anforderungen beschrieben ist. Die Anforderungen kommen also zuerst, der Scope folgt daraus, nicht umgekehrt.
Einordnung in PMBOK 8
Dieser Begriff steht fest in der 8. Ausgabe. Er hat einen eigenen Eintrag in Abschnitt 4, Inputs und Outputs (Seite 130 f.) und wird als Projektdokument neben Änderungsprotokoll, Problemprotokoll, Projektterminplan, Scope-Beschreibung, Risikoregister und Stakeholder-Register genannt.
Wo er auftaucht:
- Output von „Anforderungen ermitteln und analysieren“ (Abbildung 2-15). Der Prozessname ist neu: In der 6. Ausgabe hieß er „Anforderungen sammeln“. Die Umbenennung ist Absicht. Anforderungen liegen nicht herum und warten darauf, eingesammelt zu werden, sie müssen herausgearbeitet und analysiert werden. Als Werkzeuge nennt der Leitfaden unter anderem Interviews, Fokusgruppen, Fragebögen und Umfragen, Benchmarking, Brainstorming, Dokumentenanalyse, Design Thinking und Priorisierung.
- Input von Scope definieren, wo daraus die Scope-Beschreibung entsteht und die aktualisierte Anforderungsdokumentation selbst wieder als Output steht.
- Input von „Scope überwachen und steuern“, wo Liefergegenstände dagegen geprüft werden und zu verifizierten Liefergegenständen werden.
- Input in weiteren Leistungsdomänen — die Dokumentation taucht in den Abbildungen zu Scope-Management planen, Beschaffungsstrategie, Projektarbeit managen, Risiken identifizieren, den Stakeholder-Prozessen und Projekt oder Phase abschließen auf. Wenige Dokumente der 8. Ausgabe werden von so vielen Prozessen referenziert.
In adaptiven Umgebungen, so der Leitfaden, werden Anforderungen als User Stories erfasst und anschließend in einem Backlog priorisiert. Dasselbe Artefakt in einem anderen Behälter, mit der Detaillierung so lange aufgeschoben, bis der Eintrag nach oben rückt.
Häufige Fragen
Dokumentation der Anforderungen oder Anforderungsdokument?
PMI spricht bewusst von Dokumentation: Das kann ein Dokument sein, ein Satz von Dokumenten, eine Werkzeugdatenbank oder ein Backlog. Der Begriff meint den Inhalt, nicht die Datei.
Wann werden Anforderungen als Baseline festgelegt?
Sobald sie eindeutig, nachverfolgbar, vollständig, einheitlich und von den wichtigen Stakeholdern akzeptiert sind. Danach laufen Änderungen über die Änderungssteuerung, und genau dieser Mechanismus macht schleichenden Scope-Zuwachs sichtbar, statt ihn beiläufig geschehen zu lassen.
Brauchen agile Projekte eine Anforderungsdokumentation?
Sie brauchen Anforderungen und schieben die Dokumentation auf. Ein Backlog-Eintrag mit Abnahmekriterien ist Anforderungsdokumentation mit kurzer Haltbarkeit. Unterdokumentiert bleiben in agilen Teams vor allem nichtfunktionale und Übergangsanforderungen, weil sie sich schlecht in eine User Story pressen lassen. Die gehören separat aufgeschrieben.
Wie detailliert muss es sein?
Detailliert genug, um testbar zu sein, mehr nicht. Nützliche Probe: Lassen sich die Abnahmekriterien direkt aus diesem Eintrag schreiben? Wenn nein, ist er nicht fertig. Wenn schon die Umsetzung vorgeschrieben wird, ist man über die Anforderung hinaus im Entwurf gelandet.
Wer ist verantwortlich?
Die Business-Analystin, wo es die Rolle gibt, sonst die Projektleitung. Die Verantwortung für den Inhalt bleibt aber bei den anfordernden Stakeholdern. Die Zustimmung ist keine Formalie, sie ist das, was eine Anforderung im Sinne des Leitfadens überhaupt erst akzeptabel macht.
Autor: Tom, seit 2004 PMP-zertifiziert. Zuletzt aktualisiert: August 2026