requirement-decomposer

Requirement Decomposer

You are decomposing SRS specifications into agile delivery artifacts. Follow the two-layer architecture, decomposition rules, and quality criteria below.

Two-Layer Architecture

SPECIFICATION LAYER (stable, formal review)    DELIVERY LAYER (disposable, re-splittable)
──────────────────────────────────────────     ─────────────────────────────────────────
HLR / Use Case / Workflow              ──→     Epic
Use Case steps / Screen / Object       ──→     User Story
Business Rules / NFRs                  ──→     Acceptance Criteria / DoD items
All specs                              ──→     Release Plan (timeline overlay)
Refinement sessions                    ──→     Backlog Refinement (bridge)
Sprint execution                       ──→     Sprint (iteration record)

Key principle: Specs are stable, stories are disposable. You can throw away all stories and re-decompose from specs without losing any requirement.

Decomposition Rules

See decomposition-rules.md for the full mapping table with heuristics.

Acceptance Criteria Derivation

See acceptance-criteria.md for how to derive Given/When/Then from specs.

INVEST Checklist (Enforce for Every Story)

Criterion	Question	Fix if No
Independent	Can this story be delivered without waiting for other stories?	Remove dependency or merge stories
Negotiable	Is implementation flexible (not dictating HOW)?	Rewrite to focus on what, not how
Valuable	Does it deliver user-facing or stakeholder value?	If pure tech task, attach to a valuable story
Estimable	Can the team estimate effort?	Break into smaller pieces or spike first
Small	Fits in a single sprint?	Split if >8 SP
Testable	Are ACs unambiguous Given/When/Then?	Rewrite ACs until testable

Story Sizing Guide

SP	Complexity	Example
1	Trivial, config only	Toggle feature flag
2	Simple, well-understood	Add read-only field to form
3	Moderate, some logic	Form validation with 2-3 rules
5	Significant, multiple components	CRUD endpoint + form + validation
8	Large, complex logic	Hierarchical class picker with inheritance
13	Very large — must split	End-to-end flow with integration

Handling Incomplete Specs

When decomposing a spec that has gaps (missing fields, TBD sections, incomplete exception flows):

1. Flag gaps explicitly — list what's missing and how it affects decomposition
2. Decompose what you can — create stories for the complete portions
3. Create placeholder stories — for TBD areas, create stories marked as "Draft" with a note: "Blocked: awaiting spec completion for [section]"
4. Suggest spec completion — recommend the user fill in the gaps with /review-spec <code> or by editing the spec directly

Never silently invent requirements to fill gaps. Always surface missing information.

Decomposition Example

Given a Use Case with steps like:

1. User opens the Create Order form
2. System displays form with project context
3. User selects category from dropdown
4. System auto-populates inherited fields
5. User fills remaining fields and clicks Save
6. System validates and creates the order

The decomposition produces:

• Story 1: "Display Create Order form with project context" (steps 1-2)
• Story 2: "Select Category with hierarchical dropdown" (step 3)
• Story 3: "Auto-populate inherited fields on category selection" (step 4)
• Story 4: "Validate and save Order record" (steps 5-6)

Each story gets ACs derived from the UC steps, exception flows, and business rules using the patterns in acceptance-criteria.md.

Sprint Capacity Planning

When planning sprints:

• Velocity estimation: If no historical data, assume 8 SP/developer/sprint for a 2-week sprint
• Buffer: Plan 70-80% of capacity (leave room for bugs, tech debt, meetings)
• Dependencies: Data model stories before UI stories, API stories before integration stories
• Risk: Front-load high-risk or uncertain stories so blockers surface early

Reference

See templates/README.md for the full guide on how specification and delivery layers connect.