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 to look for when hiring
Business analyst candidates are usually articulate, which makes the interview easy to conduct and hard to read. The reliable technique is to give them a real problem from your own domain and watch them work on it, because analysis capability shows in the questions someone asks and almost never in the way they describe their method.
Questioning quality
Describe a genuine need from your business in a couple of sentences and let them interrogate it. This single exercise is more informative than the rest of the interview combined. Look for questions that probe the outcome and the exceptions rather than questions that gather features.
- Asks why before asking what
- Goes after the exception cases early
- Notices what you did not say and asks about it
- Summarises back in different words to test their understanding
Distinguishing a want from a need
Ask about a time a stakeholder requested something specific and the analyst concluded the underlying need was different. You are looking for evidence they investigate the request rather than transcribe it — and for how they handled a stakeholder who was attached to their own solution.
- Can give a concrete example with the reasoning that led there
- Redirected without dismissing the stakeholder’s expertise
- Understands that people describe solutions because problems are harder to articulate
Written precision
Ask to see a requirement or a set of acceptance criteria they wrote, redacted as necessary, or set a short written exercise. Analysis is delivered in writing, and fluency in conversation does not predict it. Vague, unfalsifiable phrasing is the defect to look for.
- Writes criteria that could be shown to fail
- Avoids terms that different readers would interpret differently
- States assumptions explicitly rather than leaving them implied
- Keeps the solution out of a statement of the requirement
Proportion in documentation
Ask how they decide how much to write. The role has a well-known failure mode of producing thorough documents that nobody consults, and the strongest candidates are alert to it. The right amount varies with risk, regulation, team continuity and how reversible the decision is.
- Adjusts depth to the cost of getting it wrong
- Can describe something they deliberately did not document
- Treats a document as a means to shared understanding, not the deliverable
Handling conflicting stakeholders
Ask how they proceeded when two parts of a business wanted incompatible things. The useful answer involves making the conflict explicit and taking it to whoever can decide, rather than quietly favouring the more senior voice or specifying an unworkable compromise.
- Surfaces disagreement early rather than absorbing it
- Identifies who actually holds the decision
- Can describe a decision that went against their own recommendation
Comfort with data and rules
Much of the hardest analysis is conditional logic and data meaning. Ask how they would establish the real rules governing a process where the documentation is out of date and the original author has left. Willingness to examine the data directly is a strong positive signal.
- Would query or inspect the data rather than rely on description
- Reaches for a decision table when conditions multiply
- Asks which system is authoritative when two hold the same entity
Working inside an engineering team
Analysts who operate at a distance from developers tend to produce specifications that are complete and unhelpful. Ask how they work with engineers during a sprint and what they do when an engineer proposes something the requirement did not anticipate.
- Available for clarification while work is in progress
- Treats an engineer’s question as a signal the requirement was unclear
- Willing to have a requirement changed by a technical insight
Interview questions worth asking
Written to support the buyer’s own interview process. Evaluation of a candidate rests with the hiring organisation, which weighs them against its own domain and expectations and reaches its own decision.
Here is a problem from our business, described in two sentences. What do you need to ask me?
What a strong answer shows
The most reliable signal available. Strong candidates pursue the outcome, the people affected, the current process and the exceptions. Weaker ones collect a feature list and begin proposing a design before the problem has been established.
Tell me about a requirement you got wrong. How did it surface, and what changed in your practice afterwards?
What a strong answer shows
Whether they have carried the consequences of their own specification. Look for a specific defect, an honest account of the ambiguity that caused it, and a change in method rather than a resolution to be more careful.
A stakeholder asks for a report with a particular set of columns. How do you respond?
What a strong answer shows
Whether they investigate requests. The strongest answers ask what decision the report supports and what the person does after reading it, since the underlying need is frequently met better by something other than the report as described.
How do you write acceptance criteria for something whose correct behaviour depends on several conditions interacting?
What a strong answer shows
Rigour with conditional logic. Look for decision tables or an equivalent structure, deliberate coverage of combinations, and explicit treatment of the boundaries — rather than prose that describes the intended case and leaves the rest to interpretation.
You are documenting an existing process and two experienced people describe it differently. What do you do?
What a strong answer shows
Investigative instinct. Good answers treat the discrepancy as information — often both are right for different cases — and go to the evidence: observe the work, inspect the data, examine what the system actually does.
How much documentation is the right amount, and how do you decide?
What a strong answer shows
Awareness of the discipline’s central failure mode. Strong answers vary the depth with risk, regulatory exposure, team turnover and reversibility, and can name something they chose not to write down.
An engineer tells you the requirement cannot be implemented as written. How do you handle it?
What a strong answer shows
Whether they collaborate or defend. The best answers treat it as a chance to revisit the underlying need, since a requirement that is technically awkward is often a requirement stated as a solution.
What is a piece of analysis you produced that had no effect, and why do you think that was?
What a strong answer shows
Honesty and a sense of proportion. Every experienced analyst has written something nobody used. Candidates who can explain why — wrong audience, wrong moment, wrong format, a decision already taken — have learned the part of the job that is not technique.
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.