What Does a Business Analyst Actually Do?

There's a question I get asked a lot, usually at family gatherings or when I tell someone new what I do for a living: "So… who exactly is a Business Analyst? What do they do?"

Being a former Software Engineer turned Business Analyst, that is probably the question I get asked most, especially by people who are not in the tech industry.

I've tried many answers. It was sometimes too vague, sometimes too buzzwordy. So let me try to explain it properly so anyone who is not in the tech can understand. I hope this will be helpful for anyone who is aspiring to be a business analyst.

TL;DR

A Business Analyst (BA) exists to make sure the right thing gets built, for the right reason, in the right way. We sit between stakeholders and technical teams, not just passing messages back and forth, but actively translating business needs into clear requirements that the technical teams can build from.

1. Understanding the Problem

Before a single line of code is written, someone has to figure out what actually needs to be built and more importantly, why.

This is where the BA starts. It means sitting down with stakeholders (clients, product owners and other stakeholders) and asking a lot of questions. Not just "what do you want?" but "what problem are you trying to solve?", "what does success look like?", and "what happens today when this goes wrong?"

It sounds simple. It isn't. People often describe symptoms, not root causes. Part of the job is digging past the noise to find the real need.

2. Analyzing the Requirements

After gathering the requirements, you sit down and go through them. Analyzing, mapping, and deciding exactly how each requirement needs to be met. You benchmark against similar products in the market, research what works, and get into the room with the product team to brainstorm the best possible approach.

This is the stage (in my honest opinion 😅) that separates a good BA from a great one. During this stage, the demand for your sharpest thinking is in all-time high.

3. Documenting Requirements

Once you understand and analyse the problem, you need to write it down in a way that developers, designers, and testers can all work from.

This takes several forms, some of them are:

• User Stories — short descriptions of a feature from the user's point-of-view.
  • If you need to read more about User Stories, I suggest this article; What is User Story? via Visual Paradigm.
  • Example User Story - "As a customer, I want to reset my password so that I can regain access to my account."
• Acceptance Criteria — the specific conditions a feature must meet to be considered done (AKA Definition-of-Done)
  • This is where you include all the specific requirements that are needed from the specific user story.
  • The requirements include, the data, data types, validations, success/failure messages and more.
• Process Flows — diagrams that show how a workflow moves from start to finish
  • Using these diagrams, the team can understand what is happening within the feature/user story from start to end typically in a flow chart. (This can be in different diagram types as well, ex: Sequence Diagram, Communication Diagram etc.)
  • Example:
• BRD / SRS — formal documents which one captures what needs to be built, the other captures how.
  • BRD - The document that includes all requirements of the product in highlevel outlining a project's goals, scope, and stakeholder needs.
  • SRS - The document that includes how the system should behave to meet the business needs defined in the BRD. It can be technical since it covers functional, non-functional requirements, user interactions, system constraints, and more.

The goal isn't to produce the paperwork, the goal is shared understanding. If everyone reads the same document and imagines the same thing, you've done a solid job!

Note: This can be the stage where you can truly incorporate AI to increase your productivity. However, you must make sure to review everything afterwards, do not blindly rely on AI.

4. Working With the Team

A BA doesn't disappear after handing over a requirements doc. You will be constantly involved in the SDLC.

During development, questions come up constantly. The BA clarifies the misunderstandings, reviews test cases to make sure they cover the right scenarios, and acts as the link between the client's expectations and what the team is building.

5. Validating the Output

Once something is built, someone has to check whether it actually solves the original problem. That's often the BA.

This could be a formal User Acceptance Testing (UAT) session with the client or with a bunch of end users, or a more informal walkthrough to catch anything that doesn't match the agreed requirements. If something needs to change, the cycle begins again.

Keep in mind that in Agile, you must be open for changes and the SDLC will be iterative process.

When can it be hard to be a Business Analyst?

The technical parts such as writing user stories, drawing process flows, using Jira or any other project management tool are learnable and can be automated to a certain extent. What's actually hard is the human side.

Things like the following can be real hard but it's genuinely interesting and rewarding when you taste success;

• Getting a stakeholder to admit they don't fully understand their own process.
• Negotiating features of the product with the stakeholders when there are clear blockers.
• Saying "I don't think this feature solves the actual problem" without derailing a meeting.
• Keeping a developer, a designer, a tester and a client aligned on the same goal when they're all doing slightly different work.

Why I like being a business analyst

I ended up in this role from a software engineering background, my bachelors degree is specialised in Software Engineering and my very first experience in tech was as a Software Engineer. So I came in with experience working with people playing a number of different roles and the work that Business Analysts, Product Owners doing made me truly interested.

As a software engineer, I have experienced situations where the requirements are not that clear and it was truly annoying at times. Those experiences shape how I write requirements today. I try to be specific, honest about unknowns, and realistic about what can be built in the time available.

The role sits at an interesting intersection. You have to understand people well enough to earn their trust, understand the domain well enough to ask the right questions, and understand technology well enough to know what's feasible. I was also fortunate enough to have a person guiding me throughout at the start of my Business Analyst career and I am truly grateful for them for everything. But none of those alone makes a good BA. All of them Together, take you close to the next step.

If you're curious about getting into Business Analysis, or if you're already in tech and wondering whether it might be a fit for feel free to reach out. I will be happy to share my experience and offer help anyway I can.