The structured process of identifying and documenting what a product or feature must do, for whom, and under what constraints — collecting input from users, stakeholders, subject matter experts, and existing data. Requirements gathering translates business intent and user needs into specific, testable criteria that guide design and development decisions.
Common contexts
- Facilitating a cross-functional workshop to capture must-have versus nice-to-have criteria before scoping a new feature
- Interviewing customer success managers to surface the three workflow problems that generate the most support tickets
- Documenting technical, legal, and accessibility constraints from engineering and legal teams before beginning concept exploration
Use when
Invest in structured requirements gathering at the start of any project with multiple stakeholders, regulatory constraints, or legacy system dependencies — when undiscovered requirements discovered late in development are expensive to accommodate.
Avoid when
Don't run an exhaustive requirements gathering process for small, low-risk improvements — attempting to fully specify a minor UI enhancement before sketching anything stalls momentum and produces documentation that's obsolete by the time design begins.
The most important requirements are rarely stated upfront — they're the constraints that stakeholders assume are obvious and therefore never mention, which is why requirements gathering is fundamentally a listening exercise, not a documentation one.
Real-world examples
- Salesforce's enterprise UX team spends 4–6 weeks on requirements gathering before any design work begins for major features, interviewing IT admins, sales managers, and end users separately to surface conflicting needs.
- The UK Universal Credit digital service gathered requirements through 200+ contextual interviews with benefits claimants before writing a single user story, ensuring the service addressed actual life circumstances rather than assumed ones.
- Agile teams at Atlassian use structured requirements-gathering workshops with three user proxy roles (customer, support, engineer) to surface conflicting assumptions within a single 90-minute session.