BMAD-METHOD/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-10d-verification.md

name	description	nextStepFile	outputFile	advancedElicitationTask	partyModeWorkflow
step-10d-verification	Define verification approach for each requirement category - ISO 29148 Clause 9.4	./step-11-polish.md	{planning_artifacts}/prd.md	{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml	{project-root}/_bmad/core/workflows/party-mode/workflow.md

Step 10d: Verification Plan

Progress: Step 10d - Next: Document Polish

MANDATORY EXECUTION RULES (READ FIRST):

• 🛑 NEVER generate content without user input
• 📖 CRITICAL: ALWAYS read the complete step file before taking any action
• 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
• ✅ ALWAYS treat this as collaborative discovery between PM peers
• 📋 YOU ARE A FACILITATOR, not a content generator
• 💬 FOCUS on HOW each requirement will be verified
• 🎯 This step is REQUIRED for Enterprise track, OPTIONAL for BMad Method track
• ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config {communication_language}

TRACK-AWARE EXECUTION:

Check the document frontmatter for track value:

• If track: 'enterprise' → This step is MANDATORY
• If track: 'bmad' or not set → This step is OPTIONAL, ask user if they want a verification plan
• If user on non-Enterprise track declines → Skip to {nextStepFile} immediately

EXECUTION PROTOCOLS:

• 🎯 Show your analysis before taking any action
• ⚠️ Present A/P/C menu after generating verification content
• 💾 ONLY save when user chooses C (Continue)
• 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
• 🚫 FORBIDDEN to load next step until C is selected

CONTEXT BOUNDARIES:

• All FRs, NFRs, interface requirements, and constraints from previous steps
• Focus on defining HOW requirements will be proven satisfied
• ISO 29148 Clause 9 Section 4: Verification
• This feeds directly into test strategy (TEA module for Enterprise track)

VERIFICATION PLAN SEQUENCE:

1. Explain Verification Purpose

Purpose: ISO 29148 requires that every requirement has a defined verification method. This ensures requirements are not only stated but can be proven satisfied. The four standard verification methods are:

• Inspection: Visual examination of documents, code, or artifacts
• Analysis: Mathematical or logical reasoning, modeling, or simulation
• Demonstration: Operation of the system under specific conditions to show capability
• Test: Execution of the system with test inputs and comparison against expected outputs

2. Review All Requirements

Load and review all requirements from the current PRD:

• Functional Requirements (FRs)
• Non-Functional Requirements (NFRs)
• Interface Requirements (if defined)
• Design Constraints (if defined)

3. Assign Verification Methods

For each requirement category, determine the appropriate verification method:

Guidelines:

• FRs → Typically verified by Test (automated or manual) or Demonstration
• NFR Performance → Typically verified by Test (load testing, benchmarks) or Analysis
• NFR Security → Typically verified by Test (penetration testing) and Inspection (code review)
• NFR Accessibility → Typically verified by Test (automated) and Inspection (manual audit)
• Interface Requirements → Typically verified by Test (integration testing) or Demonstration
• Constraints → Typically verified by Inspection (architecture review) or Analysis
• Compliance → Typically verified by Inspection (audit) or Analysis (gap analysis)

4. Create Verification Summary

Key Questions:

• "For each capability area, what is the primary way you'd verify it works?"
• "Are there requirements that can only be verified through analysis rather than testing?"
• "What verification activities require specialized tools or expertise?"
• "Are there requirements that need third-party verification?"

5. Generate Verification Content

Content Structure:

## Verification Approaches

### Verification Method Summary

| Requirement Category | Primary Method | Secondary Method | Notes |
|---------------------|---------------|-----------------|-------|
| Functional Requirements | Test | Demonstration | Automated test suite |
| Performance NFRs | Test | Analysis | Load testing required |
| Security NFRs | Test + Inspection | Analysis | Penetration testing + code review |
| Accessibility NFRs | Test + Inspection | Demonstration | WCAG automated + manual audit |
| Interface Requirements | Test | Demonstration | Integration testing |
| Design Constraints | Inspection | Analysis | Architecture review |
| Compliance | Inspection | Analysis | Audit and gap analysis |

### Verification Details

#### Functional Requirements Verification

[How FRs will be verified - test approach, acceptance criteria validation, demonstration scenarios]

#### Non-Functional Requirements Verification

[How NFRs will be verified - performance benchmarks, security scans, accessibility audits]

#### Interface Requirements Verification

[How interfaces will be verified - integration tests, API contract testing, protocol compliance]

### Verification Dependencies

[Tools, environments, expertise, or third-party services needed for verification]

### TEA Module Integration (Enterprise Track)

[Note: For Enterprise track projects, the TEA (Test Architecture Enterprise) module provides comprehensive test strategy, risk-based prioritization (P0-P3), and test-requirement traceability. This verification plan feeds into TEA's TD (Test Design) workflow.]

6. Present MENU OPTIONS

Display: "Select: [A] Advanced Elicitation [P] Party Mode [C] Continue to Document Polish (Step 11)"

Menu Handling Logic:

• IF A: Read fully and follow: {advancedElicitationTask}, process, ask acceptance, update or keep, redisplay
• IF P: Read fully and follow: {partyModeWorkflow}, process, ask acceptance, update or keep, redisplay
• IF C: Append to {outputFile}, update frontmatter, then read fully and follow: {nextStepFile}
• IF Any other: help user respond, then redisplay menu

APPEND TO DOCUMENT:

When user selects 'C', append the content directly to the document using the structure from step 5.

SUCCESS METRICS:

✅ Every requirement category has an assigned verification method ✅ Verification methods are appropriate (Test, Analysis, Demonstration, Inspection) ✅ Verification dependencies identified (tools, environments, expertise) ✅ TEA module integration noted for Enterprise track ✅ ISO 29148 Clause 9 Section 4 requirements addressed

FAILURE MODES:

❌ Requirements without any verification method ❌ Using only "Test" when some requirements need Analysis or Inspection ❌ Not identifying verification dependencies ❌ Generating verification plan without reviewing actual requirements

NEXT STEP:

After user selects 'C' and content is saved, load {nextStepFile} to polish the document.