Requirements Gathering Techniques

Choosing & Combining Techniques

18 min Lesson 9 of 10

Choosing & Combining Techniques

By now you have a full toolkit: interviews, questionnaires, observation, document analysis, workshops, brainstorming, and prototyping. The hardest skill in requirements engineering is not mastering any single technique — it is knowing which technique to reach for in a given situation, and how to weave several of them together into a coherent elicitation campaign. Choosing poorly wastes time, alienates stakeholders, and produces shallow requirements. Choosing well turns an initial fog of ideas into a crisp, traceable baseline that the whole team trusts.

This lesson gives you a practical decision framework: a set of variables to evaluate, a technique selection matrix, and three worked examples — a clinic booking system, an online store, and a logistics firm — showing how the same framework produces different answers for different contexts.

Variables That Drive Technique Selection

Before you pick a technique, assess the following five dimensions of your project:

Stakeholder availability and distribution. Are your stakeholders co-located or spread across cities and time zones? An executive who can spare 30 minutes for a structured interview cannot attend a full-day JAD session. Remote stakeholders are better served by asynchronous questionnaires than synchronous workshops.
Domain complexity and knowledge type. Is the domain well-understood, or is it a specialist field where experts hold tacit knowledge that is hard to articulate? Tacit knowledge demands observation or think-aloud prototyping; well-documented domains allow document analysis to do much of the heavy lifting.
Number and diversity of stakeholders. One senior user with a clear mandate is best interviewed. Forty users spread across eight regional offices need a survey. A cross-functional group of six to ten who must agree on a shared process is a workshop candidate.
Project risk and regulatory context. High-stakes systems (medical, financial, safety-critical) demand formal, traceable artifacts: structured interviews with verbatim notes, workshop minutes, sign-off sheets. Low-risk internal tools can afford lighter-weight techniques.
Project methodology and timeline. A waterfall project with a fixed requirements phase has budget for an upfront workshop series. An agile project running two-week sprints needs continuous, lightweight elicitation: short interviews, story-mapping sessions, and rapid prototyping feedback loops.

Key idea: No technique is universally superior. The "right" technique is the one that best matches the stakeholder, the knowledge type, the project context, and the available time — and most real projects require at least three different techniques used in combination.

The Technique Selection Matrix

The matrix below maps each of the eight techniques covered in this tutorial against the five selection variables. A filled indicator means the technique is strong for that variable; a partial indicator means it can work with some adaptation; empty means it is a poor fit.

Technique selection matrix: eight elicitation techniques rated against five project context variables. Real projects typically score multiple variables and choose the top-rated techniques for each.

Reading the Matrix: A Three-Step Process

Using the matrix is straightforward:

Identify which rows apply to your project. Most projects trigger two or three rows simultaneously — for example, "few key stakeholders" AND "tacit knowledge" AND "agile timeline".
Tally the scores per technique. The techniques with the most strong indicators for your active rows are your primary candidates.
Check for complementarity. Your primary technique will have blind spots. Add a secondary technique that is strong where your primary is weak. For example, interviews surface tacit knowledge but miss breadth; a follow-up survey covers breadth. Observation reveals how work actually happens; a workshop then validates whether your interpretation is correct.

Best practice — the 2+1 rule: Design every elicitation campaign with two primary techniques and one validation technique. The two primaries gather the raw material; the validation technique confirms the emerging requirements with a broader or different audience before you baseline them.

Worked Examples

Example 1 — Clinic Booking System

A private clinic with 8 doctors and 3 receptionists is moving from a paper diary to a digital booking platform. The project is sponsored by the clinic director. The primary risk is disrupting live patient scheduling; the methodology is a lightweight waterfall with a six-week discovery phase.

Active matrix rows: Few stakeholders, High risk / formal.
Primary technique 1 — Structured interviews with the clinic director (business goals), each doctor (scheduling preferences, appointment duration rules, follow-up logic), and each receptionist (daily workflow, edge cases, cancellation patterns). Eight interviews of 45 minutes each, recorded and transcribed.
Primary technique 2 — Observation / job shadowing of a receptionist on a busy Monday morning. This surfaces tacit knowledge: the receptionist's mental model for double-booking prevention, the informal "VIP patient" priority rule that nobody has ever written down, and the paper-based workaround for emergency walk-ins.
Validation technique — Document analysis of the existing paper appointment book, the SMS reminder log, and the clinic's patient confidentiality policy. Confirms data fields, retention rules, and compliance constraints discovered in the interviews.

Example 2 — Online Store Loyalty Programme

An established e-commerce retailer with 1.2 million registered customers wants to add a loyalty-points system. Stakeholders include the CMO, the finance controller, the mobile-app team lead, the customer-service manager, and a pool of power-users who volunteer for product testing. The project runs on a two-week-sprint agile cadence.

Active matrix rows: Many stakeholders, Agile / fast cycle.
Primary technique 1 — Survey sent to 5,000 opted-in customers. Asks what rewards they value, what point-earning actions feel fair, and what redemption mechanics they prefer. Results in 24 hours with statistical significance. This is the breadth sweep.
Primary technique 2 — Prototyping. A clickable Figma prototype of the points dashboard and earning notification is built in sprint 1. The customer-service manager and three power-users walk through it in think-aloud sessions. Reveals that users expect real-time balance updates and that a "points expiry countdown" creates anxiety rather than motivation.
Validation technique — Focus group of eight customers (mix of high-value and lapsed) facilitated by the analyst. Probes the emotional dimension: what makes points feel "real" versus "gimmicky"? Surfaces an insight absent from the survey: customers distrust point valuations they cannot verify independently, so a "points-to-cash equivalent" display is a must-have, not a nice-to-have.

Example 3 — Logistics Route Optimisation

A regional courier company wants to replace its manual route-planning spreadsheets with an automated optimisation engine. Dispatchers have 15 years of domain expertise but struggle to articulate their decision rules. The IT department has existing system documentation but it is largely outdated. The project is medium-risk, waterfall, with a 12-week analysis phase.

Active matrix rows: Few stakeholders, Tacit knowledge, High risk / formal.
Primary technique 1 — Observation / job shadowing. Two analysts shadow dispatchers across three full shifts: a normal weekday, a Friday peak, and a bank-holiday skeleton shift. They capture every decision point, every exception, and every time a dispatcher overrides the system's suggestion. This is the only reliable way to extract implicit routing heuristics.
Primary technique 2 — Structured interviews conducted immediately after each observed shift while memory is fresh. The analyst plays back specific decisions ("At 09:17 you reassigned van 4 to route 12 — can you walk me through your thinking?"). This converts tacit observation into articulated business rules.
Validation technique — Requirements workshop with dispatchers, the IT architect, and the operations director. The analyst presents a draft decision-rule catalogue derived from the observations and interviews. Participants collectively verify, refine, and prioritise the rules. The workshop output becomes the signed-off functional requirements document.

Three elicitation campaigns: the same 2+1 structure produces different technique choices when the project context differs.

Common Mistakes When Combining Techniques

Even analysts who know the matrix well make recurring errors in execution:

Duplicating effort without adding new signal. Running five individual interviews and then a workshop covering the same ground wastes stakeholders' time and erodes goodwill. Each technique should target a different knowledge type or a different validation objective.
Using the wrong technique for the relationship. Sending a survey to a CEO signals that their input is not worth a conversation. Using an open-ended interview to gather statistical data from 200 users is impractical. Match the technique's register to the stakeholder's seniority and role.
Sequencing techniques incorrectly. You cannot run a productive workshop before you have enough domain knowledge to moderate it effectively. The standard sequence is: document analysis and interviews first (build domain understanding), then workshops or JAD sessions (synthesise and validate), then prototypes or surveys (confirm with breadth). Prototyping before any elicitation produces a prototype that answers the wrong questions.
Treating the first wave as the last. Elicitation is iterative. A prototype reveals requirements you could not have written before you built it. Budget for at least two elicitation waves: a discovery wave to establish the baseline and a verification wave to confirm it.

Pitfall — stakeholder fatigue: Subjecting the same stakeholders to four different techniques in a single week destroys engagement and poisons future collaboration. Spread techniques across the project lifecycle and be transparent about the purpose of each engagement: "Today we are mapping your current workflow. Next week we will show you a rough prototype and ask for reactions." Stakeholders who understand the plan participate more willingly and more honestly.

Summary

Technique selection depends on five variables: stakeholder count and availability, domain knowledge type, project risk, and methodology / timeline.
The selection matrix maps each technique against these variables to identify the strongest candidates for a given project context.
Apply the 2+1 rule: two primary techniques to gather requirements, one validation technique to confirm them.
Sequence matters: document analysis and interviews before workshops; workshops before prototypes or surveys used for statistical breadth.
Each technique must add new signal, not repeat what a previous technique already captured.
Plan for at least two elicitation waves and manage stakeholder fatigue deliberately.