Anforderungsdokument (PRD) schreiben, das wirklich hilft

Kurz gefasst: Ein gutes Product Requirements Document (PRD) beschreibt, welches Problem ein Produkt für wen löst, welche Abläufe es dafür unterstützen muss und woran man erkennt, dass es fertig ist. Es ist kurz genug, dass alle Beteiligten es tatsächlich lesen, und präzise genug, dass Entwickler daraus schätzen und bauen können. Die wichtigsten Bestandteile sind Ziel, Zielgruppe, Kernabläufe, klare Abgrenzung und Akzeptanzkriterien. Technische Lösungen gehören meist nicht hinein.

Wozu ein Anforderungsdokument dient

Ein PRD ist die gemeinsame Grundlage für alle, die an einem Softwareprojekt beteiligt sind: Geschäftsführung, Fachabteilung, Design und Entwicklung. Es beantwortet die Frage „Was bauen wir und warum?“, bevor jemand fragt „Wie bauen wir es?“.

Im deutschen Projektalltag begegnen Ihnen auch Lastenheft und Pflichtenheft. Das Lastenheft beschreibt die Anforderungen aus Sicht des Auftraggebers, das Pflichtenheft die geplante Umsetzung durch den Auftragnehmer. Ein PRD liegt inhaltlich nah am Lastenheft, ist aber meist schlanker und wird in agilen Projekten laufend fortgeschrieben, statt einmal unterschrieben und abgeheftet zu werden.

Die Gliederung eines PRD, das funktioniert

Problem und Ziel

Beschreiben Sie in wenigen Sätzen, welches Problem Sie lösen und warum es jetzt gelöst werden soll. Ergänzen Sie, woran Sie Erfolg messen wollen, etwa weniger manuelle Bearbeitungszeit, mehr abgeschlossene Bestellungen oder weniger Supportanfragen. Ohne messbares Ziel lässt sich später nicht sagen, ob das Projekt etwas gebracht hat.

Zielgruppe und Nutzerrollen

Wer nutzt das Produkt, und in welcher Situation? Ein Außendienstmitarbeiter auf dem Smartphone hat andere Bedürfnisse als eine Sachbearbeiterin am Desktop. Nennen Sie die Rollen und ihre Rechte, etwa Admin, Mitarbeiter, Kunde.

Kernabläufe als User Stories

Beschreiben Sie die wichtigsten Abläufe aus Nutzersicht, zum Beispiel: „Als Kunde möchte ich eine Bestellung wiederholen, damit ich nicht alle Artikel neu suchen muss.“ Das Format zwingt dazu, den Nutzen jeder Funktion zu benennen. Für den Hauptablauf lohnt sich zusätzlich eine Skizze oder ein klickbarer Prototyp. Werkzeuge dafür stellen wir im Beitrag zu Prototyping für nicht-technische Gründer vor.

Akzeptanzkriterien

Zu jeder Story gehören Kriterien, an denen man prüfen kann, ob sie umgesetzt ist. „Die Suche ist schnell“ hilft niemandem. „Die Suche zeigt Ergebnisse während der Eingabe und findet Artikel auch über die Artikelnummer“ lässt sich testen.

Abgrenzung: Was nicht dazugehört

Dieser Abschnitt wird am häufigsten vergessen und ist einer der wertvollsten. Halten Sie ausdrücklich fest, was in dieser Version nicht gebaut wird. Das verhindert Missverständnisse bei Angebot und Abnahme und schützt das Projekt vor schleichender Erweiterung des Umfangs.

Rahmenbedingungen

Dazu zählen bestehende Systeme, an die angebunden werden muss, Datenschutzanforderungen, Barrierefreiheit, Sprachen, Zielgeräte und feste Termine. Sie beeinflussen Aufwand und Architektur oft stärker als einzelne Funktionen.

Typische Fehler beim Schreiben

Ein häufiger Fehler ist ein Dokument, das zu lang ist. Fünfzig Seiten liest niemand vollständig, und Widersprüche fallen nicht auf. Ebenso problematisch ist es, Lösungen statt Probleme zu beschreiben: „Wir brauchen eine Microservice-Architektur“ gehört nicht in ein PRD, „Das System muss in Spitzenzeiten viele gleichzeitige Bestellungen verarbeiten“ schon.

Viele PRDs bleiben außerdem bei Annahmen stehen, die nie überprüft wurden. Wenn Sie nicht sicher sind, ob Nutzer eine Funktion wirklich brauchen, sprechen Sie vorher mit ihnen. Wie das geht, zeigt unser Artikel zur Validierung einer Produktidee.

Das PRD im laufenden Projekt

Ein PRD ist kein Vertrag, der danach nie wieder angefasst wird. In agilen Projekten wird es zur Quelle für das Backlog und wächst mit den Erkenntnissen aus jedem Sprint. Wichtig ist, dass Änderungen nachvollziehbar bleiben und eine Person verantwortlich ist, die über Prioritäten entscheidet. Wie diese Zusammenarbeit für Fachabteilungen ohne technischen Hintergrund funktioniert, beschreiben wir im Beitrag Agile Entwicklung für nicht-technische Stakeholder.

Für ein MVP darf das Dokument besonders knapp sein. Ein bis zwei Seiten mit Ziel, Hauptablauf und Abgrenzung genügen oft. Wie daraus in wenigen Wochen ein erstes Produkt wird, zeigt unser Artikel zur MVP-Entwicklung in acht Wochen.

Häufige Fragen (FAQ)

Wie lang sollte ein Product Requirements Document sein?

So kurz wie möglich, so lang wie nötig. Für ein MVP reichen oft ein bis zwei Seiten, für größere Projekte einige Seiten mit Verweisen auf Skizzen und Prototypen. Wenn das Dokument niemand vollständig liest, ist es zu lang.

Was ist der Unterschied zwischen PRD und Lastenheft?

Beide beschreiben Anforderungen aus Sicht des Auftraggebers. Das Lastenheft ist eher formal und oft Vertragsbestandteil, das PRD ist meist schlanker und wird im agilen Projekt laufend weiterentwickelt. In der Praxis verschwimmen die Begriffe.

Muss ich das PRD selbst schreiben?

Die Inhalte müssen von Ihnen kommen, denn Sie kennen das Problem und die Nutzer. Beim Formulieren, Strukturieren und Ergänzen technischer Rahmenbedingungen kann ein Entwicklungspartner helfen. Viele Projekte starten mit einem gemeinsamen Workshop, aus dem das erste PRD entsteht.

Brauche ich ein PRD auch bei agiler Entwicklung?

Ja, in schlanker Form. Agile Entwicklung kommt ohne starre Gesamtspezifikation aus, braucht aber ein gemeinsames Verständnis von Ziel, Nutzern und Abgrenzung. Genau das liefert ein gutes PRD.

Fazit

Ein gutes Anforderungsdokument spart vor allem Gespräche, die sonst zu spät geführt werden: über den Umfang, über Prioritäten und darüber, wann etwas fertig ist. Der Abschnitt „Was nicht dazugehört“ ist dabei oft wertvoller als jede Funktionsliste. Wenn Sie Ihr nächstes Projekt mit einem klaren PRD starten möchten, unterstützen wir Sie im Rahmen unserer Webentwicklung von der Anforderung bis zum Launch.