Merge 8bb2615561 into 1198c8b9b7
This commit is contained in:
Tolga Karatas
GitHub
commit
eb587ff337
|
|
@ -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"}
|
||||
|
|
|
|||
|
|
@ -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!
|
||||
|
|
|
|||
|
|
@ -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'!
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue