BA vs SA: where the line is drawn

The learner can distinguish the focus of a business analyst (business need, goals, value) from a systems analyst (system, integrations, data, technical specification) and place adjacent roles around them.

BA and SA: a spectrum

One profession, two ends of a dial

Most analysts sit somewhere between the two ends; the roles around them answer different questions.

A horizontal gradient bar from 'Business' (left) to 'System' (right). Left end 'Business Analyst — why? value, goals; artifacts: process models, business cases, user stories'. Right end 'Systems Analyst — how? integrations, data, APIs; artifacts: specifications, ER models, API descriptions'. A pointer in the middle 'many real jobs'. Around the bar four small cards: 'Product Owner — what first? orders the backlog', 'Project Manager — when and for how much?', 'Developers — build it', 'QA — does it work as required?'. — The line between BA and SA is a dial, not a wall.

Lesson notes

A spectrum, not a hard wall

The titles 'Business Analyst' (BA) and 'Systems Analyst' (SA) are often used interchangeably, but they point to different ends of the same spectrum. A BA sits closer to the business side: their primary focus is on business needs, goals, and the value a solution should deliver. They ask 'What problem are we solving, and why does it matter?' A Systems Analyst sits closer to the system: their focus shifts to integrations between systems, data flows, data structures, and the technical specification that developers will implement. They ask 'How should the system behave to satisfy those needs?' Typical BA artifacts: process models, business cases, user stories. Typical SA artifacts: system specifications, API and integration descriptions, data (ER) models, detailed use cases. In practice, the line blurs constantly. A BA on a small team often does SA work; a senior SA often understands business goals deeply. Think of BA and SA as opposite ends of a dial you can turn, not two separate rooms with a locked door between them.

PM, PO, developers, QA — and the analyst

Around these two roles sit several others that are easy to confuse. The Project Manager (PM) owns schedule, budget, and risk — they ensure the project is delivered on time and within constraints. The Product Owner (PO) — in many companies a Product Manager plays a similar part — owns the product goal and orders the backlog: they decide what gets built in which order to maximize value. The Developer implements the solution. The QA engineer verifies it meets requirements. The analyst (BA or SA) is the specialist in requirements: discovering, specifying, and validating what needs to be built, not managing the project, not owning the product roadmap, and not building or testing the code.