Requirements gathering (also called elicitation) is the process of discovering, documenting, and validating what stakeholders need from the project. It bridges the gap between a business problem and a workable solution. Get this wrong, and everything built on top — design, development, testing — will be wrong too.
Types of Requirements
Not all requirements are the same. Understanding the categories helps ensure nothing important is missed:
Functional Requirements
- What the system must do
- Features, behaviors, functions
- "The system shall allow users to reset their password via email"
- "The report shall generate daily at 6:00 AM"
Non-Functional Requirements
- How the system must perform
- Quality attributes, constraints
- "The page must load within 2 seconds"
- "The system must support 10,000 concurrent users"
Beyond this primary split, requirements can also include:
- Business requirements: High-level needs of the organization ("Reduce customer churn by 15%")
- User requirements: What users need to accomplish ("I need to track my order status")
- System requirements: Technical specifications ("Must integrate with SAP via REST API")
- Transition requirements: Temporary needs for migration ("Data from legacy system must be migrated with zero downtime")
Gathering Techniques
No single technique captures all requirements. Effective gathering uses a combination:
Interviews
One-on-one or small group conversations with stakeholders. Best for deep understanding of individual needs, concerns, and context. Prepare questions but allow organic exploration.
Workshops
Facilitated group sessions (e.g., JAD — Joint Application Design). Bring multiple stakeholders together to discuss, negotiate, and agree on requirements in real-time. Efficient for resolving conflicts.
Surveys & Questionnaires
Useful for gathering input from a large number of stakeholders. Best for quantitative data and validating assumptions. Less effective for complex or nuanced requirements.
Observation
Watch users in their actual work environment. Reveals workflows, pain points, and workarounds that people often forget to mention in interviews. "Show me" beats "tell me."
Document Analysis
Review existing documentation — process flows, current system specs, SOPs, regulatory documents, previous project reports. Provides baseline understanding before stakeholder engagement.
Prototyping
Build a quick mockup or wireframe and use it to elicit feedback. Stakeholders often can't articulate what they need until they see something concrete. "I'll know it when I see it."
User Stories
Agile format: "As a [role], I want [feature], so that [benefit]." Keeps requirements user-centric and tied to value. Complemented by acceptance criteria for testability.
Brainstorming
Open-ended idea generation with a group. Useful early on to explore possibilities before narrowing down. Use techniques like mind mapping or affinity diagrams to organize output.
Requirements Documentation
How you document requirements depends on your approach:
| Approach | Document Format | Best For |
|---|---|---|
| Predictive (Waterfall) | Software Requirements Specification (SRS), Business Requirements Document (BRD) | Large, complex, regulated projects |
| Adaptive (Agile) | Product Backlog with User Stories, acceptance criteria, and Definition of Done | Iterative delivery, evolving requirements |
| Hybrid | Lightweight BRD for high-level scope + User Stories for detailed features | Governance + flexibility balance |
Validation & Prioritization
Validating Requirements
Every requirement should be checked against these quality criteria:
- Clear: Unambiguous — only one interpretation possible
- Complete: Contains all necessary information to implement
- Consistent: Doesn't contradict other requirements
- Testable: You can verify whether it's been met or not
- Feasible: Technically and financially achievable
- Traceable: Can be linked back to a business need and forward to a test case
Prioritizing Requirements
Not everything can be built at once. Common prioritization methods include:
- MoSCoW: Must have, Should have, Could have, Won't have (this time)
- Kano Model: Categorize into Basic (expected), Performance (more is better), and Delighter (unexpected value)
- Value vs. Effort Matrix: Plot requirements by business value and implementation effort — do high-value/low-effort first
- Weighted Scoring: Rate requirements against multiple criteria (business value, risk, cost, urgency) and calculate a weighted score
Common Pitfalls
- Asking "what do you want?" instead of "what problem are you solving?": Stakeholders often describe solutions, not problems. Dig deeper to understand the underlying need.
- Gold plating: Adding features nobody asked for because the team thinks they're "nice to have." This wastes time and budget.
- Analysis paralysis: Spending too long perfecting requirements before starting work. In Agile, you refine as you go. In Waterfall, aim for "good enough" — not perfect.
- Ignoring non-functional requirements: Performance, security, usability, and accessibility are often overlooked until too late. They're harder to retrofit.
The best requirements gatherers are translators — they speak both business and technical languages. They listen more than they talk, ask "why" relentlessly, and document not just what stakeholders say, but what they actually mean. Remember: a requirement that can't be tested is just a wish.