Business analysts
A business analyst works out what a piece of software actually has to do, and states it precisely enough to be built and verified. The discipline sits between people who understand the business and people who understand the system, and its value is measured in defects that never happened — rework avoided, misunderstandings caught while they were still cheap. This guide explains the role, the situations that create real need for it, and how to tell analysis from documentation.
What does a business analyst do on a software project?
A business analyst investigates a business problem and defines what a system must do to solve it. On a software project that means eliciting needs from stakeholders and users, mapping the existing process and where it fails, identifying the gap between current and intended behaviour, and expressing the outcome as requirements, business rules, data definitions and acceptance criteria that engineers can build against and testers can verify. The accountability is for the team building the right thing — as distinct from the team building it on schedule.
The most consequential part of the work is the distance between what a stakeholder asks for and what they need. Stakeholders describe solutions, because a solution is easier to articulate than a problem: a request for an export button is usually a request to reconcile two systems, and building the button leaves the reconciliation unsolved. A business analyst who takes requests at face value produces a specification that is accurate and beside the point.
Precision is the second half of the job. Requirements fail more often through ambiguity than through omission — words such as "quickly", "relevant", "appropriate" and "user" carry different meanings for each person reading them, and each reading is discovered separately during development, testing and after release. Making that ambiguity visible before it becomes code is the discipline’s primary economic contribution.
Much of the substance lies in rules, data and edge cases rather than in screens. What makes an account eligible, which fields are mandatory under which conditions, how a refund interacts with a partial shipment, what happens on the boundary of a date range, which system is authoritative when two disagree. Organisations usually hold this knowledge across several people, none of whom holds all of it, and often nobody has ever written down what happens when the ordinary path is not followed.
The role also carries the failure mode most associated with it. A business analyst can produce a great deal of documentation that nobody reads, satisfying a process while providing no clarity. The output that matters is a shared, current, testable understanding of what is being built — and if a document is not being used to make decisions, its length is a cost rather than evidence of work.
When teams need this capability
Analysis happens on every project, whether or not anyone is assigned to it. The question is whether it is done deliberately or discovered during development. These are the conditions under which doing it deliberately usually pays.
The domain carries rules nobody has written down
Lending, insurance, logistics, payroll, healthcare, tax, regulated pricing — areas where the correct behaviour depends on conditions that exist only in the heads of experienced staff and in the behaviour of an old system. Engineers cannot infer these, and asking them to is how rules get implemented approximately.
Tickets keep coming back
Work is built to specification, accepted, and then reopened because it does not do what somebody expected. This is nearly always a requirements defect rather than an engineering one, and it repeats because the cause is upstream of where it is being investigated.
The software is replacing an existing process
A migration, a system replacement or an automation of manual work requires someone to establish what the current process genuinely does — including the informal steps and the exceptions people handle without noticing — before deciding what the new system should do. Reproducing a process nobody has examined is how workarounds become permanent features.
Stakeholders disagree and nobody has surfaced it
Several departments each have a coherent view of how something should work, and the views are incompatible. The disagreement is usually discovered during acceptance testing, when the cost of resolving it is highest. Making it explicit early is analysis work, not diplomacy.
Engineers are spending their time in clarification
Developers repeatedly stopping work to establish what a requirement means, chasing the person who knows, and waiting. The team looks busy and delivers slowly, and the cause is that the definition work has been distributed across everyone in the least efficient possible way.
An integration must reconcile two models of the same thing
Two systems both hold customers, or orders, or accounts, and they mean subtly different things by them. Mapping the fields is straightforward; establishing which system is authoritative, how identities are matched and what happens when they conflict is analysis, and skipping it produces data problems that surface long after release.
Core capabilities
Elicitation
Drawing out what people need rather than recording what they say. That means interviewing without leading, running workshops where the quiet expert speaks, observing work as it is actually performed, and noticing the steps someone omits because they are too familiar to mention.
Problem framing
Separating the request from the underlying need, and stating the problem in terms of the outcome rather than the mechanism. A requirement written as a solution forecloses better solutions the engineering team might have proposed, and it is the most common defect in a specification.
Process analysis
Documenting how work flows today, where it stalls, where it is reworked, and where people have built informal workarounds. The exceptions matter more than the main path, because the exceptions are what the new system will handle badly if nobody names them.
Requirements definition
Expressing needs so that two people reading them reach the same conclusion. Testable, unambiguous, free of implied solutions, and traceable back to the business outcome that justifies them — with the ones that are genuinely optional identified as such.
Acceptance criteria
Defining in advance what would demonstrate that the requirement has been met, including the boundary conditions and the paths that are not the happy one. Criteria written after implementation describe what was built rather than what was needed, which is a different and much less useful artefact.
Business rules and data definition
Capturing the conditional logic, eligibility rules, calculations and validity constraints that govern behaviour, together with the meaning, source, ownership and lifecycle of the data they operate on. Decision tables usually expose gaps that prose conceals.
Gap analysis
Comparing the current state against the intended state and identifying precisely what must change — in the system, and often in the process and the responsibilities around it. Software rarely delivers a business outcome on its own, and an analysis that stops at the system boundary tends to miss why the outcome did not arrive.
Traceability
Maintaining the link from business objective to requirement to implementation to test, so that the effect of a change can be assessed and so that work with no justification behind it becomes visible. This is what makes scope reduction a considered decision rather than a guess.
Translation between audiences
Explaining a business constraint to engineers in terms that support a design decision, and explaining a technical constraint to stakeholders in terms of what it means for them. Both directions are required; analysts who are fluent in only one produce specifications that one side quietly ignores.
How the discipline works
Business analysis is defined by method rather than by a technology stack, so what follows sets out the techniques, notations and deliverables that characterise the discipline in ordinary industry practice — a description of the profession, not a claim about any individual’s toolkit. The tools themselves are largely interchangeable: a modelling notation transfers between diagramming products, and a requirements practice survives a change of tracking system, so a candidate is far better judged on how they elicit and specify than on which software they last used.
Elicitation techniques
- Structured stakeholder interviews
- Facilitated requirements workshops
- Observation and job shadowing
- Document and system analysis
- Surveys and questionnaires
- Prototypes used to provoke feedback
Process and system modelling
- BPMN process models
- Swimlane and value-stream maps
- Context and scope diagrams
- Use-case and activity diagrams
- State transition diagrams
Specification artefacts
- User stories
- Acceptance criteria in given/when/then form
- Use case descriptions
- Business rules catalogues
- Non-functional requirements
- A maintained domain glossary
Data and rules analysis
- Conceptual and logical data models
- Entity relationship diagrams
- Data dictionaries
- Decision tables and decision trees
- Create, read, update and delete matrices
- Data profiling and quality assessment
Analysis and prioritisation methods
- Gap analysis
- Root cause analysis
- Impact and story mapping
- Stakeholder mapping
- MoSCoW and other prioritisation frames
- Requirements traceability matrices
Common tool categories
- Diagramming and modelling software
- Backlog and requirements repositories
- Collaborative wikis and knowledge bases
- Wireframing and prototyping tools
- Query and reporting tools for data investigation
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- A company is replacing a long-standing internal system. The behaviour that matters is encoded in the software itself and in the habits of the people who operate it, the documentation reflects an earlier version, and the original authors have moved on. Development has started and is repeatedly interrupted by questions nobody can answer confidently.
- Approach
- Additional analysis capacity works inside the client’s existing ways of working — their backlog, their definition of ready, their stakeholder relationships and their release cadence. Ownership of the product, of what is worth doing first, and of what the replacement is ultimately for stays with the client; the added capacity establishes the current rules and data meanings, records the exceptions, and turns them into requirements and acceptance criteria the team can build and verify against.
- What this adds to the team
- The client gains analysis capacity while keeping every decision about business intent. What the system should do, and which trade-offs are acceptable, remain with the people accountable for the business outcome.
Related disciplines
Frequently asked questions
- What is the difference between a business analyst and a project manager?
- They answer different questions. A business analyst is concerned with what should be built and why: the underlying problem, the requirements, the rules, the data and the criteria for acceptance. A project manager is concerned with getting an agreed body of work delivered: sequence, dependencies, risk, timeline and reporting. Both roles talk to the same stakeholders and are easily conflated, but their accountability differs — one is answerable for correctness of definition, the other for arrival. Where one person covers both, the analysis half is usually what gets compressed, because delivery pressure is louder.
- What is the difference between a business analyst and a product owner or product manager?
- The intended distinction is authority. A product owner or product manager decides what is worth doing and in what order, and is answerable for the value of the outcome. A business analyst establishes and specifies what the chosen thing must do, and is answerable for that definition being correct and complete. In practice the boundary is not agreed across the industry: some organisations expect the product owner to do their own analysis, some employ analysts who effectively set priority, and the titles are applied inconsistently between companies. Before hiring for either, it is worth being explicit about who holds prioritisation authority in your structure, because that is the point at which the roles genuinely differ.
- Do agile teams still need business analysts?
- The assumption that they do not comes from a fair observation — agile practice replaced large upfront specification with conversation, and a great deal of documentation stopped being useful. What did not disappear is the work of understanding a complex domain, resolving contradictory stakeholder views and stating behaviour precisely enough to be tested. In a simple domain a product owner and an engaged team can absorb that. In a domain with regulatory constraints, intricate rules or a system whose behaviour nobody fully knows, it is a substantial job, and leaving it unassigned tends to mean it is done partially by several people in the middle of a sprint.
- Is a business analyst the same as a data analyst?
- No, although the titles are used loosely and some roles genuinely span both. A data analyst interprets data to answer questions about what has happened, and works largely in querying, statistics and reporting. A business analyst defines what a system should do, and uses data as evidence about how a process really behaves rather than as the product of the work. Many capable business analysts write queries, and that is a considerable asset — but a candidate whose experience is entirely in reporting has not necessarily done requirements work.
- How much documentation should a business analyst produce?
- Enough that the people building and testing the work reach the same understanding, and no more. The right level varies with the cost of being wrong: a regulated calculation, an irreversible data migration or an interface another organisation depends on deserves precision that an internal screen adjustment does not. Documents that exist to satisfy a process, rather than to inform a decision, are the discipline’s most familiar waste — and their volume is often mistaken for evidence that the analysis was thorough.
- Does a business analyst need technical skills?
- They do not need to write production code, but technical literacy substantially raises the quality of their output. Reading a database schema, writing a query to check an assumption, understanding what an API can and cannot express, and following an architectural conversation all let an analyst verify things rather than relay them. Domain knowledge matters at least as much: an analyst who understands the business area can identify a wrong answer, which is a capability that generic analytical technique does not provide.
- How does a business analyst work with an existing engineering team?
- In a staff augmentation arrangement, an analyst works inside the client’s existing process — their backlog, their refinement sessions, their documentation standards and their stakeholder relationships — with the client directing the work. Product ownership, business priorities and the roadmap remain the client’s throughout; added analysis capacity supports those decisions and never replaces them. Talent.ID’s part is confined to employment: it holds the employment relationship, runs payroll and employee benefits, handles talent administration and maintains a continuing relationship with the person employed.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.