Requirements Gathering & User Stories

What it is

Requirements gathering translates a business or customer need into a specific, testable description of what should be built — the gap between "users want faster search" and something an engineering team can actually estimate and build.

Key points

• User stories follow "as a [user], I want [goal], so that [benefit]" — the benefit clause matters because it lets engineers make good judgment calls on details the story doesn't spell out.
• Acceptance criteria define exactly when a story is done — without them, "done" becomes a matter of opinion between PM and engineer.
• Edge cases and non-functional requirements (performance, error states, empty states) are the most commonly missed part of a spec — these get discovered late and expensively if requirements gathering skips them.
• Requirements are a living artifact — they get refined as engineering surfaces new constraints, not written once and frozen.