One of the most important skills of a Business Analyst is turning an unclear business problem into clear, structured and actionable requirements.
Stakeholders rarely arrive with perfectly defined requirements.
More often, they say things like:
“The process takes too long.”
“We need better reporting.”
“The system is difficult to use.”
“We need more automation.”
“We need a new CRM.”
These statements are valuable starting points, but they are not requirements.
The Business Analyst’s role is to investigate what sits behind these statements, understand the actual business need, and progressively translate that understanding into requirements that stakeholders, designers, developers and testers can all work with.
A useful way to think about this journey is:
Business Problem → Root Cause → Business Need → Desired Outcome → Future State → Requirements → Acceptance Criteria
Let’s look at how this works in practice.
1. Start With the Problem, Not the Solution
One of the most common mistakes in projects is beginning with a predetermined solution.
A stakeholder might say:
“We need a new customer portal.”
The natural response might be to start gathering requirements for the portal.
But an experienced Business Analyst asks:
“What problem are we trying to solve?”
Further investigation might reveal:
- Customers cannot access information online
- Service centre staff receive large volumes of routine enquiries
- Information exists across multiple systems
- Customers cannot track requests
- Staff manually provide status updates
- Response times are increasing
Now the conversation has changed.
The requirement is no longer simply:
“Implement a new customer portal.”
The underlying business problem is:
Customers do not have access to timely self-service information, resulting in unnecessary service enquiries, manual work and poor customer experience.
That is a much stronger foundation for analysis.
2. Separate Problems From Solutions
Stakeholders frequently describe solutions when they believe they are describing requirements.
Consider:
“We need a mobile app.”
This is a solution idea.
The underlying need might be:
“Field employees need to access and update job information while working away from the office.”
Once the need is understood, several possible solutions could exist:
Mobile App
Responsive Web Application
Existing Platform Enhancement
Offline Capability
Third-Party Solution
By separating the need from the solution, the BA keeps options open.
A useful question is:
“What would this allow you to do that you cannot do today?”
That often exposes the real requirement.
3. Understand the Business Impact
Not every problem deserves a project.
The Business Analyst needs to understand the impact.
Ask:
- Who is affected?
- How often does the problem occur?
- How much time is lost?
- What does the problem cost?
- Does it create customer dissatisfaction?
- Does it introduce compliance or operational risk?
- Does it prevent growth?
- Does it affect decision-making?
- What happens if nothing changes?
For example:
Problem
Invoice approvals take too long.
Impact
Invoices are paid late, employees spend time following up approvals, suppliers raise complaints and Finance has limited visibility of outstanding approvals.
Now there is a clear reason for change.
4. Find the Root Cause
A good Business Analyst does not stop at the first explanation.
Suppose a stakeholder says:
“Our approvals are too slow.”
Why?
Because managers take too long to approve requests.
Why?
Because requests are sent through email.
Why?
Because there is no automated workflow.
But continue investigating.
Perhaps the deeper issues include:
- Approval responsibilities are unclear
- Financial thresholds are inconsistent
- Managers receive incomplete information
- Requests cannot be delegated
- There is no escalation process
- Approvers cannot see pending requests easily
Simply automating the existing process may therefore not solve the underlying problem.
Techniques such as 5 Whys, Root Cause Analysis, Fishbone Analysis and Process Mapping can help uncover the real causes.
The journey becomes:
Symptom → Cause → Root Cause → Business Need
5. Understand the Current State
Before defining requirements, understand how things work today.
A Business Analyst may examine:
People → Processes → Systems → Data → Business Rules → Controls
For example, when analysing an employee onboarding process, the BA might document:
New Employee Confirmed
↓
Manager emails HR
↓
HR manually creates employee record
↓
IT receives separate request
↓
Equipment ordered
↓
System access requested
↓
Manager follows up manually
↓
Employee commences
Mapping the current state can expose:
- Duplicate activities
- Manual handoffs
- Delays
- Missing information
- Unclear ownership
- System limitations
- Workarounds
- Control gaps
These findings provide evidence for future requirements.
6. Define the Desired Business Outcome
Once the problem is understood, ask:
“What should be different when we have solved this?”
This moves the discussion away from features and toward outcomes.
For example:
Problem
Managers cannot easily see the status of purchase requests.
Desired Outcome
Managers can view the current status, owner and approval history of every purchase request.
Another example:
Problem
Students repeatedly contact support teams to check application status.
Desired Outcome
Students can independently view their current application status and outstanding actions.
The desired outcome provides the bridge between the problem and the requirement.
7. Define the Future State
The Business Analyst can now work with stakeholders to understand how the organisation should operate in the future.
The progression becomes:
AS-IS → Pain Points → TO-BE → Gap → Requirements
For example:
Current State
Purchase requests are submitted through email.
Pain Point
Requests are difficult to track.
Future State
Purchase requests are submitted and managed through a central workflow.
Gap
No workflow currently exists.
Requirement
The solution must enable employees to submit purchase requests through a centralised workflow.
Now the requirement has a clear connection to the business problem.
8. Move From Business Needs to Requirements
Requirements usually exist at different levels.
Business Requirement
Describes what the organisation needs to achieve.
The organisation must reduce the time required to process purchase requests.
Stakeholder Requirement
Describes what a stakeholder needs.
Managers need visibility of purchase requests awaiting their approval.
Functional Requirement
Describes what the solution needs to do.
The solution must display all purchase requests awaiting approval by the logged-in manager.
Non-Functional Requirement
Describes how the solution needs to perform.
The approval dashboard must load within three seconds under normal operating conditions.
This hierarchy helps maintain the connection between the original business need and detailed solution requirements.
9. Make Requirements Clear and Testable
A requirement should not leave room for multiple interpretations.
Consider:
“The system should be easy to use.”
What does easy mean?
Different stakeholders will interpret it differently.
A clearer requirement might be:
“The solution must allow an authorised manager to approve or reject a purchase request from the approval dashboard without navigating to another screen.”
Now the behaviour can be demonstrated and tested.
Strong requirements should generally be:
Clear — easy to understand.
Specific — precise about what is needed.
Necessary — connected to a genuine business need.
Feasible — realistically achievable.
Traceable — connected to its source and business objective.
Testable — capable of being validated.
10. Avoid Ambiguous Language
Certain words should make a Business Analyst ask more questions.
Examples include:
- Fast
- Easy
- Flexible
- User-friendly
- Appropriate
- Efficient
- Seamless
- Regularly
- Normally
- Adequate
- Optimised
Consider:
“The system must generate reports quickly.”
Ask:
How quickly?
Then the requirement might become:
“The solution must generate the monthly financial summary report within 10 seconds for standard reporting volumes.”
The ambiguity has been removed.
11. Use Acceptance Criteria
In Agile environments, requirements may be expressed as user stories.
For example:
As a manager, I want to view purchase requests awaiting my approval so that I can action them promptly.
This explains:
Who → What → Why
But the user story alone may not provide enough detail.
Acceptance criteria establish the conditions for success.
For example:
Given a manager has purchase requests awaiting approval,
When the manager opens the approval dashboard,
Then the system displays each request with the requester, amount, submission date and current approval status.
Now developers and testers have a much clearer understanding of expected behaviour.
12. Prioritise Requirements
Not every requirement has equal value.
A Business Analyst should help stakeholders determine what is genuinely essential.
One common approach is MoSCoW prioritisation:
Must Have
Essential for the solution to succeed.
Should Have
Important but not essential for initial delivery.
Could Have
Valuable if time and resources allow.
Won’t Have Now
Explicitly deferred from the current scope.
Requirements can also be prioritised based on:
Business Value | Risk | Cost | Urgency | Compliance | Dependency
Prioritisation helps ensure the organisation focuses investment on the capabilities that matter most.
13. Validate Requirements With Stakeholders
Writing a requirement does not mean it is correct.
Requirements need to be validated.
Ask stakeholders:
- Does this accurately represent your need?
- Is anything missing?
- Does this conflict with another requirement?
- Is this genuinely necessary?
- Can we test whether it has been delivered?
- Who should approve it?
- What business outcome does it support?
Visual techniques can also improve validation.
Instead of relying only on text, consider using:
Process Maps
Wireframes
Prototypes
Decision Tables
Data Models
User Journey Maps
Stakeholders often identify gaps more easily when they can see how something is expected to work.
14. Maintain Traceability
One of the most valuable BA practices is being able to explain:
“Why does this requirement exist?”
A simple traceability chain might look like:
Business Problem
↓
Business Objective
↓
Stakeholder Need
↓
Business Requirement
↓
Functional Requirement
↓
User Story
↓
Acceptance Criteria
↓
Test Case
This creates visibility from the original business problem all the way through to the delivered solution.
If a requirement changes, the organisation can understand what else may be affected.
A Practical Example
Imagine an organisation says:
“We need to automate employee onboarding.”
Rather than immediately documenting automation requirements, the BA investigates.
Business Problem
Employee onboarding is slow and inconsistent.
Current-State Findings
- Requests are submitted through email
- Information is entered multiple times
- IT receives requests late
- Managers cannot track progress
- Equipment sometimes arrives after the employee starts
Root Cause
There is no coordinated onboarding workflow or clear ownership across HR, IT and managers.
Desired Outcome
New employees should have the required access, equipment and information available before their commencement date.
Future State
A central onboarding workflow coordinates HR, IT and manager activities.
Business Requirement
The organisation must provide a consistent and trackable employee onboarding process.
Functional Requirement
The solution must automatically create onboarding tasks for HR, IT and the employee’s manager when a new employee record is confirmed.
Acceptance Criteria
Given a new employee has been confirmed, when HR completes the employee record, then onboarding tasks must automatically be assigned to the relevant HR, IT and manager queues.
Notice how much stronger this is than simply:
“Automate onboarding.”
The Business Analyst’s Role Is Translation
Turning problems into requirements is fundamentally an exercise in translation.
The BA moves between different levels of understanding:
Stakeholder says:
“The process is terrible.”
↓
BA investigates:
“What specifically isn’t working?”
↓
Problem identified:
“Manual approvals create an average three-day delay.”
↓
Desired outcome:
“Approvals should normally be completed within one business day.”
↓
Requirement:
“The solution must automatically route requests to the appropriate approver based on approval authority.”
↓
Acceptance criteria:
The expected behaviour is clearly defined and testable.
This is where Business Analysis creates real value.
A Simple Framework to Remember
When turning a business problem into requirements, use:
PROBLEM
What isn’t working?
↓
WHY
What is causing it?
↓
IMPACT
Why does it matter?
↓
OUTCOME
What needs to improve?
↓
FUTURE STATE
How should things work?
↓
GAP
What needs to change?
↓
REQUIREMENTS
What capabilities are needed?
↓
VALIDATION
How will we know the requirement has been met?
This keeps requirements connected to genuine business needs rather than becoming a disconnected list of features.
Clear Requirements Start With Clear Problems
Good requirements do not begin with a template.
They begin with understanding.
Before asking:
“What should the system do?”
a Business Analyst should understand:
What problem are we solving?
Why does it matter?
Who is affected?
What causes the problem?
What does success look like?
What needs to change?
Only then should the conversation move toward detailed requirements.
The stronger the connection between the business problem and the requirement, the easier it becomes to prioritise scope, evaluate solutions, manage change and determine whether the final solution delivered genuine business value.
Ultimately, Business Analysis is not about producing more requirements.
It is about producing the right requirements for the right problem.
Develop Practical Requirements Analysis Skills
AgileBA’s Business Analysis training helps aspiring and practising Business Analysts develop practical skills in discovery, problem analysis, requirements elicitation, process mapping, stakeholder engagement, user stories and requirements validation.
Learn how to move confidently from an unclear business problem to structured, traceable and testable requirements using practical scenarios, templates and proven BA techniques.