Most Business Analysts write requirements. Senior BAs build the system that writes them.

Three weeks into UAT on a transformation programme, a defect comes back.

The system is doing exactly what the requirement says. The requirement is doing exactly what the BRD specified. The BRD signed off cleanly. And yet the operator is in the test environment saying this isn't what we agreed — and they're right.

If you've led a BA practice for more than a few years, you know this scene. You know what comes next. Someone pulls the workshop notes from six months ago and the original decision is there in plain language, exactly as it should be. Between the workshop and the build, the decision drifted — quietly, in standups, in a vendor's response to a clarification, in a "minor scope adjustment" that the new sponsor approved without realising it overturned the original framing. By the time UAT finds it, the cost of clarity is twenty times what it would have been at the gate.

This is the work most BA practices are not yet built to do.

The factory we're stuck in

Most organisations that say they have a BA practice actually have a BA team — a collection of skilled people each producing documents one project at a time. The senior BA on Project A produces brilliant work. The mid-level BA on Project B produces functional work. The contractor on Project C produces whatever the deadline allows. None of them are using the same templates. None of them define "requirement" the same way. None of them trace requirements to decisions the same way — if they trace them at all.

When the senior BA goes on leave for three weeks, the quality bar moves with her. When she leaves the organisation, the quality bar leaves too. The "practice" was the person. The artefacts she produced are still in SharePoint, but no-one knows which ones were the standard and which ones were one-off work for one project.

This is the documentation factory. It runs on heroes. It does not compound.

The trap is that it looks fine when you're inside it. UAT defects are blamed on testing rigour. Stakeholder pushback at sign-off is blamed on engagement. Decisions drift, but everyone has a reasonable explanation for each individual drift. The cost is invisible until you sit a senior BA next to a mid-level BA and ask them to describe what a functional requirement is — and you hear two different definitions.

Everything that follows in the guide assumes you've seen this. If you haven't, you don't need a field guide. You need a different problem.

The shift

The senior move — and the thesis the guide is built around — is this:

The BA's job is not to write the requirements. The BA's job is to build the system inside which the right requirements get written — by stakeholders, by AI, by the BA when needed — at consistent quality, repeatably, without heroics.

The shift is from author to architect. The output is no longer the requirement; the output is the structure that produces the requirement at quality. Once that structure exists, stakeholders can contribute inside it. Junior BAs can produce senior-level work inside it. AI tooling can be embedded inside it without producing rubbish. The senior BA stops being the bottleneck and starts being the editor.

This is not a methodology change. It's an organising-principle change. Methodologies sit inside the structure. The structure is what doesn't change project to project — the artefacts you always produce, the way you always classify, the way you always trace, the way you always decide what's ready and what's done. Methodology changes by context (waterfall, agile, hybrid, vendor-led). The structure doesn't.

When the structure exists, three things happen at once. Quality stops being a function of who's in the room. Onboarding time for a new BA collapses. And — most importantly — decision integrity becomes possible, because the structure carries the decisions through the project even when the people change.

What's in the guide

The guide names the structure in ten sections plus three preamble pieces. I won't summarise it here — that's what the guide is for — but five threads are worth flagging if you're deciding whether it's worth your time.

The Foundation — seven artefacts. Every project produces the same seven artefacts: Decision Log, Problem Statement, Stakeholder & Decision-rights Map, Service / Process Inventory, Requirements Register, Assumptions & Open Questions, and the Traceability Matrix. The Decision Log is the spine — the thing that survives team changes, sponsor turnover, and the audit two years from now. Every other artefact answers back to it.

Decision Integrity — the three-phase spine. The hardest BA work isn't framing the decision; it's holding the line on it. The guide sets out three phases — pre-delivery, through delivery, post-implementation — each with its own discipline. No silent re-decision in pre-delivery. Decision re-opening, not scope creep through delivery. 30 / 60 / 90-day adoption checkpoints post-implementation. Most practices treat the post-implementation discipline as someone else's problem, which is exactly why the value rarely lands.

Classification & Naming — 15 requirement types, one taxonomy. "The business needs X" is not a requirement type. The guide names fifteen — FUN, BIZ, DAT, INT, WFL, EXC, RPT, PRF, AVL, USB, SEC, CMP, MIG, CFG, AUD — each with a must-have component list, worked examples, and a clear when to use / when to avoid line. The naming convention is opinionated on purpose: a project that uses your taxonomy is a project where the senior BA can walk in cold and read the work.

AI in the practice — three layers, in order. A maturity arc through Generative AI prompts (today), AI-assisted workflows (near-term), and agentic systems (emerging). The guide includes a versioned prompt library — twelve prompts, ready to run inside the requirements stack, with guardrails built in. The order matters: practices that skip to layer three without the foundation in place accelerate the mess, not the practice.

The Operating Rhythm — four cadences. Standards stay alive only if the practice runs them. Fortnightly practice forum. Weekly BA-pair clinics. Monthly standards review. Quarterly library release. The guide doesn't just describe these — it tells you who owns each, what gets reviewed when, and what the failure mode looks like if any one of them lapses.

There's more — dial-ups by context (regulatory, multi-vendor, high-change), dial-ups by industry (eight, calibrated), BABOK alignment for the practice lead who needs to defend the framing internally. But those five threads are the structural backbone.

Who it's for

The guide is written for the person accountable for whether a BA practice produces BA-quality work without depending on individual heroics. That's usually a Lead BA, a Head of Delivery, a CIO who can't keep paying for the same lessons project after project, or a senior BA who's the de facto quality bar and wants the practice to outgrow her.

If you're a project BA whose mid-year review depends on shipping the next BRD on time, the guide will still be useful — but it's not written for you. Project BAs work inside the structure; the guide is about how to build it. Those are different jobs and they need to stay different jobs.

If you're a CFO or COO funding a transformation programme, the parallel volume — The Transformation Leader's Field Guide — is the one you want. Its thesis is the same shape, scaled up: decisions before delivery, the operating model is the deliverable, kill criteria before kickoff.

A note on length

The guide is long. That's a deliberate editorial choice. A working reference earns its length by being the thing you open during real work — when a real decision is in front of you — and finding the question you needed to ask faster than the answer you thought you needed. The right question, asked at the right stage, almost always saves more value than the right answer asked too late.

Read it section by section as the decisions in front of you call for them. The Foundation in §01 is the starting point if you're standing up a practice from scratch. Decision Integrity in §02 is the section to open if your UAT defects are tracing back to upstream drift. Classification in §04 is the one to open if your senior BAs can't agree on what counts as a functional requirement. AI in §09 is the one to open before someone in your org buys an "AI for requirements" tool that creates more problems than it solves.

What I want you to do with it

Two things, both free.

Read the field guide. The full text lives on a single page — long-form, searchable, structured for working reference rather than a one-time read. It's free, it has no email gate, it doesn't ask anything of you.

Take the diagnostic. Twelve questions, ten minutes. Names where your practice actually sits on the four dimensions the guide is built around — and which dimension to address first. Most BA practice leads come out somewhere between Document Factory and Hybrid Practice. The point is not the score; the point is the conversation it starts with the senior BAs around you.

If something in the guide shifts a decision you were about to make — about how your practice runs, about what your BAs are accountable for, about what you stop tolerating — I want to hear about it. Replies are read.

There are three companion volumes in the same series — The Transformation Leader's Field Guide (Vol. II), The ERP Field Guide (Vol. III), and Requirements Engineering (Vol. IV). They share the same editorial spine: decisions before delivery, the operating model is the deliverable, the structure outlasts the people. Each is written for a different accountable role. Pick the one that names your week.