Detect Coverage Gaps Before Your Auditor Does — Coverage Validation in Links Explorer
Overview
This document explains how Links Explorer detects coverage gaps in your Jira project — requirements that have no downstream implementation or verification links — and surfaces them automatically before an audit or release gate.
It is intended for quality managers, compliance engineers, and engineering leads who are responsible for ensuring that every requirement in a release scope is implemented and verified before an audit submission or certification review.
The central capability described here is coverage validation: the automatic identification of orphan requirements within a JQL-defined scope, without manual review of individual issues.
What Orphan Requirements Are
An orphan requirement is a requirement that has no downstream link to an implementing story, a test case, or both.
In a complete trace chain, every requirement in scope should trace forward through implementation to verification evidence. When a requirement exists in a Jira project but has no linked story, or has a linked story but no linked test case, the chain is broken at that point. The requirement is orphaned at the level where the link is missing.
Orphan requirements are the most common audit finding for regulated teams using Jira. They arise for predictable reasons:
A requirement was written and placed in the backlog but never assigned to a sprint
A story was linked to a requirement during planning but the link was removed when the story was split or rescheduled
A test case was written but linked to the story rather than the requirement, leaving the requirement without a direct verification link
Scope changed mid-development and requirements were added without corresponding test coverage being created
None of these are systemic failures. They are the routine outputs of active development. The problem is that without a coverage validation view, they are invisible until an auditor finds them.
"Gaps — requirements without tests, risks without mitigations — surface late, during audit cycles."
Links Explorer surfaces them during development, not during audit preparation.
How Coverage Validation Works
Step 1 — Define the scope with JQL
Open Links Explorer from the Jira navigation and enter a JQL query that defines the scope of your coverage check. The scope should match the boundary of your audit, release gate, or compliance submission.
Example — Medical device release scope:
project = SRS AND fixVersion = "v4.2 Release"The JQL scope is the boundary within which coverage is assessed. Requirements outside the scope are not evaluated. This allows you to run a coverage check against a specific release without noise from unrelated work.
Step 2 — Review the coverage matrix
Once the scope is defined, LXP generates a coverage matrix showing every requirement in scope alongside its coverage status. Each row represents one requirement. The columns show the linked items at each level of the trace chain and the coverage status at each level.
A row with full downstream coverage shows the linked story, the linked test case, and the test execution status — all in a single row. A row with a coverage gap shows the requirement and the point at which the chain breaks.
The coverage status for each requirement is indicated visually:
Status | Meaning |
|---|---|
Covered | Requirement has a linked implementation item and at least one linked, executed test case |
Partially covered | Requirement has a linked implementation item but no executed test case |
Not covered | Requirement has no linked implementation item (orphan requirement) |
The contrast between covered and uncovered rows is immediately visible. No manual cross-referencing is required.
Resolving Coverage Gaps
When a coverage gap is identified, the resolution depends on the reason the gap exists.
Gap Type | Common Cause | Resolution |
|---|---|---|
Requirement with no linked story | Never scheduled; or story was split and re-linked incorrectly | Link the correct implementing story from within Jira; or create and link a new story if the work was never planned |
Requirement with a linked story but no test case | Test case was not created; or test case was linked to the story but not to the requirement | Create the test case and link it directly to the requirement using the appropriate link type |
Test case with no execution result | Test case exists but has not been run in this release cycle | Execute the test case and record the result; or confirm the test execution result is linked correctly |
Standards Relevance
Coverage validation in LXP directly addresses the traceability gap requirements in the following standards.
Medical devices — IEC 62304 / ISO 13485
IEC 62304 requires that software requirements are traced to their verification activities and that the trace is documented before the software item is released. Coverage validation confirms that every software requirement in the release scope has a linked, executed verification test. The coverage matrix is the audit-ready evidence.
Relevant check: SRS requirement → implementing story → test case → test execution result (PASS)
Defence and aerospace — DO-178C
DO-178C requires bidirectional traceability between high-level requirements and test cases, and between low-level requirements and test procedures. The coverage matrix identifies high-level requirements with no linked test case — the gap a Designated Engineering Representative (DER) will look for first.
Relevant check: HLR → test case → test execution; LLR → test procedure → test result
Automotive — ASPICE / ISO 26262
ASPICE process assessment at CL2 requires evidence that all software requirements are covered by test cases and that test results are available. ISO 26262 adds the requirement that safety goals and HARA items trace through to validation evidence. Orphan safety requirements — those with no linked test — are a non-conformance at the process assessment.
Relevant check: Safety goal → system requirement → software requirement → test case → test result
Government and federal — ISO 9001
ISO 9001 design control requires that design inputs (requirements) are verified against design outputs (implementation) and that verification records are maintained. Coverage validation provides a point-in-time verification record directly from live Jira data.