Requirements Gathering Techniques

There is no single best way to gather requirements.

A stakeholder interview can uncover information that would never appear in a questionnaire. A workshop can resolve a disagreement that would take weeks to uncover through individual conversations. Shadowing (observing someone doing their role) will, in the majority of cases, reveal workarounds that nobody thinks to mention. And a prototype (or even a simple PowerPoint visual) can expose a misunderstanding simply by giving people something concrete to react to.

The most effective requirements gathering therefore uses the right technique for the information you are trying to discover.

This guide looks at the most useful requirements gathering techniques, what each one is good at, where it falls short, and how to combine different approaches to build a more complete understanding of what a project actually needs.

These are best practices, but when working on projects we may not always have the privilege of time to apply them.

What are requirements gathering techniques?

Requirements gathering techniques are the different methods used to discover, understand and capture the needs of stakeholders and the requirements of a project.

Common techniques include:

Stakeholder interviews
Requirements workshops
Shadowing (AKA Observation)
Questionnaires and surveys
Document analysis
Process mapping
Prototyping
Use cases and scenarios
Focus groups
Brainstorming
Analysis of existing systems and data

These techniques overlap with what is often called requirements elicitation. The terms requirements gathering and requirements elicitation are frequently used interchangeably, although elicitation places more emphasis on the investigative process of drawing information and needs out of stakeholders.

We don’t need to use every technique on every project.

The choice should depend on what you are trying to discover, who has the relevant knowledge, how much uncertainty exists, and whether you need individual insight, broad feedback or agreement between stakeholders. We also need to factor in other constraints such as the availability of stakeholders and access (or lack of access) to systems and information.

How do you choose the right requirements gathering technique?

Before choosing a technique, ask what you actually need to learn.

For example:

What you need to discover	Techniques that may help
An individual’s experience	Stakeholder interview
How a process actually works	Observation, process mapping
The views of a large group	Questionnaire or survey
Existing rules and constraints	Document analysis
Agreement between stakeholders	Workshop
Different perspectives on a common topic	Interviews, focus groups
How a future solution might work	Prototype, use case or scenario
How an existing system is actually used	System and data analysis

This is only a starting point.

The same technique can be useful for different purposes, and combining techniques is often more effective than relying on one.

For example, you might review existing documentation before interviewing stakeholders, observe the current process after the interviews, and then bring stakeholders together for a workshop to resolve the issues you have uncovered.

The question is not:

‘Which requirements gathering technique should I use?’

It is:

‘What do I need to understand, and which technique is most likely to reveal it?’

My practical application: Combining techniques

Observation (Shadowing) is great for learning the lower-level detail of a process. But do I just sit there silently writing notes? Nope. I can build rapport with the person being observed. Have some banter and find out some more about them as a person in general (networking) whilst informally interviewing them at the same time. It does not need to be an “interview”. A “chat” is just as powerful. Not everything needs to be a formal application of best practices.

Whilst shadowing them, I will try and take ‘enough’ notes to build a rough process map (in my own time). If I repeat this with a few other stakeholders, I may be able to learn enough to uncover 80% of the process. Then, I can email this around the group for feedback – or share it in a later workshop for refinement. So a single 30-60 minute ‘observation’ session can go a long way to ‘ticking off’ quite a few of the above list items.

1. Stakeholder interviews

Interviews are one of the most flexible requirements gathering techniques.

An interview gives you the opportunity to explore an individual’s experience in detail and, importantly, to ask follow-up questions.

A stakeholder might say:

‘The approval process takes too long.’

A questionnaire would capture that answer and move on.

An interview allows you to ask:

Which part of the process takes the longest?
How long does it normally take?
Who is involved?
What causes the delay?
Does it happen every time?
What happens when the process is delayed?
What would a better process look like?

That ability to follow-up an answer is obviously one of the biggest advantages of an interview.

When are interviews useful?

Interviews are particularly useful when you need:

Detailed knowledge of a business process
An individual’s perspective
Information about exceptions
Information about informal processes
Understanding of business rules
Information that may be sensitive or difficult to discuss in a group
The ability to explore unexpected answers

Interviews are also useful when stakeholders have very different roles. Speaking to them individually allows you to understand each perspective before bringing those perspectives together.

The limitations of interviews

Interviews take time.

They can also introduce interviewer bias. The questions you ask influence the answers you receive, and two analysts may conduct interviews with the same stakeholder and uncover different information.

There is also a risk of collecting a series of individual opinions without ever bringing them together.

My practical application: Formalities

What do you think about when you hear the word ‘interview?’ Job interview? An interview with the media? Maybe a situation involving the Police and a duty solicitor at 2 in the morning. If you saw a meeting invitation come through for an ‘interview’, would you feel more relaxed or less relaxed in that moment?

Frame your words wisely. I may call it an interview for a senior manager so that it feels more intentional and efficient. However, if I were meeting a subject matter expert, I would be more informal and frame it as exactly what it is: “Introduce myself and learn more about your role and <process>”

Similarly, it may be in a room with a table and a clip board for some stakeholders. For others, it may be “downstairs in the coffee shop” or at their desk (if we are also doing some shadowing).

2. Requirements workshops

A requirements workshop brings multiple stakeholders together to explore a problem, develop requirements, make decisions or reach agreement.

The major advantage is that people hear each other’s perspectives.

If one stakeholder says:

‘This information needs to be available immediately.’

and another says:

‘We only need it once a month.’

the disagreement can be identified and explored while everyone is present.

Workshops can also be useful for:

Agreeing a common understanding of a process
Mapping the current state
Exploring a future state
Prioritising requirements
Resolving conflicts
Identifying gaps
Making decisions

When are workshops useful?

Workshops work particularly well when collaboration and agreement are important.

They are less useful when participants arrive without enough shared context to have a productive conversation.

A workshop is not automatically a good way to begin requirements gathering.

If you put twenty people in a room and ask them what they need, you may simply get twenty different answers.

One approach is to conduct individual interviews or other discovery activities first, then use the workshop to bring the findings together and focus on the questions that actually require group discussion.

3. Shadowing / Observation

Sometimes the best way to understand a process is to watch someone perform it.

People do not always describe their work accurately. They also use acronyms and say strange terminology as if it is everyday lexicon. They can be so accustomed to their role that they forget some of these words relate to dated systems or internal queue names.

That isn’t necessarily because they are being misleading. People just become used to their own workarounds and shortcuts. Steps that are obvious to them may not seem worth mentioning.

Observation can uncover:

Manual workarounds
Repeated tasks
Unofficial processes
Exceptions
Bottlenecks
Dependencies
Information being transferred between systems
Tasks people have forgotten they perform

For example, someone might describe a process as:

‘I enter the information into the system and then send it to the next team.’

Watching the process might reveal that they first copy the information into a spreadsheet, check three fields manually, email someone for confirmation and then enter it into the system.

Those additional steps may be highly relevant requirements.

When is observation useful?

Observation is particularly useful when:

The process is operational or highly repetitive
Users perform many manual steps
Workarounds are common
People find the process difficult to describe
You suspect the documented process differs from reality

Observation can take time, particularly when the work happens infrequently or across multiple locations.

4. Questionnaires and surveys

Questionnaires are useful when you need information from a large number of people.

Instead of conducting fifty individual interviews, you might use a questionnaire to establish a broad view of:

Common problems
User preferences
Current practices
Frequency of particular issues
Differences between groups

They are particularly useful when stakeholders are geographically dispersed or when you need to establish a baseline before conducting more detailed discovery.

The limitation of questionnaires

This seems obvious but a questionnaire will give you the answers to the questions you asked. Whereas an interview can reveal something you didn’t know to ask about.

That makes questionnaires useful for breadth, but less effective when the problem is poorly understood.

For example, if you already know that five different aspects of a process need investigating, a questionnaire can efficiently collect information about those areas.

If you don’t yet understand the process, you may not know which questions to ask.

A useful approach can therefore be to use a questionnaire to identify broad themes and then follow up with interviews.

Also, we can set questionnaire questions to be mandatory, but we cannot control whether the text entered in the field will make sense or not. Respondents will often write in short-hand or provide answers that create more questions (confusion).

5. Document analysis

Existing documentation can contain a huge amount of useful information.

Before asking stakeholders to explain everything from scratch, look at what already exists.

This might include:

Existing requirements
Business rules
Policies
Procedures
Process documentation
System documentation
Reports
Forms
Customer communications
Previous project documentation
Training material

Document analysis can help you understand terminology, identify constraints and prepare better questions for stakeholder conversations.

It can also reveal contradictions. For example, a documented process might say one thing while a policy document says something else.

The limitation of document analysis

Documentation is only useful if it accurately represents reality.

A process document written five years ago may describe how the organisation intended a process to work rather than how people actually perform it today.

Use documentation as evidence, not unquestioned truth.

My practical application: Standard playbook

The first thing I do when starting a new project is a simple search of the organisation’s Intranet. This will often uncover documentation which – although often wrong or outdated – is a good conversation starter for later techniques.

The second thing I do is to request access to whatever knowledge base the team in question is using for their procedures and the third thing is to utilise my internal network to see if anyone I know has existing documentation from prior projects.

6. Process mapping

Process mapping provides a visual representation of how work moves through a process. Instead of discussing the process entirely through conversation, it is useful to map:

Who does what, when they do it, what information they use and what happens next.

This can make complicated processes much easier to discuss.

A process map can also reveal:

Handoffs
Bottlenecks
Duplicate activity
Manual intervention
Dependencies
Decision points
Loops
Exceptions

One of the biggest advantages is that stakeholders can react to something visible.

People are more willing to point out mistakes than they are to reveal hidden information. I will often show process maps knowing that they are incorrect, as it is a quick way to find out the full picture.

When is process mapping useful?

Process mapping is particularly valuable when requirements relate to:

Business processes
Operational workflows
Multiple teams
Complex handoffs
Automation
Process improvement

It is most effective when combined with interviews and observation.

7. Prototyping

A prototype gives stakeholders something concrete to react to.

This could be:

A paper sketch
A wireframe
A screen design
A clickable prototype
A model of a process
A simplified representation of a future system

Prototypes can be particularly useful when stakeholders find it difficult to describe what they need in abstract terms.

Showing a proposed screen might produce:

‘That’s not where I would expect to find that information.’

That response may reveal something that would never have appeared in a requirements document.

Prototyping is not just about design

A prototype can be used as a requirements discovery tool.

It helps stakeholders explore what they expect the future state to look or feel like and gives the analyst something specific to question.

The danger of prototypes

People can become attached to a proposed solution.

A prototype should therefore be treated as a way of exploring requirements, not proof that the proposed design is correct. Writing “DRAFT” or “FOR DISCUSSION ONLY” can help but not as much as you may think.

8. Use cases and scenarios

Use cases and scenarios describe how someone might interact with a system or perform a particular activity.

They are useful for exploring requirements from the perspective of a particular situation.

For example: A customer submits an application.

What happens next?

Who receives it?
What information is required?
What happens if information is missing?
Who reviews it?
What decisions need to be made?
What happens if the application is rejected?
What information needs to be retained?

Scenarios are particularly useful for identifying exceptions because they encourage people to think through what happens when the normal path changes.

They can also help stakeholders understand a proposed requirement in the context of actual work rather than as an isolated statement.

9. Focus groups

A focus group brings together a selected group of participants to discuss a topic under the guidance of a facilitator.

Focus groups can be useful when you want to understand attitudes, experiences or reactions across a particular user group.

They are less suited to situations where you need detailed requirements from individual subject matter experts.

A participant may also be influenced by the opinions of others in the group.

That makes facilitation important.

If one person dominates the conversation, the resulting information may represent that person’s perspective rather than the group’s.

In reality, I find focus groups best suited for groups of end-users – and especially useful when those users are actual customers (i.e. not internal staff).

10. Brainstorming

This is a technique used within a workshop but it can also be a dedicated session by itself. Brainstorming is useful when the team needs to generate ideas or explore possible approaches.

It can help when:

The problem is not well defined
There are multiple possible solutions
The team needs to explore possibilities
Stakeholders need to contribute ideas
You want to generate options before evaluating them

Brainstorming is more useful for generating possibilities than for establishing a definitive set of requirements.

Ideas produced during brainstorming of course will still need to be investigated, analysed and validated.

11. Existing system and data analysis

If a project is changing or replacing an existing system, the system itself can provide useful evidence.

You might examine:

How users interact with the system
Which functions are used most frequently
Which data is created
Which fields are populated
Where errors occur
Which manual workarounds exist
Which integrations are involved
Which reports are actually used

Data can also reveal behaviour that stakeholders do not mention during interviews.

For example, users might say a particular feature is important, while usage data shows that it is rarely used.

Neither piece of information should automatically be treated as correct or incorrect.

The discrepancy is something worth investigating.

My practical application: Explore the system yourself

In the scenario where stakeholder availability is low, but I have access to the system they use, I will essentially explore the system myself, map fields to data and note my questions. I may be able to get answers via email.

Choosing techniques based on the scenario

A useful way to choose requirements gathering techniques is to consider the type of uncertainty you are dealing with.

‘We don’t understand the problem.’

Start with interviews, observation and document analysis.

‘We understand the problem, but different people have different views.’

Use interviews followed by a workshop.

‘People can’t explain how the process actually works.’

Use observation and process mapping.

‘We need feedback from hundreds of users.’

Use a questionnaire or survey, potentially followed by targeted interviews.

‘People aren’t sure what they need from the future system.’

Use scenarios, prototypes and facilitated discussions.

‘We have existing documentation but don’t know whether it is still accurate.’

Review the documentation, then validate it through interviews and observation.

‘We need to identify disagreements.’

Interview stakeholders independently first, then bring the relevant people together to resolve the differences.

The technique should follow the problem.

Common mistakes when choosing requirements gathering techniques

Using the same technique for every project

A questionnaire is not a substitute for an interview, and an interview is not a substitute for shadowing. Different techniques reveal different types of information. The default technique seems to be workshops.

Choosing the easiest technique

The easiest technique to organise is not necessarily the one that will produce the best information. A questionnaire may be easy to send to everyone, but that doesn’t mean it is the best way to understand a complex process.

Trying to use every technique

This means assuming that more techniques automatically produce better requirements. Every technique takes time and creates information that someone needs to analyse. Every minute out of a stakeholder’s day is making their life more difficult.

Treating stakeholder answers as complete

A stakeholder interview is the beginning of investigation, not necessarily the end.

Follow-up questions are often where the useful information appears.

Ignoring the order in which techniques are used

Sequence does matter. For example, reviewing documents before interviews can give you enough context to ask better questions. And those interviews will identify issues to explore in (or before) a workshop.

How AI is changing requirements gathering techniques

AI introduces lots of new options for how some requirements gathering activities can be performed.

For example, examining data volumes in Excel can be done in a few minutes at a high level (although we must always validate what the AI has discovered). And most of the major LLMs can now take documents and mock-up HTML prototypes.

AI can also be used to conduct individual stakeholder interviews asynchronously, adapting follow-up questions based on previous answers. That changes the economics of one particular technique: the individual interview.

Instead of requiring a business analyst to schedule and conduct every interview personally, AI can handle some of the initial conversational work and produce a structured summary for the analyst to review.

It does not make the other techniques unnecessary and a workshop is still useful when people need to make decisions together.

The more interesting possibility is to combine techniques differently.

For example: AI-assisted interviews using WORKSHOP IT’s Jessica, AI synthesis of the output, identification of gaps and conflicts, focused workshop

The objective is not to replace requirements gathering techniques with AI, but to make the overall process more effective.