Requirements Gathering and Analysis: A Practical Step-by-Step Guide for Business Analysts

Requirements gathering is one of those phrases that makes Business Analysis sound simpler than it really is.

You find the stakeholders, ask them what they need, write the requirements down and hand them to the delivery team. Bosh! Job done.

Except that stakeholders regularly disagree with each other (some might say routinely). They quite often typically launch into describing solutions rather than problems (we do not want solution led requirements). Important people are missed. Existing processes are poorly understood. Requirements contradict one another. Technical constraints emerge late. What somebody says they need in a workshop can be very different from what becomes apparent when you watch them actually doing their job.

This is why good requirements work is not simply gathering. A Business Analyst has to discover, question, analyse, challenge, structure, validate and manage information until the organisation has enough shared understanding to make sensible decisions and, where appropriate, build the right thing.

There are dozens of techniques available to help you do that, but techniques without structure can easily turn into BA theatre: workshops because BAs run workshops, process maps because BAs draw process maps, and user stories because somebody has decided the project is Agile.

A better approach is to understand what you are trying to achieve at each stage.

For most pieces of requirements work, a practical structure looks something like this:

1. Understand the problem and scope → 2. Identify the right people → 3. Understand the current state → 4. Plan your elicitation → 5. Elicit the requirements → 6. Analyse and challenge → 7. Structure and document → 8. Prioritise → 9. Validate → 10. Maintain and control

The precise techniques will vary enormously from one project to another. The underlying thinking is much more consistent. You should have something akin to this as part of your "mental toolkit" (remember the BBC's Sherlock and his "mind palace" - this is your mental toolkit).

---

1. Understand the problem before gathering requirements

One of the easiest mistakes to make is beginning requirements elicitation too early. I CANNOT emphasise enough the concept of "what is the problem to solve?" - I bore people to tears by repeating this, but there's nothing worse than solving the wrong problem, quickly!

A stakeholder says:

“We need a new customer portal.”

That is not necessarily a requirement. It is a proposed solution.

Before arranging workshops about what the new portal should contain, establish why anybody thinks a new portal is needed in the first place.

Perhaps customers cannot find information. Perhaps call-centre volumes are too high. Perhaps the existing portal is expensive to maintain. Perhaps customers are abandoning an application process halfway through. Perhaps somebody senior saw a competitor's website and decided the organisation should have something similar.

Those are very different problems and could lead to very different solutions.

Start by establishing the basics:

• What problem are we trying to solve?

• Who is affected by it?

• What evidence tells us the problem exists?

• What is the impact of doing nothing?

• What outcome does the organisation want?

• What is already known?

• What constraints already exist?

• What appears to be in and out of scope?

• Has a solution already been chosen, and if so, why?

You do not need perfect answers before continuing. Early discovery is partly about uncovering what you don't yet know.

But you should be able to describe the problem in reasonably plain English.

For example:

Customers currently have to telephone the service team to change their delivery preferences. This creates approximately X contacts per month, increases service costs and prevents customers managing straightforward changes themselves. The organisation wants to reduce avoidable contacts while giving customers greater control over their deliveries.

That is a much healthier starting point than:

Requirement: Build delivery management portal.

Output from this stage

At minimum, you should have:

Problem → Desired outcome → Initial scope → Known constraints → Major unknowns

That gives the rest of the analysis a purpose.

---

2. Identify who actually needs to be involved

Requirements become dangerous when they represent the loudest stakeholder rather than the organisation.

Before deciding how you will gather information, work out where the information needs to come from.

Your stakeholder analysis does not need to become a beautiful diagram nobody looks at again. Its purpose is to answer practical questions.

Who uses the current process? Who owns it? Who makes the final decision? Who understands the technology? Who deals with the consequences when it fails? Who understands the data? Who needs to approve the change? Who could block it? Who is affected indirectly?

For a relatively simple digital change, your stakeholder landscape might include:

Stakeholder	Why you need them
Product Owner	Objectives, priorities and product direction
Operational users	How the current process actually works
Customers/end users	Needs, pain points and behaviours
Developers	Technical feasibility and constraints
QA/Test	Testability, scenarios and exceptions
Security	Security requirements and risks
Legal/Compliance	Regulatory and legal constraints
Data specialists	Data sources, definitions and quality
Service/Support	Common failures and customer problems

Missing one important group can fundamentally change your requirements later.

A classic example is designing a slick new customer journey with Product and Technology, only to discover shortly before release that Compliance requires an additional verification step.

That is not really a late requirement.

It is often an early stakeholder that was discovered late.

---

3. Understand the current state/as is

Before deciding what should change, understand what happens now.

This is particularly important when stakeholders tell you:

“The current process is simple.”

It may be simple on paper. Reality can be different.

You gotta talk to the people performing the work. Observe the process where possible. Review existing documentation, systems, data, complaints, tickets and reports. Walk through real examples rather than relying entirely on somebody's memory of what normally happens.

You may want to establish:

• What triggers the process?

• What happens next?

• Who performs each step?

• Which systems are involved?

• What information moves between them?

• Where are decisions made?

• Where are the hand-offs?

• What happens when something goes wrong?

• Where do delays occur?

• Which manual workarounds exist?

• What rules govern the process?

• What data is created or changed?

• Where do users become frustrated?

This is where process mapping can become genuinely useful. An AS-IS process map should not exist because a methodology says you need one. It should help you understand the current situation, expose complexity and give stakeholders something concrete to challenge. Don't get hung up on which diagram to use, focus on the value producing one will give you/the organisation. 

Often somebody will look at your process map and say:

“That's not what happens.”

Good.

You have just discovered something and something very useful. 

Output from this stage

Depending on the problem, you may now have an AS-IS process, pain-point list, system/context diagram, existing business rules, data observations and a clearer list of questions that need answering.

Now you are ready to investigate the future more intelligently.

---

4. Plan how you will elicit the requirements

There is no universal “requirements gathering meeting”.

Different information requires different techniques.

A workshop can be excellent when several stakeholders need to reach shared understanding. It can be terrible when one senior person dominates the room and everyone else stops talking.

An interview can uncover detailed knowledge from a subject-matter expert. Observation can reveal the difference between the documented process and the real one. Data analysis can tell you whether a supposed problem is common or merely memorable. Prototypes can help users explain something they struggle to articulate verbally.

Choose the technique according to the question.

What you need to understand	Useful approaches
Individual stakeholder needs	Interviews, 1:1 discussions
Different stakeholder perspectives	Workshops
Existing workflow	Observation, process mapping
Customer behaviour	User research, analytics, interviews
Existing system behaviour	Documentation review, system walkthrough
Scale/frequency of a problem	Data analysis
Complex future interaction	Prototype/wireframe
Business rules	SME interviews, documentation review
Competing priorities	Prioritisation workshop
Technical constraints	Three Amigos/technical discussion

Usually, you will use several.

Good elicitation is rarely one big workshop followed by three weeks writing a document.

---

5. Elicit: ask better questions

This is where people normally think requirements gathering begins.

By this point, however, you already know why the work exists, who matters and how the current environment operates. Your questions should therefore be considerably better.

Avoid relying entirely on:

“What do you need?”

Stakeholders often answer that with solutions.

Instead, explore the need underneath the request.

If somebody says:

“We need an export to Excel button.”

you might ask:

What are you trying to do once you've exported the information?

Perhaps the answer is:

“I need to combine it with the monthly finance report.”

Now you have learnt something much more useful.

Continue:

Why do you need to combine them? What information is missing from the existing report? Who uses the combined version? How often? What happens if the figures don't match?

One superficial requirement can uncover a much larger analytical problem.

Useful questions include:

• What are you trying to achieve?

• Why is that important?

• What happens today?

• What is wrong with the current approach?

• Who does this affect?

• How often does this happen?

• Can you show me an example?

• What happens if this fails?

• What are the exceptions?

• What happens before this?

• What happens afterwards?

• Who makes that decision?

• What information do they use?

• Is that always true?

• What would success look like?

• What is essential and what would simply be useful?

One of the most powerful BA questions is also one of the simplest:

“Can you show me?”

The answer can expose more than another half-hour of discussion.

---

6. Analyse and challenge what you have heard

This is where requirements gathering becomes requirements analysis.

Do not simply type up your meeting notes and call them requirements.

You need to work through the information and ask whether it makes sense.

Look for duplication, ambiguity, assumptions, conflicts, gaps, dependencies, constraints, exceptions and contradictions.

Suppose you uncover these two statements:

Customer Service: “Customers should be able to change their address instantly.”

Fraud Team: “Address changes must be reviewed before taking effect.”

You do not have two requirements ready for Jira.

You have a conflict requiring analysis.

You might need to establish whether all address changes require review, whether risk criteria can determine which changes need checking, how long review takes, what happens while a change is pending and what the customer sees.

That analytical work is where a good BA adds considerable value.

Use a simple analysis checklist

For every significant requirement, ask:

WHY — What need does this address?

WHO — Who needs or is affected by it?

WHAT — What actually needs to happen?

WHEN — What triggers it and when does it apply?

DATA — What information is required or changed?

RULES — What business rules govern it?

EXCEPTIONS — What happens when the normal path doesn't apply?

DEPENDENCIES — What else must exist or happen?

CONSTRAINTS — What limits the possible solution?

VALUE — What outcome does this contribute to?

TEST — How will we know it works?

If you cannot answer several of those, you may not understand the requirement yet.

---

7. Structure the requirements at the right level

Not every requirement belongs at the same level.

A useful hierarchy might be:

Business need

Reduce avoidable customer-service contacts relating to delivery changes.

Stakeholder/user need

Customers need to manage eligible delivery preferences without contacting Customer Service.

Functional requirement

The service shall allow an authenticated customer to change the delivery date for an eligible order.

Business rule

Delivery dates may only be changed before the order enters the dispatch process.

Non-functional requirement

A confirmed delivery-date change must be reflected in the customer's account within X seconds.

Agile user story

As a customer, I want to change my delivery date so that I can receive my order when I am available.

Acceptance criteria

Given an authenticated customer has an eligible order
When they select an available alternative delivery date
Then the new delivery date is saved and displayed in their account.

The exact artefacts will depend on how your organisation works.

The important thing is maintaining the connection between why the change exists and what the delivery team eventually builds.

If your backlog contains 150 user stories but nobody can explain which business objective they support, something has gone wrong.

---

8. Analyse the unhappy paths

Requirements sessions naturally drift towards the ideal journey.

Customer logs in. Customer selects product. Customer pays. Order confirmed.

Lovely.

Now ask what happens when:

• payment fails;

• the product goes out of stock;

• the customer loses connection;

• the address cannot be validated;

• the user presses the button twice;

• the account is locked;

• the downstream service is unavailable;

• two systems contain different information;

• the customer changes their mind;

• the request arrives after the permitted deadline.

These scenarios are often where the real requirements are hiding.

A strong BA develops the habit of asking:

“What happens if...?”

You don't need to invent every catastrophic possibility imaginable. Concentrate on realistic exceptions, failure points and business rules.

But don't allow a happy-path process to masquerade as complete analysis.

---

9. Prioritise before everything becomes “Must Have”

Not every requirement has equal value.

If everything is a priority, nothing is.

MoSCoW can be useful — Must Have, Should Have, Could Have, Won't Have for now — but simply asking stakeholders to label requirements frequently results in an enormous pile of Must Haves.

Prioritisation needs reasoning.

Consider:

• business value;

• user value;

• risk;

• regulatory necessity;

• dependencies;

• cost;

• technical feasibility;

• urgency;

• learning value;

• consequence of omission.

A useful question is:

“What happens if we don't deliver this in the first release?”

If the answer is:

“It would be mildly inconvenient.”

you may not have a Must Have.

If the answer is:

“We cannot legally operate the service.”

you probably do.

Prioritisation is not merely putting letters next to requirements. It is helping people make trade-offs.

---

10. Validate the requirements with the people who matter

Before something moves into delivery, establish whether the relevant people share the same understanding.

Do the requirements reflect the actual business need? Have the right stakeholders reviewed them? Are important assumptions explicit? Are business rules understood? Are exceptions covered? Can the delivery team understand them? Can testers determine whether the outcome is correct?

Validation does not necessarily require a formal sign-off ceremony.

It might happen through backlog refinement, Three Amigos, walkthroughs, prototypes, requirement reviews or structured stakeholder approval.

What matters is that you do not silently turn your interpretation of a conversation into the organisation's agreed requirement.

A useful test is to ask different stakeholders to explain what they believe will happen.

If you get three materially different answers, the requirement isn't ready.

---

11. Make requirements testable

A requirement that cannot be tested deserves further investigation.

Consider:

“The system should be user-friendly.”

What exactly does that mean?

Or:

“The search must be fast.”

How fast?

Or:

“Customers should receive appropriate notifications.”

Which customers? Which events? Which channel? How quickly? What information should the notification contain?

You don't necessarily need every detail immediately, but ambiguous language creates room for different interpretations.

Acceptance criteria can help turn broad expectations into observable behaviour.

For example:

Given a customer successfully changes an eligible delivery date
When the change is confirmed
Then the revised delivery date is displayed in the customer's account
And a confirmation email is sent to the registered email address.

Now Product, Development, QA and the BA have something much more concrete to discuss.

---

12. Keep traceability without creating bureaucracy

Requirements change.

Stakeholders learn things. Technical constraints appear. Regulations change. User research reveals unexpected behaviour. A prototype demonstrates that the original idea doesn't work.

Change is not automatically a failure of analysis.

The problem is uncontrolled change.

You should be able to understand, at an appropriate level:

Business problem → Objective → Requirement → Delivery item → Validation

That does not mean building a colossal requirements traceability spreadsheet for every Agile product.

The amount of control should be proportionate to the work.

A safety-critical programme may require extensive formal traceability. A small internal product improvement probably does not.

Use enough structure to answer:

“Why are we building this?”

and:

“What happens if we change it?”

If nobody can answer either question, you have probably lost control of the requirements.

---

The complete requirements approach

If you want a repeatable method rather than trying to remember dozens of techniques, use this (hopefully you find this useful!):

Stage	Key question	Typical activities	Useful output
1. Problem	Why are we doing this?	Problem analysis, objectives, scope	Problem statement
2. People	Who matters?	Stakeholder analysis	Stakeholder map/list
3. Current State	What happens now?	Observation, process/data analysis	AS-IS understanding
4. Plan	How will we learn what we need?	Select elicitation techniques	Elicitation plan
5. Elicit	What do people actually need?	Interviews, workshops, research	Raw needs/information
6. Analyse	Does it make sense?	Challenge, gaps, rules, conflicts	Analysed requirements
7. Structure	How should it be represented?	Stories, models, requirements	Structured backlog/specification
8. Prioritise	What matters most?	Value/risk/dependency analysis	Prioritised requirements
9. Validate	Do we share the same understanding?	Reviews, refinement, Three Amigos	Agreed/testable requirements
10. Maintain	What has changed and why?	Traceability/change management	Controlled requirements

The techniques underneath those stages can change.

The thinking should remain.

---

A practical BA requirements checklist

Before you consider your requirements mature enough to move forward, ask yourself:

• Do I understand the problem rather than simply the requested solution?

• Do I know what success looks like?

• Have I involved the right stakeholders?

• Do I understand the current state?

• Have I used appropriate elicitation techniques rather than defaulting to workshops?

• Have I challenged assumptions?

• Have conflicting requirements been resolved?

• Have I identified important business rules?

• Have I considered data?

• Have I considered exceptions and failure scenarios?

• Are important dependencies and constraints visible?

• Can I connect the requirements to business or user value?

• Have they been prioritised meaningfully?

• Can the delivery team understand what is needed?

• Can QA/test determine whether it works?

• Have the appropriate stakeholders validated the understanding?

If several answers are no, don't solve the problem by writing more documentation.

Work out what you still don't understand.

---

What good requirements analysis actually looks like

Strong requirements analysis is not measured by the number of user stories written, workshops facilitated or pages added to Confluence.

It is measured by clarity.

The business understands the problem. Stakeholders understand what has been agreed. Product understands the value. Developers understand what needs to happen. Testers understand how to establish whether it works. Important assumptions and exceptions have been exposed before they become expensive surprises.

And throughout all of that, somebody keeps asking the awkward questions:

Why?

Who needs this?

What problem does it solve?

What happens if it fails?

What are we assuming?

What have we missed?

How will we know it worked?

That somebody is very often the Business Analyst.

The best requirements work can therefore look deceptively simple by the time it reaches delivery. The ambiguity has been removed, the contradictions have been resolved and the important decisions have already been made.

But simplicity at the end usually exists because somebody did the difficult analysis at the beginning.

---

Developing your requirements and analysis skills

Understanding the process described above is useful. Becoming good at it requires practice. Real requirements rarely arrive neatly enough to fit into a template: stakeholders contradict one another, information is missing, priorities compete and the BA has to decide which question to ask next.

That distinction matters commercially and professionally. Reading a guide can show you what a structured requirements approach looks like; being able to apply it confidently to an ambiguous business problem is a different level of capability.

Elisto's Business Analyst training focuses on that practical application: working through requirements, user stories, acceptance criteria, stakeholder problems and delivery scenarios rather than simply memorising BA terminology.

The Knowledge Hub can show you the method.

The real skill is learning how to use it when the answer isn't sitting conveniently in front of you.