From e0b1b7cd9da3c57b0454eff4bdbbc5a25fd4418d Mon Sep 17 00:00:00 2001 From: Tolga Karatas Date: Mon, 16 Feb 2026 01:26:50 +0300 Subject: [PATCH] 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 --- .../shared/change-management/checklist.md | 53 ++++ .../shared/change-management/workflow.md | 190 +++++++++++ .../cross-document-validation/workflow.md | 294 ++++++++++++++++++ .../templates/change-request-template.md | 118 +++++++ 4 files changed, 655 insertions(+) create mode 100644 src/bmm/workflows/shared/change-management/checklist.md create mode 100644 src/bmm/workflows/shared/change-management/workflow.md create mode 100644 src/bmm/workflows/shared/cross-document-validation/workflow.md create mode 100644 src/bmm/workflows/shared/templates/change-request-template.md diff --git a/src/bmm/workflows/shared/change-management/checklist.md b/src/bmm/workflows/shared/change-management/checklist.md new file mode 100644 index 000000000..8093a97c7 --- /dev/null +++ b/src/bmm/workflows/shared/change-management/checklist.md @@ -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 diff --git a/src/bmm/workflows/shared/change-management/workflow.md b/src/bmm/workflows/shared/change-management/workflow.md new file mode 100644 index 000000000..0dc416167 --- /dev/null +++ b/src/bmm/workflows/shared/change-management/workflow.md @@ -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 diff --git a/src/bmm/workflows/shared/cross-document-validation/workflow.md b/src/bmm/workflows/shared/cross-document-validation/workflow.md new file mode 100644 index 000000000..8b6133533 --- /dev/null +++ b/src/bmm/workflows/shared/cross-document-validation/workflow.md @@ -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 diff --git a/src/bmm/workflows/shared/templates/change-request-template.md b/src/bmm/workflows/shared/templates/change-request-template.md new file mode 100644 index 000000000..b91cd9183 --- /dev/null +++ b/src/bmm/workflows/shared/templates/change-request-template.md @@ -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 |