NIST RMF Requirements Traceability
Learn more about the importance of NIST RMF, what the...
Wie erstellt man das perfekte Produktanforderungsdokument (PRD)?
Ohne klare Vorgaben zu entwickeln, ist der schnellste Weg, ein Produkt zu verzögern.
Teams beginnen oft mit der Produktentwicklung auf der Grundlage unausgereifter Vorgaben oder lückenhafter Rückmeldungen. Sie gehen davon aus, dass Besprechungsprotokolle und Chats ausreichen, um loszulegen. Das tun sie jedoch nicht. Dies führt zu Verwirrung, übersehenen Anwendungsfällen und einem hohen Hin und Her während der Entwicklung.
Ein Produktanforderungsdokument (PRD) wird erstellt, um vor Beginn der Entwicklung Klarheit zu schaffen. Es beschreibt die zu entwickelnden Funktionen, die Probleme, die damit gelöst werden sollen, und was im Endergebnis geliefert werden soll.
Ganz gleich, ob Sie Produktmanager oder Entscheidungsträger sind – dieser Leitfaden hilft Ihnen dabei, zu verstehen, was ein PRD ist, welche wesentlichen Bestandteile es umfasst und wie Sie Schritt für Schritt ein wirkungsvolles PRD erstellen.
Was ist ein Produktanforderungsdokument (PRD)?
Ein PRD (Product Requirements Document) legt klar fest, welches Produkt entwickelt werden soll und warum, bevor die eigentliche Entwicklung beginnt.
Ein gut verfasstes PRD ist keine reine Formalität, sondern dient dazu, den Arbeitsablauf reibungslos und ohne Verwirrung zu gestalten.
Einige der wichtigsten Punkte, die üblicherweise in einem PRD enthalten sind:
- Geschäftsziele
- Welche Funktionen gehören zum aktuellen Funktionsumfang?
- Details zur Benutzererfahrung
- Was sollte vorerst vermieden oder weggelassen werden?
Anschließend nutzen Business-Analysten und andere Teammitglieder das PRD, um ein Dokument mit den Systemanforderungen zu erstellen, in dem die funktionalen und nicht-funktionalen Anforderungen des Systems ausführlich definiert werden.
Wusstest du schon? Man sagt oft: „Ein PRD ist der stille Freund des Produktmanagers.“
Wie sich ein PRD von einem Business Requirements Document (BRD) unterscheidet
Das Besondere | PRD (Produktanforderungsdokument) | BRD (Anforderungsdokument) |
|---|---|---|
Zweck | Es enthält Einzelheiten dazu, wie das Produkt aus Sicht des Endnutzers funktionieren sollte.
| Darin werden die geschäftlichen Ziele, Anforderungen und Erwartungen erläutert, die dem Projekt zugrunde liegen.
|
Inhaltstyp | Funktionale Anforderungen, User Stories, Funktionsumfang und grundlegende Abläufe. | Geschäftliche Herausforderungen, Erwartungen hinsichtlich der Kapitalrendite, Risiken und Kostenbegründungen. |
Detaillierungsgrad | Mittleres Niveau, mit Schwerpunkt auf Funktionen und Nutzerbedürfnissen | Auf hoher Ebene, mit Fokus auf Geschäftsziele und Mehrwert |
Eigentumsverhältnisse | In der Regel von Produktmanagern verfasst | Oft von Business-Analysten oder Projektleitern erstellt |
Zielgruppe | Produktmanager, Designer, Entwickler, Tester | Geschäftspartner, Projektsponsoren, Kunden und manchmal auch Produktteams |
Zeitpunkt | Wird vor und während der Produktkonzeption und -entwicklung eingesetzt | Wird in der Regel erstellt, bevor ein Projekt die Budgetgenehmigung oder den Startschuss erhält |
Ausgabe im Fokus | Was soll entwickelt werden und warum ist das für die Nutzer wichtig? | Warum das Projekt für das Unternehmen wichtig ist und welche Ergebnisse erwartet werden |
Wesentliche Bestandteile eines Produktanforderungsdokuments
Es gibt keine festgelegten Bestandteile, die Sie im Produktanforderungsdokument verwenden sollten.
Auf dem folgenden Bild sehen Sie die Listen der Komponenten, die ein leitender Projektmanager verwendet:
Hier haben wir einige häufig verwendete Elemente zur Erstellung eines PRD aufgelistet:
- Zweck: Legen Sie fest , warum das Produkt entwickelt wird, wer es nutzen wird, welches Problem es löst und inwiefern es mit den Unternehmenszielen im Einklang steht.
- Funktionen: Beschreiben Sie die wichtigsten Funktionen des Produkts. Halten Sie außerdem die detaillierten Anforderungen fest.
- Umfang: Hier wird aufgeführt, was in dieser Version enthalten ist. In manchen Fällen wird hier auch erwähnt, was nicht enthalten ist.
- Projektzeitplan: Geben Sie den voraussichtlichen Zeitplan für jeden Meilenstein an.
- Offene Fragen: Dinge , die noch nicht entschieden sind. Indem man sie sichtbar hält, kann das Team spätere Verwirrung vermeiden.
So verfassen Sie ein Produktanforderungsdokument (Schritt für Schritt)
Das Hauptziel beim Verfassen des PRD besteht darin, das Produkt- und Entwicklungsteam auf ein gemeinsames Ziel auszurichten. Teams können den unten aufgeführten schrittweisen Prozess befolgen, um ein fundiertes PRD-Dokument zu erstellen:
1. Beginne mit dem Problem, nicht mit der Lösung
Fassen Sie zu Beginn das Problem zusammen und erläutern Sie, warum Sie das Produkt entwickeln.
- Beispiel: „Nutzer brechen den Bestellvorgang ab, weil keine Anmeldung als Gast möglich ist.“
Ein Satz wie dieser verdeutlicht den Zweck der Funktion. Ist das Problem nicht klar, wird die Funktion wahrscheinlich ihr Ziel verfehlen.
2. Formulieren Sie die Ziele in einfacher Sprache
Verzichten Sie hier auf überflüssige Formulierungen. Bringen Sie direkt auf den Punkt, was das Produkt oder die Funktion leisten soll. Ein oder zwei Zeilen reichen aus.
- Beispiel: „Ermöglichen Sie es den Nutzern, Einkäufe abzuschließen, ohne ein Konto anzulegen.“
Das hilft dem Team, sich zu konzentrieren. Wenn später zusätzliche Punkte hinzukommen, können diese gegen das ursprüngliche Ziel abgewogen werden.
3. Legen Sie fest, was zum Umfang gehört und was nicht
Legen Sie außerdem fest, was im Umfang des Produkts enthalten ist und was nicht. So wissen die Teams, welche Funktionen in der nächsten Version enthalten sind und welche nicht.
- Zum Beispiel:
- Im Umfang enthalten: Gastanmeldung hinzufügen, Bestätigungs-E-Mail versenden.
- Nicht im Umfang enthalten: Speichern von Benutzerdaten für zukünftige Besuche.
Kleine Notizen wie diese verhindern spätere Missverständnisse.
4. Funktionen auflisten
Schreiben Sie nun auf, was das System tun soll. Formulieren Sie kurze, klare Punkte. Achten Sie auf eine einfache und prägnante Sprache.
Beispiel:
- Wenn der Benutzer „Als Gast zur Kasse gehen“ wählt, überspringe die Kontoerstellung
- Die E-Mail-Adresse muss vor der Zahlung erfasst werden
- Die Auftragsbestätigung muss innerhalb von 5 Minuten versandt werden
Achten Sie außerdem darauf, die übergeordneten funktionalen und nicht-funktionalen Anforderungen klar zu definieren.
5. Fügen Sie den Zeitplan für die Produktveröffentlichung hinzu
Niemand kann den genauen Zeitplan für die Fertigstellung des Produkts vorgeben. Sie können jedoch den voraussichtlichen Zeitrahmen für die Fertigstellung der einzelnen Funktionen des Releases festlegen. Anhand dieser Zeitpläne können die Entwicklungsteams die Entwicklung der Funktionen priorisieren.
Beispiel:
- Die Social-Login-Funktion sollte innerhalb der ersten fünf Werktage implementiert werden.
- Änderungen an der Zahlungs-API werden für nächsten Monat erwartet
Wenn man dies frühzeitig beachtet, lassen sich spätere Überraschungen vermeiden.
6. Erfolgskriterien festlegen
Legen Sie in diesem Abschnitt die Kriterien fest, anhand derer die Teams erkennen können, ob das Produkt fertiggestellt und für die Kunden bereit ist.
Zum Beispiel:
- 100 % der gültigen Benutzertransaktionen (Anmeldung/Abmeldung) wurden fehlerfrei verarbeitet.
- Es gab keine Sicherheitsverletzungen im Zusammenhang mit unbefugtem Zugriff auf Konten.
7. Überprüfung durch die Interessengruppen
Sobald das Dokument erstellt ist, sollten alle Beteiligten es gemeinsam prüfen. Auf diese Weise können die Teams sicherstellen, dass keine Funktionen fehlen und alle Teammitglieder auf dem gleichen Stand sind.
Ein PRD wird nicht einmalig erstellt und dann vergessen. Die Teams sollten es fortlaufend aktualisieren, wenn sich die Anforderungen ändern.
Laden Sie das PRD-Demodokument hier herunter.
Erstellung von PRDs mit Modern Requirements
Das Verfassen von PRDs in Microsoft Word mag zunächst praktisch erscheinen, doch sobald Teams wachsen oder sich Änderungen häufen, wird es oft chaotisch. Es gibt keine Versionsverfolgung. Überprüfungen finden per E-Mail statt. Vorlagen werden kopiert und manuell bearbeitet, was das Risiko erhöht, dass etwas übersehen wird.
An dieser Stelle sollte der Einsatz eines geeigneten Tools für das Anforderungsmanagement in Betracht gezogen werden.
Mit Modern Requirements4DevOps können Teams die Smart Docs nutzen, um PRDs direkt in Azure DevOps selbst zu erstellen. Um ein PRD zu erstellen, können Sie die vordefinierten Meta-Vorlagen verwenden oder eine neue Vorlage erstellen, wie im folgenden Video gezeigt.
Diese Meta-Vorlage kann immer wieder verwendet werden.
Darüber hinaus bietet es einen Editor, der dem von Microsoft Word ähnelt und die Bearbeitung des Dokuments erleichtert. Die folgenden Videos zeigen, wie Sie ein Dokument erstellen und Azure-Arbeitselemente in Ihr PRD einbetten können.
Darüber hinaus bietet es eine Versionsverwaltung, um verschiedene Versionen des Dokuments nachzuverfolgen, sowie ein Überprüfungsmanagementsystem, um das Dokument gemeinsam zu überprüfen.
Mit der Zeit hilft Smart Docs Teams dabei, schneller zu schreiben, Texte besser zu überprüfen und auf dem Laufenden zu bleiben, ohne zwischen verschiedenen Tools wechseln zu müssen.
Inhaltsverzeichnis
Aktuelle Artikel
NERC CIP Compliance Traceability for Energy & Utility Organizations
Learn more about the NERC IP compliance, which industries is...
The Future of AI in Enterprise: How Agentic Systems Are Transforming Work
Artificial Intelligence (AI) is no longer a distant dream; it's...
