majiayu000 Change Request Analysis Expertise
When This Applies
Apply this guidance when:
- Creating a new Change Request (CR)
- Evaluating the feasibility of a proposed change
- Estimating scope and effort
- Assessing risk and impact of changes
CR Quality Checklist
Every Change Request should include:
- Clear Problem Statement — What problem does this solve? Why now?
- Specific Requirements — Measurable, testable acceptance criteria
- Scope Boundaries — What is explicitly out of scope
- Impact Assessment — Which components, APIs, or data are affected
- Priority Justification — Why this priority level
Scope Estimation
Sizing Guide
| Scope | Description | Typical Tasks | Typical Duration |
|---|---|---|---|
| Small | Single component change, no new APIs | 1-2 tasks | 1-2 sessions |
| Medium | Multiple components, possible new API | 3-5 tasks | 2-4 sessions |
| Large | System-wide change, new architecture | 6+ tasks | 5+ sessions |
Scope Red Flags
Watch for CRs that should be broken down further:
- Touches more than 3 project directories
- Requires changes to both frontend and backend
- Needs database schema changes alongside feature work
- Has more than 5 distinct requirements
- Affects authentication or authorization flows
Impact Analysis
Before finalizing a CR, assess:
- Breaking Changes — Will this break existing functionality or APIs?
- Data Impact — Are database migrations needed? Is data at risk?
- Dependency Impact — Will other in-progress CRs be affected?
- Test Impact — Do existing tests need updating?
- Infrastructure Impact — Are deployment or config changes needed?
CR Workflow
- Draft the CR with all required fields
- Set priority based on impact and urgency
- Assign to Architect for technical design
- Track through:
open→in_progress→completed→closed - Don't create implementation tasks until Architect has designed the solution