kelegele/oh-my-pm

PRD-Erstellung

Erstellen Sie strukturierte Product Requirements Documents aus Feature-Ideen.

Was diese Fähigkeit tut

Wandelt informelle Funktionsanfragen in vollständige PRDs mit User Stories, Abnahmekriterien, funktionalen Anforderungen, Erfolgsmetriken und Compliance-Hinweisen um. Die Ausgabe ist bereit für die Umsetzung durch Entwicklungsteams und die Überprüfung durch Stakeholder.

Wann verwenden

Aktivieren Sie diese Fähigkeit, wenn:

• Der Benutzer ein neues Feature oder eine Produktidee dokumentieren möchte
• Formulierungen wie „PRD schreiben", „Anforderungen erstellen", „dieses Feature dokumentieren" verwendet werden
• Vorbereitung auf Produkt-Review, Stakeholder-Abstimmung oder Entwickler-Übergabe
• Der Benutzer User Stories, Abnahmekriterien oder Erfolgsmetriken erwähnt
• Eine grobe Idee in eine strukturierte Dokumentation formalisiert werden muss

Szenarioerkennung (KRITISCH – Erster Schritt)

Bevor Sie PRD-Inhalte generieren, MÜSSEN Sie das Szenario identifizieren.

Verwenden Sie AskUserQuestion, um zu bestimmen, welches Szenario zutrifft:

Q: Bitte wählen Sie das PRD-Erstellungsszenario

Option	Beschreibung
Iterations-Update	Iterative Optimierung basierend auf bestehenden Funktionen
Neue Funktion	Neues Modul zu einem bestehenden Produkt hinzufügen
0-1 Neues Produkt	Ein völlig neues Produkt von Grund auf planen

Kontexterfassung nach Szenario

Sobald das Szenario identifiziert ist, sammeln Sie den erforderlichen Kontext:

Szenario	Erforderliche Informationen	Erfassungsmethode
Iterations-Update	1. Aktuelle Funktionsbeschreibung2. UI-Zustand (Screenshot/HTML/Link)3. Iterationsziele	Benutzereingabe + AskUserQuestion für UI-Zustandsoption
Neue Funktion	1. Gesamtproduktarchitektur2. Designrichtlinien (Komponentenbibliothek/Interaktionsmuster)3. Einstiegspunkt	Lesen aus docs/product/ oder Benutzereingabe
0-1 Neues Produkt	1. Produkthintergrund und Zielnutzer2. Ressourcenbeschränkungen3. Referenzprodukte	Benutzereingabe + Wettbewerbsanalyse

UI-Zustandserfassung für Iterations-Updates: Wenn der Benutzer „Iterations-Update" auswählt, fragen Sie, wie er den aktuellen UI-Zustand bereitstellen möchte:

• Screenshot – Benutzer stellt Screenshot bereit, verwenden Sie mcp__zai-mcp-server__ui_to_artifact oder mcp__4_5v_mcp__analyze_image
• HTML-Datei – Benutzer gibt lokalen HTML-Pfad an, verwenden Sie das Read-Tool zum Parsen der DOM-Struktur
• Online-Link – Benutzer gibt URL an, verwenden Sie mcp__web_reader__webReader (kein Login erforderlich)

Schritt 0.5: Informationslückenanalyse und PRD-Plan (KRITISCH – HARTE SCHRANKE)

HARTE SCHRANKE: Fahren Sie NICHT mit der Branchenbenchmark-Prüfung oder PRD-Erstellung fort, bis dieser Schritt abgeschlossen ist und der Benutzer den Plan genehmigt hat.

Explizites-Skip-Protokoll (bei expliziter Benutzerverweigerung der Interaktion): Wenn der Benutzer Fragen explizit verbietet (z. B. „Frag nicht, schreib einfach"), DÜRFEN Sie die interaktiven Schranken überspringen – aber dann MÜSSEN Sie die Ausgabe mit einem Annahmenblock beginnen, der jede getroffene Annahme auflistet (Szenario, ausgewählte/ausgeschlossene Kapitel, Zielprodukt, wichtigste Standardwerte), damit der Benutzer sie korrigieren kann. Der Annahmenblock dient gleichzeitig als Vollständigkeitsliste der Evidenzdisziplin: Nicht bestätigte Informationen als [Ausstehende Bestätigung] kennzeichnen, Behauptungen ohne Belege als [Nicht verifiziert] kennzeichnen (siehe Evidenzdisziplin unten). Überspringen Sie nicht stillschweigend.

Nach Szenarioerkennung und Kontexterfassung:

1. Lückenanalyse: Vergleichen Sie die vom Benutzer bereitgestellten Informationen mit den „Kontextanforderungen" für dieses Szenario. Listen Sie jedes fehlende Pflichtfeld auf. Überprüfen Sie auch docs/product/ auf vorhandene Wahrnehmungsdaten (market-analysis.json, competitive-analysis, user-research.json, positioning.md).

2. Eine Frage nach der anderen: Fragen Sie den Benutzer für jedes fehlende Element mit AskUserQuestion und Multiple-Choice-Optionen. Bündeln Sie NICHT mehrere Fragen in einer Nachricht.

   Fehlendes Element	Beispielhafte Frage
   UI-Screenshot	„Wie möchten Sie den UI-Zustand bereitstellen?" → A. Screenshot vorhanden B. HTML-Datei vorhanden C. Online-Link vorhanden D. Nicht vorhanden, vorerst überspringen
   Wettbewerberliste	„Welche Wettbewerber sollen analysiert werden?" → Multi-Select + „Andere"
   Zielnutzer	„Wer sind die Zielnutzer?" → A. Bereits definierte Persona B. Ich erzähle, Sie fassen zusammen C. Zuerst Benutzerforschung nötig
   Referenzprodukte	„Gibt es Referenzprodukte?" → A. Ja, ich nenne sie B. Sie suchen Branchen-Benchmarks für mich C. Keine Referenz nötig

3. Fehlende Ressourcen behandeln: Wenn der Benutzer sagt „Ich stelle Screenshots später bereit" oder „vorerst überspringen", notieren Sie, welche Elemente ausstehend sind, und vermerken Sie sie im PRD-Plan als [Ausstehend].

4. PRD-Plan generieren: Bereiten Sie die PRD-Planstruktur vor (noch nicht anzeigen). Die folgende Tabelle zeigt die Vorlage mit Standardauswahlen:

   ### Voraussichtliche PRD-Kapitel
   | Kapitel | Inhaltsübersicht | Ausgewählt | Abhängigkeitsstatus |
   |:-----|:---------|:-----|:---------|
   | Kapitel 0 Branchen-Benchmark-Analyse | Untersuchung von X Benchmark-Produkten | ✅ | Abgeschlossen / [Ausstehend] |
   | Kapitel 1 Projektübersicht | Basierend auf Benutzerbeschreibung | ✅ | Abgeschlossen |
   | Kapitel 2 Geschäftsanalyse | Zielnutzer X, Schmerzpunkte Y | ✅ | Abgeschlossen / [Ausstehend] |
   | Kapitel 3 Funktionale Anforderungen | [Liste der Kernfunktionen] | ✅ | Abgeschlossen |
   | Kapitel 4 Nicht-funktionale Anforderungen | Branchenstandardanforderungen | ✅ | Automatisch generiert |
   | Kapitel 5 Benutzererfahrungsprozess | Basierend auf Funktionsableitung | ✅ | UI-Ergänzung nötig |
   | Kapitel 6 Projektrisiken | Basierend auf Funktionskomplexität | ✅ | Automatisch generiert |
   | Kapitel 7 Compliance-Empfehlungen | Basierend auf Datentypen | ❌ | Automatisch generiert |
   | Kapitel 8 Prototyp-Design | [Prototyp-Link] | ❌ | - |
   | Kapitel 9 Erfolgsmetriken | Basierend auf Zielableitung | ❌ | Automatisch generiert |
   
   ### Ausschlussliste (folgende Inhalte werden NICHT generiert)
   - Technisches Konzept / Architekturdesign – PRD ist ein Produktanforderungsdokument, enthält keine technischen Implementierungsdetails
   - API-Schnittstellendefinition / Endpunktspezifikationen – werden vom Entwicklungsteam im technischen Konzept separat geschrieben
   - Datenbanktabellenstrukturdesign – liegt nicht im Produktanforderungsbereich
   

   Hinweis: Die obige Tabelle verwendet Standardauswahlen. Die tatsächlichen „Ausgewählt"-Werte werden in Schritt 4.5 basierend auf den Antworten des Benutzers zur Kapitelauswahl gefüllt. Präsentieren Sie diese Tabelle dem Benutzer noch NICHT.

4.5. Kapitelauswahl (HARTE SCHRANKE – Vor Präsentation des PRD-Plans):

Präsentieren Sie dem Benutzer die Kapitelauswahl über AskUserQuestion mit MultiSelect. Aufgrund des 4-Optionen-Limits teilen Sie dies in 3 aufeinanderfolgende Fragen auf. Erstellen Sie die Listen selected_chapters und excluded_chapters aus den Antworten und aktualisieren Sie die Spalte „Ausgewählt" der PRD-Plantabelle entsprechend.

Frage 1 – Kernkapitel (Kapitel 0-3):

Option	Standard	Beschreibung
Kapitel 0 Branchen-Benchmark-Analyse	✅ Ausgewählt	Benchmark-Produkte und Best Practices recherchieren
Kapitel 1 Projektübersicht	✅ Ausgewählt	Projekthintergrund, Ziele, Umfang
Kapitel 2 Geschäftsanalyse	✅ Ausgewählt	Zielnutzer, Schmerzpunkte, Marktanalyse
Kapitel 3 Funktionale Anforderungen	✅ Ausgewählt	Feature-Liste, User Stories, detaillierte Anforderungen

Frage 2 – Erweiterte Kapitel (Kapitel 4-7):

Option	Standard	Beschreibung
Kapitel 4 Nicht-funktionale Anforderungen	✅ Ausgewählt	Leistung, Sicherheit, Verfügbarkeit, Kompatibilität
Kapitel 5 Benutzererfahrungsprozess	✅ Ausgewählt	User Journey, Seitenflussdiagramme
Kapitel 6 Projektrisiken	✅ Ausgewählt	Projektrisiken und Minderungsstrategien
Kapitel 7 Compliance-Empfehlungen	⬜ Nicht ausgewählt	Compliance-Richtlinien und Risikokategorien

Frage 3 – Optionale Kapitel (Kapitel 8-9):

Option	Standard	Beschreibung
Kapitel 8 Prototyp-Design	⬜ Nicht ausgewählt	Prototyp-Links und Designnotizen
Kapitel 9 Erfolgsmetriken	⬜ Nicht ausgewählt	Nordstern-, Prozess- und Ergebnismetriken

Dauerhafte Ausschlüsse (nicht in der Auswahlliste, NIE generiert):

• Technisches Konzept / Architekturdesign – PRD enthält keine technischen Implementierungsdetails
• API-Schnittstellendefinition – Schnittstellendokumentation wird vom Entwicklungsteam separat geschrieben
• Datenbanktabellenstrukturdesign – liegt nicht im Produktanforderungsbereich

Nach dem Sammeln der Auswahlen: Aktualisieren Sie die Spalte „Ausgewählt" der PRD-Plantabelle entsprechend (✅ für ausgewählt, ❌ für nicht ausgewählt).

5. Benutzerfreigabe: Verwenden Sie AskUserQuestion, um den PRD-Plan (mit Kapitelauswahlen) zu präsentieren und die explizite Freigabe zu erhalten:

   Option	Beschreibung
   Bestätigen, PRD mit diesem Kapitelschema generieren	Gehen Sie zu Schritt 1 Branchen-Benchmark und Schritt 2 PRD-Erstellung
   Kapitelauswahl anpassen	Wählen Sie die zu generierenden Kapitel neu aus
   Schema anpassen nötig	PRD-Plan ändern und erneut bestätigen
   Ich habe weitere Informationen zu ergänzen	Zurück zu Schritt 0.5, Informationen ergänzen, Schema neu erstellen
   Zuerst Wahrnehmungsdaten ergänzen	market-research / competitive-analysis aufrufen

Anti-Pattern: „Ich habe genug Informationen, lass mich einfach generieren" – verboten. Selbst mit minimalen Lücken präsentieren Sie den Plan und holen die Freigabe ein.

Leitfaden zur Bildverarbeitung in der TUI-Umgebung

In der Terminal-Umgebung (TUI) können Benutzer Bilder wie folgt bereitstellen:

Methode 1: Lokaler Dateipfad (am einfachsten)

Geben Sie direkt den lokalen Pfad zum Bild an und verwenden Sie das Read-Tool zum Lesen:

# Beispiel für Benutzerdialog
"Analysiere diesen UI-Screenshot: /Users/fh/Desktop/screenshot.png"
"Aktuelle Oberfläche: ~/Screenshots/ui-2025-03-12.png"
"Referenzbild: ./docs/product/images/reference.png"

Unterstützte Pfadformate:

• Absoluter Pfad: /Users/fh/Desktop/screenshot.png
• Home-Verzeichnis-Abkürzung: ~/Screenshots/ui.png
• Relativer Pfad: ./images/ui.png

Unterstützte Bildformate: PNG, JPG, JPEG, WebP, GIF

Methode 2: Online-Bild-URL

Der Benutzer lädt das Bild auf einen Bildhost/Cloud-Speicher hoch und gibt die URL an:

# Beispiel für Benutzerdialog
"UI-Screenshot: https://i.imgur.com/xyz.png"
"Referenzbild: https://s3.aws.com/bucket/screenshot.png"

Verwenden Sie die Tools mcp__4_5v_mcp__analyze_image oder mcp__zai-mcp-server__ui_to_artifact, um das remote Bild zu lesen.

Empfohlene Bildhosts:

• imgur.com (kostenlos, keine Registrierung erforderlich)
• GitHub (als Issue-Anhang)
• Cloud-Speicher (AWS S3, Alibaba Cloud OSS)

Methode 3: Terminal-Screenshot-Befehl

Leiten Sie den Benutzer zur Verwendung von Terminal-Screenshot-Tools:

macOS:

# Ausgewählten Bereich aufnehmen (interaktiv)
screencapture -i ~/screenshot.png

# Gesamtes Fenster aufnehmen
screencapture -w ~/screenshot.png

# Gesamten Bildschirm aufnehmen
screencapture ~/screenshot.png

Linux:

# ImageMagick (muss zuerst installiert werden: sudo apt install imagemagick)
import ~/screenshot.png

# gnome-screenshot (Ubuntu/GNOME)
gnome-screenshot -a -f ~/screenshot.png

#spectacle (KDE)
spectacle -r -o ~/screenshot.png

Methode 4: Direkt aus der Zwischenablage (macOS)

# Installieren Sie das pngpaste-Tool
brew install pngpaste

# Speichern Sie das Bild aus der Zwischenablage als Datei
pngpaste ~/screenshot.png

Verarbeitungsablauf

Nachdem der Benutzer ein Bild bereitgestellt hat:

1. Lokaler Pfad → Mit dem Read-Tool direkt lesen
2. Remote-URL → mcp__4_5v_mcp__analyze_image oder mcp__zai-mcp-server__ui_to_artifact verwenden
3. Bildinhalt analysieren → UI-Struktur, Layout, Interaktionselemente extrahieren
4. PRD generieren → Basierend auf der Bildanalyse das Anforderungsdokument erstellen

Branchen-Benchmark-Prüfung

Nach Szenarioerkennung, Kontexterfassung und Informationsklärung:

1. Vom Benutzer bereitgestellte Benchmarks (Priorität): Vom Benutzer angegebene Referenzprodukte
2. Ergänzende Agentensuche: Automatische Suche nach Branchen-Best-Practices basierend auf Szenario-Schlüsselwörtern
3. Best Practices extrahieren: 3-5 Benchmark-Interaktionsmuster/Feature-Designs
4. Im PRD zitieren: Referenz-Benchmark-Lösungen mit Begründung für Übernahme/Differenzierung

Suchschlüsselwort-Zuordnung:

Szenario	Suchschlüsselwörter
Iterations-Update	„{Funktionsname} Best Practices", „Branchen-{Funktionsname} Design"
Neue Funktion	„{Produkttyp} {Modulname} Lösung", „Ähnliche Produkte {Funktion}"
0-1 Neues Produkt	„{Branche} Produktrahmen", „{Bereich} Produktlandkarte"

Funktionsweise

Der Erstellungsprozess gewährleistet vollständige, umsetzbare PRDs:

1. Szenarioerkennung – AskUserQuestion verwenden, um Iteration/neue Funktion/neues Produkt zu identifizieren
2. Kontexterfassung – Erforderliche Informationen basierend auf dem Szenariotyp sammeln
3. Informationslückenanalyse – Fehlende Informationen identifizieren, eine Frage nach der anderen stellen
4. Kapitelauswahl – Benutzer wählt aus, welche PRD-Kapitel generiert werden sollen (multiSelect)
5. PRD-Plan-Präsentation – Plan mit Kapitelauswahlen zur Benutzerfreigabe präsentieren (HARTE SCHRANKE)
6. Branchen-Benchmark-Recherche – Best Practices suchen und extrahieren (benutzerspezifisch + Agentensuche)
7. Anforderungen parsen – Die Funktionsanfrage des Benutzers in Schlüsselkomponenten strukturieren
8. Kontext sammeln – Marktanalyse, Wettbewerbserkenntnisse, Benutzerforschung lesen
9. Abschnitte zusammenstellen – Nur die AUSGEWÄHLTEN PRD-Abschnitte mit angemessener Detailtiefe erstellen
10. Vollständigkeit prüfen – Gegen Qualitätsstandards prüfen (nur ausgewählte Kapitel)
11. Selbstprüfung vor Auslieferung – PRD-Vorprüfung (Kapitel-Selbstcheck + Stakeholder-Perspektiven-Herausforderung); Blockierer beheben oder als [Ausstehende Bestätigung] markieren
12. Ausgabe generieren – In docs/product/prd/{feature-name}-{date}-v{version}.md schreiben (enthält am Ende einen Abschnitt „Prüfungsaufzeichnung")

Inhaltsbeschränkungen (HARTE REGELN):

Vor der Generierung von PRD-Inhalten beachten:

1. Generieren Sie NUR die vom Benutzer ausgewählten Kapitel. Überspringen Sie nicht ausgewählte Kapitel vollständig.
2. Generieren Sie NIE die folgenden Inhaltstypen, unabhängig von Benutzereingaben:
   • Technische Architektur / Implementierungsdetails
   • API-Endpunktdefinitionen oder -spezifikationen
   • Datenbankschema oder Tabellendesigns
3. Wenn die Funktionsbeschreibung des Benutzers technische Details erwähnt, fassen Sie diese als funktionale Anforderungen zusammen, OHNE Implementierungsdetails preiszugeben.

Eingabeparameter

Parameter	Typ	Erforderlich	Beschreibung
requirements	string	Ja	Funktionsbeschreibung oder User Story zur Dokumentation
target_audience	string	Nein	Zielnutzersegment oder Persona
context_refs	list	Nein	Zugehörige Kontextdateien zum Referenzieren

Evidenzdisziplin (证据纪律)

1. Fehlende Informationen als [Ausstehende Bestätigung] kennzeichnen: Alle Informationen, die nicht aus der Eingabe oder dem Kontext gewonnen werden können, als [Ausstehende Bestätigung] kennzeichnen. Keine Standardwerte erfinden.
2. Evidenzrückverfolgung [Nicht verifiziert]: Bei Benutzeranforderungen/Marktbehauptungen muss die Evidenzquelle nachgefragt werden; unbelegte Behauptungen als [Nicht verifiziert] kennzeichnen und die erforderliche Verifizierungsmethode angeben.
3. Vollständigkeitsprüfungstor: Vor der endgültigen Ausgabe des Liefergegenstands zuerst eine Informationsvollständigkeitsliste ausgeben (Bestätigt ✅ / Ausstehend ⚠️ / Nicht verifiziert ❓) und erst nach Benutzerbestätigung den Haupttext generieren.

Beziehung zum Expliziten-Skip-Protokoll (Schritt 0.5): Evidenzdisziplin ist eine Ausgabedisziplin (Informationskennzeichnung und Selbstprüfung vor Auslieferung), Explizites-Skip ist eine Interaktionsdisziplin (Degradierungsbehandlung bei expliziter Benutzerverweigerung der Interaktion). Beide ergänzen sich, ohne in Konflikt zu geraten. Im Explizites-Skip-Szenario ist die Vollständigkeitsliste nicht aufgehoben – sie wird zusammen mit dem „Annahmenblock" ausgegeben, wartet aber nicht mehr auf Benutzerbestätigung. Nicht bestätigte Informationen im Annahmenblock werden ebenfalls gemäß den Regeln dieses Abschnitts als [Ausstehende Bestätigung] / [Nicht verifiziert] gekennzeichnet.

Ausgabestruktur

Das PRD folgt dieser Struktur (abgestimmt auf die Standard-PRD-Vorlage). WICHTIG: Diese Vorlage zeigt alle möglichen Kapitel. Generieren Sie NUR die vom Benutzer ausgewählten Kapitel. Überspringen Sie nicht ausgewählte Kapitel vollständig. Generieren Sie unter keinen Umständen technische Architektur, API-Spezifikationen oder Datenbankdesigns.

# [Feature-Name] PRD

## Dokument-Grundinformationen
- **Dokumentversion**: v1.0
- **Erstellungsdatum**: YYYY-MM-DD
- **Letzte Aktualisierung**: YYYY-MM-DD
- **Dokumentstatus**: Draft/Review/Approved
- **Ersteller**: [Benutzername]
- **Prüfer**: [Ausstehend]

## Revisionshistorie
| Version | Datum | Revisionsinhalt | Revisionsverantwortlicher |
|:-----|:-----|:---------|:-------|
| v1.0 | YYYY-MM-DD | Erstversion | [Ersteller] |

## 0. Branchen-Benchmark-Analyse
### 0.1 Referenzprodukte
| Produkt | Schlüsselfunktion | Übernahme/Differenzierung |
|:-----|:---------|:-----------|
| [Wettbewerber A] | XXX | Übernahme des XXX-Musters, weil ... |
| [Wettbewerber B] | XXX | Differenzierungspunkt ist ... |

### 0.2 Zusammenfassung der Best Practices
- **Interaktionsmuster**: [Verwendetes branchenübliches Interaktionsmuster]
- **Kern-Differenzierung**: [Einzigartigkeit dieser Lösung]

## 1. Projektübersicht
### 1.1 Projekthintergrund
[Markthintergrund, Wettbewerbshintergrund, Benutzeranforderungshintergrund]

### 1.2 Projektziele
#### 1.2.1 Kernziele
- [Quantifizierbares Kernziel]

#### 1.2.2 Sekundäre Ziele
- [Unterstützende Ziele]

### 1.3 Projektumfang
#### 1.3.1 Enthaltene Bereiche
- [In dieser Iteration/Funktion enthaltene Inhalte]

#### 1.3.2 Nicht enthaltene Bereiche
- [Explizit nicht im Umfang enthaltene Punkte]

## 2. Geschäftsanalyse
### 2.1 Zielnutzer
| Benutzerrolle | Beschreibung | Kernanforderung |
|:---------|:-----|:---------|
| Benutzer A | [Aus Benutzerforschung] | XXX |
| Benutzer B | [Aus Benutzerforschung] | XXX |

### 2.2 Benutzerschmerzpunkte
| Schmerzpunkt-ID | Beschreibung | Ausmaß |
|:-------|:---------|:---------|
| P-001 | XXX | Hoch/Mittel/Niedrig |
| P-002 | XXX | Hoch/Mittel/Niedrig |

### 2.3 Marktanalyse
[Branchentrends, Wettbewerbslandschaft, Marktchancen]

## 3. Funktionale Anforderungen
### 3.1 Kernfunktionsliste
| Funktions-ID | Funktionsname | Priorität | Beschreibung |
|:-------|:---------|:-------|:-----|
| F-001 | XXX | P0/P1/P2 | XXX |
| F-002 | XXX | P0/P1/P2 | XXX |

### 3.2 User Stories
#### US-1: [Funktionsname]
**Als** [Benutzerrolle]
**möchte ich** [Funktionsbeschreibung]
**um** [geschäftlichen Wert zu erzielen]

**Abnahmekriterien**:
- Given [Vorbedingung]
- When [Aktion ausführen]
- Then [Erwartetes Ergebnis]

**Priorität**: P0/P1/P2
**Schätzung**: X Story Points

#### US-2: [Funktionsname]
...

### 3.3 Funktionsdetails
#### F-001: [Funktionsname]
**Beschreibung**: [Detaillierte Funktionsbeschreibung]

**Interaktionsablauf**:
1. Schritt eins
2. Schritt zwei
3. Schritt drei

**Grenzfälle**:
- Normaler Ablauf: ...
- Ausnahmefälle: ...

## 4. Nicht-funktionale Anforderungen
### 4.1 Leistungsanforderungen
- Seitenantwortzeit < XXXms
- Unterstützt XXX gleichzeitige Benutzer
### 4.2 Sicherheitsanforderungen
- Datenverschlüsselung bei Speicherung
- Benutzerberechtigungssteuerung
### 4.3 Verfügbarkeitsanforderungen
- Systemverfügbarkeit > 99,9%
### 4.4 Kompatibilitätsanforderungen
- iOS 14+, Android 10+
- Kompatibilität mit gängigen Browsern

## 5. Benutzererfahrungsprozess
### 5.1 User Journey
[Beschreibung des kritischen Benutzerpfads]
1. Benutzer tritt ein → 2. Aktion ausführen → 3. Ziel erreichen

### 5.2 Seitenflussdiagramm
[Beschreibung der Seitenwechselbeziehungen]
- Seite A → Seite B → Seite C

## 6. Projektrisiken und -maßnahmen
> Hinweis: Dieser Abschnitt enthält nur Produkt-/Geschäftsrisiken, keine technischen Implementierungsrisiken (technische Risiken werden vom Entwicklungsteam im technischen Konzept bewertet)
| Risiko-ID | Risikobeschreibung | Wahrscheinlichkeit | Auswirkung | Gegenmaßnahme |
|:-------|:---------|:-----|:-----|:---------|
| R-001 | XXX | Hoch/Mittel/Niedrig | Hoch/Mittel/Niedrig | XXX |
| R-002 | XXX | Hoch/Mittel/Niedrig | Hoch/Mittel/Niedrig | XXX |

## 7. Compliance-Empfehlungen

### 7.1 Zusammenfassung der Compliance-Punkte
[Zusammenfassung der wichtigsten Punkte aus der Compliance-Expertenprüfung]

### 7.2 Risikohinweise
| Risikokategorie | Beschreibung | Empfehlung |
|:---------|:-----|:-----|
| Datenschutz-Compliance | [Art der Verarbeitung von Benutzerdaten] | [Compliance-Empfehlung] |
| Inhalts-Compliance | [Wichtige Punkte der Inhaltsprüfung] | [Compliance-Empfehlung] |
| Datensicherheit | [Anforderungen an Datenspeicherung und -übertragung] | [Compliance-Empfehlung] |
| Drittanbieter-Compliance | [Compliance abhängiger Drittanbieterdienste] | [Compliance-Empfehlung] |

### 7.3 Anhang zum Compliance-Bericht
- [ ] Compliance-Analysebericht beigefügt (falls vorhanden, Pfad angeben)
- [ ] Warte auf Compliance-Prüfung (falls erforderlich, Compliance-Experten-Review vereinbaren)