Produktanforderungen

Zweck

Dieser Skill steuert, wie du sämtliche Artefakte für Produktanforderungen entwirfst, prüfst und strukturierst. Er liefert verbindliche Vorlagen, Entscheidungslogik und Qualitätsgates — keine allgemeinen Schreibtipps. Jede Ausgabe muss nachvollziehbar, eindeutig und für Engineering, Design und QA umsetzbar sein.

Clarification — When to Ask

Frage nur dann vorab nach, wenn:

• Der Artefakttyp unklar ist → „Entwirfst du ein vollständiges PRD, eine einzelne User Story oder eine abgegrenzte Feature-Spec?"

• Die Zielgruppe unklar ist → „Ist das für ein Engineering-Review, eine Freigabe durch Stakeholder oder für Backlog-Grooming gedacht?"

• Kontext fehlt (kein Produktbereich, keine Problembeschreibung) → „Welches Problem wird damit gelöst, und wer ist betroffen?"

Frage nie nach:

• Bevorzugtem Format — wende immer die in diesem Skill definierten Vorlagen an

• Detailtiefe — erzeuge immer vollständige Artefakte; kennzeichne fehlende Informationen direkt im Text mit [TBD: Grund]

• Ob Non-Goals enthalten sein sollen — immer enthalten; sie sind verpflichtend

Standards für Artefakte

1. Product Requirements Document (PRD)

Verwenden für: neue Features, größere Produktänderungen, funktionsübergreifende Initiativen.

Pflichtabschnitte — immer alle enthalten:

## Überblick
Ein Absatz. Nenne: was das ist, warum es existiert und wie Erfolg aussieht. Kein technischer Fachjargon. Geschrieben für Stakeholder ohne Engineering-Hintergrund.

## Problemstellung

• Wer ist betroffen? (Nutzersegment oder Persona)

• Worin besteht der Schmerzpunkt oder die Chance?

• Welche Belege stützen das? (Daten, Nutzerforschung, Support-Tickets, betriebswirtschaftliches Signal)

• Was passiert, wenn wir es nicht lösen?

## Ziele
Liste 3–5 konkrete, messbare Ergebnisse. Jedes Ziel muss beantworten: Woran erkennen wir, dass wir erfolgreich waren?

Format:

• Ziel: [Ergebnisaussage] — Kennzahl: [Wie wird gemessen] — Zielwert: [Schwelle oder Wert]

## Non-Goals
Benenne ausdrücklich, was dieses PRD NICHT abdeckt. Jedes PRD muss mindestens 2 Non-Goals enthalten. Non-Goals verhindern Scope Creep und richten Stakeholder aus, bevor die Arbeit beginnt.

Format:

• Nicht im Umfang: [Thema] — Grund: [Warum das jetzt ausgeschlossen ist]

## User Stories
Siehe die User-Story-Standards unten. Enthalte alle Stories, die zur Erreichung der Ziele nötig sind.

## Akzeptanzkriterien
Siehe die Standards für Akzeptanzkriterien unten. Verknüpfe jedes Kriterium mit einer User Story.

## Umfang & Abgrenzung
Definiere, was für dieses Release im Umfang ist. Unterscheide dabei ausdrücklich zwischen MVP-Umfang und späterem Umfang.

## Entscheidungsprotokoll
Siehe die Standards zur Entscheidungslogik unten.

## Offene Fragen
Liste ungeklärte Fragen auf, die Entscheidungen blockieren oder beeinflussen. Jede braucht eine verantwortliche Person und eine Frist zur Klärung.

## Abhängigkeiten
Liste Teams, Systeme oder externe Faktoren auf, von denen dieses PRD abhängt.

## Launch-Kriterien
Definiere die Mindestbedingungen, die vor dem Livegang erfüllt sein müssen. Sie sind binär — erfüllt oder nicht erfüllt.

2. User Stories

Verbindliches Format:

Als [konkreter Nutzertyp]
möchte ich [Aktion oder Fähigkeit],
damit [konkreter Nutzen oder Ergebnis].

Qualitätsregeln — alle durchsetzen:

• „Nutzer" ist als Akteur niemals akzeptabel. Verwende eine konkrete Persona oder Rolle (z. B. „Account-Admin", „Erstkäuferin", „Support-Agent").

• Der Nutzen muss ein echtes Ergebnis sein, keine Wiederholung der Aktion. „Damit ich das Feature nutzen kann" wird abgelehnt.

• Jede Story muss eigenständig lieferbar sein. Wenn sie nicht allein ausgeliefert werden kann, ist sie ein Epic — zerlege sie.

• Jede Story bildet genau einen primären Nutzertyp ab. Stories mit mehreren Akteuren müssen aufgeteilt werden.

• Stories müssen geschätzt sein. Vergib ein relatives Aufwandslabel: XS / S / M / L / XL. Alles mit XL muss vor Aufnahme in einen Sprint in kleinere Stories zerlegt werden.

Konvention für User-Story-IDs:
Vergib fortlaufende IDs: US-001, US-002 usw. Referenziere diese IDs in den Akzeptanzkriterien und im Entscheidungsprotokoll.

Beispiel für eine gut formulierte User Story:

Als Finanzmanager
möchte ich Rechnungen als gefilterten PDF-Report exportieren,
damit ich dem CFO eine monatliche Kostenübersicht ohne manuelle Dateneingabe vorlegen kann.
Größe: M | ID: US-007

Beispiel für eine abgelehnte User Story:

Als Nutzer möchte ich meine Daten sehen, damit ich die Plattform nutzen kann.
Grund: Akteur ist generisch, Nutzen ist eine Tautologie, Umfang ist undefiniert.

3. Akzeptanzkriterien

Verbindliches Format — Given/When/Then verwenden (Gherkin-Stil):

Given [Vorbedingung oder Kontext],
When [Aktion oder Ereignis],
Then [erwartetes Ergebnis — beobachtbar und überprüfbar].

Qualitätsregeln:

• Jedes Kriterium muss von einem QA-Engineer ohne Interpretationsspielraum testbar sein. Wenn zur Bewertung ein Ermessen nötig ist, formuliere es neu.

• Vermeide „sollte", „üblicherweise", „häufig", „kann" — verwende „muss", „tut", „gibt zurück", „zeigt an".

• Enthalte je User Story sowohl den Happy Path als auch mindestens einen Edge Case oder Fehlerpfad.

• Akzeptanzkriterien sind mit User-Story-IDs verknüpft: kennzeichne jeden Block mit der zugehörigen US-XXX.

Beispiel — Happy Path (US-007):

Given die nutzende Person hat die Rolle Finanzmanager und im gewählten Zeitraum existiert mindestens eine Rechnung,
When sie auf „PDF exportieren" klickt und die Filtereinstellungen bestätigt,
Then wird innerhalb von 5 Sekunden ein PDF erzeugt, das ausschließlich die zum Filter passenden Rechnungen enthält und mit Firmenlogo und Seitenzahlen formatiert ist.

Beispiel — Edge Case (US-007):

Given die nutzende Person wählt einen Zeitraum ohne passende Rechnungen,
When sie auf „PDF exportieren" klickt,
Then zeigt das System eine Inline-Meldung an: „Für den gewählten Zeitraum wurden keine Rechnungen gefunden. Bitte passe die Filter an." und es wird kein PDF erzeugt.

4. Umfang & Non-Goals

Umfang beantwortet: Was wird in diesem Release gebaut?
Non-Goals beantworten: Was wird ausdrücklich NICHT gebaut, und warum?

Beides ist verpflichtend. Non-Goals wegzulassen ist ein Qualitätsmangel — sie existieren, damit implizite Annahmen nicht zu ungeplanter Arbeit werden.

Regeln für die Umfangsdefinition:

• Umfangspunkte müssen so kleinteilig sein, dass sie geschätzt und zugewiesen werden können.

• Jeder Umfangspunkt muss auf mindestens eine User Story zurückführbar sein.

• Alles, was „nice to have" ist, muss ausdrücklich in den späteren Umfang verschoben und nicht unklar gelassen werden.

Regeln für Non-Goals:

• Jedes Non-Goal muss einen Grund nennen (technisch, strategisch, zeitlich oder ressourcenbedingt).

• Non-Goals sind keine dauerhaften Absagen — setze einen Hinweis, wenn der Punkt Kandidat für ein späteres Release ist: [Kandidat für v2].

• Typische Non-Goal-Kategorien, die immer zu prüfen sind: Performance-Optimierung über die MVP-Schwelle hinaus, Internationalisierung/Lokalisierung, Admin-Tooling, Analytics/Reporting über die Kernkennzahlen hinaus, Feature-Parität auf Mobile (bei Web-First), Drittanbieter-Integrationen außerhalb des kritischen Pfads.

5. Entscheidungslogik

Das Entscheidungsprotokoll hält alle wesentlichen Produktentscheidungen im Lebenszyklus des PRD fest. Es existiert, um bereits geklärte Fragen nicht erneut aufzurollen und späteren Beteiligten Kontext zu geben.

Wann eine Entscheidung zu protokollieren ist:

• Ein Design- oder Umfangs-Tradeoff wurde getroffen

• Eine Alternative wurde geprüft und verworfen

• Eine Meinungsverschiedenheit zwischen Stakeholdern wurde geklärt

• Eine technische Einschränkung hat eine Produktentscheidung beeinflusst

• Ein Non-Goal wurde bewusst zurückgestellt statt dauerhaft ausgeschlossen

Verbindliches Format je Entscheidung:

Beispiel:

Process — Which Artifact to Produce

Folge diesem Entscheidungsbaum, wenn die Anfrage mehrdeutig ist:

• Neues Feature oder neue Initiative, funktionsübergreifende Wirkung → vollständiges PRD (alle Abschnitte)

• Einzelnes zusätzliches Feature, ein Team → schlankes PRD (Problemstellung, Ziele, Non-Goals, User Stories, Akzeptanzkriterien, Umfangstabelle)

• Bestehendes Ticket oder Backlog-Item, das Detaillierung braucht → nur User Stories + Akzeptanzkriterien

• Frage zu Umfang oder Abgrenzung → nur Umfangstabelle + Abschnitt Non-Goals

• Vergangene Entscheidung soll dokumentiert werden → nur Eintrag im Entscheidungsprotokoll

• Vollständiges Audit oder Review eines bestehenden PRD → wende alle Qualitätsregeln Abschnitt für Abschnitt an; kennzeichne jeden Verstoß mit [Problem]: [Erforderliche Korrektur]

Output Format Rules

• Verwende durchgängig Markdown. Alle Tabellen müssen korrekt rendern.

• Jede Abschnittsüberschrift ist eine ##- oder ###-Überschrift — niemals Fettschrift als Ersatz für Überschriften.

• Kennzeichne alle fehlenden Informationen direkt im Text mit [TBD: <was benötigt wird und warum>] — lasse erforderliche Inhalte niemals stillschweigend weg.

• Verwende keine Füllsprache („Dieser Abschnitt behandelt...", „Wie oben erwähnt..."). Jeder Satz muss Information tragen.

• Wenn du ein vollständiges PRD erstellst, liefere es via create_text_document als strukturiertes Artefakt aus.

• Wenn du eine einzelne User Story oder ein einzelnes Akzeptanzkriterium erstellst, gib es direkt im Chat aus, sofern kein Dokument angefragt wurde.

Quality Gate — Before Delivering Any Artifact

Prüfe jede Ausgabe gegen diese Liste. Behebe Verstöße vor dem Antworten.

• Alle Pflichtabschnitte des PRD vorhanden (bei vollständigem PRD)

• Jede User Story hat einen konkreten Akteur, eine konkrete Aktion und einen echten Nutzen

• Jede User Story hat ein Größenlabel und eine ID

• Jedes Akzeptanzkriterium ist ohne Interpretationsspielraum testbar

• Mindestens ein Edge Case oder Fehlerpfad je User Story

• Der Abschnitt Non-Goals hat mindestens 2 Einträge mit Begründung

• Die Umfangstabelle unterscheidet dieses Release von späteren Releases

• Einträge im Entscheidungsprotokoll enthalten geprüfte Alternativen und Begründung

• Keine offene Frage ohne verantwortliche Person und Frist

• Keine [TBD]-Marker ohne Erläuterung, was benötigt wird