What is a requirements audit?

Requirements audit (coverage and drift), explained#

Teams usually know how many tasks are open. They rarely know whether those tasks add up to what was promised. A requirements audit asks a different question: for each agreed requirement, what is the state of the work behind it?

Coverage depends on traceability, the links from each task back to the requirement it serves. With those links, each requirement falls into a clear state. Nothing points at it, so it was agreed and forgotten. Work exists and is unfinished. All the work against it is done. Or it was deliberately dropped. A requirement whose only tasks were all cancelled has no work, even if three attempts were made, and a good audit says both things.

Drift compares the baseline with today. If a requirement's text was edited after the freeze, the audit flags it and shows both versions, because reporting against the new wording while claiming to assess the baseline would be misleading. If the requirement was deleted, the audit says the record is gone rather than silently omitting it.

Two cautions keep an audit honest. Finished tasks are not proof a requirement is met; someone still has to check it against the acceptance criteria. And an audit should be computed from records, not from a model's opinion, or its findings cannot be trusted. A requirements audit is also not a code audit: it does not scan source code for bugs or vulnerabilities.

For example, two weeks before launch, a founder opens the audit for baseline 1. Eleven requirements are in progress or done, two have no work at all, and one, about export formats, was reworded after sign-off. She files work for the two gaps and asks the client to confirm the reworded one.