Skip to content

Test-Case-to-Requirement Linker

Traceability linking tool — instantiates Target-Complete Mapping Design

Binds each verification test to the specific requirement it exercises, creating a per-requirement witness record and exposing requirements with no test bound to them.

A pile of passing tests says nothing about which requirement has none. Test-Case-to-Requirement Linker binds every test case to the requirement(s) it verifies, producing, for each requirement, an explicit record of the test that witnesses it — and flagging requirements with zero linked tests as empty rows. Its defining move is to establish the individual source→target link (a test witnesses a requirement) as a first-class, queryable record. That per-link record is precisely what lets a coverage matrix or traceability artifact show a real gap rather than an assumed one; the linker makes the edges, downstream tools count them.

Example

A flight-control software team works under DO-178C, which requires bidirectional traceability between requirements and the tests that verify them.[1] Engineers tag each test with the requirement ID it covers; the linker parses these tags and builds, per requirement, the set of linked tests. On its first full run, 12 of 900 requirements come back with no linked test at all — among them a low-level requirement covering a rare sensor-fault mode that everyone assumed was tested elsewhere. Those empty rows are exactly the coverage gaps a certification audit would later catch the hard way. The outcome is that the 12 unwitnessed requirements are routed for test creation before the traceability data is submitted.

How it works

What distinguishes this tool is per-link binding, not aggregate scoring. It ingests tests and requirements, resolves each test's declared requirement reference (an annotation, an ID, or a mapping file), creates a bidirectional link record carrying version and scope, and lists the requirements with no inbound link. It deliberately does one thing — attach witnesses to targets — and leaves counting, rolling up, and judging quality to other mechanisms.

Tuning parameters

  • Link source — manual tagging vs parsed annotations vs inference from names. More automation, less certainty that the link is right.
  • Link granularity — requirement-to-test vs requirement-to-assertion; finer granularity catches a test that touches a requirement without fully exercising it.
  • Bidirectionality — one-way (test→requirement) vs two-way. Only the reverse direction detects the empty requirement rows that matter here.
  • Version binding — whether a link pins the requirement version, so a changed requirement automatically unlinks its now-stale test.
  • Staleness policy — how a link ages and is invalidated when either side changes.

When it helps, and when it misleads

Its strength is turning "we have lots of tests" into "which requirement has none" — the target-side reversal the whole archetype rests on. Its failure mode is that a link records only that a test claims to cover a requirement, not that it actually does: a hollow, wrong, or trivially-passing test still creates a green link, and inferred links can be confidently mistaken. The classic misuse is auto-linking by name-matching to manufacture full coverage on paper. The discipline that guards against it is to keep links versioned and to hand every link on to validation rather than trusting its mere existence.

How it implements the components

Test-Case-to-Requirement Linker realizes the witness-attachment slice of the archetype — the components that record which source witnesses which target:

  • preimage_witness_record — its output: for each requirement, the explicit record of the test that stands as its witness (or the absence of one).
  • mapping_relation_specification — it defines the concrete test↔requirement verification relation, one typed link at a time.

It does not roll those links up into the full coverage matrix or dashboard (that's Bipartite Coverage Matrix and Requirements Traceability Matrix), nor confirm that a linked test truly exercises its requirement (Witness Validation Test).

  • Instantiates: Target-Complete Mapping Design — it produces the per-target witness records the coverage promise is built from.
  • Sibling mechanisms: Witness Validation Test · Requirements Traceability Matrix · Bipartite Coverage Matrix · Preimage Witness Generator · Coverage Dashboard

References

[1] DO-178C, the civil-avionics software assurance standard, requires bidirectional traceability between requirements and their verification cases; an unlinked requirement is a recognized coverage defect under it. The linker instantiates that trace — but the same standard also demands the test be adequate, which is a separate validation step this tool does not perform. ↩