Requirements Coverage Metrics
Requirements coverage metrics answer the most fundamental QA question: have we tested everything that was supposed to be built? They are the bridge between the requirements document and the test results - proving to auditors, stakeholders, and the team that nothing was missed.
Requirements Coverage Calculation
- Requirements Coverage Rate: (Requirements with ≥1 passing test case) / Total requirements × 100. Target: 100% for critical requirements. Report partial coverage (requirements with failing tests) separately from no coverage (requirements with no tests)
- Requirements tested per type: Break down coverage by requirement category - functional requirements coverage, non-functional requirements coverage, security requirements coverage. Each may have different target thresholds
- Coverage by priority: Critical requirements coverage should be 100% before release. High requirements coverage >95%. Medium and Low can be deferred with documented risk
- Requirements Coverage Trend: Track across releases - if requirements coverage is declining release over release, the team is accumulating a 'requirements debt' where increasingly more of the product is tested less thoroughly
Using the RTM for Coverage Reporting
The RTM is your source of truth for requirements coverage reporting. Run these RTM analyses before every release: (1) No Test Coverage Report: Filter RTM for requirements with no linked test cases - immediate remediation needed or formal risk acceptance. (2) Failed Coverage Report: Filter for requirements with all test cases failing - these requirements are NOT met by the current build. (3) Partial Coverage Report: Requirements with some passing and some failing tests - partially implemented or partially tested. (4) Complete Coverage Report: Requirements with all test cases passing - fully verified. Present the complete picture in the Test Summary Report - executives need to know not just 'testing is done' but 'X% of requirements are fully verified, Y% have open defects, Z% have deferred testing with accepted risk.'
80% min. Branch > line.
Tip
Tip
Practice Requirements Coverage Metrics in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Practice Task
Note
Practice Task - (1) Write a working example of Requirements Coverage Metrics from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Requirements Coverage Metrics is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready qa engineering code.
Key Takeaways
- Requirements coverage metrics answer the most fundamental QA question: have we tested everything that was supposed to be built.
- Requirements Coverage Rate: (Requirements with ≥1 passing test case) / Total requirements × 100. Target: 100% for critical requirements. Report partial coverage (requirements with failing tests) separately from no coverage (requirements with no tests)
- Requirements tested per type: Break down coverage by requirement category - functional requirements coverage, non-functional requirements coverage, security requirements coverage. Each may have different target thresholds
- Coverage by priority: Critical requirements coverage should be 100% before release. High requirements coverage >95%. Medium and Low can be deferred with documented risk