diff --git a/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-01-init.md b/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-01-init.md index 62969bafd..bd24778e5 100644 --- a/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-01-init.md +++ b/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-01-init.md @@ -64,7 +64,9 @@ Also - when searching - documents can be a single markdown file, or a folder wit Try to discover the following: - Product Brief (`*brief*.md`) -- Research Documents (`*prd*.md`) +- PRD (`*prd*.md`) - PRIMARY input: contains FRs and NFRs the UX must address +- Architecture Document (`*architecture*.md`) - Contains technical constraints that affect UX decisions (API limits, platform requirements, performance budgets) +- StRS (`*strs*.md`) - Enterprise track: contains user profiles and operational scenarios - Project Documentation (generally multiple documents might be found for this in the `{product_knowledge}` or `docs` folder.) - Project Context (`**/project-context.md`) @@ -98,8 +100,10 @@ Report what was found: **Documents Found:** -- PRD: {number of PRD files loaded or "None found"} +- PRD: {number of PRD files loaded or "None found"} ← Key: FRs define what UX must address - Product brief: {number of brief files loaded or "None found"} +- Architecture: {found or "None found"} ← Key: Technical constraints that affect UX +- StRS: {found or "None found"} ← Enterprise: User profiles and scenarios - Other context: {number of other files loaded or "None found"} **Files loaded:** {list of specific file names or "No additional documents found"} diff --git a/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-13-responsive-accessibility.md b/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-13-responsive-accessibility.md index 80b81d4c8..32f5fc028 100644 --- a/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-13-responsive-accessibility.md +++ b/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-13-responsive-accessibility.md @@ -227,7 +227,7 @@ Show the generated responsive and accessibility content and present choices: - Append the final content to `{planning_artifacts}/ux-design-specification.md` - Update frontmatter: append step to end of stepsCompleted array -- Load `./step-14-complete.md` +- Load `./step-13b-requirements-validation.md` ## APPEND TO DOCUMENT: @@ -259,6 +259,6 @@ When user selects 'C', append the content directly to the document using the str ## NEXT STEP: -After user selects 'C' and content is saved to document, load `./step-14-complete.md` to finalize the UX design workflow. +After user selects 'C' and content is saved to document, load `./step-13b-requirements-validation.md` to finalize the UX design workflow. Remember: Do NOT proceed to step-14 until user explicitly selects 'C' from the A/P/C menu and content is saved! diff --git a/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-13b-requirements-validation.md b/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-13b-requirements-validation.md new file mode 100644 index 000000000..99ee11628 --- /dev/null +++ b/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-13b-requirements-validation.md @@ -0,0 +1,176 @@ +# Step 13b: Requirements Validation & Handoff Checklist + +## MANDATORY EXECUTION RULES (READ FIRST): + +- 📖 CRITICAL: ALWAYS read the complete step file before taking any action +- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}` +- 🎯 This step validates UX design completeness against PRD requirements +- 📋 YOU ARE A VALIDATION FACILITATOR for this step + +## EXECUTION PROTOCOLS: + +- 🎯 Load PRD and validate requirements coverage +- 🎯 Load Architecture document and check constraint alignment +- ⚠️ Present findings with A/P/C menu +- 💾 ONLY save when user chooses C (Continue) +- 📖 Update output file frontmatter, adding this step to stepsCompleted +- 🚫 FORBIDDEN to load next step until C is selected + +## CONTEXT BOUNDARIES: + +- Complete UX design specification from all previous steps is available +- PRD (if loaded at init) contains FRs/NFRs that UX must address +- Architecture (if loaded at init) contains technical constraints +- Focus on validating coverage and creating handoff artifacts + +## YOUR TASK: + +Validate that the UX design addresses PRD requirements, respects architecture constraints, and prepare handoff artifacts for downstream workflows (Architecture, Epics & Stories). + +## VALIDATION & HANDOFF SEQUENCE: + +### 1. Requirements Coverage Validation + +If PRD was loaded during initialization: + +**Extract PRD Functional Requirements:** +- Load the PRD and find all FRs +- For each FR, determine if the UX design addresses it + +**Create Coverage Matrix:** +- Map each FR to UX design elements (user journeys, components, patterns) +- Identify FRs NOT addressed by UX design +- For unaddressed FRs, determine if they are: + - Non-UI FRs (backend-only, no UX needed) → Mark as N/A + - Missing from UX design → Flag as GAP + +**Present to user:** +"I've validated your UX design against the PRD requirements: + +**FR Coverage:** + +| FR | Description | UX Element | Status | +|----|-------------|-----------|--------| +| FR1 | [desc] | [journey/component/pattern] | ✅ Covered | +| FR5 | [desc] | - | ⚠️ Gap (UI feature) | +| FR8 | [desc] | N/A | ➖ Backend only | + +**Coverage: [X]% of UI-relevant FRs addressed** +**Gaps found: [count]**" + +If PRD was NOT loaded: +- Note that requirements validation could not be performed +- Recommend running this check later when PRD is available + +### 2. Architecture Constraint Alignment + +If Architecture document was loaded: + +**Check for conflicts:** +- API constraints vs. UX interaction patterns (e.g., real-time updates vs. REST-only API) +- Platform constraints vs. responsive strategy +- Performance budgets vs. animation/interaction complexity +- Data model constraints vs. information architecture + +**Present any conflicts found:** +- Conflict description +- UX design assumption +- Architecture constraint +- Suggested resolution + +If Architecture was NOT loaded: +- Note that constraint validation could not be performed + +### 3. Downstream Handoff Checklist + +Create handoff information for downstream workflows: + +**For Architecture Workflow (Winston):** +- [ ] UX interaction patterns that require specific API design +- [ ] Real-time requirements identified in UX (WebSocket, SSE, polling) +- [ ] Data requirements from form designs and user flows +- [ ] Performance requirements from animation/interaction specs + +**For Epics & Stories Workflow (John):** +- [ ] User journey → FR mapping (which journeys implement which FRs) +- [ ] Component complexity estimates (simple, moderate, complex) +- [ ] Design dependencies between components +- [ ] Phasing recommendations (what can be MVP vs. later) + +**Design Decision Rationale:** +- Key design decisions and WHY they were made +- Alternatives considered and rejected (with reasons) +- Assumptions made during design + +### 4. Generate Validation & Handoff Content + +Append to the document: + +```markdown +## Requirements Validation + +### FR Coverage Matrix + +[Table mapping FRs to UX elements] + +### Architecture Constraint Alignment + +[Any conflicts found and resolutions, or "No architecture document loaded"] + +## Downstream Handoff + +### Architecture Handoff + +[UX constraints and requirements for architecture decisions] + +### Epics & Stories Handoff + +[User journey → FR mapping, complexity estimates, phasing recommendations] + +### Design Decision Rationale + +[Key decisions with reasoning for downstream teams] +``` + +### 5. Present MENU OPTIONS + +Present the validation findings and handoff checklist, then display menu: +- Show coverage matrix highlights +- Show any architecture conflicts +- Show handoff readiness + +Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Complete Workflow (Step 14)" + +#### Menu Handling Logic: +- IF A: Read fully and follow Advanced Elicitation, process, ask acceptance, update or keep, redisplay +- IF P: Read fully and follow Party Mode, process, ask acceptance, update or keep, redisplay +- IF C: Append to output document, update frontmatter, then read fully and follow: `./step-14-complete.md` +- IF Any other: help user respond, then redisplay menu + +## APPEND TO DOCUMENT: + +When user selects 'C', append the content directly to the document. + +## SUCCESS METRICS: + +✅ PRD FR coverage validated (if PRD available) +✅ Architecture constraints checked (if architecture available) +✅ FR → UX element mapping created +✅ Gaps identified with clear categorization +✅ Handoff checklist prepared for Architecture and Epics workflows +✅ Design decision rationale documented +✅ A/P/C menu presented and handled correctly + +## FAILURE MODES: + +❌ Not loading PRD for validation when it was discovered at init +❌ Claiming full coverage without systematic check +❌ Not creating handoff artifacts for downstream workflows +❌ Not documenting design decision rationale +❌ Marking non-UI FRs as gaps (they should be N/A) + +## NEXT STEP: + +After user selects 'C' and content is saved, load `./step-14-complete.md` to complete the workflow. + +Remember: Do NOT proceed to step-14 until user explicitly selects 'C'! diff --git a/src/bmm/workflows/qa/automate/checklist.md b/src/bmm/workflows/qa/automate/checklist.md index 013bc6390..c34e0e1cc 100644 --- a/src/bmm/workflows/qa/automate/checklist.md +++ b/src/bmm/workflows/qa/automate/checklist.md @@ -8,6 +8,12 @@ - [ ] Tests cover happy path - [ ] Tests cover 1-2 critical error cases +## Requirements Traceability (All Tracks) + +- [ ] Each acceptance criterion has at least one test +- [ ] Each FR has at least one test scenario defined +- [ ] Test descriptions reference the FR or acceptance criterion they verify + ## Test Quality - [ ] All generated tests run successfully diff --git a/src/bmm/workflows/shared/templates/requirement-quality-checklist.md b/src/bmm/workflows/shared/templates/requirement-quality-checklist.md new file mode 100644 index 000000000..a1aa34479 --- /dev/null +++ b/src/bmm/workflows/shared/templates/requirement-quality-checklist.md @@ -0,0 +1,122 @@ +# Per-Requirement Quality Checklist (ISO 29148) + +Apply this checklist to EVERY individual requirement in StRS, SyRS, and PRD/SRS documents. Each requirement must satisfy all 9 quality criteria. + +## The 9 Quality Criteria + +### 1. Necessary + +- [ ] The requirement traces to a real stakeholder need or business objective +- [ ] Removing this requirement would leave a stakeholder need unmet +- [ ] The requirement is not gold-plating (adding unnecessary complexity) + +**Test:** "If we remove this requirement, would a stakeholder's need go unmet?" + +### 2. Implementation-Free + +- [ ] The requirement states WHAT is needed, not HOW to build it +- [ ] No technology choices are embedded (unless it IS a design constraint) +- [ ] No UI/UX specifics are included (unless it IS an interface requirement) +- [ ] The requirement could be implemented in multiple different ways + +**Test:** "Could an architect choose from 3+ different implementation approaches?" + +### 3. Unambiguous + +- [ ] The requirement has only ONE possible interpretation +- [ ] No vague adjectives (good, fast, easy, user-friendly, intuitive, robust) +- [ ] Measurable criteria are used where applicable +- [ ] Terms are defined in the glossary or are industry-standard + +**Test:** "Would 5 different engineers interpret this the same way?" + +### 4. Consistent + +- [ ] The requirement does NOT contradict any other requirement +- [ ] Terminology is consistent with the rest of the document +- [ ] Scope aligns with the product vision and boundaries +- [ ] No conflicting quality attribute targets (e.g., maximum security AND minimal latency) + +**Test:** "Does this requirement peacefully coexist with all other requirements?" + +### 5. Complete + +- [ ] The requirement contains enough detail to design and test against +- [ ] All conditions and constraints are specified +- [ ] Edge cases and boundary conditions are addressed (or explicitly deferred) +- [ ] No TBD, TBC, or placeholder values remain + +**Test:** "Could a developer implement this without asking clarifying questions?" + +### 6. Singular + +- [ ] The requirement expresses exactly ONE capability or constraint +- [ ] No compound requirements joined by "and" or "or" (split if needed) +- [ ] The requirement can be independently verified +- [ ] The requirement can be independently prioritized + +**Test:** "Can I assign a single pass/fail verdict to this requirement?" + +### 7. Feasible + +- [ ] The requirement is technically achievable with known technology +- [ ] The requirement is achievable within the project's constraints (budget, timeline, team) +- [ ] No physical impossibilities or contradictions with laws of physics/math +- [ ] Required third-party capabilities or services are available + +**Test:** "Can the team actually build this within the project constraints?" + +### 8. Traceable + +- [ ] The requirement has a unique identifier (ID) +- [ ] The requirement's source is documented (stakeholder, regulation, business objective) +- [ ] The requirement can be linked to downstream artifacts (design, code, tests) +- [ ] The requirement can be linked to upstream sources (StRS, business needs) + +**Test:** "Can I follow this requirement from origin to implementation to test?" + +### 9. Verifiable + +- [ ] There exists a method to prove the requirement is satisfied +- [ ] The verification method is identified (Test, Analysis, Demonstration, Inspection) +- [ ] Acceptance criteria are clear and objective +- [ ] The verification can be performed within project constraints + +**Test:** "Can I write a test or create a verification procedure for this?" + +--- + +## Quick Reference Card + +| # | Criterion | Key Question | Red Flags | +|---|-----------|-------------|-----------| +| 1 | Necessary | Would removing it leave a need unmet? | Gold-plating, nice-to-have disguised as must-have | +| 2 | Implementation-Free | Can it be built 3+ ways? | Technology names, UI specifics, algorithm choices | +| 3 | Unambiguous | Would 5 engineers agree? | "Good", "fast", "easy", "user-friendly", "robust" | +| 4 | Consistent | Does it conflict with others? | Contradicting metrics, overlapping scope | +| 5 | Complete | Can dev build without questions? | TBD, TBC, "details to follow", missing conditions | +| 6 | Singular | Can I give one pass/fail? | "and", "or" joining two capabilities | +| 7 | Feasible | Can the team actually build it? | Unrealistic targets, unavailable technology | +| 8 | Traceable | Can I follow origin → test? | Missing ID, no source reference | +| 9 | Verifiable | Can I test/prove it? | Subjective criteria, unmeasurable quality | + +## Usage + +**When to Apply:** +- During PRD/SRS creation (Step 9: FR synthesis, Step 10: NFR synthesis) +- During PRD validation (validation workflow) +- During StRS and SyRS review steps +- During change management (new or modified requirements) + +**How to Apply:** +1. Select a requirement +2. Walk through all 9 criteria +3. Mark any failures +4. Fix failures before proceeding or flag for review +5. A requirement that fails ANY criterion needs attention + +**Scoring:** +- 9/9: Requirement is high quality +- 7-8/9: Minor issues, address if time permits +- 5-6/9: Significant issues, must address before approval +- <5/9: Requirement needs rewrite diff --git a/tools/cli/external-official-modules.yaml b/tools/cli/external-official-modules.yaml index d6ae06ee6..298e97013 100644 --- a/tools/cli/external-official-modules.yaml +++ b/tools/cli/external-official-modules.yaml @@ -32,6 +32,16 @@ modules: type: bmad-org npmPackage: bmad-game-dev-studio + bmad-method-audit-standards-enterprise: + url: https://github.com/bmad-code-org/bmad-method-audit-standards-enterprise + module-definition: src/module.yaml + code: audit + name: "Audit Standards Enterprise" + description: "Standards Auditor for compliance, security auditing, traceability, and multi-standard governance" + defaultSelected: false + type: bmad-org + npmPackage: bmad-method-audit-standards-enterprise + bmad-method-test-architecture-enterprise: url: https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise module-definition: src/module.yaml