Business analysis is finding out what an organisation genuinely needs and writing it down precisely enough to build and to test. The artefacts change every few years; elicitation and precision do not. Demand is steady in regulated enterprises and thin in product startups.
Steady demand23 min readBusiness Analyst, Senior Business Analyst, Business Systems Analyst, Functional Consultant, Product Owner (enterprise, BA-heavy variant)Updated 2026-07-27
Assumes you know: Comfortable writing clearly under your own name, Willing to sit in long conversations with people who disagree, Enough technical literacy to read a data model and an API contract
Overview
What this area actually covers
Business analysis is the work of establishing what an organisation needs, and
expressing it precisely enough that somebody can build it and somebody else can
prove it was built. That is four distinct activities. You elicit, from people who
frequently cannot state their own need. You reconcile, because two departments
will want incompatible things and both will be reasonable. You model, because a
requirement makes no sense outside the process it sits in. And you write, in
language that two readers cannot interpret differently.
Four things get wrongly bundled in. Project management is the plan, the budget
and the risk log, which is a different accountability. Product management is
which market, which bets and which trade-offs are worth the money. Data analysis
is SQL and charts, which a BA often does but is not the discipline. Testing is a
profession in its own right, even though the BA usually writes the
user-acceptance scenarios. A job advert titled "Business Analyst" may contain any
combination of these, which is a feature of the market rather than a
misunderstanding, and it is the first thing to establish in an interview.
There is a fifth thing that is genuinely part of the job and is often left out of
descriptions of it: deciding what not to change. A large share of the value a
good analyst adds is discovering that the request in front of them is a symptom,
that the underlying problem is a data-quality issue two systems upstream, and
that the cheapest fix is a report and a rule rather than the workflow engine
somebody had already budgeted for. That finding is unglamorous and it is worth
more than most features.
Now practise it
21 interview questions in Business Analysis, each with the rubric the interviewer is scoring against.
This section is organised around the sequence in which the work actually happens
on a change, with two additions for the parts that sit outside that sequence: the
agile operating context, which changes how the artefacts are shaped rather than
what they contain, and a set of scenarios, because most of what separates a
mid-level analyst from a senior one is judgement under awkward conditions rather
than technique.
Subsection
What it is for
Requirements Elicitation
Getting the truth out of people who cannot state it
Documentation & Artefacts
Turning that into something buildable and testable
Process & Data Modelling
Showing the shape a sentence cannot carry
The BA in Agile
Doing the same work in slices, against a live backlog
Stakeholder Management
Getting decisions made and keeping them made
Analysis & UAT
Checking the claim against data, and proving acceptance
BA Scenarios
The judgement calls, rehearsed before you meet them
Requirements Elicitation
Elicitation is the act of drawing out a need, and the word is chosen carefully:
you are not collecting requirements as though they were lying on a shelf. What
a subject-matter expert can offer you is a description of their current
behaviour, filtered through what they assume you already know and what they think
you want to hear. This subsection covers the technique for getting past that —
structured interviews, workshops with the right people in the room, observation
of the work as it happens, document analysis, prototyping as a question rather
than a design, and the specific habits that surface exceptions. Open it for the
questioning patterns, for how to run a session where two attendees disagree in
front of you, and for how to tell a want from a need without accusing anybody of
having stated the wrong one.
Documentation & Artefacts
Once you know the answer you have to write it down in a form that survives being
read by a developer, a tester, an auditor and a stakeholder who was not in the
room. This is where the named artefacts live: the business requirements document
stating why the change exists and what outcome is being bought, the functional
specification stating what the system must do, the software requirements
specification where a formal one is contractually required, use cases with their
main and alternate flows, and user stories with acceptance criteria for teams
working iteratively. Traceability runs through all of it — the ability to point
at an obligation or an objective and follow it to the rule, the story, the test
and the evidence. Open it for the structure of each artefact, for when a heavier
one is warranted, and for how to write acceptance criteria that a tester can
execute without asking you a question.
Process & Data Modelling
Some requirements cannot be carried by a sentence at all. A process with three
actors, two decision points and a compensating path is unreadable as prose and
obvious as a diagram, and a rule about which system owns a customer record is
unarguable once you have drawn the entities and the direction of the
relationships. This subsection covers BPMN and simpler flow notation, the
discipline of modelling as-is before to-be, gap analysis as the deliberate
difference between the two, and the entity-relationship and field-level mapping
work a systems analyst does when data has to move between two systems that
disagree about what a customer is. Open it for notation you will be expected to
read, for how to keep an as-is model honest when the people describing it are
embarrassed by it, and for how a data mapping exposes requirements nobody
mentioned.
The BA in Agile
Iterative delivery did not remove the need for analysis; it redistributed it,
front-loading less and spreading it across every sprint. This subsection is about
what that changes in practice: refining a backlog so items are ready without
specifying them a year early, splitting a story so each slice is independently
valuable rather than a horizontal layer, negotiating a definition of ready that
is a filter rather than a gate, and working alongside a product owner whose
authority overlaps yours in a way nobody has written down. Open it for story
splitting patterns, for the difference between an acceptance criterion and a
test, and for how to handle the recurring tension between just-in-time analysis
and dependencies that need six weeks of lead time.
Stakeholder Management
You are accountable for a requirement being right while every decision it rests
on belongs to somebody else, often to two people who disagree. This subsection is
the political craft that follows from that: identifying who is affected and who
can veto, understanding influence rather than only the organisation chart,
choosing how much detail each audience needs, managing scope creep without
becoming the person who says no to the business, and running a sign-off that
means something later. Open it for stakeholder mapping, for how to frame a
decision so it is easy to make, and for what to record when a decision is made
verbally by someone who will later not remember making it.
Analysis & UAT
The analytical half of the title is real. Before committing to a rule you check
it against the data — how many records would this threshold actually catch, does
the field the business calls "status" contain what they say it contains, is the
exception they describe as rare occurring twice a day. After the build you define
the scope of user acceptance testing, write the scenarios in business language,
prepare the data, run the sessions and triage what comes back into genuine
defects and things nobody ever asked for. Open it for how to size an analysis
question so it can be answered in a morning, for what a UAT script contains that
a system-test script does not, and for how to run acceptance so that sign-off is
a conclusion rather than a negotiation.
BA Scenarios
The last subsection is deliberately unlike the others. It is a set of situations
to work through: the stakeholder who will not attend, the mid-sprint change that
invalidates half the sprint, two requirements from two directors that cannot both
be satisfied, a UAT defect that is really a missed requirement, a vendor claiming
the behaviour you specified is not supported. These are the interview questions
that separate candidates, because there is no correct answer, only a defensible
approach and a set of considerations you either raise or miss. Open it to
rehearse, and pay attention to which considerations you consistently forget.
Where it sits in a real business
Follow a change through an enterprise and you can see the gap the role fills. A
sponsor owns an outcome and a budget: reduce the time to onboard a corporate
customer, or comply with a regulation by a date. Engineers can build almost
anything, but only against a statement of what to build. Between those two sits a
set of questions nobody else is paid to answer — what the process does today
including the parts nobody documented, which rules are legal obligations and
which are habits, what happens on the exception path, and what "done" means in a
way a tester can check.
Loading diagram…
The edge worth noticing is the one from acceptance back to the rules rather than
back to the build. Most rejected UAT scenarios are not defects; they are places
where the rule was ambiguous and the developer resolved it one way while the
business assumed the other. That loop is the cost of imprecision, paid late.
So the BA is usually the only person who knows how the work actually flows: the
spreadsheet the operations team maintains beside the system, the queue where
rejected records go, the person who reconciles two ledgers by hand on Monday
mornings. Those are not curiosities. They are unfunded parts of the process, and
a change that ignores them either fails at acceptance or quietly transfers the
manual work to a different desk.
In regulated industries the requirement is also a control artefact, because an
auditor will ask who approved this rule, what evidence exists that it was tested,
and which obligation it discharges. That is why requirements work never fully
de-formalised in banking, insurance and healthcare: the specification is not
project overhead there, it is the record that makes the control demonstrable
years later. It also explains a difference in cadence that surprises people
arriving from product companies. A rule change in a lending system is not simply
a code change; it is a change to something an examiner may sample.
The boundary with the two roles people confuse it with is worth setting out by
the question each one answers.
The question being answered
Who owns the answer
Should we spend money on this at all, and what outcome are we buying?
The sponsor, usually informed by a business case a BA wrote
Which problems do we solve, in what order, for which customers?
Product manager
What does the team build next, and is this slice acceptable?
Product owner
What must the system do, exactly, and how will we know it does?
Business analyst
Will it land by the date, and what is blocking it?
Project or delivery manager
That table is the theory. In a bank the product owner is often a business
subject-matter expert who attends ceremonies while the BA does every row below
the second. In a product startup one product manager does all five and there is
no BA. In consultancy the BA does the last row too. Nothing about the split is
universal, so treat it as a question to ask rather than a fact to assert: who
writes the acceptance criteria here, who decides priority when two stakeholders
disagree, and who signs off. A candidate who asks that reads as experienced
because only experience teaches you the variation exists.
How a requirement changes state
A requirement is not a document, it is an object with a lifecycle, and knowing
that lifecycle is the difference between an analyst who writes and an analyst who
manages a body of agreed truth. It starts as something somebody said. It becomes
a candidate once you have written it in your own words and it survived being read
back. It becomes agreed when the person with authority over that area has said so
in a way you can point at. It becomes built, then accepted, and then — the state
most people forget — it becomes part of the description of the system, which the
next change will be specified against.
Loading diagram…
The transition that costs money is the one from Built back to Candidate, and the
transition people neglect is Disputed back to Candidate, because a dispute
resolved in a corridor without being recorded will be re-litigated by the same
two people in three months.
The vocabulary of the first fortnight
You will hear these terms used loosely and be expected to use them precisely. The
loose usage is not worth correcting in others, but using them precisely yourself
is one of the cheapest signals of competence available to you.
Term
What it means precisely
Business requirement
The outcome the organisation wants, stated without reference to a system
Functional requirement
Something the system must do, observable from outside it
Non-functional requirement
A quality the behaviour must have, such as a response time, a retention period or an availability target
Business rule
A constraint the organisation imposes that would still exist if the system did not
Acceptance criterion
A condition that must hold for a specific slice to be considered done
As-is / to-be
The process as it runs today, and the process after the change
Gap analysis
The deliberate difference between the two, expressed as work
Traceability
The link from an objective or obligation through to the rule, the test and the evidence
RAID
Risks, assumptions, issues and dependencies, tracked as a log
MoSCoW
A prioritisation scale of must, should, could and will not have this time
Definition of ready
The agreed filter an item passes before a team commits to it
Sign-off
A named person recording that they accept a stated scope
Two of those repay extra attention. A business rule outlives the system, so a
rule expressed as "the screen must grey out the button" has been written at the
wrong level and will need rewriting the next time the interface changes. And a
non-functional requirement is where inexperienced analysts lose most of their
credibility, because "the system must be fast" is not a requirement and the
people who know what number belongs there will not volunteer it.
Who does this work
Junior and mid-level BAs sit inside a delivery team and work at the level of a
feature: running an elicitation session, writing stories and rules, answering
developers' questions through the day, walking a screen through with the
business, triaging a UAT defect into "defect" or "we never asked for that". The
day is fragmented in a way that suits some people and exhausts others; a great
deal of it is being interruptible on purpose, because a developer blocked on an
unanswered question is more expensive than your focus.
A senior BA works nearer the problem — shaping scope, modelling a target process,
arbitrating between departments, and being the person a programme director asks
when the impact of a change is unclear. The characteristic senior task is impact
analysis: someone proposes a change to how a customer identifier is issued, and
you are the one who can say which nine downstream processes assume the current
format, which two of them are outside your programme, and which one is
contractual with a third party.
Functional consultant is the same craft aimed at packaged software, where the
answer is configuration rather than code. Those roles are labelled by product —
SAP, Salesforce, Guidewire, Temenos, Murex — and their scarcity comes from
knowing both the package's model and the business process it is being bent
towards. The work has a distinctive shape: much of it is deciding whether to
change the business to match the package or the package to match the business,
and every customisation you agree to is a maintenance liability at the next
upgrade. Business systems analyst usually means a BA who owns the interface and
data-mapping detail as well, and in practice spends a lot of time in field-level
specifications and in the conversations where two systems disagree about
cardinality.
Prioritisation plus everything a BA does, with authority attached
The domain, not the technique, is what makes a senior BA expensive. BPMN takes a
fortnight to learn. Knowing why a claims reserve moves when a case estimate
changes, or what happens to settlement when a corporate action lands mid-trade,
takes years and cannot be read up on the weekend. That shapes the career in a
specific way: each year in insurance or payments makes you more valuable inside
that domain and slightly less mobile outside it, and a switch from one heavy
domain to another is in practice a step down in scope for a year or two. It is
worth choosing the domain on purpose rather than by whoever hires you first.
Demand, adoption and how that is changing
Demand is steady, and it is unevenly distributed in a way the job title hides. It
is reliable wherever a requirement is simultaneously a compliance artefact or a
contractual one: banks, insurers, healthcare providers and payers, public sector,
utilities, telecoms. It is reliable during package implementations, core-system
replacements and migrations, where most of the work is reconciling how the
business behaves with how the software assumes it behaves. Regulatory change
drives it in waves, because a new obligation with a deadline creates analysis work
that cannot be deferred and cannot be descoped.
Migration deserves singling out, because it is where the profession is at its
most necessary and least visible. Moving a book of business from an old platform
to a new one is almost entirely an analysis problem: what does each legacy field
mean, which values are in use versus theoretically permitted, which records are
in states the new system has no concept of, and what happens to the several
thousand accounts that are wrong in the source and have been for a decade.
Nobody can write that from the target system's documentation.
It is thin in product companies. In a product-led startup or scale-up, a product
manager, a designer and the engineers do this work directly against users, and
inserting a dedicated requirements role adds a hop without adding information.
Many agile transformations removed the role deliberately for exactly that reason.
If your ambition is a product company, BA is the harder door: the same skills are
hired there under the title of product manager or product owner.
Tooling changes the artefact rather than the need. Requirements have already
moved from signed specifications to backlogs and acceptance criteria, and
language models will happily draft a story or a first-pass process description
from meeting notes. That compresses the typing, which was never the scarce part —
the scarce parts are getting a reluctant subject expert to tell you what really
happens, noticing that two rules contradict, and being precise. If anything the
generated first draft raises the bar on the reviewing skill, because a fluent,
plausible, subtly wrong specification is harder to catch than an obviously thin
one. Read the verbs in a job description before believing the title, because a
good share of advertised BA roles are reporting analysts and another share are
product owners.
What makes it hard
People do not know what they need, and they are not being difficult. What they
can tell you is what they currently do, which includes years of workarounds for
constraints that no longer exist. Take the description at face value and you will
faithfully rebuild the workaround. The skill is asking what the step is for until
you reach an answer about the business rather than about the software, and that
conversation can go wrong socially if handled clumsily — the person describing
the step often invented it, and "why do you do that?" can land as an accusation
when it was meant as curiosity.
Loading diagram…
Look at the last exchange. The developer's question arrives after the
specification is written, it is about an exception, and it is the one you did not
ask. That pattern repeats for an entire career and is the reason experienced
analysts write the exception list first.
Precision is genuinely unnatural. "The system should notify the manager promptly
when a claim is unusually large" reads fine, passes review, gets signed, and
cannot be built. Ambiguity is invisible to the person who wrote it, because they
know what they meant, so you need a deliberate habit of attacking your own
sentences for the words that carry no definition. The reliable tell is any word
that would need a number, a list or an owner behind it and does not have one:
promptly, appropriate, relevant, significant, as required, where necessary.
Then there is accountability without authority. You are answerable for a
requirement being right while every decision it depends on belongs to somebody
more senior, often to two people who disagree. Nothing in the toolkit fixes that;
you manage it by making decisions easy to make and by recording who made them. A
decision log is not bureaucracy, it is the mechanism by which you stop being
personally blamed for a choice you did not have the authority to make.
The exception path is where the business actually lives. The happy path takes an
afternoon, and refunds, partial payments, corrections, reversals, duplicate
submissions, mid-process cancellations and death of the customer take six weeks
and carry the money. An analyst is largely judged on the exceptions they thought
of before the build, because each one found afterwards costs several times what
it cost to specify.
And there is knowing when to stop. Over-analysis and under-specification are both
real failures, the line between them is judgement rather than method, and the
judgement is domain-specific: the level of detail that is excessive for an
internal reporting change is negligent for a payment instruction. The workable
heuristic is to specify to the level of the risk, which means asking what happens
if this is interpreted wrongly and writing more only where the answer is
expensive.
Why study it
Study it if you want to understand how a business works from the inside, because
no other early-career role puts you in the room where a process, its economics
and its politics are all visible at once. You will learn, quickly and for free,
what an organisation actually optimises for as opposed to what it says it
optimises for, and that knowledge transfers to almost every senior role you might
want later.
It is one of the few genuine entries into technology for people who do not want
to write code, though be realistic that entry-level competition is heavy and the
first job is often reporting or support with analysis attached. It is the
standard feeder into product ownership, product management and domain
consulting. And the core skill is unusually durable: frameworks and artefacts
have turned over repeatedly since the 1990s, and "find out what is needed, state
it unambiguously" has survived all of it.
Do not study it if you want to build things, because you will spend your life
describing work other people do. Do not study it if the meeting-heavy,
writing-heavy, blame-adjacent shape of the day sounds like a cost rather than the
job. And do not study it as the shortest route to a high ceiling: in product
companies the ceiling above product management and engineering is higher, and the
highest-paid BA careers are domain specialists in finance and insurance who got
there by a decade in one industry.
Your first hour
Take one badly written requirement and beat it into rules. Use the sentence
below, or better, a real one from work.
Original: "The system should notify the manager promptly when a claim is
unusually large, so they can review it."
Which words carry no definition:
notify email, in-app, both? What if the send fails?
the manager of whom? What if the claimant is the manager?
promptly within what interval, measured from which event?
unusually large by what threshold, in which currency, gross or net of excess?
review advisory, or does it block payment?
(unasked) what happens if nobody reviews it at all?
Rewritten as rules:
R1 A claim whose gross value exceeds the product's referral limit
(configuration; currently GBP 25,000) is marked Referred on submission.
R2 A Referred claim cannot be paid until an assessor holding Referral
authority records an outcome against it.
R3 On marking, the claim enters the owning team's queue and the assigned
assessor is emailed within five minutes.
R4 A Referred claim with no recorded outcome after two working days appears
on the team leader's exception report.
R5 If the email in R3 fails, R1 and R2 still apply. The notification is not
the control; the block on payment is.
Now notice what the exercise produced. One sentence became five rules, a
configuration item, an authority model, a timer, an exception report and a stated
failure mode — and R5 is the one a developer would otherwise have decided alone
at four in the afternoon. If you found that satisfying rather than tedious, the
profession will suit you. If you can also see the question this still leaves
open, which is who maintains the referral limit and under what approval, you
already have the instinct.
With the second half of the hour, make the rules testable and traceable. Write
one acceptance scenario per rule in the same plain language, and put them in a
four-column table: objective, rule, scenario, evidence.
Objective Rule Scenario Evidence
Reduce large-claim R1 Claim of 25,000.01 submitted -> Referred Test case UAT-11
leakage R1 Claim of 25,000.00 submitted -> not Test case UAT-12
R2 Referred claim payment attempted -> blocked Test case UAT-13
R4 Referred, no outcome, day 3 -> on report Test case UAT-14
Two things fall out of that table immediately. The boundary case in UAT-12 is a
requirement you had not written down — whether the limit is exclusive or
inclusive — and you have just found it for free. And the first column being
sparse tells you the objective is carried mostly by one rule, which is worth
knowing before somebody proposes dropping it for schedule.
What this is not
It is not project management. You will maintain a RAID log at some point and it
is still not your accountability; if the interview is mostly about dates and
dependencies, the role is a delivery role with a BA title. That is not
necessarily a bad job, but you should take it knowingly, because the skills it
builds are different and the next role you can get is different too.
It is not note-taking. A BA who writes down what stakeholders said, faithfully
and without challenge, has produced a transcript of the current workaround. The
value is entirely in the questions asked between the statements.
It is not business process outsourcing analysis, and it is not the same as being
the person who knows the system. Long-serving super-users are invaluable and
frequently make excellent analysts, but the knowledge of how the current system
behaves is an input to the discipline rather than the discipline itself; the
craft is in generalising from it and in being willing to conclude that the
current behaviour is wrong.
It is not testing, though you will write the UAT scenarios and often run the
sessions, and it is not data analysis, though you will write SQL to check whether
the rule the business described matches the data it produced. And it is
emphatically not the non-technical option in the sense of the undemanding one:
the artefacts are prose and tables rather than code, but a requirement is a
specification and it is either right or it is expensive.
The artefacts go out of fashion every few years. The person who can find out
what is actually needed and write it so it cannot be read two ways has never
gone out of fashion.