feat(enterprise): add change management and cross-document validation workflows
Change Management (Enterprise track): Formal requirements change control with change request template, impact analysis, baseline management, and approval process. Supports New/Review/Implement/History modes. Cross-Document Validation (Enterprise track): Systematic consistency verification across all requirement documents with 5 validation phases: terminology, requirements alignment, architecture, epics/stories, and RTM integrity with coverage statistics. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Tolga Karatas
parent
2159182fdf
commit
e0b1b7cd9d
|
|
@ -0,0 +1,53 @@
|
||||||
|
# Requirements Change Management - Validation Checklist
|
||||||
|
|
||||||
|
## Change Request Completeness
|
||||||
|
|
||||||
|
- [ ] Change request has unique ID (CR-###)
|
||||||
|
- [ ] Change title clearly describes the modification
|
||||||
|
- [ ] Change category identified (New / Modification / Deletion / Clarification)
|
||||||
|
- [ ] Priority assigned (Must / Should / Could / Won't)
|
||||||
|
- [ ] Rationale provided explaining why the change is needed
|
||||||
|
- [ ] Source identified (stakeholder, technical finding, defect, etc.)
|
||||||
|
- [ ] Affected requirements listed with current and proposed text
|
||||||
|
|
||||||
|
## Impact Analysis
|
||||||
|
|
||||||
|
- [ ] All affected requirement documents identified
|
||||||
|
- [ ] Impact level assessed for each document (None / Low / Medium / High)
|
||||||
|
- [ ] RTM traceability chain traced for affected requirements
|
||||||
|
- [ ] Scope impact assessed (Increase / Decrease / Neutral)
|
||||||
|
- [ ] Effort estimate provided (Minimal / Moderate / Significant)
|
||||||
|
- [ ] Timeline impact assessed (None / Minor delay / Major delay)
|
||||||
|
- [ ] Risk assessment completed (Low / Medium / High)
|
||||||
|
|
||||||
|
## Baseline Comparison
|
||||||
|
|
||||||
|
- [ ] Current baseline version documented
|
||||||
|
- [ ] Baseline state vs. proposed state compared
|
||||||
|
- [ ] All deviations from baseline clearly documented
|
||||||
|
|
||||||
|
## Approval Process
|
||||||
|
|
||||||
|
- [ ] Change request presented to appropriate decision maker
|
||||||
|
- [ ] Decision recorded (Approved / Rejected / Deferred)
|
||||||
|
- [ ] Decision rationale documented
|
||||||
|
- [ ] If deferred: conditions for revisiting specified
|
||||||
|
|
||||||
|
## Implementation (After Approval)
|
||||||
|
|
||||||
|
- [ ] All affected requirement documents updated
|
||||||
|
- [ ] Requirement attributes updated (status, change reference)
|
||||||
|
- [ ] RTM updated with new/modified traceability links
|
||||||
|
- [ ] No orphan requirements created by the change
|
||||||
|
- [ ] No broken traceability links after the change
|
||||||
|
- [ ] Downstream artifacts update plan created (stories, tests, architecture)
|
||||||
|
- [ ] Baseline version incremented in all affected documents
|
||||||
|
- [ ] Change log entries added to all affected documents
|
||||||
|
- [ ] Change request status updated to "IMPLEMENTED"
|
||||||
|
|
||||||
|
## Post-Implementation Verification
|
||||||
|
|
||||||
|
- [ ] Cross-document consistency verified (no terminology conflicts)
|
||||||
|
- [ ] RTM integrity verified (forward and backward traceability intact)
|
||||||
|
- [ ] No scope creep introduced beyond approved change
|
||||||
|
- [ ] Change history file updated and searchable
|
||||||
|
|
@ -0,0 +1,190 @@
|
||||||
|
---
|
||||||
|
name: requirements-change-management
|
||||||
|
description: Formal requirements change control process for managing modifications to baselined requirements. Enterprise track workflow.
|
||||||
|
track: enterprise
|
||||||
|
---
|
||||||
|
|
||||||
|
# Requirements Change Management Workflow
|
||||||
|
|
||||||
|
**Goal:** Provide a formal, traceable process for requesting, analyzing, approving, and implementing changes to baselined requirements.
|
||||||
|
|
||||||
|
**Your Role:** You are a Change Control Analyst. Your job is to ensure every requirements change is properly documented, impact-analyzed, approved, and traced through the full requirements chain.
|
||||||
|
|
||||||
|
**Track:** This workflow is primarily for the **Enterprise** track (mandatory). It is available but optional for **BMad Method** track.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## CHANGE MANAGEMENT ARCHITECTURE
|
||||||
|
|
||||||
|
This is a **single-pass analytical workflow** (not step-file based). It guides the user through the complete change control cycle.
|
||||||
|
|
||||||
|
### Critical Rules
|
||||||
|
|
||||||
|
- 🔐 **NEVER** modify baselined requirements without a formal change request
|
||||||
|
- 📋 **ALWAYS** perform impact analysis before approving any change
|
||||||
|
- 🔗 **ALWAYS** update RTM after implementing any requirement change
|
||||||
|
- ⚠️ **ALWAYS** assess downstream impact (stories, tests, architecture)
|
||||||
|
- 💾 **ALWAYS** increment baseline version after approved changes are implemented
|
||||||
|
- 🚫 **NEVER** implement changes without explicit user approval
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## INITIALIZATION
|
||||||
|
|
||||||
|
### 1. Configuration Loading
|
||||||
|
|
||||||
|
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve project variables.
|
||||||
|
|
||||||
|
### 2. Context Discovery
|
||||||
|
|
||||||
|
Discover and load all available requirement documents:
|
||||||
|
|
||||||
|
- **StRS:** `{planning_artifacts}/*strs*.md`
|
||||||
|
- **SyRS:** `{planning_artifacts}/*syrs*.md`
|
||||||
|
- **PRD/SRS:** `{planning_artifacts}/*prd*.md`
|
||||||
|
- **Architecture:** `{planning_artifacts}/*architecture*.md`
|
||||||
|
- **Epics:** `{planning_artifacts}/*epic*.md`
|
||||||
|
- **RTM:** `{planning_artifacts}/*rtm*.md`
|
||||||
|
- **UX Design:** `{planning_artifacts}/*ux*.md`
|
||||||
|
|
||||||
|
Report which documents were found and their current baseline versions (from frontmatter).
|
||||||
|
|
||||||
|
### 3. Change Mode Detection
|
||||||
|
|
||||||
|
Ask the user which mode to operate in:
|
||||||
|
|
||||||
|
- **[NC] New Change Request:** Create a new change request from scratch
|
||||||
|
- **[RC] Review Change:** Review and decide on an existing change request
|
||||||
|
- **[IC] Implement Change:** Implement an approved change request
|
||||||
|
- **[SH] Change History:** View change history and statistics
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## MODE: NEW CHANGE REQUEST (NC)
|
||||||
|
|
||||||
|
### Step 1: Capture Change Details
|
||||||
|
|
||||||
|
Ask the user:
|
||||||
|
1. **What is changing?** (specific requirement ID or general area)
|
||||||
|
2. **Why is it changing?** (stakeholder feedback, technical discovery, defect, scope refinement)
|
||||||
|
3. **What is the proposed new state?** (new requirement text, modification, or deletion)
|
||||||
|
|
||||||
|
### Step 2: Locate Affected Requirements
|
||||||
|
|
||||||
|
Using the discovered documents:
|
||||||
|
1. Find the specific requirement(s) being changed
|
||||||
|
2. Follow traceability links in RTM to identify all connected requirements
|
||||||
|
3. Build the complete impact chain: StRS → SyRS → PRD → Stories → Tests
|
||||||
|
|
||||||
|
### Step 3: Impact Analysis
|
||||||
|
|
||||||
|
For each affected document, assess:
|
||||||
|
|
||||||
|
**Document Impact Assessment:**
|
||||||
|
|
||||||
|
| Document | Impact Level | Specific Changes Needed |
|
||||||
|
|----------|-------------|------------------------|
|
||||||
|
| StRS | None / Low / Medium / High | Details |
|
||||||
|
| SyRS | None / Low / Medium / High | Details |
|
||||||
|
| PRD/SRS | None / Low / Medium / High | Details |
|
||||||
|
| Architecture | None / Low / Medium / High | Details |
|
||||||
|
| UX Design | None / Low / Medium / High | Details |
|
||||||
|
| Epics & Stories | None / Low / Medium / High | Details |
|
||||||
|
| Test Cases | None / Low / Medium / High | Details |
|
||||||
|
|
||||||
|
**Scope Impact:**
|
||||||
|
- Does this increase, decrease, or maintain current scope?
|
||||||
|
- Estimated effort impact (Minimal / Moderate / Significant)
|
||||||
|
- Timeline risk (None / Minor / Major)
|
||||||
|
|
||||||
|
### Step 4: Generate Change Request
|
||||||
|
|
||||||
|
Create the formal change request document using the template at `{project-root}/_bmad/bmm/workflows/shared/templates/change-request-template.md`.
|
||||||
|
|
||||||
|
Populate all sections with the analysis results.
|
||||||
|
|
||||||
|
Save to: `{planning_artifacts}/change-requests/{{change_id}}.md`
|
||||||
|
|
||||||
|
### Step 5: Present for Decision
|
||||||
|
|
||||||
|
Present the change request summary to the user with:
|
||||||
|
- Clear statement of what's changing and why
|
||||||
|
- Impact analysis summary (highlight HIGH impact areas)
|
||||||
|
- Recommendation: Approve / Reject / Defer
|
||||||
|
- If approving, outline the implementation plan
|
||||||
|
|
||||||
|
**Menu:**
|
||||||
|
- **[A] Approve** - Mark as approved, proceed to implementation guidance
|
||||||
|
- **[R] Reject** - Mark as rejected with rationale
|
||||||
|
- **[D] Defer** - Mark as deferred with conditions for revisiting
|
||||||
|
- **[M] Modify** - Revise the change request before deciding
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## MODE: IMPLEMENT CHANGE (IC)
|
||||||
|
|
||||||
|
### Step 1: Load Approved Change Request
|
||||||
|
|
||||||
|
Load the specified change request file. Verify status is "APPROVED".
|
||||||
|
|
||||||
|
### Step 2: Document Update Checklist
|
||||||
|
|
||||||
|
For each affected document, guide the user through updates:
|
||||||
|
|
||||||
|
1. **Update requirement text** in the source document
|
||||||
|
2. **Update requirement attributes** (status → "Modified", change reference)
|
||||||
|
3. **Update RTM** with new traceability links
|
||||||
|
4. **Update downstream artifacts** (stories, tests)
|
||||||
|
|
||||||
|
### Step 3: Baseline Version Increment
|
||||||
|
|
||||||
|
After all changes are implemented:
|
||||||
|
1. Increment the baseline version in all affected document frontmatters
|
||||||
|
2. Add change log entry to each affected document
|
||||||
|
3. Update the change request status to "IMPLEMENTED"
|
||||||
|
|
||||||
|
### Step 4: Verification
|
||||||
|
|
||||||
|
Run the cross-document validation workflow to ensure consistency after changes:
|
||||||
|
- Terminology still consistent across documents?
|
||||||
|
- No broken traceability links?
|
||||||
|
- No orphan requirements created?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## MODE: CHANGE HISTORY (SH)
|
||||||
|
|
||||||
|
Scan `{planning_artifacts}/change-requests/` directory for all change request files.
|
||||||
|
|
||||||
|
Present a summary table:
|
||||||
|
|
||||||
|
| CR ID | Title | Status | Priority | Date | Impact |
|
||||||
|
|-------|-------|--------|----------|------|--------|
|
||||||
|
| CR-001 | ... | Approved | Must | ... | High |
|
||||||
|
|
||||||
|
Provide statistics:
|
||||||
|
- Total change requests
|
||||||
|
- By status (Proposed / Approved / Rejected / Deferred / Implemented)
|
||||||
|
- By priority (Must / Should / Could)
|
||||||
|
- By impact level
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ Change request properly documented with all required fields
|
||||||
|
✅ Impact analysis covers all requirement documents and downstream artifacts
|
||||||
|
✅ RTM traceability links identified for affected requirements
|
||||||
|
✅ Clear approval decision with rationale
|
||||||
|
✅ Implementation plan includes all affected documents
|
||||||
|
✅ Baseline version management maintained
|
||||||
|
✅ Change history searchable and complete
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Modifying baselined requirements without formal change request
|
||||||
|
❌ Incomplete impact analysis (missing downstream effects)
|
||||||
|
❌ Not updating RTM after implementing changes
|
||||||
|
❌ Not incrementing baseline version after changes
|
||||||
|
❌ Approving changes without assessing scope/timeline impact
|
||||||
|
❌ Not notifying downstream agents/workflows of changes
|
||||||
|
|
@ -0,0 +1,294 @@
|
||||||
|
---
|
||||||
|
name: cross-document-validation
|
||||||
|
description: Systematic validation of consistency and alignment across all requirement documents in the project. Enterprise track workflow with BMad Method optional use.
|
||||||
|
track: enterprise
|
||||||
|
---
|
||||||
|
|
||||||
|
# Cross-Document Validation Workflow
|
||||||
|
|
||||||
|
**Goal:** Systematically verify that all requirement documents (StRS, SyRS, PRD/SRS, Architecture, UX, Epics) are internally consistent, properly aligned, and maintain full traceability.
|
||||||
|
|
||||||
|
**Your Role:** You are a Consistency Auditor. Your job is to find every contradiction, gap, terminology mismatch, and broken traceability link across all project documents. You are THOROUGH and UNFORGIVING - inconsistencies cause implementation failures.
|
||||||
|
|
||||||
|
**Track:** This workflow is primarily for the **Enterprise** track (mandatory before implementation). Available but optional for **BMad Method** track.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## CROSS-DOCUMENT VALIDATION ARCHITECTURE
|
||||||
|
|
||||||
|
This is a **single-pass analytical workflow** (not step-file based). It loads all documents and performs systematic cross-referencing.
|
||||||
|
|
||||||
|
### Critical Rules
|
||||||
|
|
||||||
|
- 🔐 **NEVER** declare consistency without checking every document pair
|
||||||
|
- 📖 **ALWAYS** load and read ALL available requirement documents fully
|
||||||
|
- 🔗 **ALWAYS** verify both forward AND backward traceability
|
||||||
|
- ⚠️ **ALWAYS** report findings with specific document locations and quotes
|
||||||
|
- 💾 **ALWAYS** produce a consistency report with actionable findings
|
||||||
|
- 🚫 **NEVER** assume consistency - verify everything explicitly
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## INITIALIZATION
|
||||||
|
|
||||||
|
### 1. Configuration Loading
|
||||||
|
|
||||||
|
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve project variables.
|
||||||
|
|
||||||
|
### 2. Document Discovery
|
||||||
|
|
||||||
|
Search for and load ALL available requirement documents:
|
||||||
|
|
||||||
|
| Document | Search Pattern | Required? |
|
||||||
|
|----------|---------------|-----------|
|
||||||
|
| StRS | `{planning_artifacts}/*strs*.md` | Enterprise: Yes |
|
||||||
|
| SyRS | `{planning_artifacts}/*syrs*.md` | Enterprise: Yes |
|
||||||
|
| PRD/SRS | `{planning_artifacts}/*prd*.md` | All tracks: Yes |
|
||||||
|
| Architecture | `{planning_artifacts}/*architecture*.md` | BMad+Enterprise: Yes |
|
||||||
|
| UX Design | `{planning_artifacts}/*ux*.md` | Optional |
|
||||||
|
| Epics & Stories | `{planning_artifacts}/*epic*.md` | All tracks: Yes |
|
||||||
|
| RTM | `{planning_artifacts}/*rtm*.md` | Enterprise: Yes |
|
||||||
|
| Product Brief | `{planning_artifacts}/*brief*.md` | Optional (reference) |
|
||||||
|
|
||||||
|
Report which documents were found and which are missing.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## VALIDATION PHASE 1: Terminology Consistency
|
||||||
|
|
||||||
|
### 1.1 Term Extraction
|
||||||
|
|
||||||
|
From each document, extract:
|
||||||
|
- Key domain terms and their definitions
|
||||||
|
- Actor/user role names
|
||||||
|
- System component names
|
||||||
|
- Feature/capability names
|
||||||
|
|
||||||
|
### 1.2 Terminology Cross-Check
|
||||||
|
|
||||||
|
| Check | Description |
|
||||||
|
|-------|-------------|
|
||||||
|
| **Same concept, different names** | Is "user" called "customer" in one doc and "end-user" in another? |
|
||||||
|
| **Same name, different meanings** | Does "admin" mean different things in different documents? |
|
||||||
|
| **Undefined terms** | Terms used but never defined in any glossary |
|
||||||
|
| **Conflicting definitions** | Same term defined differently in different glossaries |
|
||||||
|
|
||||||
|
**Output:** Terminology Consistency Matrix with all findings.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## VALIDATION PHASE 2: Requirements Alignment
|
||||||
|
|
||||||
|
### 2.1 StRS ↔ PRD/SRS Alignment (Enterprise)
|
||||||
|
|
||||||
|
For each StRS stakeholder requirement:
|
||||||
|
- [ ] Is it traced forward to at least one PRD requirement?
|
||||||
|
- [ ] Does the PRD requirement accurately reflect the stakeholder need?
|
||||||
|
- [ ] Is the scope of the PRD requirement within the StRS scope?
|
||||||
|
|
||||||
|
For each PRD requirement:
|
||||||
|
- [ ] Does it trace back to a StRS stakeholder need?
|
||||||
|
- [ ] If not traceable to StRS, is it justified (derived requirement)?
|
||||||
|
|
||||||
|
**Check for:**
|
||||||
|
- StRS requirements with no PRD coverage (orphans)
|
||||||
|
- PRD requirements not traceable to StRS (scope creep or derived)
|
||||||
|
- Scope contradictions (PRD exceeds StRS boundaries)
|
||||||
|
- Priority mismatches (StRS Must → PRD Could = inconsistency)
|
||||||
|
|
||||||
|
### 2.2 SyRS ↔ PRD Alignment (Enterprise)
|
||||||
|
|
||||||
|
For each SyRS system requirement:
|
||||||
|
- [ ] Is it traceable to a PRD requirement?
|
||||||
|
- [ ] Does the system-level requirement correctly decompose the software requirement?
|
||||||
|
|
||||||
|
For each PRD functional requirement:
|
||||||
|
- [ ] Is there a corresponding SyRS system requirement?
|
||||||
|
- [ ] Are the system-level constraints compatible with the PRD requirement?
|
||||||
|
|
||||||
|
**Check for:**
|
||||||
|
- SyRS requirements without PRD traceability
|
||||||
|
- PRD requirements without SyRS system-level mapping
|
||||||
|
- Interface specification contradictions
|
||||||
|
- Performance/quality attribute mismatches
|
||||||
|
|
||||||
|
### 2.3 StRS ↔ SyRS Alignment (Enterprise)
|
||||||
|
|
||||||
|
- [ ] SyRS system scope aligns with StRS operational concept
|
||||||
|
- [ ] SyRS interfaces cover all StRS operational scenarios
|
||||||
|
- [ ] SyRS constraints are compatible with StRS project constraints
|
||||||
|
- [ ] SyRS quality attributes meet StRS operational quality expectations
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## VALIDATION PHASE 3: Architecture Alignment
|
||||||
|
|
||||||
|
### 3.1 Architecture ↔ PRD Alignment
|
||||||
|
|
||||||
|
- [ ] Every PRD functional requirement is addressable by the architecture
|
||||||
|
- [ ] Architecture tech stack supports all PRD non-functional requirements
|
||||||
|
- [ ] Architecture data model supports all PRD data-related requirements
|
||||||
|
- [ ] No architecture decisions contradict PRD requirements
|
||||||
|
- [ ] API design covers all PRD functional capabilities
|
||||||
|
|
||||||
|
### 3.2 Architecture ↔ SyRS Alignment (Enterprise)
|
||||||
|
|
||||||
|
- [ ] Architecture interfaces match SyRS interface specifications
|
||||||
|
- [ ] Architecture performance characteristics meet SyRS quality requirements
|
||||||
|
- [ ] Architecture security model satisfies SyRS security requirements
|
||||||
|
- [ ] Architecture deployment model aligns with SyRS operational requirements
|
||||||
|
|
||||||
|
### 3.3 Architecture ↔ UX Alignment (if UX exists)
|
||||||
|
|
||||||
|
- [ ] Architecture API endpoints support all UX interaction patterns
|
||||||
|
- [ ] Architecture data model supports all UX data display needs
|
||||||
|
- [ ] Architecture performance targets enable responsive UX
|
||||||
|
- [ ] No architecture constraints make UX designs infeasible
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## VALIDATION PHASE 4: Epics & Stories Alignment
|
||||||
|
|
||||||
|
### 4.1 Epics ↔ PRD Coverage
|
||||||
|
|
||||||
|
- [ ] Every PRD functional requirement is covered by at least one story
|
||||||
|
- [ ] Story acceptance criteria accurately reflect PRD requirement intent
|
||||||
|
- [ ] No stories introduce features beyond PRD scope (scope creep)
|
||||||
|
- [ ] Epic grouping aligns with PRD capability areas
|
||||||
|
|
||||||
|
### 4.2 Stories ↔ Architecture Alignment
|
||||||
|
|
||||||
|
- [ ] Stories reference correct architectural components
|
||||||
|
- [ ] Story implementation approach is compatible with architecture decisions
|
||||||
|
- [ ] Database stories align with architecture data model
|
||||||
|
- [ ] API stories align with architecture API design
|
||||||
|
|
||||||
|
### 4.3 Stories ↔ UX Alignment (if UX exists)
|
||||||
|
|
||||||
|
- [ ] UI stories implement the correct UX designs
|
||||||
|
- [ ] UX interaction patterns are captured in story acceptance criteria
|
||||||
|
- [ ] All UX screens/flows have corresponding stories
|
||||||
|
|
||||||
|
### 4.4 Stories ↔ SyRS Alignment (Enterprise)
|
||||||
|
|
||||||
|
- [ ] Stories reference source requirement IDs (StRS/SyRS/PRD)
|
||||||
|
- [ ] Story acceptance criteria support verification of system requirements
|
||||||
|
- [ ] No stories implement features not traceable to system requirements
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## VALIDATION PHASE 5: RTM Integrity (Enterprise)
|
||||||
|
|
||||||
|
### 5.1 Forward Traceability
|
||||||
|
|
||||||
|
- [ ] StRS → SyRS: Every StRS requirement traces to at least one SyRS requirement
|
||||||
|
- [ ] SyRS → PRD: Every SyRS requirement traces to at least one PRD requirement
|
||||||
|
- [ ] PRD → Stories: Every PRD requirement traces to at least one story
|
||||||
|
- [ ] Stories → Tests: Every story has associated test references (if TEA module active)
|
||||||
|
|
||||||
|
### 5.2 Backward Traceability
|
||||||
|
|
||||||
|
- [ ] Tests → Stories: Every test traces back to a story
|
||||||
|
- [ ] Stories → PRD: Every story traces back to a PRD requirement
|
||||||
|
- [ ] PRD → SyRS: Every PRD requirement traces back to a SyRS requirement
|
||||||
|
- [ ] SyRS → StRS: Every SyRS requirement traces back to a StRS requirement
|
||||||
|
|
||||||
|
### 5.3 Orphan Detection
|
||||||
|
|
||||||
|
- [ ] No StRS requirements without forward links
|
||||||
|
- [ ] No SyRS requirements without forward OR backward links
|
||||||
|
- [ ] No PRD requirements without forward links
|
||||||
|
- [ ] No stories without backward links to requirements
|
||||||
|
- [ ] No derived requirements without documented justification
|
||||||
|
|
||||||
|
### 5.4 Coverage Statistics
|
||||||
|
|
||||||
|
Calculate and report:
|
||||||
|
- Forward traceability coverage % at each level
|
||||||
|
- Backward traceability coverage % at each level
|
||||||
|
- Number of orphan requirements per level
|
||||||
|
- Number of derived (unlinked) requirements per level
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## CONSISTENCY REPORT
|
||||||
|
|
||||||
|
After completing all validation phases, produce a report:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# Cross-Document Consistency Report - {{project_name}}
|
||||||
|
|
||||||
|
**Date:** {{date}}
|
||||||
|
**Assessed By:** {{agent_name}}
|
||||||
|
**Documents Assessed:** {{list of documents found}}
|
||||||
|
|
||||||
|
## Overall Consistency Score: [HIGH / MEDIUM / LOW / CRITICAL ISSUES]
|
||||||
|
|
||||||
|
## Phase 1: Terminology Consistency
|
||||||
|
|
||||||
|
| Finding | Severity | Documents | Details |
|
||||||
|
|---------|----------|-----------|---------|
|
||||||
|
| [Finding] | [Critical/High/Medium/Low] | [Doc A ↔ Doc B] | [Specific text] |
|
||||||
|
|
||||||
|
## Phase 2: Requirements Alignment
|
||||||
|
|
||||||
|
### StRS ↔ PRD
|
||||||
|
| Check | Result | Details |
|
||||||
|
|-------|--------|---------|
|
||||||
|
|
||||||
|
### SyRS ↔ PRD
|
||||||
|
| Check | Result | Details |
|
||||||
|
|-------|--------|---------|
|
||||||
|
|
||||||
|
## Phase 3: Architecture Alignment
|
||||||
|
|
||||||
|
| Check | Result | Details |
|
||||||
|
|-------|--------|---------|
|
||||||
|
|
||||||
|
## Phase 4: Epics & Stories Alignment
|
||||||
|
|
||||||
|
| Check | Result | Details |
|
||||||
|
|-------|--------|---------|
|
||||||
|
|
||||||
|
## Phase 5: RTM Integrity
|
||||||
|
|
||||||
|
| Metric | Value | Target | Status |
|
||||||
|
|--------|-------|--------|--------|
|
||||||
|
| Forward Traceability (StRS→SyRS) | X% | >90% | PASS/FAIL |
|
||||||
|
| Forward Traceability (SyRS→PRD) | X% | >90% | PASS/FAIL |
|
||||||
|
| Forward Traceability (PRD→Stories) | X% | >95% | PASS/FAIL |
|
||||||
|
| Orphan Requirements | N | 0 | PASS/FAIL |
|
||||||
|
|
||||||
|
## Critical Issues Requiring Resolution
|
||||||
|
|
||||||
|
| Issue | Severity | Documents | Resolution Required |
|
||||||
|
|-------|----------|-----------|-------------------|
|
||||||
|
|
||||||
|
## Recommendations
|
||||||
|
|
||||||
|
[Prioritized list of actions to resolve consistency issues]
|
||||||
|
```
|
||||||
|
|
||||||
|
Save report to: `{planning_artifacts}/cross-document-validation-report-{{date}}.md`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ All available documents discovered and loaded
|
||||||
|
✅ Terminology consistency checked across all document pairs
|
||||||
|
✅ Requirements alignment verified at every level (StRS↔SyRS↔PRD)
|
||||||
|
✅ Architecture alignment checked against requirements and UX
|
||||||
|
✅ Epics & Stories coverage validated against PRD
|
||||||
|
✅ RTM integrity verified with coverage statistics
|
||||||
|
✅ Consistency report generated with specific, actionable findings
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Missing documents not flagged
|
||||||
|
❌ Terminology inconsistencies not caught
|
||||||
|
❌ Orphan requirements not detected
|
||||||
|
❌ Scope creep in stories not flagged
|
||||||
|
❌ Broken traceability links not identified
|
||||||
|
❌ Vague findings without specific document references
|
||||||
|
❌ Not checking all document pair combinations
|
||||||
|
|
@ -0,0 +1,118 @@
|
||||||
|
---
|
||||||
|
change_id: "CR-{{sequence_number}}"
|
||||||
|
title: "{{change_title}}"
|
||||||
|
date_submitted: "{{date}}"
|
||||||
|
submitted_by: "{{agent_name}}"
|
||||||
|
status: "proposed"
|
||||||
|
priority: "{{Must|Should|Could|Won't}}"
|
||||||
|
baseline_version: "{{current_baseline_version}}"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Requirements Change Request: {{change_id}}
|
||||||
|
|
||||||
|
## 1. Change Identification
|
||||||
|
|
||||||
|
| Field | Value |
|
||||||
|
|-------|-------|
|
||||||
|
| **Change ID** | {{change_id}} |
|
||||||
|
| **Title** | {{change_title}} |
|
||||||
|
| **Date Submitted** | {{date}} |
|
||||||
|
| **Submitted By** | {{agent_name}} |
|
||||||
|
| **Priority** | {{Must / Should / Could / Won't}} |
|
||||||
|
| **Category** | {{New Requirement / Modification / Deletion / Clarification}} |
|
||||||
|
|
||||||
|
## 2. Change Description
|
||||||
|
|
||||||
|
### What is being changed?
|
||||||
|
|
||||||
|
{{Detailed description of the proposed change}}
|
||||||
|
|
||||||
|
### Rationale
|
||||||
|
|
||||||
|
{{Why this change is necessary - link to stakeholder need, user feedback, technical discovery, or defect}}
|
||||||
|
|
||||||
|
### Source
|
||||||
|
|
||||||
|
{{Where did this change request originate - stakeholder name, user interview, technical finding, etc.}}
|
||||||
|
|
||||||
|
## 3. Affected Requirements
|
||||||
|
|
||||||
|
| Requirement ID | Document | Current Text | Proposed Change |
|
||||||
|
|---------------|----------|-------------|-----------------|
|
||||||
|
| {{REQ-ID}} | {{StRS/SyRS/PRD}} | {{Current requirement text}} | {{New/modified text or "DELETE"}} |
|
||||||
|
|
||||||
|
## 4. Impact Analysis
|
||||||
|
|
||||||
|
### 4.1 Document Impact
|
||||||
|
|
||||||
|
| Document | Impact Level | Description |
|
||||||
|
|----------|-------------|-------------|
|
||||||
|
| StRS | {{None / Low / Medium / High}} | {{What changes needed}} |
|
||||||
|
| SyRS | {{None / Low / Medium / High}} | {{What changes needed}} |
|
||||||
|
| PRD/SRS | {{None / Low / Medium / High}} | {{What changes needed}} |
|
||||||
|
| Architecture | {{None / Low / Medium / High}} | {{What changes needed}} |
|
||||||
|
| UX Design | {{None / Low / Medium / High}} | {{What changes needed}} |
|
||||||
|
| Epics & Stories | {{None / Low / Medium / High}} | {{What changes needed}} |
|
||||||
|
| Test Cases | {{None / Low / Medium / High}} | {{What changes needed}} |
|
||||||
|
|
||||||
|
### 4.2 RTM Impact
|
||||||
|
|
||||||
|
| Traceability Chain | Affected? | Details |
|
||||||
|
|-------------------|----------|---------|
|
||||||
|
| StRS → SyRS | {{Yes/No}} | {{Which links affected}} |
|
||||||
|
| SyRS → PRD | {{Yes/No}} | {{Which links affected}} |
|
||||||
|
| PRD → Stories | {{Yes/No}} | {{Which links affected}} |
|
||||||
|
| Stories → Tests | {{Yes/No}} | {{Which links affected}} |
|
||||||
|
|
||||||
|
### 4.3 Scope Impact
|
||||||
|
|
||||||
|
- **Scope Change:** {{Increase / Decrease / Neutral}}
|
||||||
|
- **Effort Estimate:** {{Minimal / Moderate / Significant}}
|
||||||
|
- **Timeline Impact:** {{None / Minor delay / Major delay}}
|
||||||
|
- **Risk Assessment:** {{Low / Medium / High}}
|
||||||
|
|
||||||
|
## 5. Baseline Comparison
|
||||||
|
|
||||||
|
**Current Baseline Version:** {{baseline_version}}
|
||||||
|
|
||||||
|
| Aspect | Baseline State | Proposed State |
|
||||||
|
|--------|---------------|---------------|
|
||||||
|
| {{Requirement count}} | {{N}} | {{N+/-M}} |
|
||||||
|
| {{Scope boundary}} | {{Current}} | {{Proposed}} |
|
||||||
|
| {{Architecture impact}} | {{Current}} | {{Proposed}} |
|
||||||
|
|
||||||
|
## 6. Approval
|
||||||
|
|
||||||
|
| Role | Decision | Date | Notes |
|
||||||
|
|------|---------|------|-------|
|
||||||
|
| Product Manager | {{Approved / Rejected / Deferred}} | {{date}} | {{notes}} |
|
||||||
|
| Architect | {{Approved / Rejected / Deferred}} | {{date}} | {{notes}} |
|
||||||
|
| Stakeholder | {{Approved / Rejected / Deferred}} | {{date}} | {{notes}} |
|
||||||
|
|
||||||
|
**Final Decision:** {{APPROVED / REJECTED / DEFERRED}}
|
||||||
|
|
||||||
|
## 7. Implementation Plan
|
||||||
|
|
||||||
|
### 7.1 Document Updates Required
|
||||||
|
|
||||||
|
- [ ] StRS updated (if affected)
|
||||||
|
- [ ] SyRS updated (if affected)
|
||||||
|
- [ ] PRD/SRS updated (if affected)
|
||||||
|
- [ ] Architecture updated (if affected)
|
||||||
|
- [ ] UX Design updated (if affected)
|
||||||
|
- [ ] Epics & Stories updated (if affected)
|
||||||
|
- [ ] RTM updated with new traceability links
|
||||||
|
- [ ] Test cases updated (if affected)
|
||||||
|
- [ ] Baseline version incremented
|
||||||
|
|
||||||
|
### 7.2 Downstream Notifications
|
||||||
|
|
||||||
|
| Workflow/Agent | Action Required |
|
||||||
|
|---------------|----------------|
|
||||||
|
| {{Agent/Workflow}} | {{What needs to happen}} |
|
||||||
|
|
||||||
|
## 8. Change History
|
||||||
|
|
||||||
|
| Date | Action | By | Details |
|
||||||
|
|------|--------|-----|---------|
|
||||||
|
| {{date}} | Created | {{agent}} | Initial change request |
|
||||||
Loading…
Reference in New Issue