Requirements Elicitation
Functional vs non-functional, user stories, epics, acceptance criteria, MoSCoW
Requirements elicitation is the structured process of discovering, analyzing, and documenting what a system must do (functional requirements) and how well it must do it (non-functional requirements). User stories ("As a [role], I want [goal] so that [benefit]") capture functional needs at the feature level, while epics group related stories into business capabilities. Acceptance criteria define the precise conditions under which a story is "done," and the MoSCoW method (Must Have, Should Have, Could Have, Won't Have) provides a negotiation framework when scope must be cut. Inadequate requirements elicitation is cited as the #1 cause of project failure in the CHAOS Report (Standish Group).
Key Points
- Functional requirements define behavior: "the system shall process a payment and return a confirmation within 3 seconds" — specific, testable, behavioral
- Non-functional requirements (NFRs) define quality attributes: performance (p99 < 200ms), availability (99.9%), security (SOC 2 Type II), and must be quantified with acceptance thresholds
- User story format: As a [persona], I want [action] so that [business value]; acceptance criteria use Given/When/Then (Gherkin) format for testability
- Epic = large user story decomposed into multiple smaller stories that fit within 1–2 sprints; epics map to business capabilities in the product roadmap
- MoSCoW prioritization: Must Haves are non-negotiable for launch (legal, core UX); Should Haves are high-value but deferrable; Could Haves are nice-to-have scope for buffer; Won't Haves are explicitly out of scope for this release
- Elicitation techniques: structured interviews (with prepared question frameworks), event storming (DDD), user journey mapping, context diagrams (C4 Level 1), and reviewing existing system analytics
- Requirements traceability matrix: links each requirement to its source (stakeholder/regulation), design decision, implementation ticket, and test case — critical for regulated industries (FDA, HIPAA)
- NFR prioritization: use a trade-off matrix when NFRs conflict (high availability vs consistency in CAP); get explicit stakeholder sign-off on which attribute takes precedence
| Priority | MoSCoW Category | Decision Criteria | Real-World Example | Launch Impact if Missing |
|---|---|---|---|---|
| P0 | Must Have | Legal obligation, core safety, or system cannot function without it | PCI-DSS compliant payment processing for an e-commerce checkout | Cannot launch — legal or existential risk |
| P1 | Should Have | High business value; significant user pain if absent; workaround exists but poor UX | Real-time inventory updates on product pages to prevent overselling | Launch with caveat; fix in sprint 1 post-launch |
| P2 | Could Have | Desirable feature; improves experience but users can self-serve workaround | Save payment method for one-click future checkout | Deferred to v1.1; noted in release notes |
| P3 | Won't Have (this release) | Explicitly agreed as out of scope; documented to prevent scope creep | Multi-currency support; international shipping calculator | Excluded from contract scope; planned for Q3 |
Real-World Example
Amazon's "Working Backwards" process inverts traditional requirements: engineers write the press release and FAQ for a new feature before writing a line of code, forcing clarity on the customer benefit before technical decisions are made.