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.[n1] 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).
Related¶
- 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
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Test Case To Requirement Linker is defined in the frozen evidence as: 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. Its operative deployed or enacted form is therefore Record, Log & Register.
Nearest alternative: Representation, Specification & Plan — Representation, Specification & Plan can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: The defining operation is: 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. In the engineering_design lineage, that operation is specifically evidenced by authoritative or primary work that requires bidirectional links from each requirement to verifying tests and uses the matrix to expose untested requirements. This makes engineering_design the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins.
Related originating lineages:
- Computer Science & Software Engineering — Computer science and software-engineering practice supplies a parallel or contributing lineage for the mechanism's defining operation: 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.
- Security Studies & Intelligence Analysis — Security's adversarial analysis, integrity, and incident-response tradition provides a formative adjacent lineage for the same test case to requirement linker operation.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: 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.
Review resolution: The blind reviewers disagree on primary lineage (computer_science versus engineering_design), so I adjudicated the mechanism rather than inheriting either label. The defining operation is: 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. In the engineering_design lineage, that operation is specifically evidenced by authoritative or primary work that requires bidirectional links from each requirement to verifying tests and uses the matrix to expose untested requirements. This makes engineering_design the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins. The cited NASA SWE-072 Requirements-to-Test Traceability directly supports the mechanism-specific operation and its disciplinary lineage. I retain all independently explained historical alternates without a numeric cap. origin_mode=single_lineage records how the mechanism arose; domain_reach=multi_domain separately records how broadly it can now be applied.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] 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. ↩