What Does a Business Analyst Do?

A business analyst studies how a business currently works, finds the gap between that and what the business actually needs, and writes down exactly what has to change to close that gap. In plain terms: when a company wants to fix a broken process, launch a new system, or solve a recurring problem, a business analyst is the person who figures out precisely what "fixed" looks like, before anyone starts building anything. That written-down definition is what engineers, vendors, or operations teams then use to actually make the change.

Quick facts

• A business analyst's main output is clear, agreed requirements — a written description of what needs to be true after a change is made.
• Common tools of the trade: gap analysis (comparing current state to desired state), stakeholder analysis (mapping who's affected by a change), and a RACI matrix (who does what).
• Business analysts work across almost every industry, not just software — banking, healthcare, insurance, government, and manufacturing all rely heavily on this role.
• A business analyst is different from a product manager: a business analyst usually documents what a business needs and how current processes work; a product manager usually decides what a product should become and why. See Business Analyst vs Product Manager.
• The most recognized certifications are CBAP and ECBA, both from IIBA (the International Institute of Business Analysis).

The core job, broken into four parts

A day in the life of a business analyst

A typical day might include a requirements workshop — a structured meeting where the business analyst asks a group of stakeholders detailed questions about how a process works and what's wrong with it. It might also include time spent writing up what was discussed into a clear document, reviewing that document with the people who'll actually build the solution (often engineers or a vendor), and following up on questions that came up during a previous review. Business analysts also spend real time simply observing how work actually gets done — sitting with a team and watching their real workflow often reveals gaps that no one mentions out loud in a meeting, because the people doing the work don't realize it's unusual.

The core skills a business analyst needs

• Asking sharp, specific questions. The difference between a good and a mediocre requirements document usually comes down to whether the business analyst asked "what exactly happens when X goes wrong" instead of accepting a vague answer.
• Writing clearly. A requirement that can be read two different ways will be built two different ways — clarity in writing is not optional in this role.
• Mapping processes visually. Diagrams (like a process map or a use case diagram) often communicate a complex workflow faster than paragraphs of text.
• Staying neutral between competing stakeholders. Different departments often want different, sometimes conflicting things from the same change — a good business analyst surfaces that conflict clearly instead of quietly picking a side.

Where business analysts sit in a project

A business analyst usually gets involved before a project officially starts, helping decide whether a proposed change is even worth pursuing through a feasibility study. Once a project is approved, the business analyst becomes the main source of truth for what the solution actually needs to do, working closely with a project manager (who manages the schedule and budget) and, in software projects, a product manager or product owner who prioritizes and builds it.

Common mistakes new business analysts make

• Writing down what a stakeholder asked for, instead of what they actually need. Stakeholders often describe a solution ("we need a new button here") instead of the underlying problem ("customers can't find where to update their address") — a good business analyst digs past the requested solution to the real need.
• Skipping the people who actually do the work day to day. Talking only to managers, and not the people executing a process, often produces requirements based on how a process is supposed to work on paper, not how it actually happens.
• Treating the requirements document as finished after the first draft. Requirements almost always need revision after the first round of stakeholder review — treating a first draft as final leads to building the wrong thing.
• Not documenting edge cases. A requirement that only describes the normal, expected situation, and skips what happens when something goes wrong, leaves engineers guessing — and guessing usually goes badly.

FAQ

Is business analyst a technical job? It can be, depending on the industry — some business analysts work closely with databases and systems and need real technical knowledge, while others work purely on process and requirements without needing to understand any code. What's always required is the ability to translate between technical and non-technical people.

What's the difference between a business analyst and a systems analyst? A business analyst focuses on the business need — what problem needs solving and why. A systems analyst focuses more specifically on how a technical system should be designed to meet that need. In smaller companies, one person often does both.

Do business analysts need a certification? Not always, but IIBA's CBAP (Certified Business Analysis Professional) and ECBA (Entry Certificate in Business Analysis) are the most recognized credentials in the field and can help, especially early in a career or when switching industries. See our best certifications for business analysts guide.

Can a business analyst become a product manager? Yes, and it's a common career move — many of the core skills (talking to stakeholders, writing clear requirements, understanding a business problem deeply) transfer directly. The main gap to close is usually strategic, market-facing thinking, since business analysis tends to focus more on internal processes than on customers and competitive positioning. See How to Transition from BA to Product Manager.