Requirements gathering that survives contact with delivery.

A requirement is a statement of what a system must do or a quality it must have, agreed by the people who need it and testable by the people who build it. Every word in that sentence does work. Not agreed? You have an opinion. Not testable? You have a hope. No named person behind it? You have a rumour with a reference number.

The failure modes are boringly consistent. Requirements captured as solutions ("we need a dashboard") rather than needs ("the operations lead cannot see which orders are stuck"). The official process documented while the real one, held together with a shared spreadsheet, goes unrecorded. Non-functional requirements skipped entirely because nobody owns them. And the quiet killer: requirements with no source, so when priorities collide months later, nobody can weigh one against another because nobody knows where either came from.

Everything below is aimed at those failure modes. Elicitation techniques that surface the real process. Questions that produce numbers, not adjectives. Workshops that resolve conflict instead of averaging it. And traceability from day one, because the cheapest moment to record where a requirement came from is the moment it is said.

A requirements set that contains only requirements is lying about its own certainty. At any point in discovery you actually hold three kinds of statement: things you know, things you are assuming, and things you know you do not know. Mature teams keep all three visible, because the second and third categories are where the risk lives.

An assumption is a statement you are treating as true without confirmation. "Claims volume is roughly 200 a day." "Finance can approve within 48 hours." Write each one down with who asserted it, how confident they were, and what breaks if it turns out false. The discipline sounds bureaucratic and takes about a minute per assumption. The alternative is discovering at integration testing that the 200-a-day figure was a guess made in a corridor, and the real month-end number is 4,000.

An open question is sharper: a named unknown with an owner and a date. "Do we need to support paper claims at launch? Owner: Sarah. Needed by: end of March." A well-run open-questions list is the heartbeat of discovery. Questions get opened in one meeting, assigned, answered in a later one, and closed with the answer recorded. If your list only ever grows, discovery is stalling. If it is empty, you are not asking hard enough questions.

Mark statistics with their provenance too. A figure someone measured last week and a figure someone remembered from 2023 look identical in a document unless you tag them: verified, estimate, or to be confirmed. This is the single cheapest quality practice in requirements work, and the one most often skipped.

Traceability answers two directions of question. Backwards: where did this requirement come from? Which stakeholder, which conversation, which business objective? Forwards: what happened to it? Which stories implement it, which tests verify it, which release shipped it?

Backwards traceability is what settles arguments. Nine months into a project, requirement R-042 collides with a new constraint and something has to give. If R-042 traces to "Priya, claims operations lead, discovery workshop on 4 March, because manual re-keying causes roughly 30 errors a month", you know exactly who to consult and what is at stake. If it traces to nothing, the conversation becomes archaeology, and archaeology at delivery prices.

Forwards traceability is what makes scope honest. When every requirement links to the backlog items that implement it, "are we done?" becomes a query instead of a debate, and a cut story visibly orphans the requirement it served. In regulated environments this is not optional: auditors ask precisely these questions, in both directions.

The classic tool is the requirements traceability matrix, a table mapping each requirement to its source on one side and its delivery items and tests on the other. Nobody enjoys maintaining one by hand, which is exactly why the modern move is to capture the source link at the moment of extraction. When requirements are generated from a recorded conversation with the verbatim quote attached, backwards traceability is free, because the evidence never got separated from the requirement in the first place.

A requirement states what must be true. Acceptance criteria state how you will know it is true, in scenarios concrete enough to test. They are the handover point where analysis becomes delivery, and where vague requirements go to be found out.

The Given/When/Then form (Gherkin) earns its popularity because it forces three decisions per scenario: the starting state, the trigger, and the observable outcome. Take the requirement "the system must recalculate VAT on mid-cycle plan upgrades". As acceptance criteria:

Notice what writing the criteria did. Scenario 2 surfaced a question the requirement never asked (which address governs the rate?), and scenario 3 forced a decision about failure behaviour. That is the real value: acceptance criteria are an elicitation technique in disguise. If you cannot write three concrete scenarios for a requirement, the requirement is not ready, and better to learn that now than in sprint review.

Two rules keep criteria honest. Every scenario must be observable, meaning a tester can verify it without reading the code. And the unhappy paths belong in the criteria, not in a tester's imagination. A requirement with only happy-path criteria is roughly half a requirement.

The 90-page BRD deserved its death. It froze a moving picture, took six weeks to write, and was read carefully by exactly one person: its author. But the reaction against it went too far when teams decided the backlog is the only artefact. A backlog is a list of work. It does not tell a new joiner why the project exists, what is out of scope, or which constraint everyone agreed to live with in February.

What still needs a home, whatever you call the document that holds it:

There is a version of this section that promises AI will do your requirements for you. It is wrong, and you should distrust anyone selling it. Here is what extraction from conversation actually does well, and what still needs a human analyst.

What it does well: the write-up. A two-hour workshop produces maybe twenty candidate requirements, a dozen decisions, a handful of assumptions and a stack of open questions, scattered across the conversation in half-sentences. Extracting those into structured, testable drafts with the verbatim quote attached is exactly the kind of high-volume, pattern-matching work machines are good at, and it removes the two days of write-up that usually stand between a workshop and its outputs. Done properly, every draft carries its evidence, so the reviewer can check the source in seconds. That is the model behind transcript to requirements extraction: the machine drafts, the human reviews, nothing ships unreviewed.

What still needs a human: everything upstream and downstream of the transcript. Deciding who to interview. Noticing that the operations lead went quiet when deadlines came up. Recognising that two stakeholders are describing different processes and convening the workshop to resolve it. Judging whether "we need it to be fast" means 2 seconds or 200 milliseconds in this domain. Weighing a requirement against a budget. No transcript contains what was not said, and what was not said is frequently the finding.

The practical division of labour: humans run the conversations and make the judgements, the machine turns the conversations into structured drafts with provenance, and humans review before anything becomes a commitment. Teams running discovery workshops this way spend their hours on elicitation and analysis instead of typing, which was always the point.