prd

Product Manager로서 **PRD (제품 요구사항 문서)** 워크플로우를 실행합니다.

Product Manager로서 PRD (제품 요구사항 문서) 워크플로우를 실행합니다.

Workflow Overview#

Goal: Create comprehensive PRD defining functional requirements, non-functional requirements, and epics

Phase: 2 - Planning

Agent: Product Manager

Inputs: Product brief (if available), interactive requirements gathering

Output: docs/prd-{project-name}-{date}.md

Duration: 45-90 minutes

Best for: Level 2+ projects (5+ stories)

Pre-Flight#

Execute these helper operations:

Load context per helpers.md#Combined-Config-Load
Check status per helpers.md#Load-Workflow-Status
Load product brief if exists:
- Check docs/ for product-brief-*.md
- Read and extract key information
- Use as foundation for PRD
Load template per helpers.md#Load-Template
- Template: ~/.claude/config/bmad/templates/prd.md

Requirements Gathering Process#

Use TodoWrite to track: Pre-flight → FRs → NFRs → Epics → Stories → Generate → Validate → Update

Approach: Strategic, organized, pragmatic.

Part 1: Foundation (From Product Brief)#

If product brief exists, extract and confirm:

Executive summary
Business objectives
Success metrics
User personas
Out of scope items

Ask user: "I've reviewed your product brief. Are there any changes or additions before we define requirements?"

If NO product brief: Ask user: "Let's establish the foundation. What are your top 3 business objectives for this project?"

Store as: ,

Part 2: Functional Requirements (FRs)#

Explain to user:

"Functional Requirements define what the system does. Each FR is a specific capability or feature. We'll organize these into Must/Should/Could priorities using the MoSCoW method."

Interactive FR Collection:

For each major feature area (derived from product brief or user input):

Ask: "What should the system do for [feature area]?"
For each requirement, collect:
- Description (specific, actionable)
- Priority (Must/Should/Could)
- Acceptance Criteria (how to test it's done)
Assign FR-ID: FR-001, FR-002, etc. (sequential)

Format each FR:

### FR-{ID}: {Short Title}

**Priority:** {Must Have | Should Have | Could Have}

**Description:**
{What the system should do - specific and testable}

**Acceptance Criteria:**
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

**Dependencies:** {FR-XXX if applicable}

Guidance:

Must Have: Critical for MVP, project fails without it
Should Have: Important but workaround exists
Could Have: Nice to have, skip if time/budget tight

Typical FR count by level:

Level 2: 8-15 FRs
Level 3: 15-30 FRs
Level 4: 30-50 FRs

Store as: `` (markdown formatted list)

Part 3: Non-Functional Requirements (NFRs)#

Explain to user:

"Non-Functional Requirements define how the system performs - quality attributes like performance, security, scalability."

NFR Categories to cover:

Performance
- Response time targets
- Throughput requirements
- Concurrent user capacity
Security
- Authentication requirements
- Authorization rules
- Data encryption needs
- Compliance (GDPR, HIPAA, etc.)
Scalability
- Expected growth
- Load handling
- Data volume
Reliability/Availability
- Uptime targets (99%, 99.9%, 99.99%)
- Disaster recovery
- Backup requirements
Usability
- Accessibility standards (WCAG)
- Browser/device support
- Internationalization
Maintainability
- Code quality standards
- Documentation requirements
- Testing coverage
Compatibility
- Integration requirements
- API standards
- Data format requirements

For each relevant NFR:

Ask: "What are your [category] requirements?"

Format:

### NFR-{ID}: {Category} - {Short Title}

**Priority:** {Must Have | Should Have}

**Description:**
{Specific, measurable requirement}

**Acceptance Criteria:**
- [ ] Measurable criterion (e.g., "Response time < 200ms for 95% of requests")

**Rationale:**
{Why this matters}

Typical NFR count: 5-12 NFRs

Store as: `` (markdown formatted list)

Part 4: Epics#

Explain to user:

"Epics are large bodies of work that group related FRs. Each epic will break down into 2-10 user stories in Phase 4."

Epic Creation Process:

Review FRs, identify natural groupings
For each epic:
- ID: EPIC-001, EPIC-002, etc.
- Name: Short, descriptive
- Description: What this epic accomplishes
- Related FRs: Which FRs belong to this epic
- Story Count Estimate: 2-10 stories

Format:

### EPIC-{ID}: {Epic Name}

**Description:**
{What this epic delivers}

**Functional Requirements:**
- FR-001
- FR-003
- FR-007

**Story Count Estimate:** {2-10}

**Priority:** {Must Have | Should Have | Could Have}

**Business Value:**
{Why this epic matters}

Typical epic count by level:

Level 2: 2-4 epics
Level 3: 4-8 epics
Level 4: 8-15 epics

Store as: `` (markdown formatted list)

Part 5: High-Level User Stories (Optional)#

Ask user: "Would you like to create high-level user stories now, or wait for sprint planning (Phase 4)?"

If YES: For each epic, create 2-3 example stories in format:

"As a [user type], I want [goal] so that [benefit]."

Store as: ``

If NO: Set `` to:

"Detailed user stories will be created during sprint planning (Phase 4)."

Part 6: Additional Sections#

Collect briefly:

User Personas (if not in product brief): "Who are the primary user types?" Store as: ``
Key User Flows: "What are the 2-3 most important user journeys?" Store as: ``
Dependencies: "What does this project depend on (internal systems, external APIs, etc.)?" Store as: ,
Assumptions: "What assumptions are we making?" Store as: ``
Out of Scope (confirm from brief): Store as: ``
Open Questions: "Are there any unresolved questions?" Store as: ``
Stakeholders (from brief or new): Store as: ``

Generate Document#

Load template from ~/.claude/config/bmad/templates/prd.md
Substitute variables per helpers.md#Apply-Variables-to-Template:
- All collected requirements (FRs, NFRs, Epics)
- Standard variables (date, user_name, project_name, etc.)
- Product brief path if available

Generate traceability matrix:

| Epic ID | Epic Name | FRs | Story Estimate |
|---------|-----------|-----|----------------|
| EPIC-001 | User Management | FR-001, FR-002, FR-005 | 5-8 stories |

Store as: ``

Generate prioritization summary:
- Count Must/Should/Could FRs and NFRs
- Store as: ``
Determine output path per helpers.md#Save-Output-Document:
- Format: {output_folder}/prd-{project-name}-{date}.md
Write document using Write tool

Display summary:

✓ PRD Created!

Summary:
- Functional Requirements: {count} ({must} must, {should} should, {could} could)
- Non-Functional Requirements: {count}
- Epics: {count}
- Estimated Stories: {total}

Validation#

Review the PRD:

✓ Checklist:
- [ ] All Must-Have FRs are clearly defined
- [ ] Each FR has testable acceptance criteria
- [ ] NFRs cover key quality attributes (performance, security, etc.)
- [ ] NFRs are measurable (specific numbers/targets)
- [ ] Epics logically group related FRs
- [ ] All FRs are assigned to epics
- [ ] Priorities are realistic (not everything is "Must Have")
- [ ] Requirements trace to business objectives
- [ ] Out of scope is clearly stated

Ask user: "Please review the PRD. Are the requirements complete and clear?"

If changes needed → Edit and re-validate If approved → Continue

Update Status#

Per helpers.md#Update-Workflow-Status:

Load docs/bmm-workflow-status.yaml
Update prd status to file path
Update last_updated timestamp
Save

Per helpers.md#Determine-Next-Workflow:

Based on project level:

Level 2:

✓ PRD complete!

Next: Architecture Design
Run /architecture to design system that meets all requirements.

Why architecture? Level 2 projects need architectural planning to ensure
FRs and NFRs are addressed systematically.

Level 3-4:

✓ PRD complete!

Next: Architecture Design (Required)
Run /architecture to design comprehensive system architecture.

With {count} requirements and {epic_count} epics, architectural planning
is critical for success.

Offer: "Would you like me to hand off to System Architect to design your system?"

Helper References#

Load config: helpers.md#Combined-Config-Load
Load status: helpers.md#Load-Workflow-Status
Load template: helpers.md#Load-Template
Apply variables: helpers.md#Apply-Variables-to-Template
Save document: helpers.md#Save-Output-Document
Update status: helpers.md#Update-Workflow-Status
Recommend next: helpers.md#Determine-Next-Workflow

Tips for Effective Requirements Gathering#

Functional Requirements:

Be specific: "User can upload PDF files up to 10MB" vs. "User can upload files"
Be testable: Include clear acceptance criteria
Avoid solution statements: "User can reset password" vs. "System uses JWT tokens"
One requirement per FR: Break complex features into atomic FRs

Non-Functional Requirements:

Be measurable: "API response < 200ms" vs. "System is fast"
Include context: "99.9% uptime during business hours (M-F, 8am-6pm EST)"
Consider cost: Some NFRs are expensive (e.g., 99.999% uptime)

Epics:

Epic ≠ Feature: An epic can span multiple features
Right-sized: 2-10 stories each (not 1, not 50)
Vertical slices: Each epic delivers end-to-end value

Prioritization:

Not everything is "Must Have" - be honest about what's critical
Use data: Impact × Reach ÷ Effort
Consider dependencies: Some FRs must come before others

Notes for LLMs#

Maintain approach (strategic, organized, pragmatic)
Use TodoWrite to track 8 major sections
Apply MoSCoW prioritization consistently
Ensure all requirements are testable
Create traceability (FRs → Epics → Stories)
Use Memory tool to store requirements for Phase 4
Don't rush - good requirements save time later
Validate completeness before finalizing

Remember: PRD quality determines implementation success. Take time to get requirements right.

prd

Workflow Overview#

Pre-Flight#

Requirements Gathering Process#

Part 1: Foundation (From Product Brief)#

Part 2: Functional Requirements (FRs)#

Part 3: Non-Functional Requirements (NFRs)#

Part 4: Epics#

Part 5: High-Level User Stories (Optional)#

Part 6: Additional Sections#

Generate Document#

Validation#

Update Status#

Recommend Next Steps#

Helper References#

Tips for Effective Requirements Gathering#

Notes for LLMs#