Guides requirements lifecycle per CMMI RD/REQM: elicitation, analysis, prioritization, specification, bidirectional traceability, change control, and RTM. Use for scope creep, audits, volatility.
npx claudepluginhub tachyon-beep/skillpacks --plugin axiom-sdlc-engineeringThis skill uses the workspace's default tool permissions.
This skill guides the complete **requirements lifecycle** from elicitation through change management. It covers both CMMI process areas:
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
This skill guides the complete requirements lifecycle from elicitation through change management. It covers both CMMI process areas:
Key capabilities:
Reference: See docs/sdlc-prescription-cmmi-levels-2-4.md Section 3.1 (Requirements Phase) for complete CMMI policy.
Use this skill when:
When NOT to use this skill:
Requirements Development (RD) = Creating new requirements
Requirements Management (REQM) = Maintaining existing requirements
Timeline: RD happens during requirements phase. REQM is continuous throughout the project.
Common mistake: Treating them as sequential. They're concurrent - you develop new requirements while managing existing ones.
The Modern Approach (Recommended):
Traceability as workflow byproduct using platform-native linking:
GitHub:
- Commit message: "Implements #123" → auto-links to requirement
- PR description: "Closes #123" → auto-links to requirement
- Test file comment: "Verifies #123" → searchable reference
- Generate RTM on-demand via API query (for audits)
Azure DevOps:
- Commit message: "AB#123" → auto-links to work item
- Built-in traceability views (work item → commits → builds)
- Query for RTM when needed
Key principle: Traceability should be free (part of normal workflow), not a separate manual task.
Anti-Pattern: Manual spreadsheet RTM that becomes stale within days.
Level 2: Platform linking is sufficient (GitHub Issues ↔ PRs ↔ commits) Level 3: Tool-based queries to generate traceability reports Level 4: Automated coverage metrics (% requirements traced, orphaned tests detected)
See requirements-traceability.md for GitHub/Azure DevOps implementation patterns.
Baseline agents said: "Perform impact analysis" (but didn't say HOW).
This skill provides: Impact analysis checklist and template.
Minimal Impact Analysis (Level 2):
Change Request: Add OAuth login support
Affected Requirements: REQ-AUTH-001, REQ-AUTH-002
Impact:
- Design: New OAuth module needed
- Implementation: 3 days effort
- Testing: 5 new test cases (2 days)
- Documentation: User guide update (1 day)
Total Effort: 6 days
Schedule Impact: Delays Sprint 3 → Sprint 4
Approval: Product Owner (required)
Formal Impact Analysis (Level 3):
requirements-change-management.md)Quantitative Impact Analysis (Level 4):
See requirements-change-management.md for complete templates and workflows.
Two enforcement mechanisms:
1. MoSCoW Prioritization
Classify every requirement:
Enforcement: Once sprint capacity is reached (e.g., 30 story points), all new additions must be "Could Have" or "Won't Have". Product Owner can't add "Must Have" mid-sprint without removing existing "Must Have".
2. Change Request Process
Level 2: Lightweight - Product Owner approval, informal impact assessment Level 3: Formal - Change request form, multi-party approval, documented impact Level 4: Quantitative - Change metrics tracked, volatility thresholds enforced
Red flag: >30% requirements changed per sprint → Scope thrashing, need stakeholder stabilization meeting.
See requirements-analysis.md for prioritization templates and conflict resolution.
Biggest misconception: Level 3 requires 100-page specs and waterfall.
Reality:
| Aspect | Level 2 | Level 3 | Level 4 |
|---|---|---|---|
| Format | User stories + acceptance criteria | Organizational template | + Quality metrics |
| Review | Optional/informal | Peer review required | + Defect density tracking |
| Traceability | Spreadsheet OR platform links | Tool-based, API-generated | + Coverage metrics (>95%) |
| Changes | Tracked in issue history | Formal change requests, approval workflow | + Volatility metrics, SPC |
| Effort | 3-5% project time | 10-15% project time | 15-20% project time |
Escalation from L2 → L3:
Escalation from L3 → L4:
See level-scaling.md for complete escalation criteria and de-escalation guidance.
Which scenario applies to you?
What's your primary need?
├─ Starting a new feature from scratch → Scenario 1
├─ Requirements changing constantly → Scenario 2
├─ Stakeholders in conflict → Scenario 3
├─ Preparing for audit, need RTM → Scenario 4
└─ Unsure how much documentation needed → Scenario 5
Scenario 1: New Feature, Starting from Scratch
requirements-elicitation.md - Run stakeholder workshoprequirements-specification.md - Document as user stories (L2) or template (L3)requirements-traceability.md - Set up GitHub/Azure DevOps linkingTimeline: 1-2 days for Level 2, 3-5 days for Level 3
Scenario 2: Constant Changes, Volatility Management
requirements-change-management.md - Implement change request processScenario 3: Stakeholder Conflict, Two VPs Want Different Things
requirements-analysis.md - Conflict resolution sectiongovernance-and-risk skill for ADR processDo NOT: Make the business decision yourself, pick sides, or implement both hoping it works out.
Scenario 4: Audit Preparation, Need RTM
requirements-traceability.md - GitHub/Azure DevOps RTM patternsTarget: >90% coverage for Level 3, >95% for Level 4
Scenario 5: "How much documentation?" Question
level-scaling.md - Shows exactly what Level 2/3/4 requirerequirements-elicitation.md)When to load: Starting requirements gathering, unclear requirements, stakeholder workshops, new project kickoff
Gather requirements from stakeholders using structured techniques:
Provides: Interview scripts, workshop agendas, prototyping workflows, stakeholder mapping templates
Load reference: See requirements-elicitation.md for complete elicitation techniques.
requirements-analysis.md)When to load: Conflicting requirements, prioritization needed, scope management, gold plating concerns
Analyze and prioritize requirements, resolve conflicts:
Provides: MoSCoW templates, conflict analysis templates, completeness checklists, decision matrices
Load reference: See requirements-analysis.md for prioritization and conflict resolution.
requirements-specification.md)When to load: Writing requirements, creating user stories, defining acceptance criteria, documentation standards
Document requirements in appropriate formats:
Provides: User story templates, use case templates, SRS outline, acceptance criteria checklist
Load reference: See requirements-specification.md for specification formats and templates.
requirements-traceability.md)When to load: Creating RTM, establishing traceability, audit preparation, compliance verification
Implement bidirectional traceability between requirements, design, and tests:
Provides: RTM templates, GitHub/Azure DevOps linking patterns, verification queries, automation scripts
Load reference: See requirements-traceability.md for platform-specific traceability implementation.
requirements-change-management.md)When to load: Requirements changing frequently, volatility management, impact analysis, change approval
Manage requirements changes systematically:
Provides: Change request forms, impact analysis templates, approval matrices, volatility tracking dashboards
Load reference: See requirements-change-management.md for change control processes.
level-scaling.md)When to load: Choosing CMMI level, scaling practices, understanding requirements, documentation overhead concerns
Understand what changes across maturity levels:
Provides: Level comparison tables, escalation decision trees, overhead estimates, team size guidelines
Load reference: See level-scaling.md for complete maturity level guidance.
How to access:
"I need detailed guidance on [topic]"
→ Load the appropriate reference sheet from the list above
When you need a reference:
Cross-references: Reference sheets link to:
platform-integration skill for tool-specific implementationsgovernance-and-risk skill for ADR process and decision analysis