What does a business analyst do?

The short answer

A business analyst sits between the people who need a change and the people who build it. They listen to the business, investigate how the work really happens, describe what has to change in words that developers and testers can use, and then stay involved until the change works. The job is mostly communication and clear thinking, supported by a few practical techniques.

If you have read what business analysis is, this article shows the practical side: what fills the working day. The honest answer is that it varies. A business analyst in a bank, a hospital group and a small software company will do overlapping work with different emphasis, different tools and different job titles. The sections below describe the common core.

Core responsibilities

Most business analyst job descriptions are variations on the same group of responsibilities. It helps to see them as a loop rather than a list, because real projects keep cycling through them.

Understand the business and the problem

The analyst reads existing documents, studies the current process, looks at relevant data and talks to people. The aim is to write a sharp problem statement and to understand what success would look like. They question solutions that arrive before the problem is clear.

Work with stakeholders

They identify the stakeholders, find out what each needs, handle disagreements and keep people informed. Our guide to stakeholder analysis and RACI covers this in detail.

Gather requirements

Using elicitation techniques such as interviews, workshops and observation, the analyst collects needs, then analyses them for gaps, conflicts and ambiguity.

Model and document

They draw process models, write user stories and acceptance criteria, and maintain documents such as a BRD. The BRD, FRD and SRS comparison explains which document fits which purpose.

Support delivery

During build, developers ask questions and change requests appear. The analyst clarifies, adjusts priorities with the product owner, updates documents and keeps the backlog ready for the next sprint.

Support testing and release

They help design test scenarios, coordinate user acceptance testing, review defects and help the business prepare for go-live.

Check that value arrived

After release, they compare real results with the original goals and record what was learned. This last step is often skipped, and it is where analysts add the most credibility.

A typical week: a fictional example

To make this concrete, here is an invented week for Priya, a business analyst at Cedar Credit Union. The credit union wants to cut the time customers wait for a loan decision. Priya is two weeks into the project.

Notice several things. Priya spends most of her time talking, listening and writing, not producing complicated diagrams. She tests her assumptions with data. She also shortens the loop between learning something and sharing it, with same-day minutes and a Friday review with a developer. These habits matter more than any particular template.

Notice too what the example does not include: she does not choose the technology, she does not decide the loan approval policy and she does not manage the budget. She prepares good information for the people who do.

The tools and outputs you will meet

Tools change by employer, but the categories are stable. You do not need to master all of them before applying for roles, but you should know what each is for.

• Documents and wikis. Requirements pages, meeting notes and decision logs, often in a Confluence-style space. See documentation for business analysts.
• Work trackers. Tools like Jira hold stories, bugs and tasks. See Jira for business analysts.
• Diagramming. BPMN or simple flowcharts for processes, and entity relationship diagrams for data.
• Spreadsheets. Surprisingly central: for traceability, analysis, mapping and quick calculations.
• SQL and reporting tools. Used to check data and to specify dashboards. See SQL for business analysts.
• API tools. Used to look at what systems exchange. See APIs for business analysts.

The outputs worth knowing about are the ones in the table in our introduction to business analysis: problem statements, process models, requirements, stories, acceptance criteria and test scenarios. Each exists to answer a question for a specific reader.

Who business analysts work with

Because the role connects people, the list of colleagues is long. Understanding how each group sees your work makes you easier to work with.

• Sponsors and senior managers want to know whether the change is worth it, how long it will take and what could go wrong. They need short, evidence-based summaries.
• Business users know how the work really happens. They need to feel listened to, and they need plain language.
• Developers need unambiguous rules, examples and quick answers. They dislike surprises mid-sprint.
• Testers need testable statements and clear expected results. Good acceptance criteria help them enormously.
• Project managers plan time and money; analysts define the content of the work. Read how the two roles differ in business analyst vs project manager.
• Data and reporting colleagues help find and interpret data. See business analyst vs data analyst.
• Compliance, legal and security specialists shape rules that cannot be negotiated.

What separates a strong analyst from an average one

The tasks above are the same for everyone. The difference lies in habits. These are the ones that experienced teams tend to notice.

1. They ask why before what. When someone says they need a report, a strong analyst asks what decision it supports.
2. They use examples. A rule tested on three real cases is clearer than a paragraph of policy.
3. They write for the reader. A sponsor, a developer and a tester each get what they need, not one long document.
4. They check numbers. A claim such as "most customers cancel late" is tested against data before it becomes a requirement.
5. They record decisions. Who decided what, and why, is written where the team can find it.
6. They stay calm with conflict. They surface disagreements early and help the right person decide.
7. They follow through. They stay involved in testing and check the outcome after release.

The full list of capabilities, with ways to practise each, is in our guide to business analyst skills.

Job titles and how the role varies

Not every job advert says "business analyst". You will see related titles that contain much of the same work: systems analyst, functional analyst, product analyst, process analyst, requirements engineer, and sometimes "product owner" or "business systems analyst". The emphasis differs.

• In finance and banking, rules, controls and regulation take a large share of the work.
• In software companies, the analyst often works inside an agile team, closely with a product owner.
• In operations-heavy firms, such as logistics, process improvement is more prominent.
• In data-focused teams, the analyst may specify reports and check data quality more often.

Read advert descriptions closely and compare the actual responsibilities to this list. If you are choosing between neighbouring careers, the comparisons with project management and data analysis may help.

If you want to try parts of the job before committing, the free demo lets you attempt a fictional banking mission, and the BA Lab lets you work through a simulated company project stage by stage. Neither is a job offer or a credential, but both give you something concrete to talk about.

Frequently asked questions