Business Analysis

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.

The seven areas underneath

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.

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.

flowchart TD
  A[Sponsor states an outcome and a budget] --> B[BA elicits how the work runs today]
  B --> C[As-is model plus gap analysis]
  C --> D[Rules, stories and acceptance criteria]
  D --> E[Delivery team builds a slice]
  E --> F[UAT against the same criteria]
  F --> G{Business accepts}
  G -- no --> D
  G -- yes --> H[Live, with benefits measured against the outcome]

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.

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.

stateDiagram-v2
  [*] --> Stated
  Stated --> Candidate: written and read back
  Candidate --> Disputed: another party objects
  Disputed --> Candidate: decision recorded
  Candidate --> Agreed: owner signs off
  Agreed --> Built
  Built --> Accepted: UAT passes
  Accepted --> [*]
  Built --> Candidate: acceptance exposes ambiguity

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.

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.

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.

sequenceDiagram
  participant SME as Operations expert
  participant BA
  participant Fin as Finance
  participant Dev as Delivery team
  SME->>BA: This is what I do each morning
  BA->>SME: What would break if the step were skipped
  BA->>Fin: Your rule contradicts theirs
  Fin->>BA: Ruling, with a reason
  BA->>Dev: Rule plus acceptance criteria plus who decided
  Dev->>BA: What happens on the reversal path

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.