What is business analysis?

Business analysis in one clear definition

Business analysis is the work of finding out what an organisation really needs and describing the change that would meet that need. The change might be a new screen in a mobile app, a simpler approval process, a report that finally matches the finance ledger, or a rule that stops customers being charged twice. What matters is that someone takes the time to understand the situation before money and effort are spent on a solution.

It helps to break the idea into three plain questions that every piece of business analysis tries to answer.

• What is the problem or opportunity? Not what people think the answer is, but what is actually going wrong or what could be better.
• What would a good outcome look like? A change is only useful if you can say how you will recognise success.
• What exactly must the solution do? Clear requirements that developers can build and testers can check.

A person who does this work is called a business analyst, although many people do business analysis without that job title: product owners, operations managers, consultants and project coordinators all do it some of the time. The discipline is wider than the job title, which is good news if you are moving into it from another role.

What business analysis is not

It is not the same as writing code, managing the project budget or analysing large data sets for statistical patterns, although it touches all three. A business analyst usually does not decide the technology, and does not own the final business decision. Their job is to make sure the people who do make those decisions have clear, evidence-based information, and that the delivery team understands what has been agreed.

Why business analysis matters

Most failed projects do not fail because the developers cannot write code. They fail because people built something that did not fit the real need. The requirement was vague, a key stakeholder was never asked, two teams meant different things by the same word, or the problem that was solved was not the problem that hurt.

Business analysis reduces these risks in a very practical way: the misunderstanding is discovered in a conversation or a diagram, where it costs minutes to fix, rather than in a finished system, where it costs weeks. Think of it as a cheap way of testing an idea before the expensive part begins.

• It saves rework. A rule written down and agreed early does not have to be rebuilt later.
• It gives decisions evidence. Options are compared using facts about cost, effort and benefit, not volume of opinion.
• It keeps teams aligned. Business people, developers and testers all work from the same description.
• It protects the scope. A written boundary lets a team say no politely to work that was never agreed.
• It lets you measure value. When a goal has a measure, you can check afterwards whether the change worked.

None of this requires a special tool. A short conversation, a clear sentence and a sketch on paper are often enough. The value comes from the thinking, not the format.

What business analysts actually produce

Business analysis is mostly invisible when it goes well: people simply find that the project makes sense. But there are concrete things an analyst creates along the way. Each one answers a particular question for a particular reader.

Notice how each output has a reader. A common beginner mistake is to produce a long document because documents feel like proof of work. A good analyst asks who will use the document and what decision or action it supports, and then makes it exactly that long.

The main steps of business analysis

Projects differ, but most business analysis follows a recognisable path. In an agile team the steps repeat in small cycles; in a more traditional project they may happen in longer phases. Either way, the thinking is the same.

1. Understand the situation. Learn how the business works today, who is involved and what has already been tried. Read documents, look at data and watch the work happen if you can.
2. Define the problem and goal. Write a short problem statement and a measurable objective. Agree them with the sponsor before going further.
3. Find the stakeholders. Identify who is affected, who decides and who has knowledge you need. The stakeholder analysis and RACI guide shows how.
4. Gather information. Use elicitation techniques such as interviews, workshops, observation and document review.
5. Analyse. Model the current process, find the pain points, compare the current and desired states and list the options.
6. Specify. Write requirements, stories and acceptance criteria that are clear, consistent and testable.
7. Confirm. Check with stakeholders that what you wrote is what they meant, and get sign-off where needed.
8. Support delivery. Answer questions from developers, help prioritise, clarify changes and join testing.
9. Check the result. After go-live, compare real results with the goal and record what you learned.

The order is not strict. You will often return to an earlier step when you learn something new, and that is a sign the analysis is working, not that it is failing.

A worked example: the abandoned checkout

Here is a small, fictional example that shows the steps in action. Marlow Online Store sells kitchen equipment. The owner tells the team: "We need a new checkout page. People are leaving without paying."

Step 1: question the solution

The owner has already jumped to a solution, a new page. The analyst, Dev, asks what the owner has seen. The answer is that sales dropped after a promotion ended and the analytics tool shows that many shoppers leave on the last page of checkout. That is an observation worth investigating, not yet a proven cause.

Step 2: gather evidence

Dev interviews two customer-support staff, who say that customers often call to ask about delivery charges. He reviews the checkout flow himself and notices that delivery cost appears only after the customer has typed a card number. He also pulls last month's order data and counts how many baskets reached the payment step compared with how many completed payment. The figures support the story: many people reach payment and few complete it, especially on larger baskets, where delivery cost is higher.

Step 3: write the problem statement

"Customers with larger baskets abandon checkout at the payment step. Support staff report that unexpected delivery charges are the most common complaint. Delivery cost is currently shown only after payment details are entered."

Step 4: define the goal and scope

The sponsor and Dev agree a SMART objective: increase the share of baskets that complete payment, measured from the same analytics report, over the six weeks after release. In scope is showing delivery cost earlier. Out of scope are a new payment provider and a complete redesign, which stay on a list for later.

Step 5: specify the change

Dev writes a user story: "As a shopper, I want to see the delivery cost before I enter my card details, so that I am not surprised at the end." He adds acceptance criteria, for example: the cost appears on the basket page once a postcode is entered; it changes if the postcode changes; an invalid postcode shows a clear message; and the total shown equals the total charged.

Step 6: check and learn

After release, Dev compares completed payments before and after. If the figure improves, the benefit is recorded. If it does not, the team has learned that delivery cost was not the whole story, and the next round of analysis begins. Either result is useful, because it replaces a guess with evidence.

Notice what Dev did not do. He did not argue with the owner's idea of a new page, and he did not start designing. He asked questions, found evidence, wrote a precise problem and then described the smallest change that addressed it. That sequence, repeated with care, is business analysis.

Where business analysis happens

Business analysis is used in almost every kind of organisation: banks, insurers, hospitals, retailers, logistics firms, software companies and government departments. The techniques are the same, but each domain brings its own vocabulary and rules, which is why analysts often say they spend their first weeks on a new project learning the language.

• Project work. A time-limited change, such as replacing a system or launching a service. The analyst works with the project manager to define scope and requirements.
• Product work. Continuous improvement of a product. The analyst works with the product owner to keep the backlog clear and ready.
• Process improvement. Looking at how work flows and removing waste, often without new technology.
• Data and reporting. Defining what should be measured and making sure reports and dashboards answer real questions.
• Strategy and planning. Helping leaders compare options and write a business case.

Business analysis also overlaps with neighbouring roles. If you are comparing paths, read how the work differs from project management and from data analysis.

How to start learning business analysis

You do not need permission or a particular degree to start thinking like an analyst. The most effective beginners practise the core habits on small, real problems before they worry about tools.

1. Learn the vocabulary. Our glossary explains each term with a short What, Why and Example entry. Begin with stakeholder, requirement and user story.
2. Practise on something you know. Pick a process from your own job or daily life, such as how your team handles leave requests. Draw how it works, list the pain points and write one requirement and its acceptance criteria.
3. Study worked examples. Our requirements example and SQL practice guide show reasoning step by step on fictional data.
4. Learn the data basics. Reading a table and writing a simple SELECT query changes how you ask questions.
5. Build evidence of your thinking. Keep your practice work, clearly labelled as practice, and read how to build a portfolio without experience.

If you want a path with a guided sequence, our step-by-step guide to becoming a business analyst sets out a realistic route, and the skills overview explains what to build first. The BA Lab turns the whole sequence into a simulated company project, though you can learn the fundamentals without it.

One honest note: reading about business analysis is a start, but the skill grows by doing. Whatever route you choose, make sure you are producing real attempts, getting feedback and improving them.

Frequently asked questions