Requirements gathering is treated as a simple exercise: talk to stakeholders, write down what they say, and turn it into requirements. Projects have deadlines and the priority is to tick it off as quickly as possible.
We know that the reality is much harder.
People describe problems differently. They use different terminology. They make assumptions without realising it. They ask for solutions when what they actually need is something else. Different stakeholders can have completely different views of what the project should deliver. Time is our enemy. Understandably, our stakeholders have their own roles to fulfil outside of our projects and not everyone is available at our beck and call.
Good requirements gathering is not about collecting a list of requests. It is about building a reliable understanding of what a project needs, why it needs it, and where there are still questions to resolve. If we simply collect everything that we are told and try to implement it, we can end up with clashing instructions or solutions which do not meet the real needs of the business.
This guide explains what requirements gathering is, how the process works, the techniques you can use, the questions worth asking, and some of the common mistakes that can undermine requirements before a project has properly started.
What is requirements gathering?
Requirements gathering is the process of discovering, understanding and documenting what stakeholders need from a project, system or change.
It involves finding out:
- What problem are we trying to solve?
- What does the business need to achieve?
- Who needs something from the project?
- How does the current process work?
- What needs to change?
- What constraints need to be considered?
- What assumptions are being made?
- What information is missing?
- Where do stakeholders disagree?
The term “requirements gathering” is widely used, but it can give the impression that requirements already exist and simply need to be collected.
In practice, requirements often need to be uncovered. What a stakeholder says is not necessarily what the business really needs.
A stakeholder might say: “We need a new reporting dashboard.”
That is a request for a solution, not necessarily a requirement.
The next questions might be:
- What problem does the current reporting process create?
- Who uses the reports?
- What decisions do they need to make?
- What information do they need?
- How often do they need it?
- What is missing from the current reports?
The answers may reveal that the real requirement has little to do with building a dashboard.
This investigative work is often referred to as requirements elicitation.
Requirements gathering and requirements elicitation are closely related terms. Gathering is the broader term commonly used to describe the activity. Elicitation emphasises the work involved in drawing information, needs and expectations out of stakeholders.
Why does requirements gathering matter?
Poor requirements create problems long before development begins.
If important information is missed or misunderstood, the consequences can include:
- Building the wrong thing
- Discovering important requirements late
- Conflicting stakeholder expectations
- General rework
- Scope changes
- Poor estimates
- Requirements that cannot be tested
- Decisions based on incomplete information
- Disagreements appearing during development rather than during discovery
All of the above lead to drama and an increase in blood pressure for all involved. More importantly for the business, the cost of finding a problem generally increases as a project progresses. So we need to avoid it.
A misunderstanding during an early stakeholder conversation can be relatively easy to resolve. The same misunderstanding discovered after development, testing or implementation can require significant rework.
Good requirements gathering does not eliminate uncertainty. But it does make uncertainty visible early enough to do something about it as a team.
Who should be involved in requirements gathering?
The right stakeholders depend on the project.
They may include:
- Business owners
- End users
- Subject matter experts
- Operational staff
- Managers
- Customers
- Technical specialists
- Compliance or risk representatives
- People responsible for downstream processes
- People affected by the change
- People who will support or operate the resulting system (Production Support)
One of the most common mistakes is assuming that the most senior person in the room has all the answers.
They may understand the strategic objective, but someone working with the process every day may understand the practical problems in much greater detail. It’s important that all voices are heard. Which means that relying purely on a group workshop may result in voices being missed. Not everyone will speak for equal amounts of time in such settings.
The reverse can also be true. An operational stakeholder may understand today’s process extremely well but have little visibility of the wider business objective. If we rely only on these stakeholders, we can end up with a solution which is not strategic and is built around “the way we have always done it”.
Good requirements gathering therefore involves speaking to the people who understand different parts of the problem.
The requirements gathering process
There is no single process that works for every project, but a useful requirements gathering process generally includes the following stages.
1. Understand the problem
Before asking what the new system should do, understand why the project exists.
What problem is the organisation trying to solve?
What is happening today?
What is not working?
What would success look like?
Starting with the problem helps prevent the conversation from becoming a list of requested features.
2. Identify the stakeholders
Determine who has knowledge about the problem, who uses the existing process, who is affected by the change and who has authority to make decisions.
Do not assume that one stakeholder group represents everyone.
Different people often have different experiences of the same process.
3. Review existing information
Requirements gathering does not always start with a blank page.
Existing information may include:
- Process documentation
- Existing requirements
- Business rules
- Policies
- Procedures
- System documentation
- Reports
- Customer feedback
- Existing data
- Previous project documentation
- Known issues
Reviewing this material before speaking to stakeholders can make interviews more productive and help identify areas that need clarification.
4. Gather information from stakeholders
This is where techniques such as interviews, workshops, observation and questionnaires can be used.
The choice of technique depends on what you need to discover.
An individual interview may be useful when you need to understand someone’s experience in detail.
A workshop may be better when several people need to develop a shared understanding or make decisions together.
Observation (also referred to as “shadowing” can reveal how a process actually works rather than how people think it works.
5. Ask follow-up questions
The first answer is rarely the complete answer.
If someone says that “The process takes too long.”
Then we need to ask why.
Which part takes too long? How long does it take?
Who is affected?
What happens as a result?
What would an acceptable process look like?
Follow-up questions are one of the most important parts of requirements gathering because they turn broad statements into something that can actually be understood and assessed.
This is one of the areas where requirements gathering becomes requirements elicitation.
6. Analyse what you have heard
Once information has been gathered, look for patterns and problems.
For example:
- Duplicate requirements
- Missing information
- Ambiguous statements
- Assumptions
- Dependencies
- Constraints
- Contradictions
- Different interpretations of the same requirement
It is important not to assume that two similar statements are necessarily the same requirement.
Likewise, conflicting requirements should not simply be combined into one statement to make the list look cleaner.
If two stakeholders genuinely want different things, that disagreement is useful information.
It needs to be identified and resolved.
7. Document the requirements
The information gathered from stakeholders needs to be turned into requirements that other people can understand and work with.
Good requirements should be clear, specific, measurable and testable.
They should describe what is actually needed rather than simply recording the words used by a stakeholder.
The appropriate documentation depends on the project. Requirements may be represented as individual requirements, business requirements, functional and non-functional requirements, user stories, acceptance criteria or other forms of specification.
See also: Writing Project Requirements: Best Practices.
8. Validate the requirements
Documentation does not automatically make a requirement correct.
Stakeholders should have an opportunity to review and confirm that the documented requirements accurately represent what is needed.
Validation can reveal:
- Misunderstandings
- Missing information
- Incorrect assumptions
- Conflicting expectations
- Requirements that are too vague
- Requirements that cannot realistically be delivered
9. Prioritise the requirements
Not every requirement has the same importance.
Some may be essential to achieving the project’s objective. Others may be desirable but optional.
Prioritisation helps the project understand what matters most and provides a basis for making decisions when time, budget or technical constraints appear.
10. Maintain the requirements
Requirements can change.
New information may emerge. Business priorities may change. Constraints may become apparent. Stakeholders may identify new needs.
Requirements therefore need to be managed throughout the project rather than treated as a one-off activity that ends when the initial document is produced.
Requirements gathering techniques
There are many established techniques for gathering requirements.
Stakeholder interviews
Interviews allow you to explore an individual’s experience in detail.
They are particularly useful when you need to understand:
- How someone performs their work
- Problems with the current process
- Exceptions
- Business rules
- Assumptions
- Unwritten practices
- What someone actually needs from the future state
The biggest advantage of an interview is the ability to ask follow-up questions.
Workshops
Workshops bring multiple stakeholders together to explore requirements, resolve questions and make decisions.
They can be particularly effective when the project needs a shared understanding across different groups.
They can also expose disagreements that might remain hidden during individual conversations.
However, workshops are not always the best place to discover every requirement from scratch.
If twenty people arrive at a workshop with twenty different understandings of the problem, much of the session can be spent simply working out what people already know.
Observation
Sometimes the best way to understand a process is to watch someone perform it.
Observation can reveal:
- Workarounds
- Manual steps
- Exceptions
- Dependencies
- Informal processes
- Information that people do not think to mention during an interview
What people say they do and what they actually do are not always the same.
Questionnaires and surveys
Questionnaires can gather information from a larger group of stakeholders.
They are useful when you need breadth rather than a detailed conversation with every participant.
The limitation is that a fixed questionnaire generally cannot explore an unexpected answer in the way an interview can.
Document analysis
Existing documents can provide valuable information before or during requirements gathering.
Policies, procedures, reports, existing requirements and system documentation can reveal business rules, constraints and terminology that need to be understood.
Process mapping
Mapping the current process can help stakeholders explain how work moves between people, systems and departments.
It can also expose hand-offs, bottlenecks and areas where requirements need further investigation.
Prototyping
A prototype can help stakeholders respond to something concrete.
Rather than asking someone to imagine a future system from a written description, a prototype can give them something to react to.
However, prototypes should not be mistaken for requirements themselves. They are a way of exploring and communicating what is needed.
The questions you ask matter
Good requirements gathering is not simply about asking lots of questions.
The questions need to help uncover useful information.
Questions about the problem
- What problem are you trying to solve?
- What happens today?
- What is causing the problem?
- Who is affected?
- How often does it happen?
Questions about the desired outcome
- What needs to be different?
- What would a successful outcome look like?
- How would you know the problem had been solved?
Questions about the current process
- How is this done today?
- Who performs each step?
- What happens before this?
- What happens afterwards?
- Where does information come from?
Questions about exceptions
- What happens when this doesn’t go normally?
- Are there situations where the process is different?
- What happens when information is missing?
- What happens when something goes wrong?
Questions about constraints
- What cannot change?
- Are there regulatory or policy requirements?
- Are there technical limitations?
- Are there dependencies on other systems or teams?
Questions about disagreement
- Does everyone agree with this?
- Are there different ways of doing this?
- Who has a different view?
- What happens when these requirements conflict?
Questions about the future
- What needs to be possible that isn’t possible today?
- What might change in the future?
- Are there expected changes that the project needs to accommodate?
The best questions often lead to more questions.
That is not a sign that requirements gathering is failing. It is usually a sign that you are discovering something worth investigating.
What stakeholders say is not always what they need
One of the most important skills in requirements gathering is separating a requested solution from the underlying need.
Consider:
“We need a button that sends the report to finance.”
The button may be the stakeholder’s proposed solution.
But the underlying requirement might be something like: “Finance needs access to the information required to complete its monthly reconciliation”.
Those are very different statements.
If you immediately document the requested button as the requirement, you have potentially locked the project into a solution before understanding the problem.
Good requirements gathering creates space to ask:
Why?
What is the stakeholder trying to achieve?
What problem does the request solve?
What happens if the requested solution isn’t available?
Are there other ways to meet the underlying need?
This is one reason experienced business analysts spend so much time asking questions rather than simply recording answers.
Common requirements gathering mistakes
1. Speaking to too few stakeholders
A requirement based on one person’s experience may not represent the needs of everyone affected by the project.
2. Treating every stakeholder statement as a requirement
People describe solutions, preferences, assumptions and problems as well as actual requirements.
They need to be analysed rather than copied directly into a requirements list.
3. Jumping to solutions too early
Once a solution is proposed, it becomes harder to explore alternatives.
Understand the problem first.
4. Asking only closed questions
Questions that produce a yes/no answer can be useful, but they rarely uncover everything you need to know.
Open questions encourage stakeholders to explain their experience.
5. Ignoring exceptions
The normal process is usually easy to describe.
The exceptions are often where the important requirements are hiding.
6. Failing to investigate disagreements
Different stakeholder views are not an inconvenience to be tidied away.
They are evidence that something needs to be understood.
7. Documenting without validating
A well-written requirement can still be wrong.
The people who provided the information need an opportunity to confirm that it has been understood correctly.
8. Assuming silence means agreement
A stakeholder who does not raise an issue has not necessarily agreed with everything.
They may not have understood the question, may not have thought of the issue yet, or may assume someone else will raise it.
How AI is changing requirements gathering
AI is beginning to change some of the more repetitive parts of requirements gathering.
For example, AI can conduct stakeholder interviews asynchronously, ask follow-up questions based on previous answers, identify missing information, summarise responses and compare information across multiple participants.
This is particularly interesting when a project has many stakeholders.
Instead of asking every stakeholder the same fixed questionnaire, an AI system can conduct a conversation that adapts to each person’s responses.
It can then help identify areas that require further investigation before a traditional discovery workshop takes place.
The goal is not necessarily to replace the business analyst or eliminate workshops.
Some of the most important parts of requirements work involve judgement, negotiation, prioritisation and decision-making. Those still require people.
AI can instead help move some of the information-gathering work earlier in the process, leaving workshops with a more focused set of questions and decisions to address.
See also: AI Requirements Elicitation Platforms.
What should you have when requirements gathering is finished?
There is no single document that every project should produce.
The output should depend on the project and its needs.
In my experience, this is typically a Business Requirements Document. But as the environment changes with AI, we will see this move towards other terminology such as specifications, contracts and constitutions. I expect the trend to shift more towards documentation written in natural language. But the essence is the same. A set of documents for agreement and approval.
But by the end of requirements gathering, you should have a much clearer understanding of:
- The problem being addressed
- The desired outcomes
- The stakeholders involved
- The requirements
- Business rules
- Constraints
- Assumptions
- Dependencies
- Unresolved questions
- Conflicting requirements
- Priorities
- How the requirements will be validated
Most importantly, the project should have a shared understanding of what is known, what is not known and what still needs to be decided.
That is more valuable than simply having a large requirements document.
Requirements gathering FAQs
What is requirements gathering?
Requirements gathering is the process of discovering, understanding and documenting what stakeholders and a business need from a project, system or change.
What is the difference between requirements gathering and requirements elicitation?
The terms are often used interchangeably. Requirements gathering is the broader term commonly used for discovering and documenting requirements. Requirements elicitation emphasises the investigative process of drawing information, needs and expectations out of stakeholders.
What are the main requirements gathering techniques?
Common techniques include stakeholder interviews, workshops, observation, questionnaires, document analysis, process mapping and prototyping. The most appropriate technique depends on what you need to discover and the circumstances of the project.
Who should be involved in requirements gathering?
Anyone with important knowledge of the problem, current process, desired outcome or constraints may need to be involved. This can include business users, subject matter experts, managers, technical specialists, customers and people affected by the change.
How do you gather requirements from difficult stakeholders?
Start by understanding why the stakeholder is difficult to engage. They may be busy, sceptical, unfamiliar with the project or concerned about the change. Clear questions, good preparation and explaining why their input matters can help. Individual conversations can also be more productive than asking them to contribute in a large group.
How long should requirements gathering take?
There is no standard duration. It depends on the size and complexity of the project, the number of stakeholders, the amount of existing information and how much uncertainty needs to be resolved. The objective should not be to finish gathering as quickly as possible, but to reach a level of understanding appropriate for the decisions the project needs to make.
Can AI gather requirements?
AI can assist with parts of requirements gathering, including conducting stakeholder interviews, asking follow-up questions, identifying gaps and synthesising responses. Human judgement is still important for interpreting requirements, resolving conflicts, making decisions and understanding organisational context. AI alone (at the moment) will miss a lot of tacit knowledge.
Final thoughts
Good requirements gathering is not about collecting as many requirements as possible and it is definitely not about blindly proceeding with everything we are told. It is about understanding the underlying problems well enough to know what the project actually needs to deliver.
That means talking to the right people, asking useful questions, investigating the answers, looking for gaps and contradictions, and turning what you discover into requirements that people can understand and validate.
The better this work is done, the more useful the conversations that follow become.
And that is ultimately the point of requirements gathering: not to produce a longer list of requirements, but to create a better (shared) understanding of what needs to happen.