What is a requirements audit? Coverage, drift and a worked example
A requirements audit compares the requirements you signed off with the work that exists: coverage per requirement, drift since the baseline. Not a code scan.
On this page
A requirements audit compares the requirements a team agreed to, frozen at sign-off as a baseline, with the work that actually exists. For each requirement it reports coverage: is there work against it, and is that work done? It also reports drift: requirements whose wording changed, or that were dropped, after sign-off. It does not read source code.
That is the whole idea in one paragraph. The rest of this post explains why teams need it, walks through a worked example of a PRD drifting away from what shipped, shows how it differs from a code scan, and ends with how to run one, by hand or with a tool.
Why "what did we agree to build?" is a hard question
Every team can say how many tasks are open. Very few can say, requirement by requirement, whether the open tasks add up to what was promised. The two facts live in different places. Requirements sit in a PRD, a proposal, a contract or a Notion page written months ago. Work sits in a tracker, broken into issues that were named by whoever picked them up. Nobody links the two, and the gap between them is invisible until a client, a launch or a new hire finds it.
The gap grows in three ways:
- Omission. A requirement was agreed and never turned into work. It is not in the backlog, so no board shows it as late.
- Quiet rewording. A requirement was edited after sign-off, usually to match what was easier to build. The live document now says the build "passes", and the original wording is gone.
- Silent removal. A requirement was deleted. The document is shorter, and nobody decided it should be.
A requirements audit makes all three visible. The glossary entry gives the formal definition; the terms people also use for it are requirements traceability audit and requirements coverage.
The three parts: baseline, coverage, drift
Baseline. A requirements baseline is a frozen, numbered copy of the requirements at the moment they were approved: identifier, wording, priority and acceptance criteria for each. The live document keeps changing; the baseline does not. The baseline entry covers the practice in more depth. Without a baseline there is nothing to audit against, because the only version of the requirements is the one that has already drifted.
Coverage. For each baselined requirement, what is the state of the work behind it? A useful audit distinguishes at least these states:
| State | Meaning | What it usually signals |
|---|---|---|
| No work | Nothing in the tracker points at this requirement | It was agreed and forgotten |
| In progress | Linked work exists and is not finished | On track, or stalled; check dates |
| Work done | Every linked task is complete | Ready to verify against acceptance criteria |
| Dropped since | The requirement was removed from the live document after the baseline | A scope decision, recorded or not |
| Record gone | The requirement record was deleted entirely | Someone cleaned up; was it agreed? |
A requirement whose only tasks were all cancelled has no work, even if three attempts were made, and an honest audit says both things.
Drift. Drift compares the baseline wording with today's. If a requirement's text changed after the freeze, the audit flags it and shows both versions. Reporting coverage against the new wording while claiming to assess the baseline would be misleading, so a good audit always measures against the frozen text and shows the live text next to it.
A worked example: the PRD said one thing, the build did another
Here is a small, realistic case. A four-person team agrees a PRD for a customer portal with fourteen requirements and freezes it as baseline 1 on 2 September. Launch is 30 October. Two weeks before launch, someone runs the audit.
Eleven requirements are in progress or done. Three are not:
- REQ-006, "Customers can export their invoices as CSV and PDF." Coverage: work done. Drift: flagged. The live wording now reads "Customers can export their invoices as CSV." The PDF half was dropped when the developer found the PDF library awkward, and the requirement was edited to match. No one told the customer who asked for PDF.
- REQ-009, "Admins receive an email when a customer disputes an invoice." Coverage: no work. It was agreed, nobody filed an issue, and the backlog has no row for it. Every board was green because the board only knows about issues that exist.
- REQ-013, "Portal supports two languages at launch." Coverage: dropped since. It was removed from the live PRD in week three during a scoping conversation that happened in chat. The decision may have been right; the record of it is a message nobody can find.
None of this would show in a sprint review. REQ-006 was demoed and looked finished. REQ-009 never existed as a task. REQ-013 had quietly stopped being a requirement. The audit turned three invisible gaps into three decisions: file the work for REQ-009, restore or formally renegotiate REQ-006, and write down the REQ-013 decision so baseline 2 carries it.
This is also why the audit should run from records, not from a model's reading of the project. A language model asked "is REQ-009 covered?" will look for something that resembles email notifications and may find a related issue about receipts. Coverage computed from explicit links between requirements and issues gives a plain "no work", which is the answer the team needed.
Requirements audit vs code scan vs code review
People hear "audit" and think of a scanner reading source code. That is a different activity with a different question.
| Requirements audit | Code scan (static analysis) | Code review | |
|---|---|---|---|
| Question | Did we build what we agreed? | Is the code sound? | Is this change good? |
| Input | Baseline requirements and linked work items | Source code | One pull request |
| Reads code | No | Yes | Yes |
| Finds | Omissions, rewording, silent scope removal | Bugs, vulnerabilities, bad patterns | Local errors, design and style problems |
| Misses | Whether done work actually meets the criteria | Promises not in the code at all | Problems across many changes |
| Output | Coverage and drift per requirement | Findings per file or line | Approval or requested changes |
The three do not substitute for each other. A codebase can pass every scan and still be missing the feature a client paid for. A requirements audit can show every requirement covered and still ship a security hole. Teams that care about both run both.
Two cautions keep a requirements audit honest. First, "work done" is not "requirement met". A completed issue proves someone finished a task, not that the result satisfies the acceptance criteria; a person still has to check. Second, the audit is only as good as the links. If issues are not tied to requirements, every requirement reads "no work", which is useless. Linking is the up-front cost, and it is the same cost that makes the audit possible.
How to run a requirements audit by hand
You do not need a tool. You need discipline and a spreadsheet.
- Freeze the baseline. Copy the approved requirements into a sheet with a stable ID per row (REQ-001, REQ-002), the exact wording, priority and acceptance criteria. Date it and record who approved it. Do not edit this sheet again.
- Link work to requirements. In your tracker, give every issue a field or label naming the requirement it serves. New work without a requirement ID is either a bug, a chore or scope creep; decide which.
- Compute coverage. For each REQ row, list its issues and their statuses. Assign a state from the table above. Count the rows with no work first; that list is the audit's main finding.
- Check drift. Put the live requirements document next to the frozen sheet. Mark every row whose wording differs and every row that is missing from the live version.
- Write the decisions. For each gap: file work, renegotiate, or formally drop it. Record the dropped ones with a reason, then freeze baseline 2.
- Repeat at milestones. Before a client review, a launch, an invoice, or a handover. Monthly is enough for most small teams.
The manual version works. Its weakness is step 2: links decay as soon as people are busy, and a sheet nobody updates produces an audit nobody trusts.
How tools do it, and what Atrix does
Several requirements-management tools aimed at regulated industries have done traceability for decades, usually as a matrix of requirements against tests and tasks. They are built for aerospace, medical and automotive teams and priced that way.
For small product teams, the practical version is a tracker that holds requirements and issues in the same place and keeps the links for you. This is what we built into Atrix for our own projects, and it is worth being exact about what it does. The agent's Develop run writes the requirements from a brief; you edit and approve them, and the Audit mode freezes a baseline. From then on, the audit reports the five states above for every baselined requirement, with a drift flag and the live wording when it changed. Every state is computed from rows, not from a model's judgement, so the audit costs no AI runs and gives the same answer twice. Linked GitHub and Vercel projects add repository and deployment signals alongside it.
What it does not do matters just as much. Atrix does not scan code, run static analysis or find vulnerabilities, and the feature page says so. If you need a code audit, that is a different service, and on our side it is the agency's human auditors, not the product. If you need to know whether the build matches the agreement, that is the product's job.
FAQ
What is the difference between a requirements audit and a code audit?
A requirements audit compares agreed requirements with the work that exists and reports coverage and drift. A code audit examines source code against a standard for bugs, security and quality. The first answers "did we build what we agreed?"; the second answers "is the code sound?". Neither replaces the other.
What is requirements traceability?
Traceability is the set of links from each requirement to the work, tests or code that implement it, and back. A requirements audit depends on it: without links from issues to requirements, coverage cannot be computed.
What is scope drift?
Scope drift, or requirements drift, is the gradual change of what a project is meant to deliver without an explicit decision: requirements reworded to match the build, dropped quietly, or added without approval. An audit detects it by comparing a frozen baseline with the live requirements.
How often should you audit requirements?
At milestones rather than on a fixed calendar: before a client review, a launch, a handover or a major invoice. Teams that keep links current can audit on demand in minutes; teams that do it by hand usually manage monthly.
Does a finished task mean a requirement is met?
No. A completed task shows someone finished work, not that the result satisfies the acceptance criteria. A good audit labels this state "work done" and leaves verification against the criteria to a person.
Can AI run a requirements audit?
AI can write and refine requirements, and it can help link work to them. The audit itself should be computed from records, because a model's opinion of whether something is "covered" varies between runs and cannot be defended to a client. Atrix uses the agent to write the requirements and plain data to compute the audit.
Next step
Start with the definition and states in the requirements audit glossary entry, then freeze your first baseline. If you want the links and the audit kept for you, the requirements audit in Atrix does it from your own issues.