.svg){kind=small}
Requirements gathering is the process of discovering, exploring and confirming what stakeholders and an organisation need from a proposed change or solution. In professional business analysis, the term requirements elicitation is often more accurate because a Business Analyst does not simply collect a ready-made list of requirements. They ask questions, investigate problems, observe how work is performed, challenge assumptions and help stakeholders express needs that may initially be incomplete, unclear or even conflicting.
Good requirements work can prevent an organisation from investing time and money in a solution that addresses the wrong problem. It helps teams understand what a change is meant to achieve, who is affected, what capabilities are required and how success will be judged.
Requirements gathering vs requirements elicitation
The phrases are often used interchangeably, but there is a useful distinction.
Requirements gathering can sound as though requirements already exist in a finished form and simply need to be collected. In reality, stakeholders may know what frustrates them or what outcome they want without being able to describe a complete requirement.
Requirements elicitation reflects the investigative nature of the work. The Business Analyst draws out information, explores different perspectives, identifies gaps and confirms what has been understood.
The International Institute of Business Analysis places elicitation and collaboration among the core knowledge areas of business analysis. Its framework includes preparing for elicitation, conducting elicitation, confirming the results, communicating business analysis information and managing stakeholder collaboration.
Why are good requirements so important?
A project can be delivered on time and within budget and still fail if it solves the wrong problem. Weak requirements can lead to:
- features that users do not actually need
- important capabilities being discovered late
- conflicting interpretations between business and technical teams
- rework during development or implementation
- poor estimates and unrealistic plans
- failed acceptance testing
- solutions that meet a specification but do not deliver business value
- stakeholder frustration and loss of confidence
Requirements therefore provide more than a checklist for a development team. They connect the original business need with the change that will eventually be implemented.
What is a requirement?
In business analysis, a requirement represents a need rather than simply a requested feature. Requirements can exist at different levels.
Business requirements
These describe the goals, objectives or outcomes that explain why a change is being considered.
For example: Reduce the average time taken to resolve customer service enquiries.
Stakeholder requirements
These describe what particular stakeholders need in order for the wider business requirement to be achieved.
For example: Customer service advisers need to see a customer's previous contacts without opening several separate systems.
Solution requirements
These describe the capabilities and qualities a solution must provide. They include functional requirements and non-functional requirements.
For example: The system must display all customer interactions from the previous 24 months on one screen.
Our guide to functional vs non-functional requirements explores this distinction in more detail.
Transition requirements
These are temporary needs associated with moving from the current state to the future state, such as data migration, training or business continuity arrangements.
Where do requirements come from?
Stakeholders are a major source of requirements, but they are not the only source. A Business Analyst may need to investigate:
- customers and end users
- managers and process owners
- subject-matter experts
- existing procedures and documentation
- current systems and data
- laws and regulations
- contracts and service agreements
- business rules
- complaints and support records
- performance data
- competitor or market expectations
- technical constraints
- organisational policies and standards
This matters because stakeholders may unintentionally omit requirements that they take for granted. Someone who has performed a task for ten years may not think to mention an important exception because it feels obvious to them.
The requirements gathering process
There is no single sequence that fits every initiative, but a practical approach usually includes the following stages.
1. Understand the business problem
Before asking what a new system should do, clarify why change is needed. Useful questions include:
- What problem or opportunity triggered this work?
- Who is affected?
- What evidence shows there is a problem?
- What happens if nothing changes?
- What outcome would indicate success?
This step helps prevent a proposed solution from being mistaken for the underlying requirement.
2. Identify the stakeholders
The Business Analyst needs to determine whose knowledge, needs, authority or experience is relevant. A stakeholder can be anyone with a relationship to the change, need or solution.
Missing an important stakeholder group can create serious gaps. For example, designing a new purchasing process only with managers could overlook the people who enter orders every day, Finance staff who reconcile invoices and suppliers who need accurate purchase information.
3. Plan the elicitation
Choose techniques according to the information required, the stakeholders involved and the constraints of the initiative. A workshop may be ideal when several departments need to reach agreement, while observation may be better for understanding a manual operational process.
4. Conduct elicitation
This is the investigative stage. The analyst asks questions, listens, observes, records information and follows up inconsistencies or assumptions.
5. Analyse and model the information
Raw notes are not the finished requirements. The analyst needs to organise findings, identify relationships, remove duplication, resolve ambiguity and model information where diagrams provide greater clarity.
6. Confirm the results
Stakeholders should have an opportunity to verify that the captured information accurately reflects what was discussed. Confirmation is especially important where terminology is ambiguous or several stakeholder groups have different perspectives.
7. Prioritise and manage requirements
Not every requirement has the same value or urgency. Requirements may need prioritisation, traceability, formal approval and controlled change as the initiative develops.
Common requirements elicitation techniques
Interviews
One-to-one or small-group interviews are useful for exploring a stakeholder's role, concerns, knowledge and expectations in depth.
Strong interviews use open questions such as “What happens next?” and “Why is that step necessary?” rather than simply asking whether a pre-written requirement is correct.
Workshops
Workshops bring multiple stakeholders together to explore a topic collaboratively. They can be very effective when departments need to understand one another's needs or reach agreement on a future process.
The facilitator needs to make sure that louder participants do not dominate and that disagreement is explored rather than hidden.
Observation
Watching people perform real tasks can reveal knowledge that is difficult to describe in an interview. Observation can uncover workarounds, exceptions, duplicate data entry and unofficial steps that are absent from documented procedures.
Document analysis
Existing policies, forms, process guides, reports, contracts and system documentation can provide useful evidence. They should not automatically be assumed to reflect current practice, however.
Surveys and questionnaires
These are useful for collecting structured input from a large or geographically dispersed group. They are less suitable where the analyst needs to explore unexpected answers in depth.
Process modelling
Drawing the current process can expose hand-offs, loops, delays and unclear responsibilities that are hard to see in narrative notes. Standard approaches such as BPMN can provide a common language for more detailed process modelling. See What Is BPMN? A Beginner's Guide to Business Process Modelling.
Prototyping
A simple mock-up, wireframe or prototype can help stakeholders react to something concrete. It can expose assumptions about screens, information and workflow before expensive development begins.
Data analysis
Operational data can challenge perceptions. Stakeholders may believe a delay affects every customer when data shows it is concentrated in one product or one stage of the process. Evidence helps the analyst distinguish symptoms from causes.
How to ask better requirements questions
Questions are one of the Business Analyst's most important tools. Useful categories include:
- Purpose: Why is this needed?
- Outcome: What should be different when the change succeeds?
- People: Who performs this activity and who is affected by it?
- Process: What happens before and after this step?
- Information: What data is needed, where does it come from and who owns it?
- Rules: What determines which path is followed?
- Exceptions: What happens when the normal process cannot be followed?
- Volume: How often does this happen and how many transactions or users are involved?
- Quality: How fast, secure, reliable or usable must the solution be?
- Evidence: How do we know this is a problem?
- Priority: What happens if this requirement is not delivered?
A good analyst is comfortable asking apparently simple questions. “Why?” and “What do you mean by that?” can uncover more value than highly technical questions asked too early.
Requirements are not the same as solutions
One of the most common mistakes is recording a proposed solution as though it were the requirement.
Consider the statement: “We need a mobile app.”
That is a solution idea. The analyst should investigate the need behind it. Perhaps field engineers need access to job information while away from the office. Once the actual need is understood, possible solutions might include a mobile app, a responsive web application, changes to an existing field-service platform or another approach.
Separating the need from the proposed solution creates room for better options.
How detailed should requirements be?
The appropriate level of detail depends on the delivery approach, risk, complexity and audience.
A regulated system may require highly detailed, traceable specifications. An Agile product team may refine user stories progressively as work approaches. Neither approach removes the need for clarity.
The key question is whether the requirement contains enough information for the next activity. Can stakeholders judge whether it reflects the need? Can designers and developers understand what must be achieved? Can testers determine whether the result is acceptable?
What makes a good requirement?
Useful requirements should be:
- clear and unambiguous
- necessary
- consistent with other requirements
- feasible
- appropriately detailed
- testable or verifiable where applicable
- traceable to the business or stakeholder need
- understood and agreed by the relevant people
Words such as “fast”, “user-friendly”, “simple” and “secure” can create ambiguity unless they are defined in measurable or observable terms.
What are the most common requirements gathering mistakes?
- Starting with the solution. The team asks what features are needed before understanding the underlying problem.
- Talking to only one stakeholder. One perspective is treated as the whole organisation's requirement.
- Asking only closed questions. The analyst confirms assumptions rather than discovering new information.
- Ignoring exceptions. Only the normal process is documented.
- Recording wants without asking why. Stakeholder requests are copied directly into the specification.
- Forgetting non-functional requirements. The team defines behaviour but not performance, security, accessibility, reliability or other quality needs.
- Failing to confirm findings. Misunderstandings remain hidden until much later.
- Assuming requirements never change. New evidence and changing circumstances are not managed properly.
Requirements gathering in Agile environments
Agile delivery does not mean “no requirements”. It changes when and how some requirements are developed.
Instead of attempting to specify the entire solution in exhaustive detail before delivery begins, an Agile team may maintain a prioritised backlog and progressively refine items as they move closer to implementation.
Business analysis remains valuable because the team still needs to understand business goals, stakeholder needs, process context, acceptance criteria and solution quality. The analyst may work closely with a Product Owner and delivery team to explore upcoming work and maintain a coherent view of the wider change.
Who is responsible for gathering requirements?
A Business Analyst frequently leads requirements elicitation and analysis, but requirements are a collaborative responsibility. Stakeholders provide knowledge and decisions; subject-matter experts explain rules and processes; architects and developers contribute technical constraints and options; testers help make requirements verifiable; and project or product leaders help manage priorities and delivery.
The Business Analyst's value lies in bringing those perspectives together in a disciplined way.
Frequently asked questions
What is the difference between gathering and documenting requirements?
Gathering or eliciting requirements is about discovering and exploring needs. Documentation records those needs in an appropriate form. Good documentation cannot compensate for poor elicitation because an incomplete understanding can simply be documented very neatly.
What is a requirements workshop?
A requirements workshop is a facilitated session in which relevant stakeholders explore, define, analyse or agree requirements together. Workshops can reduce lengthy chains of separate meetings when several groups need to resolve shared issues.
Do requirements have to be written as user stories?
No. User stories are one way of representing needs, particularly in Agile environments. Requirements can also be expressed through models, diagrams, use cases, business rules, tables, prototypes, specifications and other forms.
Is a Business Requirements Document always necessary?
No. The documentation approach should suit the organisation, project and delivery method. What matters is that the necessary information is understood, controlled and available to the people who need it.
Can requirements change after they have been approved?
Yes. Business needs, regulations, technology and stakeholder understanding can change. The important point is that changes are assessed and controlled rather than silently introduced.
What is requirements traceability?
Traceability records relationships between requirements, needs, designs, tests and other related information. It helps teams understand why a requirement exists and assess the impact when something changes.
Develop your requirements skills with ExperTrain
ExperTrain offers a range of instructor-led Business Analysis training for people who need to investigate business needs, work with stakeholders and define high-quality requirements.
The Business Analysis: Requirements Development, Documentation and Management course covers requirements planning, elicitation, modelling, documentation, quality, traceability and lifecycle management in depth.
You may also find our Business Analysis Glossary, Business Analyst vs Project Manager and Data Analyst vs Business Analyst useful.
Further reading
Found this article useful? Add ExperTrain as a Preferred Source on Google to help surface more of our training guides, articles and learning resources.
.png){kind=small}
