Using Your RTM to Find Untested Requirements Before They Reach Production

The single most valuable thing a requirements traceability matrix produces is a coverage report: the list of requirements that have no linked, passing test. That list is a precise inventory of delivery risk — every item on it is something you promised to deliver but cannot yet prove works. Producing and acting on this report before a release is the difference between an RTM that is decorative and one that earns its keep.

## What test coverage means in an RTM context

Coverage here is *requirements* coverage, not code coverage. Code coverage tells you which lines a test exercised; requirements coverage tells you which *obligations* are verified. The two are independent — you can have high code coverage while leaving a stated requirement entirely untested, and vice versa. An RTM measures the dimension that matters most to stakeholders: did we verify what we promised?

A requirement is covered when it is linked to at least one test case, and that test case has passed. Anything short of that is a gap:

- **No linked test** — the requirement was never planned for verification.

- **Linked test, never run** — verification planned but not executed.

- **Linked test, failed or blocked** — verification attempted but the requirement is not met.

## Producing the coverage report

With status captured in your matrix, the report is a filter, not a manual audit. Derive a coverage flag per requirement and slice it three ways:

1. **Uncovered requirements** — zero linked tests. These are the most dangerous because they are invisible to test-status dashboards; the tests simply don't exist.

2. **Unverified requirements** — linked tests that are not-run or blocked. Real, but pending.

3. **Failing requirements** — linked tests that failed. Known not-met scope.

Sort by priority. An uncovered "must-have" is a release blocker; an uncovered "could-have" may be an acceptable, documented deferral.

## Reading the gaps intelligently

Not every gap is equal, and the RTM lets you triage rather than panic:

- **High priority + uncovered** → escalate immediately; this is the classic cause of a requirement quietly missing from a release.

- **High priority + failing** → known defect against committed scope; needs a fix-or-defer decision.

- **Low priority + uncovered** → candidate for explicit deferral with stakeholder sign-off.

- **Withdrawn requirements** → should show no coverage and that is correct; make sure they are marked withdrawn, not silently uncovered.

The goal is not zero gaps at all times — it is *no unknown* gaps and *no unacceptable* gaps at the point of release.

## Catching the subtle failure: orphan tests

Coverage analysis runs both ways. As well as requirements with no tests, look for tests with no requirement — "orphan" tests. These are not always wrong, but they often indicate one of three things: scope that was built without a corresponding requirement, a requirement that was removed without retiring its test, or test effort spent where there is no stated need. Orphan tests are a backward-traceability signal worth reviewing every cycle.

## Building coverage into the delivery rhythm

A coverage report is most powerful when it is routine, not a pre-release scramble:

- **Each sprint or cycle:** review newly added requirements for at least one planned test.

- **Before each stage gate or release:** generate the full coverage report and require explicit sign-off on every remaining gap.

- **At release readiness:** present coverage as numbers — covered, unverified, failing, deferred — so the go/no-go decision is evidence-based.

This cadence stops gaps accumulating silently until the worst possible moment.

## Why manual coverage analysis breaks down

Deriving coverage by hand from a spreadsheet works for a few dozen requirements and a stable test set. Beyond that, the cross-referencing becomes error-prone exactly as the stakes rise — large scope, many tests, frequent change. The risk is a coverage report that is itself out of date, which reintroduces the false confidence an RTM is meant to eliminate. Tooling that reads requirements and test results directly and computes coverage automatically — of the kind neart.ai builds — keeps the report trustworthy at scale and turns it from a periodic exercise into an always-available view.

## Takeaway

The day before a release, you should be able to answer one question in seconds: which committed requirements have no passing test? Make that coverage report a standing output of your RTM, triage the gaps by priority, watch for orphan tests, and require sign-off on anything still uncovered. Hidden gaps become a managed list — which is the entire purpose of traceability.