writing-requirementslisted

# Writing Requirements ## Overview Turns validated discovery into **buildable, testable** specifications. The core discipline: a requirement states the *what/why* (the need), not the *how* (the design), and every requirement must be **verifiable** — if no test or observation can confirm "done," it's at the wrong level of detail. ## User stories - **Template:** "As a [user], I want [goal], so that [reason]." The "so that" captures value and guides prioritization. - **INVEST** quality: **I**ndependent, **N**egotiable, **V**aluable, **E**stimable, **S**mall, **T**estable. - **A story is a placeholder for a conversation** — the **3 C's**: **Card** (brief written token), **Conversation** (where the real detail emerges), **Confirmation** (acceptance criteria/tests). - **Split vertically** (each slice still delivers end-to-end value) with **SPIDR**: **S**pike (research), **P**aths (one user path per story), **I**nterfaces (progressive UI), **D**ata (limit data scope first), **R**ules (relax a business rule, add later). ## Acceptance criteria - **Given/When/Then** (Gherkin): *Given* a context, *When* an action, *Then* an observable outcome. ~3–5 criteria per story; assert observable behavior, not internal state. - **Rule-oriented** (a checklist of behaviors that must always hold) vs. **scenario-oriented** (concrete examples). Use rules for general constraints, scenarios for end-to-end flows; iterate from rules toward scenarios. - **Specification by Example** (Adzic): collaborat