What Does ‘Bidirectional Traceability’ Really Mean on a Certified Program?
Ask ten engineers working on a certified program to define bidirectional traceability and most will say something like: “You can go from a requirement to its test, and from the test back to the requirement.” That is correct but incomplete — and the gap between that definition and the full operational reality is where programs get into trouble during audits.
DO-178C, DO-254, ISO 26262, IEC 61508, and MIL-STD-882 all require bidirectional traceability. The language varies but the intent is identical: demonstrate that every stakeholder need is satisfied by design and verified, and demonstrate that every design decision and test exists to satisfy a need. Neither direction alone is sufficient. Yet in practice, most programs only enforce one direction consistently — and they usually discover which one they skipped when a certification authority starts asking hard questions.
The Hierarchy You Are Actually Tracing
Before the mechanics make sense, the hierarchy has to be explicit. On a typical certified hardware or embedded systems program, requirements exist at several levels:
Stakeholder needs — what the customer, operator, or regulatory body actually requires. These are often qualitative, operational, and written in domain language rather than engineering language.
System requirements — engineering decomposition of stakeholder needs into verifiable, unambiguous statements at the system boundary.
Subsystem requirements — allocation of system requirements to specific subsystems (hardware, software, mechanical, power, communications).
Component requirements — further allocation to individual components, modules, or units.
Design artifacts — architecture documents, schematics, firmware specifications, interface control documents, and BOMs that implement the requirements.
Verification evidence — test cases, test procedures, test results, analysis reports, and inspection records that confirm the design satisfies the requirements.
Bidirectional traceability means you can traverse this entire chain in both directions. Downward: from a stakeholder need, through every level of decomposition, to the specific test result that verifies the implementation. Upward: from any test result, through every level of allocation, back to the stakeholder need that justified writing the test in the first place.
That is six levels. Most traceability matrices cover two.
What Is Lost When You Only Trace Downward
Downward-only traceability is the more common failure mode. The team maintains a matrix that maps requirements to tests. Requirement REQ-042 traces to test case TC-117. REQ-043 traces to TC-118 and TC-119. The matrix looks complete.
What this matrix does not tell you: why REQ-042 exists. Which system requirement it satisfies. Which stakeholder need drove that system requirement. Whether the stakeholder need was fully decomposed into system requirements, or whether part of it disappeared in translation.
When you can only trace downward, orphaned requirements become invisible. An orphaned requirement is a design or verification artifact — a requirement, a test, a design decision — that has no parent. It exists in the model but nothing above it justifies its existence.
Orphaned requirements are expensive in two ways. First, they represent work that may have no certification credit. If a component requirement cannot be traced to a system requirement, the certification authority will ask why it exists. If you cannot answer, the requirement and everything derived from it is suspect. Second, they can hide scope creep. Engineers add requirements that address real engineering concerns — electromagnetic compatibility margins, derating rules, thermal guards — without formally allocating them from a parent. The design is better for it, but the paperwork doesn’t support it.
At audit time, orphaned requirements become findings. Findings delay certification. Delays are expensive.
What Is Lost When You Only Trace Upward
Upward-only traceability is less common but equally damaging. Here the team maintains a parent-child hierarchy — every requirement knows its parent. The decomposition looks clean. Stakeholder need SN-007 allocated to system requirement SR-022, which allocated to subsystem requirements SSR-041 through SSR-045.
What this does not tell you: whether SR-022 has been verified. Whether SSR-041 through SSR-045 have design artifacts implementing them. Whether any of those design artifacts have test coverage.
When you can only trace upward, unallocated needs become invisible. An unallocated need is a stakeholder requirement, or a system requirement, that was never decomposed into actionable engineering requirements or never connected to a verification activity.
The most dangerous variant is the requirement that was decomposed correctly at the time of writing but then became disconnected when the design changed. A hardware revision drops a component. The requirements that existed only to specify that component are deleted — but nobody checks whether those requirements were the sole satisfiers of a subsystem requirement above them. The subsystem requirement now has no implementation. The stakeholder need it served has a gap.
Upward traceability without downward traceability cannot catch this. You can still walk from the subsystem requirement up to the stakeholder need. The chain looks intact. But walk downward from the subsystem requirement and you fall off a cliff.
How Most Programs Actually Do This (And Why It Fails)
The honest description of bidirectional traceability on most certified programs: a requirements management tool (IBM DOORS, Jama Connect, Polarion, or a spreadsheet) captures requirements with parent-child relationships. Separately, a test management tool or spreadsheet captures test cases mapped to requirements. At audit time, a program manager exports both, reconciles them manually, and generates a Requirements Traceability Matrix.
The RTM is accurate as of the moment it was generated. By the time the auditor reads it, the design has changed. Requirements have been added, split, or deleted. Tests have been revised. The RTM reflects a program that no longer exists.
This is not a process failure — it is a structural failure. When traceability lives in separate tools and documents that are reconciled manually, bidirectional traceability is a snapshot, not a property of the program. You generate the evidence of compliance rather than continuously maintaining it.
The audit finding is not usually “your RTM is wrong.” It is “your RTM is dated three weeks before the design review where you changed the power architecture, and we need to see coverage of the new requirements.” That is when programs scramble.
What Bidirectional Traceability Looks Like When It Is Live
The alternative to snapshot traceability is model-based traceability — where the connections between needs, requirements, design artifacts, and verification evidence are maintained as first-class relationships in a single model, and the integrity of those relationships is checked continuously.
In a properly implemented model, every link is typed. “Satisfies,” “is verified by,” “is allocated to,” “is derived from” — these are not the same relationship and should not be stored the same way. A requirement that satisfies a parent need is a different kind of link than a test case that verifies a requirement. The model knows the difference. When you query for coverage gaps, the model can distinguish between “no test case linked” and “no parent requirement linked.”
This matters operationally because different roles own different link types. A systems engineer is responsible for ensuring every stakeholder need has satisfying system requirements. A hardware engineer is responsible for ensuring every component requirement has a design artifact. A verification engineer is responsible for ensuring every verifiable requirement has test coverage. If the model surfaces gaps by link type, each role sees their specific coverage holes without needing to generate and interpret a full RTM.
The second property of live traceability is that coverage is a dashboard metric, not an audit artifact. At any point in the program, you can answer: what percentage of stakeholder needs have full downward coverage to verification evidence? What requirements have no parent? What tests have no upstream requirement? These numbers should be visible on a daily basis, not computed once a quarter.
Flow Engineering is built around exactly this model. Requirements, needs, design artifacts, and verification activities are nodes in a graph, and the relationships between them are typed edges that the system monitors continuously. When an engineer adds a component requirement without linking it to a parent, the model immediately surfaces it as an orphan. When a design revision removes the only design artifact satisfying a subsystem requirement, the subsystem requirement immediately shows a coverage gap. The traceability matrix is not a document you generate — it is a live query against a graph that is always current.
This also changes how change impact analysis works. When a stakeholder need changes, you can instantly see every requirement, design artifact, and test case downstream of it. You know exactly what needs review. You do not need to manually trace through an Excel workbook or run a DOORS module query.
Practical Starting Points If You Are Not There Yet
If your program is currently running on document-based traceability, full model migration before your next audit is probably not realistic. But there are concrete steps that reduce exposure.
Audit your link types first. Most programs have requirements with parent links but no verification links, or verification links with no parent. Query your current tool for requirements with zero child links below the component level. Those are your unallocated needs. Query for requirements with no verification link. Those are your unverified requirements. Both lists are actionable before you change tools.
Define coverage rules explicitly. Write down what “covered” means for your program: a stakeholder need is covered when it has at least one satisfying system requirement, each of which has at least one satisfying lower-level requirement, each of which has at least one passing test result. This sounds obvious but most programs have not written it down, which means coverage checks are inconsistent.
Treat link creation as part of the engineering workflow, not as a documentation step. Traceability gaps grow when engineers write requirements or tests without creating links because “we’ll do the matrix later.” Later is when the audit is next week.
When you are ready to move to a tool purpose-built for this, look for graph-native data models, typed relationships, live coverage dashboards, and change impact analysis that propagates automatically. Those capabilities determine whether bidirectional traceability is something your program maintains or something your program proves it maintained after the fact.
The Honest Summary
Bidirectional traceability is not a matrix. It is a structural property of your program’s requirements model. The matrix is evidence that the property holds — but only if it is generated from a live model, not assembled from disconnected documents.
Programs that treat traceability as documentation produce evidence of compliance. Programs that treat traceability as a live model property maintain compliance. The difference shows up at design reviews, at audits, and when the hardware changes three weeks before a delivery milestone.
Every gap in your traceability graph — every orphaned requirement, every unallocated need, every unverified requirement — is a question a certification authority can ask that you cannot answer cleanly. In a live model, those gaps are visible the day they are created. In a document-based process, they are visible the day you look.