Important things to know
Many beginners think becoming a good Business Analyst is about learning tools.
Jira. Confluence. Visio. SQL. Power BI. Those tools can help you do the work, but they don't teach you how to think through a business problem.
A stakeholder says, “We need a new system.” A good Business Analyst doesn't immediately start writing requirements. They ask: Why?
What problem are we actually solving? Who is affected? What happens today? What happens if we do nothing?
That is where Business Analysis techniques become powerful.
Here are the techniques I recommend every beginner learn.
1. Stakeholder Analysis
Before gathering requirements, understand who you're dealing with.
Stakeholders have different levels of influence, interest, knowledge, and impact.
A senior executive may have the authority to approve a project but limited knowledge of the day-to-day process. Meanwhile, an operational employee may have little decision-making power but understand the problem better than anyone else.
Stakeholder analysis helps you identify:
- Who needs to be involved
- Who makes decisions
- Who provides critical information
- Who may resist the change
- Who will be affected by the solution
Don't assume the person with the highest title knows the most about the problem.
2. Requirements Elicitation
Requirements elicitation is more than asking stakeholders, "What do you need?"
People often describe solutions instead of problems.
A stakeholder might say:
"We need a dashboard."
But what they may actually need is a faster way to access performance data without manually combining five spreadsheets every week.
Techniques such as:
- Interviews
- Workshops
- Observation
- Surveys
- Document analysis
help you uncover the real need behind the request.
My advice: Don't take the first requirement you hear at face value. Ask questions until you understand the business problem behind it.
3. Root Cause Analysis
One of the biggest mistakes a Business Analyst can make is solving a symptom instead of the actual problem.
Imagine a company says:
"Customer applications are taking too long."
The immediate solution might be to redesign the application form.
But further investigation reveals that applications are delayed because employees manually transfer customer information between three systems.
The real problem isn't the form.
It's the process and system integration.
Techniques such as the 5 Whys help you move from the visible problem to its underlying cause.
Don't just ask, "What's wrong?" Ask, "Why is it happening?"
4. Process Mapping
If you don't understand how a process works, you probably aren't ready to improve it.
Process mapping helps you visualize:
- Activities
- Decisions
- Handoffs
- Roles
- Systems
- Bottlenecks
For example:
Customer submits request → Employee reviews → Missing information identified → Customer contacted → Request resubmitted → Review repeated
Suddenly, you can see where the process is breaking down.
Business Analysts commonly use flowcharts, swimlane diagrams, and BPMN to represent processes.
One important rule:
Understand the AS-IS process before designing the TO-BE process. Otherwise, you risk automating a broken process instead of fixing it.
5. Gap Analysis
Gap analysis helps you understand the difference between where the business is today and where it wants to be. This technique is particularly useful for digital transformation, system implementation, and process improvement projects.
It turns a vague statement like "We need to improve our process" into something more concrete:
What is missing, and what needs to change?
6. User Stories and Use Cases
Once you've understood the problem, you need to clearly describe what users need from the solution.
A simple user story might be:
As a procurement officer, I want to review supplier submissions so that I can evaluate vendors before making a recommendation.
Use cases go deeper by describing how a user interacts with a system, including:
- Preconditions
- Main flow
- Alternative flows
- Exceptions
- Expected outcomes
The key is not to write requirements that simply describe features.
Connect the requirement to the user and the business value.
7. MoSCoW Prioritization
Here's a reality every beginner Business Analyst eventually encounters:
You cannot build everything at once.
MoSCoW helps prioritize requirements as:
- Must Have
- Should Have
- Could Have
- Won't Have This Time
Imagine a procurement system with 30 requested features. If all 30 are "Must Haves," you've learned nothing about priorities. The real skill is helping stakeholders decide: What creates the most value now, and what can wait? Prioritization is about making trade-offs visible.
The biggest mistake I see new Business Analysts make is confusing documentation with analysis. You can write a perfect requirements document for the wrong problem. You can create a beautiful process map for a process that shouldn't exist, document excellent user stories for features users don't actually need but your value as a Business Analyst comes from what happens before the documentation: You investigate, question, challenge assumptions, identify root causes and bring people into alignment. Then you document the outcome. That's analysis.
The best Business Analysts don't simply document what the business says it wants but help the business discover what it actually needs and that is why the projects you work on when building your portfolio has to scream business impacts/value. If you don't know where to start from, book a free clarity call with someone on our team who will guide you on how to join the next cohort of our business analysis work experience program. Use this link to book a call
