Requirements Gathering Techniques

What Are Requirements?

18 min Lesson 1 of 10

What Are Requirements?

Before a single line of code is written, before a database schema is sketched, before a wireframe is drawn — someone must answer a deceptively simple question: what exactly does this system need to do? The answer to that question lives in the requirements. Requirements are the foundation of every software project, and getting them right is the single most powerful way to reduce cost, rework, and project failure.

In formal terms, a requirement is a condition or capability that a system must possess to satisfy a business need, to fulfil a contract, or to comply with a regulation. Analysts distinguish three interconnected levels of requirement, each addressing a different audience and a different level of detail.

The Three Levels of Requirements

Consider a growing clinic that decides to replace its paper appointment book with a digital booking system. Three very different conversations will take place:

Business Requirements — The clinic director says: "We need to reduce no-shows by 30 % and give patients the ability to book outside office hours." This is a business requirement. It expresses a goal, a problem, or an opportunity at the organisational level. It does not tell the development team what to build; it tells them why to build it. Business requirements are owned by executive sponsors and senior stakeholders.
User Requirements — The receptionist says: "I need to view all appointments for the day on one screen, cancel a booking with a single click, and send the patient an SMS reminder." This is a user requirement (sometimes called a stakeholder requirement). It describes what a specific category of person needs to be able to do with the system. User requirements are written in plain language, often captured as use cases or user stories.
System Requirements — The developer says: "The system shall send an SMS notification no later than 24 hours before the appointment. The booking API shall respond in under 200 ms under a concurrent load of 500 users. Patient records shall be encrypted at rest using AES-256." These are system requirements. They specify precisely what the software must do (functional requirements) and how well it must do it (non-functional requirements). System requirements are the direct input to design and construction.

The three requirement levels: each builds on the one above, moving from strategic goals down to precise technical specifications.

Key idea: Every system requirement must ultimately be traceable back to at least one user requirement, and every user requirement must serve at least one business requirement. This chain — called requirements traceability — is how analysts prove that what is being built actually matters to the business.

Functional vs. Non-Functional Requirements

Within the system-requirements level, analysts draw a crucial distinction:

Functional requirements describe what the system does — the behaviours, rules, and data transformations it must perform. Example: "The system shall allow a registered patient to cancel a booking up to 2 hours before the scheduled time."
Non-functional requirements (NFRs) describe how well it does it — quality attributes such as performance, security, scalability, availability, usability, and compliance. Example: "The cancellation confirmation email shall be delivered within 30 seconds of the user action in 99 % of cases."

A common mistake is to capture only functional requirements and treat NFRs as an afterthought. In practice, NFRs often drive architectural decisions more than any functional feature does. An online retailer that handles 10 000 concurrent checkout sessions during a flash sale has very different architecture from one that handles 50 a day — even if every functional requirement is identical.

Best practice: Write NFRs as measurable acceptance criteria from the start. "The system shall be fast" is useless. "The product-search page shall return results within 400 ms at the 95th percentile under 2 000 concurrent users" is testable and actionable.

Why Requirements Elicitation Is Hard

If requirements are so important, why are they so often wrong? Research from the Standish Group consistently finds that incomplete, ambiguous, or constantly-changing requirements are the leading causes of project failure. The difficulty comes from several sources:

The knowledge gap. Stakeholders are domain experts but not systems thinkers. They know what they do every day, but they struggle to articulate it in a form an analyst or developer can act on. A logistics dispatcher may not realise they apply a dozen mental heuristics when assigning routes — until you watch them work.
The communication gap. Analysts and developers use technical vocabulary; business users use domain vocabulary. The same word can mean completely different things. At one logistics firm, "delivery date" meant the date the goods left the warehouse to the operations team, but the date the customer signed the receipt to the accounts team — a difference that caused months of reconciliation errors.
The tacit knowledge problem. Much of what expert users know is subconscious. They cannot tell you what they know because they are not aware they know it. Observation and prototyping are often the only ways to surface this hidden knowledge.
Changing business context. Business goals shift during a project. A requirements baseline agreed in January may be partially obsolete by June. Managing change without allowing scope creep is a perpetual challenge.
Multiple conflicting stakeholders. The clinic director wants appointment slots to be as short as possible to maximise throughput. The doctor wants longer slots for complex cases. The patient wants convenient times. The IT manager wants minimal custom development. Balancing these competing interests requires negotiation, not just documentation.

Five root causes that make requirements elicitation harder than it first appears — each demands a different mitigation strategy.

Requirements in Context: A Realistic Example

An online store hires a business analyst to help them build a loyalty-points system. Early conversations surface a tangle of assumptions. The marketing director wants points awarded immediately so customers feel rewarded. The finance controller wants points awarded only after the return window closes to prevent fraud. The mobile team assumes points will be visible in the app; no one has told them about a planned kiosk terminal in stores. Each perspective is legitimate. The analyst's job is to surface these conflicts before development begins — not during user-acceptance testing when they cost ten times as much to fix.

This is why elicitation is not a single meeting or a questionnaire. It is a structured, iterative campaign that uses multiple techniques — interviews, workshops, observation, prototyping, and document analysis — to build a shared, agreed, and verifiable understanding of what the system must do. The remaining lessons in this tutorial cover each technique in depth.

Common pitfall: Treating requirements gathering as a one-time event at the start of a project. Requirements are a living baseline. Even on a waterfall project, every change request is a requirements activity. On agile projects, the backlog is a continuously refined requirements repository. Analysts who stop listening after the kickoff workshop almost always produce systems that miss the mark.

Summary

Business requirements state the organisational why — goals, problems, and opportunities.
User requirements state who needs what — capabilities required by each stakeholder role.
System requirements state the technical how — functional behaviours and measurable non-functional qualities.
Requirements elicitation is difficult because of knowledge gaps, communication gaps, tacit knowledge, changing context, and stakeholder conflict.
Getting requirements right early is the highest-return investment on any software project.