How to Gather Requirements

Gathering requirements is where the real understanding happens. It's not checking a box—it's deep work to surface what people actually need (as opposed to what they think they want).

Functional vs. Non-Functional Requirements

Functional requirements are what the system does. "Users can reset their password via email." "Admins can view a report of all orders from the past 30 days." "The system prevents duplicate entries." These are the features and behaviors.

Non-functional requirements are how well the system performs. "The dashboard loads in under 2 seconds." "The system can handle 10,000 concurrent users." "The system must be available 99.9% of the time." "Data must be encrypted in transit and at rest." "The application must support 10 languages." These affect architecture and infrastructure.

Both matter. A functional system that takes 10 seconds to load is unusable. A system that loads fast but does the wrong thing is useless.

Who to Talk To

For internal tools: Talk to the people who will use the tool. If you're building a dashboard for the sales team, interview sales reps, not just the sales VP. They use the system 8 hours a day. They know what they need.

For customer-facing applications: Interview actual users or target users. If you don't have them yet (you're pre-launch), interview people similar to your target market. Ask them what they do today, what's broken about it, what they wish existed.

For internal systems with multiple stakeholders: Talk to operations who use the system day-to-day, management who monitors metrics, and IT who maintains infrastructure. These groups often have conflicting requirements. You need to understand them all.

Don't just talk to the person who commissioned the project. They have perspective but they're one person with one view. The people who actually use the system have different priorities. You need both.

The Stakeholder Interview

A structured interview usually follows this pattern:

Context (5 minutes): "Tell me about your current process. Walk me through a typical day." Don't ask about the system yet—understand the work.

Pain points (10 minutes): "What's frustrating about how you work today?" "What takes too long?" "What causes errors?" Let them talk. Take notes. Don't jump to solutions yet.

Success criteria (10 minutes): "If this new system was perfect, what would be different?" "How would you know it was successful?" This gets at their actual needs beneath the pain points.

Specific features (15 minutes): Now you can ask about specific requirements. "Would you need to generate reports? What kind?" "How many people would use this?" "What data do you need to see?"

Constraints and edge cases (10 minutes): "Are there scenarios where the normal flow breaks?" "What happens if [unusual situation]?" "Are there regulations or compliance requirements?"

Total: ~50 minutes per person. Try to interview 3-5 people (or more if the system is complex). You'll see patterns—if 4 out of 5 people mention the same pain point, it's real. If one person mentions something unique, ask if it's a niche case or if others are too polite to say it matters to them too.

The Interviewer's Trap

When you ask a leading question like "Don't you think you need a dashboard?" people say yes because they're being polite or because you suggested it. Ask open-ended questions instead: "How do you currently track this metric?" then listen. Let them tell you what they need, not the other way around.

Documentation: Not a 100-Page Specification

Requirements don't need to be a formal specification. In fact, a 100-page spec that nobody reads is worse than useless. Requirements documentation should be:

Clear. Anyone on the team should be able to read it and understand what the system will do.

Organized. Group related requirements. Separate functional from non-functional. Have a table of contents.

Specific. Not "the system should be fast" but "the dashboard should load in under 2 seconds for 10,000 records."

Traceable. Every requirement should have an ID (like REQ-001) so you can reference it and track it.

Signed off. Stakeholders agree these are the right requirements before development starts.

Use a document (Notion, Confluence, Google Doc) with sections for:

Overview and scope
User types and personas
Functional requirements (organized by feature or workflow)
Non-functional requirements (performance, security, scalability, compliance)
Assumptions and constraints
Out of scope (what won't be included)
Open questions or risks

This can be 5-20 pages depending on complexity. The goal is clarity, not completeness.

Functional Requirements Format

A good functional requirement looks like: "The system shall allow users with admin role to delete archived projects. A confirmation dialog shall appear before deletion. Once deleted, the project cannot be recovered."

Not: "Implement project deletion." (Too vague—which roles? What confirmation? Can they be recovered?)

Functional requirements should answer:

Who can do this?
What are they doing?
What happens after?
What about edge cases?
What constraints exist?

Non-Functional Requirements Format

Performance: The system shall return search results in under 1 second for queries containing up to 1,000,000 records.

Scalability: The system shall support 10,000 concurrent users without performance degradation.

Availability: The system shall be available 99.9% of the time, excluding scheduled maintenance windows.

Security: All data shall be encrypted using AES-256 encryption at rest and TLS 1.2 in transit. User passwords shall not be stored in plaintext.

Compliance: The system shall comply with GDPR regulations including data retention policies and the right to be forgotten.

Be specific. "The system should be secure" is not a requirement. "All API calls shall use HTTPS with certificate pinning" is.

Common Requirement Gathering Failures

Talking only to the person who commissioned the project. That person has one perspective. Real users have different priorities. Get their input too.

Requirements that are actually solutions. "Build a mobile app" is a solution. "Sales reps need to access customer data while in the field" is a requirement. The solution could be a mobile app, a responsive web app, or integration with their CRM.

Ignoring edge cases. The normal case is obvious. Edge cases are where systems fail. What happens when there's no internet? When the API is slow? When the user has 100,000 records? When two people try to edit the same thing?

Vague language. "The system should be user-friendly" or "reports should be easy to generate." These mean different things to different people. What does user-friendly actually mean? Fewer clicks? Self-explanatory? Can be learned without training?

Forgetting to ask about integrations. "Do you need to integrate with other systems?" Most organizations do. The Salesforce integration, the accounting software, the payment processor. Discovering mid-project that you need an integration adds weeks.

The Sign-Off

Once requirements are documented, get stakeholder sign-off. Have people who represent different user groups sign (or digitally confirm) that these requirements are correct. This serves two purposes:

It forces a final alignment. Often, writing requirements down reveals misalignment. Stakeholder A thought feature X was in scope; stakeholder B thought it wasn't. Better to discover this before development starts.

It provides a reference. If mid-project someone says "but we also need this," you can point to the signed requirements and ask if it was missed, or if it's a change request that should be assessed for impact.

The sign-off doesn't need to be formal. An email saying "I reviewed the requirements document and everything looks right" is sufficient. Or a comment on the document saying "Approved by [Name] on [Date]."