Business analysis fundamentals

The definition of the problem and the precision of what is being asked for. That means the analyst owns whether the need has been understood, whether the requirement is unambiguous enough to build and to test, whether the affected processes and data have been traced, and whether the people who will live with the change have been consulted. What the analyst does not own is the decision about what gets built or when, which belongs to whoever holds the budget and the roadmap. The distinction matters because it explains the failure mode of the role: an analyst who owns clarity but believes they own priority becomes a bottleneck nobody asked for, and an analyst who owns neither becomes a scribe transcribing whatever the loudest stakeholder said last.

A product manager decides what is worth building and is accountable for the outcome; a business analyst establishes what the thing actually is and is accountable for the change being understood. Product management points outward at a market, a competitive position and a commercial result, and answers "should we". Business analysis points inward at processes, systems of record, data and the people doing the work, and answers "what exactly, and what breaks". On small teams one person does both and the honest answer in an interview is to say which hat you were wearing in each example. The two roles fail differently: a product manager with no analysis ships a feature that does not fit the operational reality, and an analyst with no product owner produces a specification for something nobody needed.

Three levels, and conflating them is the most common structural fault in a requirements document.

level          answers                       example                                        owned by
-------------  ----------------------------  ---------------------------------------------  -----------------
Business       Why are we doing this at      "Reduce the cost of processing a supplier      Sponsor
requirement    all, in terms the business    invoice from £14 to under £5 by Q3."
               already measures                                                             Measurable in
                                                                                            the business's
                                                                                            own numbers

Stakeholder    What does a particular group  "As an accounts payable clerk I need to see     Named stakeholder
requirement    need in order to do their     which invoices are blocked and why, without    group
               work                          opening each one."
                                                                                            Traceable up to
                                                                                            a business req

Solution       What must the solution do or  Functional: "The system shall match an          Delivery team
requirement    be                            incoming invoice to a purchase order on
                                             supplier ID, PO number and net amount."

                                             Non-functional: "Matching shall complete
                                             within 2 seconds for 95% of invoices at a
                                             load of 8,000 invoices per hour."

Transition     What is needed only to get    "Twenty-two months of open invoices must be     Delivery team,
requirement    from as-is to to-be, then     migrated and reconciled to a zero variance      then retired
               becomes obsolete              before cutover."

The column that gets skipped is the first. A document that begins at the solution level describes a system with no stated reason to exist, so when the budget is challenged there is nothing to defend it with, and when two solution requirements conflict there is no higher authority to resolve them against. "Reduce cost per invoice to £5" settles arguments that "the system shall have a dashboard" cannot.

The transition row is the one candidates have never heard of and it is where projects overrun. Migration, dual running, reconciliation, training and decommissioning are real work with real requirements, and because they do not appear in the target-state specification they are routinely discovered in the last month. Naming the category unprompted is a strong signal.

The ownership column is the practical use of the model. Each level has a different person who can approve a change to it, so a request that alters a business requirement cannot be waved through by a delivery team, and a solution detail does not need a steering committee. Most change-control disputes are really disputes about which level was affected.

Only as a last resort, and saying so plainly is a better answer than accepting the framing. An analyst is a proxy for the understanding of the need, not for the person who has it, because the analyst has no authority to trade one need against another and no consequences when the answer is wrong. Acting as a proxy is sometimes unavoidable — the users are ten thousand consumers, or a regulator, or a group whose time cannot be bought — and then the correct behaviour is to make the proxying visible: state which assertions are yours rather than a user's, record them as assumptions, and get them tested at the earliest opportunity. The failure mode is an analyst whose opinions have quietly become requirements that nobody outside the project has ever seen.

Look sideways. Engineers optimise within the boundary of the thing being built, product decides what is next, testers verify what was specified, and none of those roles is structurally responsible for the question "what else does this touch". The analyst is the person who notices that the new status value breaks the nightly extract that finance depends on, that the field being made mandatory has nulls in sixty per cent of historic rows, and that the process being automated has a manual exception path handling eight per cent of volume. That work is unglamorous and it is where the cost of a missed requirement actually lands, because integration and data surprises are discovered late and are expensive precisely then.

The activities are the same and the batch size changes. In a waterfall shape the analysis is front-loaded into a signed specification, which buys a stable contract and pays for it with a long gap between deciding and learning. In an iterative shape the analysis is continuous and just-in-time: enough detail for the next increment, refined as the team learns, with the specification emerging as stories, acceptance criteria and working software rather than as a document. What does not change is the need for traceability, for non-functional requirements and for process and data analysis, and the common agile failure is assuming those disappeared with the document. The honest interview answer is that agile changes when you write things down and how much, not whether analysis happened.

It appears as rework rather than as an absence. Requirements arrive as solutions, so the underlying need is never examined and the cheaper option is never found. Integration and data effects surface in testing rather than in design, which is the most expensive point at which to learn them. The exception paths in the current process go undiscovered until go-live, when the eight per cent of cases nobody modelled arrive at a system with nowhere to put them. And because nothing was traced to an objective, the change cannot be evaluated afterwards, so the organisation repeats the mistake. None of this shows up as a missing role in a project report; it shows up as scope growth and a delayed date.