whitepaper · 10 pages · September 22, 2026

From Spec to Shipped: Measuring Delivery Against Requirements

How to know, with evidence, that the plan actually shipped, not just that the tickets closed.

Drafted with AI assistance and reviewed by the CodeReviewer team. How we use AI

  • Where requirements go missing between the specification and the merged code.
  • Why partially delivered requirements are more dangerous than missing ones.
  • A lightweight traceability method using must, should and may priorities, with evidence behind every status.
  • The delivery metrics that answer "are we done?" honestly.
  • An illustrative model of what it costs to find gaps at the demo instead of during development.

Get the full paper

Free PDF. We'll send the odd product update. Unsubscribe any time.

“Done” is a claim, not a measurement

Ask a team whether a feature is finished and the answer is usually based on activity: tickets closed, pull requests merged, branch deployed. Those are signs that work happened. They are not proof that the thing that was promised now exists.

The gap tends to show up at the worst possible moment: the client demo, user acceptance testing, or a support ticket weeks after launch. A requirement that was agreed, estimated and scheduled never made it into the code. Nobody noticed, because every individual task looked complete.

Where requirements go missing

Requirements rarely vanish through one big mistake. They leak out at each hand-off: from spec to tasks, from tasks to pull requests, inside a pull request that skips an edge case, and between two people who each assumed the other had it covered. Partially delivered requirements are the hardest to catch. The screen exists and the button works, but the export leaves out refunds. A casual walkthrough passes it, and production doesn’t.

Code review doesn’t catch this, because review looks at one change on its own. Completeness is a property of the whole body of work, and no single review can see it.

A lighter kind of traceability

Traditional traceability matrices are heavy, manual and quickly go stale. The paper describes a lighter approach that keeps the useful core:

  • Write requirements as discrete, checkable statements.
  • Prioritise them as must, should or may.
  • Mark a requirement as shipped only when it can point at the change that delivered it.

On top of that, a small set of metrics answers the question stakeholders actually ask: requirement coverage, must-have coverage, partial count, gap age and evidence ratio. Report them by priority, so one missing must-have can’t hide behind a pile of finished nice-to-haves.

The cost of finding gaps late

A missed requirement found while the code is fresh is a small follow-up. The same requirement found at the demo means reopening finished work, re-testing it and often renegotiating dates. The paper includes an illustrative model with transparent assumptions that you can adapt to estimate the difference for your own projects.

Download the full paper

The full 10-page paper includes the hand-off leak map, the status and evidence model, the metrics table, the worked cost model and a delivery checklist for agencies and product teams. It’s free. Fill in the form to download the PDF.

Give every PR the review it deserves.

Start your 15-day free trial. We onboard a few teams every week.