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.

Because it asks a stakeholder to do the analyst's job in a form they are not equipped for. People are reliable witnesses of their problems and unreliable designers of solutions, so the answer arrives as a feature request — usually a description of the last tool they used — and the underlying need stays hidden. It also anchors the conversation: once someone has said "I want a dashboard", the project is about the dashboard, and the fact that they needed a weekly exception alert is never discovered. The better questions are about the work rather than the system. What happens today, step by step. Where does it go wrong. What do you do when it goes wrong. What decision are you trying to make. How would you know this was better.

Technique choice follows from what kind of unknown you have, and the interview question behind this is whether you have a reason for the one you picked.

technique          right when                              gives you             fails when
-----------------  --------------------------------------  --------------------  ------------------------------
Interview,         The unknown is a person's reasoning,    Depth, motive,        Two people would contradict
one to one         or the topic is politically             the exceptions        each other and you never find
                   sensitive and they will not say it      nobody documents      out. Also: what they say they
                   in a room                                                     do, not what they do

Workshop           The unknown is a disagreement, or a     Shared decisions,     Seniority silences the people
                   decision needs several parties in       cross-team gaps       who know. Or it becomes a
                   the same place                          surfaced live         status meeting with a flipchart

Observation,       The process is habitual, manual or      The real path,        The task is cognitive rather
job shadowing      undocumented, and the gap between       including the         than physical. Also observer
                   the stated and actual process is        spreadsheet nobody    effect: people work to the
                   the risk                                admits to            documented process while watched

Document           There is an existing system, a          Data structures,      Documents describe intent and
analysis           regulation, a contract or a prior       rules, volumes,       age badly. Never treat one as
                   specification                           the vocabulary       evidence of current behaviour

Prototyping,       The stakeholder cannot articulate       Concrete reactions,   It anchors on a design. Also
wireframes         what they want but will recognise       misunderstandings     invites cosmetic feedback when
                   it. Or two parties think they agree     of your own model     you needed the rule underneath

Survey             You need breadth across hundreds of     Distribution,         Anything requiring a follow-up
                   people and the questions are already    frequencies,          question. Poor for discovering
                   well formed                             where to look next    what you did not think to ask

Data profiling     The requirement depends on what is      Actual volumes,       Nothing about why the data is
                   actually in the system rather than      null rates, the       like that, which is where the
                   what is supposed to be                  exceptions           requirement usually hides

The sequencing matters more than any individual choice. Document analysis and data profiling first, because they are cheap and they mean you arrive at an interview able to ask a specific question rather than an open one; interviews next, to build the picture and locate the disagreements; a workshop only once you know what the disagreement is, because a workshop convened to discover requirements from scratch produces a list of features and no decisions.

Observation is the technique candidates omit and the one that most reliably finds the real requirement. What people describe is the process as it was designed and as they believe they follow it. What observation reveals is the spreadsheet on the second monitor, the paper note passed to a colleague, the field used for a purpose it was not named for, and the workaround so habitual that nobody thinks of it as a step. Every one of those is either a requirement or a defect in the model.

Each technique's failure column is what you use to pair them. Interviews plus observation cover the say-do gap. Surveys plus interviews cover breadth and depth. Prototyping plus a written rule covers the case where the screen looked right and the logic behind it was never agreed.

The answer that scores is naming the unknown first. "I would start by profiling the invoice table, because the requirement depends on how many of them arrive without a purchase order and nobody in the room will know that number" is a different quality of answer from a list of techniques.

Preparation and silence. Preparation means arriving with the documents read, the data profiled and three specific hypotheses to test, so the stakeholder's time is spent on what only they know rather than on things you could have found out. Silence means asking an open question and then not filling the pause, because the useful information is usually in the second half of the answer. Beyond that: start with their work rather than the system, ask for a recent concrete case rather than a general description, chase the exceptions explicitly by asking what happens when it goes wrong, and finish by reading back your understanding and inviting correction. Send the notes within a day, because a correction is cheap while the conversation is fresh and expensive once it has become a requirement.

It is right when the unknown is a disagreement rather than a fact — two departments with incompatible definitions of the same term, or a decision that needs several parties to be present so nobody relitigates it afterwards. It is the only technique that produces a shared decision rather than a collected opinion. It goes wrong in two predictable ways. Seniority in the room silences the people who actually do the work, so you leave with the manager's version of the process, which is the documented one. And a workshop with no decision to make becomes a feature-brainstorming session whose output is a list nobody owns. The fixes are mundane: a stated decision to be reached, pre-read material, separate sessions for different levels, and a facilitator who is not also a stakeholder.

The difference between the process people describe and the process they perform. That gap is not dishonesty; it is that habitual work becomes invisible to the person doing it, so the twelve keystrokes, the second system checked, the colleague asked and the personal spreadsheet all vanish from the account. Sitting with someone for a morning surfaces the exception rate too, because you see how often the happy path is not taken, which is the number that decides whether an exception path needs building. The limit worth stating is the observer effect: being watched pulls people towards the documented process, so a long enough sit or a second visit matters, and the throwaway remark — "I usually just do it this way, but" — is the sentence to follow.

It is the cheapest way to acquire the vocabulary, the data structures, the volumes and the rules that are genuinely fixed, and it is how you arrive at an interview able to ask a sharp question. Regulations, contracts, interface specifications and database schemas are all evidence. What it must never be trusted for is current behaviour. A process document describes intent at the moment it was written, and the gap between it and reality grows silently with every workaround, so treating it as the as-is process is how a project builds an automation of a process nobody follows. The discipline is to treat every document as a hypothesis, and to confirm it against data or observation before it becomes an input to a requirement.

When its purpose is to provoke a reaction rather than to specify an interface. People who cannot describe what they need can almost always tell you what is wrong with something in front of them, so a deliberately rough wireframe extracts requirements that no question would have reached. It is also the fastest way to discover that your own model is wrong, because a stakeholder correcting a screen is correcting your understanding. The cost is anchoring: a polished prototype ends the conversation about whether the underlying rule is right and starts one about colours, and stakeholders reliably read a prototype as a commitment. Keeping it visibly unfinished is a technique, not laziness, and every insight it produces still has to be written down as a requirement.

The test of a five-whys is not that you asked five times, it is that the solution at the end is different from the solution at the start.

Problem as reported: the finance team closes the month three days late,
every month, and has done for two years.

Why 1  Why is the close late?
       Because reconciling the incoming payments file takes three days.

Why 2  Why does that take three days?
       Because about 8% of payment lines do not match an invoice
       automatically. That is roughly 400 lines a month, matched by hand.

Why 3  Why do 8% fail to match?
       Because the match needs the invoice reference, and the reference
       arrives as free text typed by the customer, so it comes through
       abbreviated, truncated, or with the purchase order number instead.

Why 4  Why is the reference free text?
       Because the reference is printed in the body of the invoice PDF
       and the customer retypes it into their own banking screen.

Why 5  Why is it never machine-readable?
       Because the payment flow was designed for cards, where the
       reference is carried automatically. Bank transfer was added in
       2019 as a manual alternative and the flow was never revisited.

SOLUTION IF YOU STOP AT WHY 1 OR 2
  Hire a temp for month end, or build a fuzzy-matching screen so a clerk
  can clear 400 exceptions faster. Cost recurs monthly, forever.

SOLUTION AFTER WHY 5
  Issue a per-invoice virtual account number, or a structured reference
  on the transfer instruction, so the reference cannot be mistyped.
  Unmatched lines fall from 8% to under 1% and the close is not late.

The chain works because each answer is a fact rather than an opinion, and two of them are numbers. "About 8%, roughly 400 lines" is what makes the difference between a root-cause analysis and a discussion, and getting it required profiling the payments table rather than asking anyone.

Notice where the obvious project sat. A request had already arrived as "we need a better reconciliation screen", which is a solution to why 2, and it would have been delivered, used, and correct — while leaving the cost in place permanently. That is the specific value of the technique: it does not make the analysis cleverer, it moves the intervention upstream of where the pain is felt.

The stopping rule is worth stating because five is arbitrary. You stop when the next why leaves the boundary of anything you can change, or when the answer becomes a person rather than a mechanism. If a chain terminates in "because Dave forgot", you have taken a wrong turn — the real question is what allowed a single person's memory to be a control.

The honest caveat to volunteer is that causes branch. Five whys follows one thread and real problems have several contributing ones, so it is a probe rather than a complete method; a fishbone or a fault tree is what you reach for when the first why has three credible answers.

A functional requirement says what the system does — matches an invoice, sends a statement, rejects a duplicate. A non-functional requirement constrains how well it must do it: response time under load, availability, recovery time, capacity, security posture, accessibility standard, auditability, retention period, supportability. The distinction matters because the two are discovered differently and by different people. Functional requirements come from asking users about their work; non-functional ones usually come from the business's own obligations, from operations, from regulators and from data on existing volumes, and nobody volunteers them. They also fail differently: a missed functional requirement is a gap someone reports, while a missed non-functional one is usually an architectural rework, because it cannot be added late.

The same requirement four times, and only the last can be failed by a tester.

AS ELICITED
  "The system must be fast."

  Untestable. Fast doing what, for whom, at what load, and how often is
  it allowed not to be. Any implementation satisfies it and none does.

FIRST ATTEMPT
  "Invoice search must respond quickly under normal load."

  Still untestable. "Quickly" and "normal" are the two words carrying all
  the meaning and neither is defined. This is the version that reaches
  sign-off because it reads like a requirement.

SECOND ATTEMPT
  "Invoice search must respond in under 2 seconds."

  Better - there is a number. Still not testable: measured where, at what
  concurrency, on what data volume, and for what proportion of requests.
  An average of 2 seconds and a p95 of 2 seconds are different systems.

TESTABLE
  ID          NFR-014
  Statement   Invoice search shall return the first page of results
              within 2.0 seconds at the 95th percentile, and within
              5.0 seconds at the 99th, measured at the browser, with
              50 concurrent users and 4 million invoices in the store.
  Rationale   Clerks run 30-40 searches per shift. Above ~2s they batch
              their work and stop searching mid-call, which is the
              behaviour the project exists to remove.
  Source      AP team lead, interview 12 Jun. Volumes from profiling.
  Verified by Load test LT-07 against a production-sized data set,
              re-run each release.
  Depends on  Assumption A-03: invoice volume grows under 15% a year.

Four things changed, and each closes a specific escape route. A number replaced an adjective. A percentile replaced an implied average, which is the substantive change, because an average hides the slow requests that are the actual complaint. A measurement point and a load were named, so the test is reproducible and cannot be passed by measuring a warm cache on an empty database. And the verification method was written next to the requirement, which is the discipline that makes a requirement testable — if you cannot say how it would be proven, it is not a requirement yet.

The rationale line is the part candidates leave out and the part that survives contact with a delivery trade-off. When an engineer reports that 2.0 seconds costs three weeks and 3.0 costs nothing, the rationale is what lets you answer, because it says what the number is protecting. A requirement with no rationale is either defended for no reason or dropped for no reason.

Source and dependency lines make the requirement maintainable rather than merely correct. The source is who to go back to when reality changes; the assumption is the thing that, if wrong, invalidates the number, and stating it means a growth rate of forty per cent triggers a review instead of an incident two years later.

The trap in the "second attempt" row is the one worth naming aloud in an interview. A requirement containing a number feels rigorous and can still be untestable, so the check is not "is there a figure" but "could two competent testers, working independently, agree on whether this passed".

That an independent person can determine unambiguously whether it has been met, without asking the author what was meant. In practice that requires a measurable or observable outcome rather than an adjective, defined conditions including load and data state, a stated tolerance where variability exists, and a named verification method. The habit that produces it is writing the test alongside the requirement, because the attempt exposes the ambiguity immediately: any word you cannot design a test around — user-friendly, seamless, robust, intuitive, efficient, minimal — is a placeholder for a conversation you have not had. Testability is also the cheapest defence against scope disputes, since a requirement that can be objectively passed can also be objectively finished.

INVEST is quoted far more often than it is applied, so the useful exercise is to fail a story on it and then fix it.

ORIGINAL
  "As a user, I want better reporting so that I can see how the
   business is doing."

I  Independent   FAIL   No idea. It touches every report, so it collides
                        with anything else in the area.
N  Negotiable    FAIL   Nothing to negotiate. There is no boundary, so
                        the team cannot propose a cheaper version.
V  Valuable      ?      Plausibly valuable, but to whom and worth what
                        is unstated. "A user" is nobody.
E  Estimable     FAIL   Could be two days or two quarters.
S  Small         FAIL   Not one increment. This is an epic wearing a
                        story's clothes.
T  Testable      FAIL   "Better" and "how the business is doing" cannot
                        be passed or failed.

REWRITTEN
  "As an accounts payable team lead, I want a list of invoices blocked
   for more than 5 working days, with the block reason, so that I can
   clear the ones at risk of a late-payment charge before month end."

  Acceptance criteria
    - Blocked means status in Held, Query or Awaiting-PO.
    - Working days exclude weekends and the England bank holiday list.
    - Columns: invoice no, supplier, amount, days blocked, reason, owner.
    - Sorted by days blocked, descending. Default filter: my team only.
    - Empty state reads "No invoices blocked over 5 days".
    - Exportable to CSV with the same columns and sort order.

I  Independent   PASS   Read-only over existing data. No shared schema
                        change, so it can ship in any order.
N  Negotiable    PASS   The CSV export and the team filter are both
                        droppable without destroying the value.
V  Valuable      PASS   Named beneficiary, and the value is a late-
                        payment charge the business already measures.
E  Estimable     PASS   One query, one screen, one export. Two to three
                        days with the rules above settled.
S  Small         PASS   Fits an iteration with room to spare.
T  Testable      PASS   Every criterion above is objectively decidable.

The letter that does the most work is T, because failing it usually fails three others as a consequence. Once "better reporting" became a specific list with defined columns, the story became estimable and small at the same time — those were never independent problems.

The rules hidden in the acceptance criteria are the actual analysis. Which statuses count as blocked, and whether working days exclude bank holidays, are questions with owners and wrong answers; leaving them out does not make the story smaller, it defers them to a developer who will guess and to a tester who will disagree. This is the single most useful thing an analyst does to a story.

N is the letter with a political edge. A negotiable story is one where the team can come back and say the export costs an extra day, and the analyst can trade it. A story written as a fixed list of eleven mandatory behaviours has removed that conversation, which is how a two-week iteration becomes a five-week one with no decision having been taken.

Two honest caveats. I is aspirational — real stories have dependencies, and the useful version of the letter is knowing what they are rather than pretending they are absent. And a story is a placeholder for a conversation, so a story that passes INVEST on paper and was written by an analyst alone has satisfied the acronym and skipped the point.

They are the conditions under which the story is agreed to be done: the observable behaviours, the rules, the boundaries and the notable negative cases. They are drafted by whoever owns the requirement — the analyst or product owner — and then refined with the team and the tester, because that conversation is where the missing cases surface. Written well, they do three jobs: they bound the story so that "done" is not a matter of opinion, they carry the business rules to the person implementing them, and they become the basis of the tests. The failure mode is criteria written after the fact to describe what was built, which is documentation rather than agreement, and criteria written as a design — naming buttons and layouts — which constrains the solution without specifying the rule.

One rule with several branches, written as scenarios rather than as a paragraph.

Rule: a customer may return an item for a full refund within 30 days of
delivery, unless it is a hygiene item, in which case it must be unopened.
Refunds above £500 need a supervisor. Postage is refunded only if the
item was faulty.

Scenario  Standard return inside the window
  Given   an order delivered 12 days ago
  And     the item is not a hygiene item
  When    the customer requests a return
  Then    a full refund of the item price is authorised automatically
  And     the postage is not refunded

Scenario  Outside the window
  Given   an order delivered 31 days ago
  When    the customer requests a return
  Then    the request is rejected with reason OUT_OF_WINDOW
  And     the customer is offered store credit at 80% of item price

Scenario  Hygiene item, seal intact
  Given   an order delivered 5 days ago containing a hygiene item
  And     the agent has recorded the seal as intact
  When    the customer requests a return
  Then    a full refund of the item price is authorised automatically

Scenario  Hygiene item, seal broken
  Given   an order delivered 5 days ago containing a hygiene item
  And     the agent has recorded the seal as broken
  When    the customer requests a return
  Then    the request is rejected with reason HYGIENE_OPENED
  And     no store credit is offered

Scenario  Faulty item, postage
  Given   an order delivered 40 days ago
  And     the customer has reported the item as faulty
  When    the customer requests a return
  Then    the 30-day window does not apply
  And     the item price and the original postage are both refunded

Scenario  Refund above the authorisation limit
  Given   an approved return with a refund value of £501.00
  When    the refund is submitted
  Then    it is held in status AWAITING_SUPERVISOR
  And     no money moves until a supervisor with the Refunds role approves

Boundaries confirmed with the returns manager, 3 Jul
  - Day 30 is inclusive. Day 31 is out. Measured from delivery date,
    not dispatch, in the customer's local date.
  - £500 is exclusive: £500.00 is automatic, £500.01 needs a supervisor.
  - Faulty overrides the window entirely and has no upper time bound
    beyond statutory rights.

The structure earns its place by forcing each branch to be written separately. The prose rule above the scenarios is three lines and contains at least six distinct behaviours, and it is precisely the kind of paragraph that is signed off by everyone and implemented differently by each developer who reads it.

The boundary block is where the real defects were prevented. Whether day 30 is inclusive, whether £500.00 is above or below the limit, and whether the clock starts at dispatch or delivery are the three things that will be wrong in production if they are not written down, and none of them is answerable by inspection — each needed a decision from a named person on a date.

The negative scenarios are what distinguishes acceptance criteria from a demo script. Anyone can write the happy path; the rejected hygiene item with no store credit offered is the case that a tester will otherwise raise as a defect and the business will insist was always obvious. Writing "and no store credit is offered" records a deliberate asymmetry.

The interaction to watch is the faulty-item path, which overrides the window and changes the postage treatment. Rules that override other rules are the usual source of contradictory specifications, so the analyst's job is to find the precedence order and state it explicitly rather than leaving two clauses to collide.

A use case describes a complete interaction between an actor and the system to achieve a goal, with a main success scenario, alternative flows, exception flows, preconditions and postconditions. A user story is a short placeholder for a conversation, sized to be delivered in an iteration, with the detail carried in acceptance criteria. So a use case is a fuller specification of one goal and a story is a thin slice of value; several stories usually implement one use case. Use cases suit domains where the exception flows are the substance — payments, clinical, regulated processes — and where a single agreed document must serve many readers. Stories suit incremental delivery. The mistake is treating them as rival philosophies rather than as different batch sizes for the same content.

Because nobody in the room is the customer for them. Users describe the work they do, which produces functional requirements; the constraints that matter — availability, recovery point, retention, peak capacity, accessibility conformance, auditability, supportability — belong to operations, compliance, security and finance, and none of those people is usually invited to a requirements workshop. They are also unfalsifiable in the states in which they are normally checked: a system with one test user meets every performance requirement. And they are architectural rather than additive, so discovering a recovery-time obligation after the design is fixed is a rebuild rather than a change. The countermeasure is a standing checklist of non-functional categories applied to every change, so their absence is a recorded decision rather than an omission.

Enough that the next decision can be taken correctly, and no more. The calibration is by cost of being wrong and by distance from delivery: a rule that will be implemented next week, in a regulated area, with money attached, is worth specifying to the boundary condition, while a feature six months out is worth a paragraph and an open question. Over-specification is a real cost rather than a harmless surplus, because it consumes the analyst's scarcest resource, invites sign-off on detail nobody has examined, and becomes stale in a way that misleads. The signal that you have written too little is developers making silent assumptions; the signal that you have written too much is documents nobody reads and a change-control queue full of trivia.

To establish what actually happens, which is nearly always different from what anyone believes, and to give the to-be design something to be measured against. Without it there is no baseline, so the benefit claimed for the change is unverifiable, and the exception paths that carry a surprising share of volume are invisible. It is also the fastest way to find the cheap improvement: a process map frequently shows two handoffs and a re-keying step that can be removed without any system change at all. The counter-discipline is proportion — an as-is model taken to the level of every keystroke on a process about to be replaced entirely is archaeology, so the depth follows what decision the model is informing.

The value of the map is not the boxes, it is what the annotations reveal about where the cost sits.

flowchart TD
    A[Invoice arrives by email<br/>to a shared inbox] --> B[Clerk keys header<br/>into the finance system]
    B --> C{PO number present<br/>and readable}
    C -->|no, 8% of volume| D[PAIN 1<br/>Clerk emails supplier<br/>average wait 4 days]
    C -->|yes| E[System matches to PO]
    E --> F{Amount within<br/>tolerance}
    F -->|no, 6%| G[PAIN 2<br/>Manual query queue<br/>no owner, no SLA]
    F -->|yes| H[Approver notified<br/>by email]
    H --> I[PAIN 3<br/>Approval by email reply<br/>no audit trail, 3 day median]
    I --> J[Payment run, weekly]

Read the percentages before the shape. Fourteen per cent of invoices leave the automated path, and because each exception costs days rather than minutes, that minority consumes most of the team's time and all of the lateness. A map without volumes invites the project to optimise the happy path, which is already fine.

Each pain point is a different class of problem and needs naming as such. Pain 1 is a data-capture defect at the boundary, fixable upstream by making the reference machine-readable rather than downstream by chasing. Pain 2 is an ownership defect — a queue with no owner and no service level is where work goes to age — and it can be fixed by assignment rules with no development at all. Pain 3 is a control defect: approval by email reply means the organisation cannot evidence who authorised a payment, which is an audit finding waiting to happen and is the one that unlocks the budget.

The weekly payment run at the end is the constraint nobody marked as a pain, and it is worth pointing at anyway. Any improvement upstream is capped by it, so reducing approval time from three days to three hours changes nothing a supplier can perceive unless the run frequency changes too. Finding the binding constraint is what stops a project delivering a measurable improvement that no stakeholder can feel.

The one thing this diagram deliberately does not do is show the future state. Mixing as-is and to-be on one map is the commonest modelling error, because it becomes impossible to say what is observed and what is proposed, and the baseline disappears.

Swimlanes exist to expose handoffs, and a sequence view makes each one a line you can count.

sequenceDiagram
    participant C as Customer
    participant S as Sales
    participant R as Credit control
    participant F as Fulfilment
    C->>S: Submits order
    S->>R: Requests credit check
    R-->>S: Approves with a limit
    S->>F: Releases order
    F-->>C: Confirms dispatch date
    F->>R: Flags order over the limit
    R-->>F: Grants a one-off override

Count the crossings rather than the steps. Seven messages cross four lanes, and each crossing is a queue, a possible loss, and a place where the process waits on someone whose priorities are set elsewhere. Cycle time in a process like this is almost entirely waiting rather than working, which is why measuring touch time tells you nothing useful.

The last two lines are the interesting part of the model. Fulfilment discovers an over-limit order after the order was already released, which means the credit check happened too early or on the wrong value — a sequencing defect that a step-list would never expose and that a lane diagram makes obvious. Rework loops that go backwards across a lane boundary are the highest-value thing a swimlane finds.

The modelling discipline is one lane per role, not per person or per system, and lanes ordered so that the common flow moves in one direction. When a lane has a single box in it, ask whether that role needs to be in the process at all; when two lanes exchange five messages, ask whether the boundary between them is in the right place. Both questions are about organisational design rather than software, which is often where the real answer lives.

The limitation to state honestly is that a sequence view shows the interaction and suppresses the decision logic. It is the right model for handoffs and the wrong one for branching rules, which is why the two diagrams above answer different questions and neither replaces the other.

The subset that a business stakeholder can read without training, which is a start and end event, a task, a gateway for a decision, a sequence flow, a pool and lanes for participants, and a message flow between pools. That vocabulary models almost every business process anyone will ask you about. Beyond it lies a large notation — event subprocesses, compensation, error boundaries, correlation — whose purpose is executable orchestration rather than communication, and using it in a stakeholder review reliably means the review becomes about the notation. The judgement being tested is audience awareness: the model exists to be validated by people who know the process and cannot be expected to learn a specification, so correctness in BPMN terms is worth less than being unambiguously readable.

Before any screen is designed, the nouns and their cardinalities settle a surprising number of arguments.

ENTITIES

entity          means                          identifier        notable attributes
--------------  -----------------------------  ----------------  --------------------------
Supplier        A legal entity we can pay      supplier_id       vat_no, payment_terms,
                                                                 status, bank_account_id

Purchase order  A commitment to buy, approved  po_number         supplier_id, raised_by,
                before goods arrive                              approved_at, currency

PO line         One orderable item on a PO     po_number +       description, qty, unit
                                               line_no           price, gl_code

Goods receipt   Evidence something arrived     grn_id            po_number, received_at,
                                                                 received_by

Invoice         A supplier's demand for        invoice_id        supplier_id, supplier_ref,
                payment                                          gross, net, tax, due_date

Invoice line    One charged item                invoice_id +      description, qty, amount
                                               line_no

Match           The link asserting that an     match_id          invoice_line_id,
                invoice line is covered by                       po_line_id, matched_by,
                a PO line and a receipt                          confidence, method

Payment         Money leaving, possibly        payment_id        run_id, amount, cleared_at
                covering several invoices

RELATIONSHIPS

Supplier    1 --- 0..*  Purchase order      a supplier may have none
Purchase order 1 --- 1..*  PO line          a PO with no lines is invalid
Purchase order 1 --- 0..*  Goods receipt    partial deliveries are normal
Supplier    1 --- 0..*  Invoice
Invoice     1 --- 1..*  Invoice line
Invoice line 0..1 --- 0..1 Match            unmatched lines are the 8%
PO line     1 --- 0..*  Match               one PO line covers several
                                             invoice lines over time
Invoice     0..* --- 0..* Payment           a payment covers many invoices
                                             and an invoice may be part paid

DECISIONS THIS MODEL FORCES
  - supplier_ref is the supplier's own invoice number. It is not unique
    across suppliers and is not our identifier. Uniqueness rule agreed:
    supplier_id + supplier_ref, used for duplicate detection.
  - Match is an entity, not a foreign key. It carries who matched, how,
    and with what confidence, which the audit requirement needs.
  - Invoice-to-payment is many-to-many, so a resolving entity is
    required. Every project that models it as one-to-many rediscovers
    part payments in UAT.

The cardinalities are the substance. Each 0..* is a case that must exist in the user interface and in the tests — the purchase order with no receipt yet, the invoice line matched to nothing, the part-paid invoice — and each one is a screen state or an error message that gets forgotten when the model is only drawn as boxes and lines.

Promoting Match from a relationship to an entity is the modelling decision worth being able to defend. The moment the business needs to know who matched an invoice line, when, by which method and how confidently, the link carries attributes and is therefore a thing rather than a pointer. Recognising when a relationship has become an entity is most of the skill in this technique.

The duplicate-detection rule is the requirement the model produced rather than recorded. Once you notice that the supplier's reference is not globally unique, you have discovered that duplicate-invoice prevention needs a composite rule, and duplicate payments are among the most expensive defects in accounts payable.

What the sketch deliberately omits is data types, indexes and nullability. This is a conceptual model for agreeing meaning with the business, and dragging physical detail into it moves the conversation to people who cannot validate the meaning, which is the only thing the model is for.

It is the agreed definition of each data item: its business meaning, its owner, its permitted values, its format, its source system and its relationship to other items. It settles arguments because most cross-department disputes are lexical rather than substantive — two teams reporting different revenue figures usually have different definitions of when revenue is recognised, and neither is wrong. Writing the definition down converts an argument into a decision with an owner and a date. It is also the practical prerequisite for integration and for reporting, since a field cannot be mapped until its meaning and permitted values are stated, and it is the artefact that outlives the project: the code will be replaced and the definition of "active customer" will not.

Entities against processes, with the operation in each cell — a two-minute technique that finds gaps no requirements list shows.

                        Supplier  PO    Goods    Invoice  Match  Payment
                                        receipt
----------------------  --------  ----  -------  -------  -----  -------
Onboard a supplier      C R U     -     -        -        -      -
Raise a PO              R         C R U -        -        -      -
Receive goods           -         R U   C R      -        -      -
Register an invoice     R         -     -        C R      -      -
Match an invoice        -         R     R        R U      C R    -
Resolve a query         R         R     R        R U      R U D  -
Run a payment           R         -     -        R U      R      C R
Close the period        R         R     R        R        R      R U
Offboard a supplier     R U       R     -        R        -      R

GAPS THIS EXPOSES
  1  Nothing deletes a Purchase order. Is a PO ever cancelled, and if
     so by whom? No process in scope covers it, and procurement
     assumed it existed.
  2  Nothing updates a Goods receipt except "receive goods" itself.
     What happens on a mis-keyed quantity? Currently: a credit note
     workaround nobody documented.
  3  Match is deleted only in "resolve a query". That is the only
     unmatch path, so if the query process is unavailable, an
     incorrect match cannot be reversed at all.
  4  Supplier is never deleted, only updated to inactive. Correct, and
     worth recording as a decision because it drives the retention
     requirement rather than being an oversight.
  5  Payment has no delete and no reversal row. Refunds and failed
     payments are out of scope by omission rather than by decision.

The technique works because it is exhaustive in a way that narrative requirements never are. Every entity must be created by some process and, in most domains, amended and disposed of by some process, so an empty column in C or D is either a missing requirement or a decision nobody has taken.

Gaps three and five are the expensive ones. A single reversal path is a single point of failure in the process rather than in the software, and an entity with no reversal at all means the first operational error becomes a database intervention. Both are invisible in a list of user stories because nobody writes a story for undoing something.

Gap four is included to make the point that a blank cell is not automatically a defect. Suppliers are never deleted for good reasons — retention obligations, historic payment records — and writing that down converts an apparent hole into a stated requirement with a retention period attached.

The variant worth knowing is the same matrix with roles instead of processes down the side, which becomes the input to the permissions model. Run it that way and the question "who can delete a match" has an answer before someone in UAT discovers that everybody can.

Gap analysis is the bridge between the as-is and the to-be, and its value is that each row names the work rather than the shortfall.

capability            as-is                     to-be                   gap type      action
--------------------  ------------------------  ----------------------  -----------  ------------------------
Invoice capture       Email to a shared         Supplier portal upload  System +     Build portal. Retain
                      inbox, keyed by hand      plus e-invoicing feed   process      email path for the tail
                                                                                     of small suppliers

Reference quality     Free text typed by the    Structured reference    Data +       Virtual account per
                      customer, 8% unmatched    issued per invoice      external     invoice. Needs the bank.
                                                                                     Longest lead time here

PO matching           Two-way, header only      Three-way at line       System       Extend match to receipt
                                                level incl. receipt                  and line. Depends on
                                                                                     line-level receipt data

Query ownership       Unowned queue             Assigned on creation    Process      No development. Assign
                                                with a 2-day SLA        only         rules and a report

Approval evidence     Email reply               In-system approval      Compliance   Blocking for the audit.
                                                with audit trail                     Do first, not last

Skills                Two clerks can run the    Six can, cross-trained  People      Training and a runbook.
                      matching exception path                                        Not in the project plan
                                                                                     as written

Reporting             Manual spreadsheet, one   Cost per invoice on a    Data         Needs the baseline
                      person, monthly           dashboard, weekly                    measured now, before
                                                                                     the change

NO GAP
Payment run           Weekly BACS run           Unchanged               -            Explicitly out of scope.
                                                                                     Caps the achievable
                                                                                     cycle time at ~5 days

The gap-type column is the point of the table. Only three of these rows are software, and the two cheapest wins — query ownership and reporting — need no development at all. A gap analysis whose every row is a system change has usually been produced by asking a delivery team rather than by examining the process.

The people row is the one that gets cut from plans and then causes the go-live to fail. A to-be process that only two people can operate has not reduced risk, it has automated around a bottleneck while leaving it in place, and training, runbooks and cross-cover are requirements with cost and lead time like any other.

The external dependency in row two deserves separate treatment because it has the longest lead time and the least control. Sequencing work by dependency lead time rather than by business priority is how a project avoids finishing everything except the one thing that unblocks the benefit.

The "no gap" row is the discipline that keeps the analysis honest. Recording that the payment run is unchanged, and that it therefore caps the achievable cycle time, prevents a benefit case from claiming an improvement the process cannot deliver — which is the kind of claim that gets discovered at the benefits review rather than at design time.

Power against interest, with a named strategy per quadrant, because the grid is useless as a classification exercise alone.

                    HIGH INTEREST                     LOW INTEREST
                    ------------------------------    ------------------------------
HIGH POWER          MANAGE CLOSELY                    KEEP SATISFIED
                    Finance director (sponsor)        Group CIO
                    Head of accounts payable          Data protection officer
                    External auditor                  Procurement director

                    Strategy: co-author. They see     Strategy: no surprises, low
                    drafts before anyone else, and     volume. One page a month, and
                    they decide the trades. Weekly     an early warning of anything
                    contact. Their objection is a      touching their domain. They
                    decision, not feedback.           become blockers only when
                                                       something reaches them late

LOW POWER           KEEP INFORMED                     MONITOR
                    AP clerks, 11 people              Facilities
                    Supplier relationship managers     Internal comms
                    Service desk                       Two suppliers on legacy EDI

                    Strategy: the richest source of    Strategy: a distribution list
                    requirements and the people who    and a periodic check that
                    live with the result. Involve in   nothing has changed. Re-run
                    elicitation, prototypes and UAT.   the grid at each phase, since
                    Cheapest way to lose the project   this quadrant is where the
                    is to design without them          surprises come from

RECLASSIFICATIONS MADE, AND WHY
  Data protection officer  monitor -> keep satisfied, once supplier bank
    details entered scope. Low interest until the day they have veto.
  AP clerks  keep informed, but they hold the only accurate account of
    the exception process. Low positional power, high informational
    power - the grid does not capture that, so note it separately.
  External auditor  high power and high interest, and not employed by
    us. Cannot be managed, only satisfied with evidence.

The grid earns its place only because each cell contains a verb. Sorting stakeholders into four boxes and stopping is the version that appears in documents and changes nothing; the useful artefact says what contact each group gets, at what frequency, and what their objection means.

The reclassification note is what makes it a live tool. Power and interest move with the phase — a data protection officer is indifferent until personal or financial data appears in scope, and then holds a veto — so a grid drawn at initiation and never revisited is a snapshot of a situation that no longer exists.

The gap in the model is worth volunteering before an interviewer finds it. Two axes cannot express informational power, which is the clerks' position exactly: no authority and the only accurate knowledge of the process. Treating them as "keep informed" in the low-power sense is how a project ends up with a design validated by managers and rejected by the people who use it.

The auditor row makes the strategy concrete. Some stakeholders cannot be influenced at all, so the only available move is to produce evidence in the form they require, early enough for a finding to be avoidable rather than reported.

One row per decision or deliverable, one accountable person per row, and the disputes appear immediately.

R responsible, does the work   A accountable, one only, owns the outcome
C consulted, before the fact   I informed, after the fact

                             Sponsor  Prod   BA    Tech   QA   AP    DPO
                             (Fin     owner        lead        head
                              dir)
---------------------------  -------  -----  ----  -----  ---  ----  ---
Business case and benefits   A        C      R     I      -    C     -
Scope and priority           A        R      C     C      -    C     I
Requirements and criteria    I        A      R     C      C    C     C
Non-functional requirements  I        C      R     A      C    I     C
Data protection assessment   I        C      R     C      -    I     A
Solution design              -        I      C     A/R    C    -     C
Test strategy and plan       -        I      C     C      A/R  I     -
UAT execution                I        C      R     I      C    A     -
Go-live decision             A        R      C     C      C    C     C
Benefits measurement         A        C      R     -      -    C     -

WHAT THIS EXPOSED IN THE REVIEW
  1  Two people believed they owned the go-live decision. Resolved to
     the sponsor, with the product owner recommending. Ten minutes of
     awkwardness now, against an argument on the night.
  2  UAT execution: the BA does the work, the AP head is accountable
     for the verdict. Previously the BA was implicitly both, which is
     why the last project's sign-off meant nothing.
  3  The DPO was originally I on the assessment they are legally
     accountable for. Corrected to A.
  4  Requirements had three Cs and no A until the product owner took
     it. A row with no A is where requirements churn comes from.
  5  QA is C rather than R on acceptance criteria, deliberately: they
     review for testability, they do not author the rules.

The single-A rule is the whole mechanism. Two accountable people means neither is, and the failure surfaces at exactly the wrong moment — the night of the go-live, or in a dispute about whether sign-off was given. Every genuinely useful RACI conversation I have sat in produced at least one row where two people were surprised.

The distinction between R and A on UAT is the row worth understanding in detail. An analyst can organise the testing, write the scripts and chase the defects, and still must not be the person who declares the business satisfied, because the analyst does not carry the consequence of accepting something unfit. Collapsing those two roles is why sign-offs become rituals.

Row three is the compliance pattern in general. Where accountability is assigned by law or regulation rather than by the project, the RACI must follow the obligation, and a project that puts a regulator-facing role in the informed column has created an exposure rather than a process.

The failure mode of the technique is a matrix with a C in every cell, which is how a delivery becomes unable to decide anything. Consultation has a cost measured in elapsed time, so the useful question about each C is what would change if that person were merely informed — and if the answer is nothing, downgrade it.

The accumulation of small additions that were each individually reasonable and were never priced. It is rarely a single large demand, which would be visible and would be refused; it is the field added in a review, the extra report agreed in a corridor, the edge case absorbed because it seemed cheap, and the total is a project that is late for reasons nobody can point to. That framing matters because it identifies the real defect: not the requests, which are inevitable and often right, but the absence of a moment where each one is costed against what it displaces. Distinguish it from scope discovery, which is analysis working correctly — finding a genuine requirement that was always needed and was missed — and which needs a re-baseline rather than a refusal.

Change control is not a defence against change; it is the mechanism that makes a change a decision rather than a drift.

flowchart TD
    A[Request raised<br/>by anyone, in one place] --> B[Analyst assesses<br/>need, alternatives, which<br/>requirement level is affected]
    B --> C{Is this new scope or a<br/>defect in the baseline}
    C -->|defect in analysis| D[Re-baseline<br/>no negotiation, record<br/>the miss and the cause]
    C -->|new scope| E[Price it<br/>effort, risk, and what<br/>it displaces]
    E --> F{Within the delegated<br/>authority of the owner}
    F -->|yes| G[Owner decides<br/>same week, recorded]
    F -->|no| H[Sponsor decides<br/>with the trade stated]

The branch at the top is the part most processes get wrong. A requirement that was always necessary and was missed by the analysis is not a change request, and processing it as one lets the analysis failure be recorded as a stakeholder's change of mind — which corrupts both the metrics and the learning. Separating the two is uncomfortable precisely because it makes the analyst's misses visible.

Pricing before deciding is the second load-bearing step. A request costed as "two days, and it displaces the CSV export" can be approved in a minute; the same request presented as a yes-or-no question generates a meeting and an escalation. This is the same move as pricing a stakeholder's request rather than refusing it, applied to a process.

Delegated authority is what stops the process from becoming the bottleneck it is accused of being. If every change goes to a sponsor, the practical outcome is that people route around the process entirely and the baseline quietly stops describing what is being built. A stated threshold — anything under a few days, within the agreed budget and not touching a business requirement, is the owner's call — keeps the small decisions fast and the large ones visible.

What the diagram cannot show is the cultural condition. Change control works only where saying no is possible; where every request is approved, the process is theatre that adds latency and records the overrun in more detail.

An assumption is something you have decided to treat as true without having verified it, and it is a risk with a different name — if it is false, some part of the analysis is wrong. A constraint is a boundary you have been given and cannot change: a fixed regulatory date, an existing system that must be integrated with, a budget, a technology standard, a language obligation. The reason to keep them separate is that they require opposite handling. An assumption should be tested, has an owner and a date by which it will be confirmed, and its falsification triggers a review. A constraint is designed within and does not get an action to resolve it. Conflating them produces registers full of assumptions nobody will ever test and constraints somebody keeps trying to remove.

By following the artefacts rather than the organisation chart. Trace the data — who receives an extract from this system, who reports on it, whose month-end depends on a field you are changing. Trace the process forwards and backwards past the boundary you were given, because the step before and after your scope usually belongs to someone who has not been consulted. Read the interfaces, the support queues and the last audit report. Ask every stakeholder who else is affected and who will be annoyed. The groups most often missed are the ones with no representative in the project: operations and support, who inherit the result; downstream reporting consumers; and the external parties — suppliers, partners, regulators — whose behaviour the change quietly requires.

Three things: the decision when priorities conflict, the authority to make another department cooperate, and a stated business objective with a number attached. Those are the things no amount of analysis substitutes for. Without an engaged sponsor the visible symptoms are consistent — priority disputes escalate and return unresolved, other departments deprioritise your requests without consequence, and the scope grows because nobody with standing is willing to refuse anything. The analyst's failure mode in that situation is to absorb the vacuum by making the decisions informally, which works for a while and then collapses when a decision is challenged by someone senior. The better move is to make the absence explicit and escalate the lack of a decider as the risk it is.

Every prioritisation exercise arrives here, and the technique is worthless until the constraint is made numeric.

AS SUBMITTED BY THE BUSINESS
  Must    Portal upload, e-invoicing feed, three-way match, query SLA
          report, approval audit trail, supplier self-service, dashboard,
          CSV export, mobile approval, 22 months of migrated history
  Should  -
  Could   -
  Won't   -

  Ten Musts, zero of anything else. This is not a priority order, it is
  a restatement of the requirements list.

FORCING THE TRADE - step 1: state the capacity
  Available: 14 developer-weeks before the audit date. Nothing about
  the list changes that number.

FORCING THE TRADE - step 2: define Must against a consequence
  A Must is something without which the release cannot go live at all -
  it is illegal, unsafe, or the process physically cannot run. If the
  answer to "what happens if this is not there on day one" is anything
  other than "we do not go live", it is not a Must.

FORCING THE TRADE - step 3: re-sort with cost attached
  item                    est.  what happens without it on day one
  ----------------------  ----  --------------------------------------
  Approval audit trail      3   Audit finding. MUST
  Three-way match           4   Core process cannot run. MUST
  Portal upload             3   Email path still works. SHOULD
  Query SLA report          1   Manual for a month. SHOULD
  Migrated history 22mo     4   6 months covers the audit. SHOULD,
                                 reduced to 6 months = 1 week
  E-invoicing feed          3   Bank dependency unresolved anyway. COULD
  Dashboard                 2   Spreadsheet continues. COULD
  CSV export                1   COULD
  Supplier self-service     5   WON'T this release
  Mobile approval           2   WON'T this release

  Must total       7 weeks of 14        <- the rule that makes it work
  Should total     5 weeks  (fits)
  Could            3 weeks  (does not fit. Deliberately.)

THE RULE
  Musts may not exceed about 60% of capacity. The remainder is the
  buffer that absorbs the estimate being wrong. A plan where Musts are
  100% of capacity has no priority order at all, because the first
  overrun forces an unmanaged cut under time pressure.

The step that actually changes behaviour is the second one. "Must" is meaningless as an expression of importance, because everything on a requirements list is important to whoever asked for it; defining it by a consequence — we do not go live — converts an argument about enthusiasm into a question of fact that the business can answer.

The capacity number has to come first and has to be someone else's. Presenting the constraint as arithmetic rather than as the analyst's opinion is what stops the conversation becoming a negotiation about whether the estimate is pessimistic. Fourteen weeks against thirty of asks is not a disagreement, it is a subtraction.

The sixty per cent rule is the part candidates never mention and it is the most practical thing in the method. Musts consuming the entire capacity means the plan has no contingency, so the first bad estimate produces a panic descope with no prior thinking behind it — which is precisely the situation prioritisation existed to prevent.

Two refinements worth having ready. The migrated-history row was not dropped, it was reduced — descoping a requirement's extent rather than its existence is the move that resolves most of these standoffs. And "Won't" must be recorded rather than deleted, because a stakeholder whose item silently disappears raises it again in six weeks, whereas one whose item is written down as a decision for this release usually accepts it.

The matrix's job is to make orphans and gaps visible, in both directions.

objective                    requirement                      story    test        status
---------------------------  -------------------------------  -------  ----------  -----------
BO-1  Cost per invoice       FR-04 three-way match at line    S-112    TC-21..29   passed
      £14 -> under £5        FR-05 auto-authorise within      S-113    TC-30..33   passed
                                    tolerance
                             NFR-14 match within 2s at p95    S-118    LT-07       failed,
                                                                                    3.1s
                             FR-09 exception queue with       S-121    TC-40..44   passed
                                    assigned owner

BO-2  Evidence every         FR-11 in-system approval with    S-115    TC-50..56   passed
      approval for audit            immutable audit entry
                             FR-12 approval limits by role    S-116    TC-57..61   passed
                             NFR-18 audit entries retained    S-119    TC-62       not run
                                    7 years

BO-3  Late payment charges   FR-14 due-date alert at T-5      S-122    TC-70..72   passed
      to zero                FR-15 payment run includes       S-123    TC-73..75   passed
                                    all approved

ORPHANS - requirement with no objective above it
  FR-21  supplier logo on the portal header.  No objective. Added in a
         review in May. Cost 2 days. This is the audit trail of scope
         creep, and it is why the matrix is worth maintaining.

GAPS - objective with no requirement below it
  BO-4   "reduce supplier payment queries by half" has no requirement
         at all. Nobody noticed until this matrix was built. Either
         drop the objective or fund the work - it cannot stay.

COVERAGE - requirement with no test
  NFR-18 has one test and it has not been run. A seven-year retention
         requirement verified by nothing is the kind of gap that is
         found by an auditor rather than by QA.

Read the matrix in both directions, because each direction answers a different question. Downward from an objective it asks whether the thing the business is paying for is actually covered by anything, and BO-4 shows what that finds. Upward from a requirement it asks why this is being built at all, and FR-21 shows what that finds.

The failed row is the most immediately useful cell in the table. A performance requirement missing its target at 3.1 seconds against 2.0 is now visibly attached to the objective it protects, so the decision about whether to accept it is a business conversation about cost per invoice rather than a technical argument about a threshold.

The orphan section is the reason to build the matrix during delivery rather than at the end. Two days spent on a supplier logo is trivial in isolation and it is the shape of every overrun, and the matrix is the only artefact that makes the pattern visible while there is still time to stop it.

The honest cost is maintenance. A matrix kept by hand across hundreds of requirements decays quickly and a decayed matrix is worse than none, because it is trusted. The pragmatic version traces objectives to requirements to tests through the tooling the team already uses, and accepts coarser granularity in exchange for being accurate.

Three things that matter during delivery rather than after it. It answers "why are we building this", so a requirement with nothing above it can be challenged while it is still cheap to remove. It answers "is this objective actually covered", which is how you discover that the benefit everyone signed up to has no work attached. And it answers impact: when a requirement changes, traceability tells you which stories, tests, interfaces and processes move with it, which is the difference between a scoped change and a surprise in regression. The audit use is real and secondary. In regulated work you must additionally evidence that every requirement was verified, which is why traceability there extends to test results and to the approval record.

By slicing through the layers rather than along them. A story that delivers only the database table, or only the screen, is a task disguised as a story: it cannot be demonstrated, cannot be tested end to end and produces no feedback. The slices that work are by business rule, by variation of the same journey, by data subset, by channel, or by taking the simplest complete path first and adding sophistication afterwards — one supplier type before all of them, manual override before automation, happy path before exception handling. The test to apply to each candidate slice is whether you could put it in front of a user and learn something. If not, it is a technical dependency to be sequenced rather than a story to be prioritised.

Work one step ahead and one step behind. Ahead means the next iteration's stories are refined enough to start: rules confirmed, criteria written, dependencies identified, the open questions asked of stakeholders before the team needs the answer. Behind means supporting what is in progress — answering the questions that arise mid-implementation, reviewing what has been built against the intent, and being present when the tester finds a case nobody specified. In between sits the work that has no ceremony: chasing a decision from a stakeholder who is on leave, profiling data to settle an argument, and updating the process model that the last three stories have quietly invalidated. The failure mode is refining so far ahead that the analysis is stale by the time it is built.

Assess it, do not absorb it. First establish whether it is genuinely urgent — which usually means a live customer impact, a regulatory date or a blocked dependency — because most mid-sprint arrivals are merely recent. Then price it and name what it displaces, since sprint capacity is fixed and the only honest options are to swap something out, to shorten the increment, or to take it next. Then route it through whoever owns priority rather than deciding yourself, and make the decision visible so the team is not quietly absorbing extra work. The pattern to watch is frequency: one urgent arrival is delivery, a steady stream is a signal that either the planning horizon is wrong or someone is bypassing the priority process.

A short agreed checklist that a story must satisfy before a team commits to it: the value and beneficiary stated, acceptance criteria written, dependencies identified, non-functional expectations known, test data available, sized by the team. Its purpose is to prevent the commonest cause of an iteration failing — starting work whose rules were never settled, and discovering mid-sprint that a decision is needed from someone unavailable. The failure mode is turning it into a gate: a checklist so long that stories queue in analysis, which reintroduces a waterfall stage under a new name and pushes detail to be settled in the abstract rather than in conversation. The calibration is that it should catch missing decisions, not enforce completeness of documentation.

Verification asks whether the thing was built as specified; validation asks whether the thing specified was the right thing. They are different questions with different evidence and different people. Verification is satisfied by tests against acceptance criteria and can be entirely automated. Validation requires someone who owns the business outcome to look at working software, or at a prototype, or at a process walkthrough, and confirm that it solves the problem. The distinction is the whole reason a project can pass every test and still fail: a perfectly verified implementation of a misunderstood requirement is the most expensive artefact in software. Validating early and repeatedly, on something concrete, is the only reliable defence, and it is what an analyst's reviews and prototypes are for.

It exists to answer whether the business can do its work with this, using real scenarios and real data, and it is deliberately not a repeat of system testing. The distinction matters because UAT executed as a re-run of the functional test pack finds nothing and consumes the users' goodwill; UAT run as "process a day's worth of your actual invoices, including the awkward ones" finds the gaps that matter. Sign-off belongs to the business owner of the process being changed — the person who carries the consequence of it not working — and not to the analyst, the project manager or the test lead. That rule is often broken for convenience, and the result is a signature that means nobody in the operation examined the thing.

A decision that exists only in a meeting did not happen, and the cheapest artefact in analysis is the one that records it in a fixed shape.

DECISION D-017   Duplicate invoice detection rule

Date          14 Jul 2026
Status        Agreed. Supersedes D-009.
Decision      An invoice is a duplicate if supplier_id, supplier_ref and
              gross amount all match an existing invoice in any status
              other than Cancelled. Matches are blocked and queued for
              review, not rejected outright.
Decided by    Head of accounts payable, accountable. Present: BA,
              tech lead, financial controller.

Context       8% of invoices arrive with an unreliable reference, so an
              exact-match rule on supplier_ref alone both misses real
              duplicates and blocks legitimate re-issues. Duplicate
              payments cost roughly £40k last year across 11 incidents.

Options considered
  A  supplier_ref alone           Rejected. Misses ~30% of duplicates
                                   found in the sample of 1,200.
  B  ref + amount, block          CHOSEN. Caught 11 of 11 in the sample
                                   with 4 false positives, all reviewable.
  C  ref + amount + date, block   Rejected. Missed 3 of 11, because
                                   duplicates are often re-sent weeks later.
  D  fuzzy match on all fields    Rejected for now. Better recall, no
                                   explainable reason for a block, which
                                   the audit requirement needs.

Consequences
  + Blocks the loss with an explainable rule an auditor can follow.
  - Roughly 4 false positives per 1,200 invoices need manual release.
    A new review step with an owner, ~10 minutes a day.
  - Cancelled invoices are excluded, so a cancel-and-reissue cycle
    is not blocked. This is deliberate and is the residual risk.

Assumptions   A-07 supplier_ref is populated on over 99% of invoices.
              Verified by profiling, 22 Jun.
Revisit if    False positives exceed 1% of volume, or a duplicate is
              paid despite the rule.
Traces to     BO-1 cost per invoice, FR-17, TC-88..92

The two fields that make this worth writing are the options and the consequences. A record of what was decided lets someone comply with it; a record of what was rejected and why prevents the same argument being reopened in four months by someone who was not in the room, which is the actual recurring cost.

The negative consequences are stated as plainly as the positive ones. Ten minutes a day of manual review and an accepted residual risk around cancellations are the price of the decision, and writing them down is what makes it possible later to tell a considered trade from an oversight. A decision log containing only benefits is a marketing document.

Superseding rather than editing is a small discipline with a large effect. D-009 still exists and still records what was believed in April, which means the project's reasoning is reconstructable — and when the rule surprises someone in production, the question "why is it like this" has an answer.

The revisit condition is the part almost nobody writes and it is what turns a decision into something maintainable. Naming the observation that would falsify the choice means the rule gets reviewed on evidence rather than either surviving forever or being changed on the first complaint.

Two stakeholders, both right, and the analyst's job is to make the choice explicit rather than to pick a winner privately.

THE CONFLICT
  Head of accounts payable   "Block any invoice without a matching PO.
                              No-PO invoices are how we overpay."
  Procurement director       "Do not block them. 22% of our spend is
                              low-value services with no PO, and blocking
                              means suppliers stop delivering."

  Both statements are true. This is not a misunderstanding to be
  cleared up, it is a genuine trade between control and throughput,
  and it cannot be resolved by more elicitation.

WHAT THE DATA SAYS
  22% of invoices have no PO. Of those, 91% are under £250, from 40
  suppliers on standing arrangements. The remaining 9% average £3,100
  and account for 8 of last year's 11 overpayment incidents.

OPTION 1  Block all no-PO invoices
  satisfies AP fully, procurement not at all
  cost      ~2,900 invoices a year into a manual queue. At 10 minutes
            each that is ~60 days of clerk time, and it does not exist
            in the budget
  risk      service suppliers stop delivering. Named risk raised by
            procurement, and they have precedent from 2023

OPTION 2  Block none, report after the fact
  satisfies procurement fully, AP not at all
  cost      the overpayment exposure continues, roughly £40k a year
  risk      audit finding on preventative controls. The auditor has
            already raised this once

OPTION 3  Threshold. Auto-approve no-PO invoices under £250 from an
          approved supplier list, block the rest
  satisfies both substantially
  cost      an approved-supplier list to build and maintain, ~40
            entries, plus an owner for it. 3 days of build
  risk      the list decays. Mitigation: quarterly review, and any
            supplier unused for 12 months drops off automatically
  covers    91% of the volume automatically, and 8 of the 11 known
            incidents fall in the blocked band. RECOMMENDED

OPTION 4  Retrospective sampling. Approve all, audit 10% monthly
  satisfies procurement fully, AP partially
  cost      cheapest to build. An auditor's time monthly
  risk      detective rather than preventative, so the money has
            already left. Acceptable to the auditor only with a
            recovery process, which we do not have

WHAT I NEED
  A decision between 3 and 4 from the finance director by 25 Jul,
  because the match rules are built in the sprint starting 28 Jul.
  Both stakeholders have seen this document and neither has changed
  their stated position, which is expected and fine.

The move that resolves this is finding the number. Both stakeholders were arguing from anecdote, and profiling the data showed the conflict was much smaller than either believed: ninety-one per cent of the disputed volume is low-value and low-risk, so a threshold satisfies most of both positions. A large share of apparently irreconcilable requirements dissolve this way, and the analyst is the only person likely to go and look.

Escalating with a recommendation rather than with the conflict is the second essential move. A sponsor handed a disagreement can only convene a meeting; a sponsor handed four priced options and a recommendation can decide, and the decision arrives in days rather than weeks. Withholding the recommendation to appear neutral makes the outcome worse — the analyst holds information about relative risk that neither stakeholder has.

Option 4 is in the list because someone will propose it. Pricing it honestly, including the detail that a detective control needs a recovery process the organisation does not have, is far more persuasive than dismissing it when it is raised from the floor.

The last block is what most option papers omit. A named decider, a date, and the delivery consequence of not deciding — because the default outcome of an undecided trade is whatever the developer implements, and that is the worst of the four.

Diagnose before managing, because the four causes need different responses. If they never understood what they were agreeing to, the artefacts are the problem and a prototype or a walkthrough will settle more than another document. If their environment genuinely keeps changing — a new regulation, a reorganisation — this is not indecision and the response is a shorter delivery cadence. If they are relaying other people's views, the actual decider has not been in the room and the fix is to find them. If it is genuine ambivalence, structure forces closure: write the decision down with options and consequences, name the date after which it becomes a change request with a price, and record what they agreed. The recurring mistake is escalating before knowing which of the four you are facing.

Triage before anything else, because the response differs entirely by cause. If the software does not match the criteria, it is a defect and goes back to the team. If the software matches the criteria and the business still cannot do its work, the requirement was wrong and that is an analysis failure, needing a decision about scope rather than a bug fix. If it is a case nobody specified, the question is whether it was always in scope or is new. And if the tester is describing a preference rather than a shortfall, it is a change request. Recording that split honestly is the part that requires character, because the second category is your own error and the temptation to file it as a defect is considerable — and doing so removes the only chance to learn from it.

It is a structured review in which the requirement or model is read aloud to the people who know the domain, with the reviewer's job being to look for ambiguity, contradiction, missing cases and untestable statements rather than to approve. It works because a requirement defect found in review costs a conversation, the same defect found in UAT costs a rework cycle, and found in production it costs an incident and a remediation. The technique's own failure mode is a review meeting where a document is presented and everyone nods, which happens whenever the material was not circulated beforehand or the reviewers have no defined lens. The sharpening move is to give each reviewer a specific question — the tester looks for testability, operations for supportability, the clerk for the exception cases.

Whether you have a method for reducing ambiguity, or whether you either guess and build or freeze and escalate. A strong answer is specific about what exactly was unclear — the rule, the beneficiary, the boundary, the volume — and then describes the cheapest available way of resolving it: profiling the data, finding the document, running a walkthrough with a prototype, or asking one named person a narrow question. It states which parts you settled, which you recorded as assumptions with owners and dates, and which you deliberately deferred because the decision was not yet needed. It ends with what actually happened, including whether an assumption turned out to be wrong. A weak answer says you arranged a workshop with the stakeholders and clarified the requirements, which names a ceremony rather than a method and could describe any outcome including failure.

Because it implies the requirements already exist and merely need collecting, which is almost never true. What exists is a set of problems, some solutions people have prematurely settled on, several conflicting accounts of the current process, and a body of constraints nobody has articulated. Turning that into requirements is analysis, elicitation and negotiation, and the word "gather" disclaims all of it. It also predicts the failure mode of the person who says it: requirements transcribed rather than examined, so the underlying need is never tested and the cheaper option is never found. The stronger formulation names the work — establishing the problem, resolving the disagreements, and specifying it precisely enough to build and to test.

Because a signature is evidence that a process was followed, not that anyone understood what they were agreeing to. If a stakeholder signs a hundred-page specification, the sign-off transfers formal responsibility while leaving the real risk exactly where it was, and when the delivered system does not fit the work, the organisation still has the problem and the analyst still failed. The professional position is that sign-off is a milestone rather than a defence, and the obligations that make it meaningful are the analyst's: material short enough to be read, walkthroughs so that the content is heard rather than skimmed, validation against something concrete, and specific attention to the person who signs everything without comment, since they are the highest risk in the process.

That you may have produced artefacts without changing any outcome. Business analysis has a characteristic failure mode of visible productivity — a requirements catalogue, a process model, a traceability matrix, all present and none load-bearing — and answers composed entirely of deliverables are indistinguishable from it. The fix is to make each artefact the middle of a sentence rather than the end: I profiled the data and found eight per cent of invoices had no usable reference, which changed the solution from a matching screen to a structured reference and removed the recurring cost. The document is mentioned in passing and the decision it changed is the point. Interviewers are listening for a decision that went differently because of your work, and if no example contains one, the answer has described process compliance.

"Tell me about a requirement you were given that turned out to be the wrong solution, and what you did about it." It resists preparation because it requires having challenged a stakeholder rather than served one. A strong answer states what was asked for, what made you doubt it — usually a specific piece of evidence, a number from the data, an observation of the actual process — how you tested that doubt without simply refusing the request, who you had to persuade and what their objection was, what was built instead, and what it saved. It is comfortable saying that the original request was reasonable given what its author knew, because disparaging the stakeholder is itself a signal. A weak answer either has no such example, which suggests every requirement was transcribed, or describes overruling a stakeholder on the strength of the analyst's own opinion with no evidence and no persuasion in the story. The underlying test is whether you treat a requirement as an instruction or as a hypothesis about a need.