Requirements traceability coverage
The percentage of requirements with at least one linked test — a coverage measure used most in regulated-industry QA.
// Formula
// About this metric
Requirements traceability coverage measures whether every requirement in your system has a corresponding test that verifies it. The formula is: requirements with linked tests divided by total requirements, expressed as a percentage.
Traceability matters most in regulated domains — medical devices (IEC 62304), automotive (ISO 26262), aerospace (DO-178C), and financial software (SOX, PCI) all require evidence that requirements have been verified. In these contexts, traceability is not a quality metric but a compliance obligation with specific percentage targets defined by the regulation.
For general commercial software, traceability is valuable as an audit tool: it answers "what test verifies requirement X?" and "which requirements are untested?" without requiring 100% coverage. The signal is whether you can trace any given requirement to at least one test — not the aggregate percentage.
Tooling matters significantly: traceability tracking works well in tools such as Jira with test management integrations (Xray, Zephyr), TestRail, or Azure DevOps. Manual tracking in spreadsheets becomes unsustainable above a few hundred requirements.
// Calculator
🧮 Calculator
// Benchmark
// When this is healthy
Above 90% is typical for regulated industries (medical, automotive, finance). For consumer software, lower is often acceptable. The signal is whether you can answer "what test verifies requirement X?" for any X — not the percentage itself.
// Why no numeric benchmark
Traceability targets are driven by regulatory requirements, not optimisation goals. Industry numbers don't generalise.
// When to use this metric
Use traceability coverage as a compliance requirement tracker in regulated domains, and as a periodic audit tool in commercial software. It is not a day-to-day metric — run traceability analysis at major milestones (release, audit, architecture review).
It is less useful in teams with high-agility, story-driven development where requirements are implicit in user stories and acceptance criteria rather than formal specification documents.
// Common pitfall
Traceability coverage is trivially inflated by creating a test with the same title as a requirement and linking them without the test actually verifying anything meaningful. The metric measures whether a link exists, not whether the linked test is adequate. Pair traceability coverage with test quality reviews — 100% traceability with shallow tests is a compliance risk, not a quality achievement.