If you are trying to figure out how business analysts gather requirements on a live project, the honest answer is that there is no single method that works every time. What you actually do is select from a set of proven techniques, adapt them to your stakeholders and context, and keep iterating until what you have captured genuinely reflects what the business needs rather than what people said in the first meeting. I have been doing this work for over 25 years across government, utilities, health, education, and enterprise environments, and the requirements phase is still the one most likely to go sideways without a clear plan behind it.
Before you book a single interview or run a workshop, you need to know what types of requirements you are trying to gather. This shapes every technique you choose and every question you ask.
The Five Types of Requirements You Need to Cover
Requirements do not all sit at the same level, and conflating them is one of the most common mistakes I see on early-career BAs. Here is how I categorise them and what each one means in practice.
- Business requirements. These are the high-level goals the organisation wants to achieve, such as reducing customer wait times or increasing digital self-service adoption. They answer the question of why the project exists.
- Stakeholder requirements. These are the specific needs of the people affected by the change, such as a team leader needing consolidated reporting or a front-line worker needing faster system response times.
- Functional requirements. These describe what the solution must do, such as allowing users to reset their own passwords or generating an automated invoice on purchase completion.
- Non-functional requirements. These define the quality standards the solution must meet, covering areas like performance, security, accessibility, and reliability. They are easy to overlook and expensive to retrofit later.
- Transition requirements. These cover everything needed to move from the current state to the future state, including data migration, staff training, and parallel running periods.
Understanding this structure before you start elicitation means you can check coverage as you go rather than realising at the end that you have missed an entire category. For a deeper look at where business and functional requirements sit in relation to each other, the article on business vs functional requirements is worth reading alongside this one.
The Core Elicitation Techniques and When to Use Each
There are six techniques I return to on almost every project. The skill is not in knowing all of them; it is in knowing which one to reach for given your stakeholders, your timeline, and the nature of the problem.
Stakeholder Interviews
Interviews are the most direct route to understanding individual perspectives. I prepare open-ended questions in advance, listen actively rather than leading, and always summarise back at the end to confirm what I have understood. The key discipline is following up: the first answer is rarely the complete picture. A well-run interview surfaces assumptions and constraints that would never appear in a survey.
Workshops
Workshops bring multiple stakeholders together to surface conflicting priorities and reach shared agreement. I use them when I need to build consensus or when requirements are genuinely unclear and need to be worked through collaboratively. A workshop without a structured agenda is just a meeting. I always set clear objectives, use visual aids such as process maps or sticky notes to anchor discussion, and manage dominant voices so that quieter participants are heard. If you want more on running these sessions effectively, the article on BA facilitation skills goes into the detail.
Surveys and Questionnaires
When I need to gather input from a large or geographically distributed group, surveys give me breadth that interviews cannot. I mix closed questions for quantifiable data with open fields for nuance. The risk is low response rates and surface-level answers, so I always follow up with targeted interviews for the themes that matter most.
Document Analysis
Reviewing existing materials before speaking to anyone is one of the most underused techniques I know. Process maps, policy documents, previous project reports, and system manuals tell you what the organisation thought it needed last time, where it ran into problems, and what language people use. It makes every subsequent conversation sharper and faster. I wrote more about this approach in the article on desktop analysis in business analysis.
Observation
Watching people do their actual jobs reveals things they will never think to tell you. Workarounds, informal processes, and pain points that have become so normalised nobody mentions them. I always arrange observation sessions in advance, explain what I am looking for, and where possible observe at different times of day or different points in a cycle to catch variation.
Prototyping
Low-fidelity prototypes, whether sketched on paper or built in a tool like Figma or Balsamiq, make abstract requirements concrete. When stakeholders can see and interact with a representation of the solution, they give far more specific and useful feedback. I use prototyping particularly for user interface requirements and for situations where stakeholders struggle to articulate needs in the abstract.
Choosing the Right Technique: A Quick Comparison
| Technique | Best used when | Main risk |
|---|---|---|
| Stakeholder interview | You need depth from a specific individual or role | One person’s view dominates the picture |
| Workshop | You need consensus across competing perspectives | Dominant voices drown out quieter stakeholders |
| Survey | You need breadth from a large or dispersed group | Low engagement and shallow responses |
| Document analysis | You are new to the domain or need historical context | Documents may be outdated or misleading |
| Observation | Processes are complex, informal, or poorly documented | Hawthorne effect changes behaviour during observation |
| Prototyping | Requirements involve user interfaces or workflows | Stakeholders anchor too firmly on early designs |
A Worked Example: When Stakeholder Agreement Fell Apart
On Project X, a case management system replacement for a mid-sized public sector organisation, I had completed initial interviews with seven stakeholders across three directorates. On paper, requirements looked well-aligned. When I ran the first consolidation workshop to validate them, the head of one directorate, who had been broadly supportive in their individual interview, flatly rejected two requirements that the other two directorates considered non-negotiable. Their concern was that the proposed data sharing model would expose their team’s performance metrics to senior leadership in a way they had not agreed to. The requirement had been documented as a business requirement. They experienced it as a surveillance mechanism.
I had to halt the workshop, acknowledge the concern directly, and arrange a separate session with that stakeholder and the programme sponsor before we could continue. What looked like a requirements conflict was actually a governance and trust issue that had not surfaced in the one-to-one interview because the stakeholder had not yet seen how their input would be combined with others. We revised the requirement to separate operational reporting from management oversight, which resolved the immediate tension but added two weeks to the elicitation phase. The lesson I took from it: validating requirements in a group setting always reveals things that individual interviews miss, and a point of friction in a workshop is usually a signal, not an obstacle.
Documentation That Supports Requirements Gathering
Gathering requirements without documenting them in a structured, traceable way means you cannot validate them, manage changes to them, or demonstrate that the delivered solution meets what was agreed. The main formats I use are:
- Business Requirements Document (BRD). This captures the high-level goals, project scope, and business context. It is the anchor document that everything else traces back to.
- Functional Requirements Specification (FRS). This details what the system or solution must do, at a level of specificity that development or delivery teams can act on.
- User stories with acceptance criteria. In agile environments, these describe requirements from the end user’s perspective and include the conditions under which the requirement is considered met.
- Use cases. These map out specific scenarios of how users interact with the solution, ensuring functionality is grounded in real-world context rather than abstract descriptions.
For practical guidance on the difference between a BRD and an FRS and when to use each, the article on Business Requirements Document vs Functional Requirements Document is a useful reference.
Managing Requirements Through the Project Lifecycle
Gathering requirements is not a phase that ends. On every project I have worked on, requirements have changed, been challenged, or needed to be revisited as context shifted. The practices that keep this manageable are:
- Validation with stakeholders. After gathering, share what you have captured in a format stakeholders can review and confirm. Do not assume that because someone said something in an interview, they will recognise it in a written requirement.
- Prioritisation. Work with stakeholders to rank requirements by business value, cost, and urgency. Not everything can be delivered at once, and unaprioritised backlogs are a direct route to scope creep.
- Traceability. A requirements traceability matrix links each requirement to its source, its associated test cases, and its implementation status. This is not bureaucracy; it is the mechanism that lets you prove the solution delivers what was asked for.
- Change management. Any change to a requirement after sign-off should go through a formal review. Without this, scope creep is almost inevitable and the project team ends up building something nobody agreed to fund.
There is no version of good requirements work that skips the management piece. Eliciting requirements and then losing track of them is worse than not having a structured process at all, because it creates a false sense of confidence that things are under control.
The real measure of how well you gather requirements is not the volume of what you produce but whether the people who rely on that work, developers, testers, project managers, and sponsors, can make confident decisions from it. Every technique in this article exists to serve that goal. Get comfortable with the ones that suit your context, be willing to combine them, and treat every point of friction from a stakeholder as information rather than interference.
Frequently asked questions
How do business analysts gather requirements?
Business analysts gather requirements using a combination of techniques including stakeholder interviews, workshops, document analysis, observation, surveys, and prototyping. The choice of technique depends on the stakeholders involved, the complexity of the problem, and the project context. Requirements are then documented, validated with stakeholders, and managed throughout the project lifecycle.
What is the most effective technique for gathering requirements?
There is no single most effective technique because the right approach depends on the situation. Interviews work well for depth from specific individuals, while workshops are better for building consensus across groups. Most experienced business analysts use a combination of techniques on the same project to get complete coverage.
What types of requirements does a business analyst gather?
Business analysts typically gather five types of requirements: business requirements, stakeholder requirements, functional requirements, non-functional requirements, and transition requirements. Each type sits at a different level of detail and serves a different purpose in defining what the solution must achieve.
How do you document requirements as a business analyst?
Common documentation formats include a Business Requirements Document for high-level goals and scope, a Functional Requirements Specification for detailed system behaviour, user stories with acceptance criteria in agile settings, and use cases to describe how users interact with the solution. The format you choose should match the methodology and the audience who will use the documentation.
What is requirements traceability and why does it matter?
Requirements traceability is the practice of linking each requirement back to its business source and forward to its test cases and implementation. It matters because it lets you verify that the delivered solution actually meets what was agreed and makes it easier to assess the impact of any changes during the project.
Try Ash, Your Virtual BA
If you are in the middle of gathering requirements right now and need help structuring your questions, organising what you have heard, or drafting the documentation that comes next, Ash is built specifically for this kind of work. Ash can guide you through elicitation question sets, help you structure requirements by type, and support you in producing a Business Requirements Document or Functional Requirements Specification from what you have gathered. It is the kind of support that makes the difference between requirements that drift and requirements that hold. Try Ash Virtual BA.
Further reading
- How Business Analysts Use AI to Improve Requirements, Elicitation, and Stakeholder Alignment | IIBA
- Learn How to Succeed as a Business Analyst | IIBA
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.