Business Analysis

What Does a Business Analyst Actually Do in a Real Project?

Business Analysts do far more than gather requirements. In a real project they understand business problems, engage stakeholders, analyse processes, define requirements and help delivery teams build the right thing.

The Business Analyst role is often misunderstood. Some people think a Business Analyst simply writes documents. Some think the role is mainly about gathering requirements. Others assume the BA acts as a bridge between business and technology, but do not fully understand what that means in practice.

In a real project, the Business Analyst does much more than collect information. A BA helps the organisation understand the business problem, clarify what needs to change, identify who is affected, define requirements, analyse processes, support decisions and help delivery teams build the right thing. The work is practical, structured and highly dependent on communication, judgement and context.

The simple explanation of the Business Analyst role

A Business Analyst helps turn business need into delivery clarity. That means helping the project answer questions such as: what problem are we trying to solve? Why does this matter? Who is affected? What does the business need? What is in scope and what is out? How does the current process work? What should change? What assumptions are we making? What risks or dependencies exist? How will we know the solution works?

The BA does not usually own every decision — they are not always the project manager, product owner, designer or developer. However, the BA works closely with these roles to ensure the business need is understood clearly enough for delivery to happen properly. A good BA reduces confusion. A weak BA can allow confusion to travel into design, build, testing and implementation.

Why "gathering requirements" is not enough

Many people describe business analysis as "requirements gathering" — a phrase that makes the work sound as though requirements are already sitting somewhere, waiting to be collected. In reality, requirements often need to be discovered, challenged, clarified, refined and agreed.

Stakeholders may not know exactly what they need. Different teams may disagree. Some people may describe solutions rather than needs. Others may focus on symptoms rather than root causes. The BA helps bring clarity to this situation. The work is not only gathering — it is analysis. A BA listens, questions, structures, tests understanding, confirms meaning and turns unclear information into usable delivery material.

Ten core responsibilities in a real project

1. Understand the business problem. A project may begin with a proposed solution, but the BA needs to understand the underlying need. A stakeholder may say "we need a new system" — the BA should ask what problem the current system is creating, who is affected, what evidence supports this need, and whether the problem is caused by technology, process, data, policy or training. A good BA helps the team avoid solving the wrong problem.

2. Identify stakeholders and their needs. Projects involve people. A BA needs to identify who is affected by the change, who has information, who makes decisions, who will use the solution and who may be impacted indirectly. Stakeholder work is not only about keeping a list of names — it is about understanding perspectives. One stakeholder may care about speed, another about control, another about compliance, another about cost. The BA helps bring these perspectives together so the project can make informed decisions.

3. Clarify scope and boundaries. If scope is unclear, teams may build too much, too little or the wrong thing. The BA helps clarify what is in scope, what is out of scope and where the boundaries sit: which users are included, which systems are affected, which requirements must be delivered now, which requirements may be delivered later, and what is explicitly excluded. Clear scope protects delivery and helps stakeholders understand expectations.

4. Analyse current processes. BAs often analyse how work happens today — current-state or "as-is" analysis. This means mapping the current process, identifying pain points, documenting handovers, highlighting delays and capturing where errors or duplication occur. A project should not design the future without understanding the present. Current-state analysis helps the organisation avoid automating poor ways of working and helps delivery teams understand the real operational environment.

5. Define future-state needs. Once the current state is understood, the BA helps define what the future state should look like. This does not always mean designing the technical solution — it means helping the business clarify what needs to be different. The BA helps translate problems into future needs through process redesign, options analysis, workshops, user journey mapping, gap analysis and collaboration with product, technology and design teams. A good future-state view gives delivery teams direction.

6. Document business requirements. A requirement describes what the business needs from a process, product, service or system. Good requirements should be clear, unambiguous, testable and traceable. A weak requirement says "the system should be easy to use." A stronger requirement identifies the user, need, action and purpose — for example: "Customer service advisers must be able to search for an existing customer record using surname, postcode or reference number so that they can locate the correct record during a live enquiry." Requirements should reduce ambiguity.

7. Support user stories and acceptance criteria. In agile or product-led environments, BAs often support user stories and acceptance criteria. A user story expresses a need from the user's perspective. Acceptance criteria define the conditions that must be met for the story to be accepted. The BA helps ensure that stories are clear, valuable and testable — working with product owners, developers, testers, designers and stakeholders to refine the detail. Good acceptance criteria help prevent misunderstanding during build and testing.

8. Manage assumptions, risks, issues and dependencies. Business analysis is not only about requirements. A BA also helps identify assumptions (something believed to be true but not confirmed), risks (something that may happen and could affect the project), issues (something that has already happened and needs action) and dependencies (something the project relies on). Capturing these items helps the project manage uncertainty. A BA may not own every risk or issue, but they often surface them through discovery and analysis.

9. Support solution design and delivery conversations. The BA plays a key role in solution conversations even without designing the full technical solution. They help ensure that designers, developers, architects and delivery teams understand the business need — answering questions, clarifying requirements, explaining process context, supporting trade-off decisions and helping assess whether proposed solutions meet the original need. This is why traceability matters: the BA should be able to connect design decisions back to business need, stakeholder input and agreed requirements.

10. Help testing, UAT and change readiness. BAs often support testing and user acceptance by helping testers understand requirements, reviewing test scenarios, supporting defect triage, clarifying expected behaviour and helping business users prepare for UAT. BAs may also support change readiness through training materials, process guidance, user communications, implementation checklists and post-launch support planning. The BA's role is not finished when requirements are written — they often remain involved to help ensure that what is delivered still matches the business need.

Common Business Analyst deliverables

Common deliverables may include: project context summary, stakeholder register, stakeholder analysis, workshop notes, current-state process map, future-state process map, gap analysis, business requirements document, functional and non-functional requirements, user stories, acceptance criteria, assumptions/constraints/dependencies log, options analysis, impact assessment, data flow summary, UAT scenarios and requirements traceability matrix.

Not every BA produces all of these on every project. The best deliverable is the one that helps the project make better decisions and deliver the right outcome. A BA should not produce documents for the sake of documents — they should produce clarity.

What makes a good BA in a real project?

A good Business Analyst is not only someone who knows BA terminology. A good BA can listen carefully, ask useful questions, structure messy information and help people reach shared understanding. They are curious, practical and clear. They can work with detail without losing sight of the bigger picture. They understand that stakeholders may disagree, that requirements need to be tested not just recorded, and that clear writing matters. They can adapt their communication for business, technical and delivery audiences. In real projects, the BA adds value by reducing uncertainty.

Aspiring BAs need practice, not theory alone

Business analysis cannot be mastered through theory alone. Courses are useful — they explain concepts and methods — but aspiring BAs need opportunities to practise the work. They need to practise reading a brief, identifying stakeholders, asking questions, analysing processes, writing requirements, producing deliverables and responding to feedback. They need to experience ambiguity. They need to learn how to make decisions when information is incomplete. They need to understand what a good deliverable looks like.

A Business Analyst helps turn business need into delivery clarity. They help the business and delivery teams understand each other and make sure the solution being delivered is connected to the problem that needs solving. For aspiring BAs, the best preparation is not theory alone — it is practice, feedback and evidence of real-style work.

Practise the role. Prove the work. Build the evidence.

AI Workplace Simulator

Stop describing what you know.
Start showing what you can do.

30 days. 26 verified deliverables across the Junior and Intermediate BA tiers. A portfolio employers can inspect.

More from the blog