Coverage

Coverage is the measure of how complete your thread is: of all the connections your process requires, how many actually exist. It turns “are we traced?” into a number you can track and a list of gaps you can close.

Coverage as a percentage

Coverage is reported as a percentage for each kind of relationship — what proportion of requirements have tests, what proportion of risks have controls, and so on. A single figure tells you where a program stands; watching it over time tells you whether you’re catching up or falling behind as work grows.

Forward and backward

Coverage runs in both directions. Forward coverage asks whether each requirement is verified — does it have a test behind it? Backward coverage asks the opposite — does each test trace back to a requirement, or is it testing something no one asked for? Both gaps matter: an unverified requirement is a hole in your evidence, and an orphaned test is effort that traces to nothing.

The gaps view

Because the value is in the exceptions, the Traceability Gaps view lists exactly the items that break coverage — the requirements with no verification, the items missing a required link. Rather than reading a whole matrix to find the holes, you get the holes directly, as a worklist you can act on.

Coverage and verification

Verification coverage — requirements proven by passing tests — is the coverage view most programs watch closest, and it’s covered from the testing side in Coverage. Traceability coverage is the broader picture: every relationship type your process depends on, measured the same way.

Why it has to be live

A coverage number is only useful if it’s current. Because it’s computed from the actual links and results in the system, coverage updates as you work — and the next piece, suspect links, is what stops a “covered” item from quietly becoming stale when something it depends on changes.