Back to candidates
Career GuideFor Candidates

How to Become a Business Analyst

How to become a Business Analyst: what the job involves day to day, the skills to build, how to break in, and the levels from junior to senior.

Overview

Business analysis is the discipline of working out what an organisation actually needs before anyone commits money to building it. The role spans requirements, process design, data investigation and stakeholder negotiation, and its shape varies enormously between a bank, a consultancy and a software product company. It is one of the more accessible routes into technology from a non-technical background, and one of the easiest to plateau in. This guide covers the real work, the progression, and how to avoid becoming a scribe.

What a Business Analyst actually does

The persistent misreading of this role is that it is documentation — someone writes down what stakeholders say they want and passes it on. Good business analysis is closer to investigation: stakeholders describe solutions rather than problems, describe the process they believe exists rather than the one that runs, and disagree with each other without realising it. Much of the job is sitting with the people who do the work, watching what they actually do, and finding the exceptions nobody mentioned because they seem normal to them. There is genuine drudgery — reconciling conflicting definitions of the same field across three systems, chasing sign-off, maintaining a traceability matrix nobody reads until an audit. The analysts who matter are the ones who reduce the scope of a project by discovering that most of it was unnecessary.

A typical week

  • •Running a workshop or elicitation session where the real task is getting two departments to admit they define the same term differently
  • •Mapping an as-is process and finding the undocumented workaround that the whole thing actually depends on
  • •Writing user stories with acceptance criteria specific enough that a developer does not have to guess
  • •Querying the data directly to check whether a stated business rule is what the system actually does
  • •Walking a solution through with developers and testers, then reworking the parts that were ambiguous once questioned
  • •Chasing a decision or a sign-off that is blocking work, and managing the expectations of the people waiting on it

Cohesyve for candidates

Thinking about a Business Analyst role? Find out where your skills stand today.

Run a role-specific simulation, get a scored report on your actual gaps, and follow a learning pathway built from them. Free to start, no card required.

The career path

Junior Business Analyst

0-2 years

You support a senior analyst: taking notes in workshops, documenting as-is processes, writing straightforward stories and doing the legwork on data checks. The main growth is learning the domain and the systems well enough to ask a useful question.

Business Analyst

2-5 years

You run your own elicitation, own the requirements for a workstream, and are trusted in front of business stakeholders alone. You start challenging requests rather than only recording them.

Senior Business Analyst

5-8 years

You take on ambiguous, cross-functional problems where the scope is not yet defined and stakeholders conflict. You are expected to shape the solution approach, not just specify it, and to mentor junior analysts.

Lead or Principal Business Analyst

8-12 years

You work at programme level across multiple teams, set analysis standards, and are involved before funding decisions are made. Influence shifts from documenting a solution to shaping which problems get invested in.

Head of Business Analysis or Product / Consulting leadership

12+ years

Either you run the analysis practice — capability, standards, hiring — or you convert the domain expertise into product ownership, transformation leadership or consulting. Most senior BAs eventually branch rather than continue upward in title.

The skills that matter

Requirements elicitation

Stakeholders volunteer solutions, not problems. The ability to interview past the stated request to the underlying need is the single skill that separates an analyst from a note-taker.

Process modelling

A clear as-is and to-be model, in a notation the business can actually read, exposes handoffs, duplicated effort and unowned exceptions faster than any amount of discussion.

SQL and data investigation

Being able to check a claim against the data yourself, rather than raising a request and waiting a week, changes both your speed and your credibility. It is the highest-return technical skill for a BA.

Writing precise acceptance criteria

Ambiguity in a requirement gets resolved by whoever is closest to the keyboard, usually incorrectly and usually late. Testable criteria are where rework is prevented.

Stakeholder management

Requirements conflict because interests conflict. Surfacing a disagreement early and driving it to a decision is more valuable than producing a document that papers over it.

Domain knowledge

In payments, insurance, clinical or logistics work, the regulatory and operational detail is the job. Deep domain knowledge is what makes a BA hard to replace and is the main driver of seniority.

How to break in

  • #1

    Move from an operational role in the business you already know — claims, underwriting, finance operations, customer service. Domain knowledge is the expensive half and you already have it.

  • #2

    Learn SQL properly and use it in your current job. Being the person in the team who can answer a data question is the most common way people get pulled onto a project.

  • #3

    Volunteer for the analysis work on a change project at your current employer, even unofficially, so you have a real process map and a real set of requirements to talk about.

  • #4

    Take a recognised certification — the BCS or IIBA routes — if you are entering from outside; it will not impress a hiring manager on its own but it gets a non-obvious CV past a screen.

  • #5

    Learn a modelling notation and a documentation toolchain properly so a work sample looks professional rather than improvised.

  • #6

    Apply to consultancies and graduate schemes if you are early career; they hire on aptitude, train the method, and give you exposure to several domains quickly.

What drives pay

Compensation varies too much by country, sector and company size for a single figure to be useful. These are the factors that actually move it.

  • Depth of domain expertise, particularly in regulated areas where a wrong requirement carries legal or financial consequence

  • Technical range — analysts who can query data, read an API contract and reason about integrations sit in a different bracket from those who only document

  • Whether you operate at project level or are trusted at programme and pre-investment level, where the decisions are larger

  • Sector and contracting model, with consultancy, contract and regulated-industry work priced differently from in-house permanent roles

  • Proximity to the commercial outcome — analysts on revenue-affecting change are valued above those maintaining internal process documentation

Where demand is heading

Demand is steady rather than fashionable, and it holds up because large organisations do not stop changing their systems. The nature of the role has narrowed at one end and deepened at the other: purely documentation-focused analysis is being absorbed into product and delivery roles and is increasingly automated at the drafting stage, while analysts who combine domain depth with data capability are consistently hard to hire. Regulated sectors, ERP and core-system migrations, and data platform programmes remain reliable sources of work. The honest read is that the title is not at risk but the narrow version of the job is, and the defence is technical range plus domain depth.

Roles this transfers to

Product Owner

Nearly the same skill set applied inside a delivery team, with backlog authority added. The most common next step for a BA in an agile organisation.

Data Analyst

Shared SQL, data modelling and stakeholder-question skills. The gap is statistical reasoning and visualisation rather than domain understanding.

Systems Analyst

Same investigative method pointed at systems and integrations rather than business processes. A natural move for BAs who gravitate to the technical detail.

Management Consultant

Process analysis, stakeholder interviewing and structured problem-solving are directly reusable. The gap is commercial framing and client-facing pace.

Common mistakes

  • Recording what stakeholders ask for instead of investigating why they asked for it

  • Writing requirements that cannot be tested, so ambiguity is discovered during UAT rather than during analysis

  • Producing volume — enormous documents that nobody reads — as evidence of thoroughness

  • Avoiding the data and relying on what stakeholders believe the system does

  • Staying in one system or one project type for so long that the expertise stops transferring to another employer

  • Treating conflicting stakeholder requirements as something to smooth over in wording rather than escalate for a decision

Frequently Asked Questions

Do I need to know how to code?

You do not need to write applications, but SQL is close to mandatory in most serious BA roles, and being comfortable reading an API specification or a data model materially widens the jobs you can take. It is the difference between describing a system and understanding one.

Is a BCS or IIBA certification worth doing?

It helps most when you are moving in from outside the field and need a CV to survive a screen, and it gives you shared vocabulary. It carries little weight against demonstrated project experience, so treat it as an entry aid rather than a career step.

What is the difference between a business analyst and a product owner?

A BA is typically accountable for understanding and specifying the need; a product owner is accountable for the backlog and for deciding what gets built next. In many organisations one person does both, which is why the titles blur, but the authority differs.

Is the role at risk from automation?

The drafting and documentation portion is genuinely being compressed. The investigative portion — noticing that two departments define a term differently, or that the documented process is not the one being run — is not, because it depends on access to people and context. Weight your development accordingly.

How do I tell whether my analysis skills are at the level a role expects?

Interviews for this role often test elicitation and precision through a scenario, and it is difficult to judge your own answers. Running a scored business-analysis simulation against a live job description shows you where you lose marks; Cohesyve includes three free assessments with a full report and a learning pathway.

Explore another career

Cohesyve · Practice for candidates

Practise a Business Analyst assessment before the real one

Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.

3

free assessments

$0

no card required

Full

scored report every run

Every

question type included

3 free assessments · No card required · Pro from $16/mo

For hiring teams

Hiring for a Business Analyst role? See how your applicants perform before you spend interview time.

Practise before it counts

3 free assessments

Start practising free