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: .bmad/prd-{project-name}-{date}.md

Duration: 45-90 minutes

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

Pre-Flight#

Execute these helper operations:

1. Load context per helpers.md#Combined-Config-Load
2. Check status per helpers.md#Load-Workflow-Status
3. Load product brief if exists:
   • Check .bmad/ for product-brief-*.md
   • Read and extract key information
   • Use as foundation for PRD
4. Load template per helpers.md#Load-Template
   • Template: ${CLAUDE_PLUGIN_ROOT}/references/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: {{business_objectives}}, {{success_metrics}}

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):

1. Ask: "What should the system do for [feature area]?"

2. For each requirement, collect:

   • Description (specific, actionable)
   • Priority (Must/Should/Could)
   • Acceptance Criteria (how to test it's done)

3. 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: {{functional_requirements}} (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:

1. Performance

   • Response time targets
   • Throughput requirements
   • Concurrent user capacity

2. Security

   • Authentication requirements
   • Authorization rules
   • Data encryption needs
   • Compliance (GDPR, HIPAA, etc.)

3. Scalability

   • Expected growth
   • Load handling
   • Data volume

4. Reliability/Availability

   • Uptime targets (99%, 99.9%, 99.99%)
   • Disaster recovery
   • Backup requirements

5. Usability

   • Accessibility standards (WCAG)
   • Browser/device support
   • Internationalization

6. Maintainability

   • Code quality standards
   • Documentation requirements
   • Testing coverage

7. 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: {{non_functional_requirements}} (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:

1. Review FRs, identify natural groupings
2. 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: {{epics}} (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: {{user_stories}}

If NO: Set {{user_stories}} to:

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

Part 6: Additional Sections#

Collect briefly:

1. User Personas (if not in product brief): "Who are the primary user types?" Store as: {{user_personas}}

2. Key User Flows: "What are the 2-3 most important user journeys?" Store as: {{user_flows}}

3. Dependencies: "What does this project depend on (internal systems, external APIs, etc.)?" Store as: {{internal_dependencies}}, {{external_dependencies}}

4. Assumptions: "What assumptions are we making?" Store as: {{assumptions}}

5. Out of Scope (confirm from brief): Store as: {{out_of_scope}}

6. Open Questions: "Are there any unresolved questions?" Store as: {{open_questions}}

7. Stakeholders (from brief or new): Store as: {{stakeholders}}

Generate Document#

1. Load template from ${CLAUDE_PLUGIN_ROOT}/references/templates/prd.md

2. 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

3. 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: {{traceability_matrix}}

4. Generate prioritization summary:

   • Count Must/Should/Could FRs and NFRs
   • Store as: {{prioritization_details}}

5. Determine output path per helpers.md#Save-Output-Document:

   • Format: {output_folder}/prd-{project-name}-{date}.md

6. Write document using Write tool

7. 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:

1. Load .bmad/bmm-workflow-status.yaml
2. Update prd status to file path
3. Update last_updated timestamp
4. Save

Recommend Next Steps#

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.