What Is Traceability? A Guide for Regulated Product Teams

When a requirement changes and nobody can say which test cases or risk items now need another look, the trace behind that requirement has already failed. In regulated product development, traceability supplies the evidence that every requirement was designed, built and verified, and that evidence has to stay connected while the product keeps changing. A missing link hides a requirement without verification until it is expensive to fix.

Standards bodies define traceability’s scope, and a Traceability Information Model (TIM) sets which links each artifact must carry. This guide covers what the standards require of a trace and why a requirement change is the test the whole structure has to pass.

What Is Traceability in Product Development?

Traceability is the recorded chain of links that lets a team follow any requirement backward to the user need, regulation or hazard that created it and forward to the design, code, tests and results that satisfy and verify it. Manufacturing uses the word for following a part or lot through production and supply, while product development uses it for following a requirement through design, code and verification, the sense that safety standards such as ISO 26262 and DO-178C enforce. A trace is useful only when a reviewer can follow it in either direction and understand both why a requirement exists and how the product fulfills it.

How Standards and Handbooks Define Traceability

Requirements traceability is the ability to “describe and follow the life of a requirement” in both directions, in the 1994 definition by Gotel and Finkelstein that still anchors the research literature. Their definition covers the whole span, from the requirement’s origin to its use in the field and every revision along the way. The same idea is compressed to “a discernible association among two or more logical entities such as requirements, system elements, verifications, or tasks” in the glossary definition of traceability of the National Aeronautics and Space Administration (NASA) Systems Engineering Handbook. Bidirectional traceability is the ability to trace any requirement to its parent and to its allocated children, in the same handbook’s terms.

An older glossary adds a second sense worth keeping. Beyond “the degree to which a relationship can be established between two or more products of the development process,” traceability is also “the degree to which each element in a software development product establishes its reason for existing.” Both definitions come from the Institute of Electrical and Electronics Engineers (IEEE), in the glossary the U.S. Food and Drug Administration (FDA) reproduces for software development terms. A design element with no requirement behind it fails the test as surely as a requirement with no test behind it.

Accountability connects both senses in ISO/IEC/IEEE 29148:2018, the international standard for requirements engineering. The standard describes requirements traceability as “frequently used as a single point of accountability for tracing a requirement back to the source of the requirement and forward through the life cycle to assess that the requirement has been met.” Verification methods are associated with each requirement under the same standard, which also calls for a unique identifier on every one. Identifier discipline sounds trivial until a program tries to trace a requirement that was renumbered between two revisions of a Word document.

Traceability Versus Verification, Coverage, and Configuration Management

Traceability records which verification method belongs to a requirement, and verification is the separate act of confirming the requirement has been met. Verification results are objects connected by trace links, and traceability is the relationship between them. For a test engineer, a requirement with a linked test case is covered in the trace sense, while test execution and pass status are attributes on the test run. Validation sits on the other leg of the V-model, confirming the right product was built against user needs, and trace links have to reach both.

Coverage is an output of traceability rather than a synonym for it. Links kept in both directions are what let a team show that every source requirement has been addressed and that every lower-level requirement has a legitimate parent, which is the purpose Capability Maturity Model Integration (CMMI) gives bidirectional traceability. A coverage percentage is what you get when you count those links against the rules that say which ones are required.

Configuration management is a third thing again, and the Systems Engineering Body of Knowledge (SEBoK) lists it as a separate technical management process from requirements management. Baselining, version control and access control are the governance that trace links live inside. A program can therefore run disciplined configuration management and still have no idea which tests a requirement change invalidated.

The Types of Traceability, Mapped to the V-Model

Traceability can be classified by direction and by level in the hierarchy, and each cut answers a different engineering question. The standards tend to require both without naming them. Mapping those cuts to the V-model shows which relationships support decomposition, implementation, verification and validation.

Forward and Backward Traceability

Forward traceability follows a requirement down to the design, code and tests that satisfy and verify it, and backward traceability follows any of those artifacts up to the requirement and source that justify it. Holding both directions at once is bidirectional traceability. Direction splits further into four link types, each with its own question, in Kotonya and Sommerville’s scheme:

• Backward-from: A requirement is linked to its sources, whether a user need, a regulation, or a prior document. The link answers why the requirement exists.
• Forward-from: Each requirement connects to the design elements and code built to satisfy it. The link answers what was built for this requirement.
• Backward-to: Design elements or code units link back to a requirement. The link detects orphaned code and design that no requirement justifies.
• Forward-to: A source, such as a user need, a regulation or an earlier document, is linked forward to the requirements it gives rise to. The link answers which requirements a change in that source affects.

NASA’s handbook applies the backward-from rule to every requirement, with one allowance. A requirement with no parent in a baselined document is acceptable only if it is identified as self-derived, for example because it records a design decision. Otherwise the handbook reads it as a flawed trace or as “gold plating” to be removed. The backward-to rule applies to code in DO-178C source-code trace data, which requires trace data between low-level requirements and source code so a verifier can confirm that no source code contains undocumented functions. DO-254 carries the same expectation for airborne electronic hardware at Design Assurance Level (DAL) A and B, where traceability runs through hardware requirements, design, implementation and verification results.

Vertical and Horizontal Traceability

Vertical traceability follows requirements through the system hierarchy as they decompose from mission-level need through system, subsystem and component levels. Horizontal traceability connects peer artifacts at the same abstraction level and captures the interface dependencies between parallel development streams. In an automotive program that means hardware and software safety requirements within each electronic control unit (ECU), interface requirements between ECUs at the same system level, and cross-cutting functional safety requirements that run across subsystem teams working in parallel.

On a V-model, vertical links run down the left leg as requirements decompose, and horizontal links cross the V from each requirement level to the verification activity at that same level. Because interfaces sit between subsystems, the links have to cross them as well as run up and down the hierarchy, so an interface requirement between two subsystems needs an owner. Bidirectional traceability describes the nature of a link independent of its orientation, so it applies to vertical and horizontal relationships alike.

What the Standards Require of a Trace

Each standard below requires traceability across some part of the V-model. The standards differ in which artifact pairs they name and in how far the safety class or assurance level raises the rigor.

Standard	Sector	What it expects of the trace
ISO 13485:2016 Clause 7.3, incorporated by 21 Code of Federal Regulations (CFR) 820.10(c) in the FDA Quality Management System Regulation (QMSR)	Medical devices	Identifiable inputs traced to outputs and tests. Every output linked to an input. Changes identified, verified or validated, reviewed and approved.
IEC 62304	Medical device software	Traceability among system requirements, software requirements, software system tests, and software risk controls. The software safety class decides how much of that documentation, including risk-control traceability, the standard asks for.
ISO 14971:2019	Medical device risk management	Each hazard traced to risk analysis, risk evaluation, controls put in place and verified, and residual risk evaluation.
ISO 26262:2018	Automotive functional safety	Safety goals from the hazard analysis traced down through functional and technical safety requirements to hardware and software, with the Automotive Safety Integrity Level (ASIL) setting the rigor.
Automotive SPICE (ASPICE) 4.0	Automotive process assessment	Consistency and bidirectional traceability in each engineering process from system requirements analysis onward, and between change requests and affected work products in change request management.
DO-178C and DO-254	Airborne software and electronic hardware	Trace data among system, high-level and low-level requirements, source code, tests, procedures and results. For DO-254 at DAL A and B, bidirectional traceability across hardware requirements, design, implementation and verification results.
IEC 61508	Industrial functional safety	Forward and backward traceability between safety requirements and their verification and validation, with the rigor expected rising with the Safety Integrity Level (SIL).
EN 50716:2023	Railway software	Traceability from requirements through design, implementation and every testing phase. EN 50716 replaced EN 50128 and EN 50657 in 2023.

Four of the rows tie the depth of the trace to a classification, whether the software safety class in IEC 62304, the ASIL in ISO 26262, the DAL in DO-254 or the SIL in IEC 61508. The same requirement can therefore need a denser trace on one program than on another.

Compliance obligations can also stretch past release. Post-release work can include maintaining a software bill of materials for cyber devices under section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act). Since 11 September 2026, it can also include reporting actively exploited vulnerabilities in products with digital elements under the European Union’s Cyber Resilience Act. The trace chain that used to end at the verification result increasingly has to reach the software components inside a shipped product.

How Assessors Read the Trace

An assessor reads a trace for whether the links exist and for whether the linked content still agrees, because a link between a requirement and a test proves nothing about whether the test still checks what the requirement now says. The ASPICE 4.0 change merged what had been two separate base practices, in each engineering process from system requirements analysis onward, into one that establishes bidirectional traceability and ensures consistency. Traceability is about the links between work products, while consistency is about whether their content agrees, and the notes to the 4.0 base practice warn that links alone do not make the information consistent. ASPICE also does not expect every work product traced to every other. Its notes allow non-functional requirements at the user-need level, such as process requirements, that no system requirement traces to, and the traces assessors look for are the ones that support impact analysis and coverage.

The medical rows carry the most recent change. On 2 February 2026, the FDA QMSR took effect, and the agency replaced the Quality System Inspection Technique with Compliance Program 7382.850. Documents that merely exist no longer satisfy investigators, who now evaluate whether documentation reflects a functioning system, in MDDI Online’s reading of the new compliance program.

Under the QMSR, FDA’s design and development requirements sit at 21 CFR 820.10(c), which incorporates ISO 13485:2016 Clause 7.3 and its subclauses. The design controls section of the former regulation is now marked Reserved. ISO 13485 calls the required record the design and development file, the counterpart of the legacy Design History File (DHF).

A design record can exist without showing that the work behind it was done, as a June 2026 FDA warning letter shows. The letter followed a July 2025 inspection under the former regulation, and the firm’s design traceability matrix assigned a user need to design verification, but the verification report never described how it was verified. In that record the trace link was in place, and the evidence at its far end was not.

How the TIM Defines Coverage Before Authoring

By setting the permitted artifact types and relationships in advance, a TIM turns coverage into a rule that can be checked throughout development. The model replaces after-the-fact reconstruction with a structure the team declares up front. Two programs under identical standards obligations can produce evidence that differs in completeness and consistency, and whether each declared a TIM is one reason why.

What the TIM Declares

Teams use a TIM to set the permitted artifact types and relationships when a program starts. A TIM has two kinds of element, with the artifact types that can be traced drawn as classes and the trace relations allowed between them drawn as associations, in the modeling language Mäder and Cleland-Huang proposed. Four kinds of traceability link appear in the reference models Ramesh and Jarke built from studies of traceability practice in major development companies. The count is a useful reminder that every link in a program does not mean “this satisfies that.”

In requirements management practice built on a TIM, an administrator declares which item types exist, typically user needs, system requirements, subsystem requirements, design elements, risk items, test cases and defects, and sets a relationship rule for each pair. A rule marked as required for coverage turns a missing link into a detected exception. If a system requirement must link to at least one test case, a requirement with none is flagged automatically as missing its required verification, without anyone running a report. Optional relationships, by contrast, allow a link without enforcing it.

Timing decides whether any of this works, because a TIM written after requirements are authored or migrated has to be fitted onto data that never followed its rules. The model therefore belongs ahead of data mapping for a migration and ahead of the next evidence checkpoint, such as a baseline review or the first formal verification plan. In a new program, that checkpoint comes before the first requirement. Recording the verification method with each requirement when it is defined puts that part of the trace in place months before test planning starts. Early definition lets the same rules govern both newly authored and migrated artifacts.

Comparing the TIM and RTM

A Requirements Traceability Matrix (RTM) and a TIM answer different questions, because the RTM records what exists at a single point in time. It maps every requirement backward to the user need or regulation that created it and forward to the design elements, test cases and verification activities tied to it. A TIM records what must exist, and it does so before authoring.

Dimension	RTM	TIM
When it is built	After artifacts exist, often before a submission or audit	Before the first requirement is authored
What it records	Links present when it was generated	Item types and relationship rules every item must satisfy
How a missing link surfaces	An empty cell is found during review	The model flags the item automatically
Behavior after a change	Diverges until manually regenerated	Persistent rules check new and changed items

The RTM is still the artifact reviewers expect to see. For IEC 62304 software it typically carries columns for the software requirement, the architecture element, the software unit, the unit test, the integration test, and the anomaly recorded during testing. Under DO-178C, requirements-based coverage analysis connects high-level requirements and functional test cases so that every requirement has associated verification.

None of the standards in the table names a tool for producing that matrix, so a spreadsheet export and a traceability matrix generated from live data can both carry the evidence. Regulated projects need approval records with change history and timestamps, and a TIM enforces the declared relationship rules around them. A spreadsheet can hold those records, but nothing in it rejects a missing approval.

Managing by Exception Against the Model

Once the rules are declared, the difference between what the program has built and what the model says it should have becomes the exception list. Management by exception means a lead steps in only where the data shows a deviation and leaves the team alone while development is on track. Against a TIM, the list usually holds three kinds of item:

• Unverified requirements: No test has been written yet for a requirement with no linked verification.
• Orphaned design elements: A design element with no upstream requirement is design that nothing justifies.
• Out-of-flow work items: Work created outside the defined flow has no place in any chain the model expects.

For a quality lead, the exception list is most of the audit preparation, and for a systems engineer it replaces the week spent cross-referencing a Word document against an Excel matrix. Both readings depend on rules written down before the work started, because tool cleverness cannot replace those rules.

Read the Webinar Recap

Change Is the Stress Test for Traceability

The next requirement change tests the trace structure established at the baseline review. Design change control appears explicitly in ISO 13485 Clause 7.3.9 and in the ASPICE change request process. A change request therefore exposes whether links support impact analysis or capture only the state assembled for review.

Baselines and Impact Analysis

A baseline is the approved state of a system at a milestone, and every proposed change is judged against it. The formal configuration baselines are functional, allocated and product in SEBoK’s scheme, and NASA’s handbook adds an as-deployed baseline as a fourth. A baseline is a reference point for comparison and can still accommodate requirement changes, provided each change carries a rationale and passes through a configuration control board that assesses its cost, performance, schedule and safety impact before authorizing it. The baseline gives that board a known point against which to evaluate the proposed change.

Each change needs that rationale because its effects can reach suppliers and multiple levels of the architecture hierarchy. Changes can also affect the cost and schedule of work already in progress and carry other technical consequences. Traceability is the prerequisite for assessing that impact before a board decides. With relevant links in place, the assessment can become faster and more reliable.

Suspect Links and the Direction of a Change

Trace links have a direction, and change flows along it. A test case becomes suspect when at least one of its linked functional requirements changes, because the test may no longer match the requirement. Impact analysis across multiple degrees of separation extends that logic beyond the first link.

A change to a customer requirement can reach system requirements, subsystem requirements, design elements, test cases and risk items across the whole chain. The chain can expand quickly across degrees of separation, as a recorded webinar demonstration showed. One proposed upstream change touched two validations and two system requirements directly, then reached system architectures, subsystem requirements, further verifications and existing defects at the second degree of separation. When the upstream item changes, a suspect link marks each downstream artifact for review, and the test lead or design owner assesses the impact before updating the artifact or clearing the flag. The decision records that the downstream effect was considered.

What Investigators Found When a Change Went Untraced

Ariane 5 Flight 501 lost its guidance about 30 seconds after lift-off on 4 June 1996, when inertial reference software carried over from Ariane 4 hit an operand error on a horizontal-bias value driven by the new launcher’s higher horizontal velocity, according to the Inquiry Board report commissioned by the European Space Agency (ESA) and the French space agency CNES. The flight profile had changed with the vehicle, yet the board found that Ariane 5 trajectory data had been deliberately left out of the reference system’s requirements and specification. No test checked the system against the Ariane 5 trajectory, so nothing connected the changed flight profile to the requirements and tests it invalidated.

Medical device enforcement shows the same pattern at smaller scale. The June 2026 warning letter cited above also found inadequate procedures for identifying, validating, reviewing and approving design changes before implementation, alongside complaint-handling and corrective-action findings.

Periodic Reconstruction and Its Costs

Once development is largely complete, teams without maintained links must recreate them, usually by hand, to satisfy a standard or an auditor’s request. Because after-the-fact traceability is generated at the end, it often fails to reflect the product state during design. A static matrix has the same weakness, frozen at the date it was exported. An auditor reviewing an outdated spreadsheet sees a matrix that no longer matches the project’s actual state, which is hard to defend on a safety-critical product.

Teams that spend the week before every audit reconciling requirements in one tool against tests in another are paying for the reconstruction model. Audit preparation time is where that cost is easiest to see. Apex.AI, which builds an ASIL-D safety-certified software framework for mobility systems, reported a 75% improvement in audit efficiency.

Learn About Requirements Traceability

How Jama Connect Supports Traceability in Regulated Product Development

Jama Connect®, a web-based requirements management and traceability platform for complex, regulated product development, starts a regulated program from pre-built industry frameworks and industry-specific TIMs, each matched to rows in the standards table above. For the three medical rows, the frameworks for medical devices align design and development to ISO 13485 Clause 7.3 as incorporated by 21 CFR 820.10(c), support IEC 62304, and align risk management to ISO 14971. Airborne programs start from the Airborne Systems Framework, which covers the DO-178C and DO-254 row for aerospace and defense development. Jama Connect’s automotive frameworks support ISO 26262 and ASPICE. The Industrial Machinery framework supports IEC 61508 and lists the railway standards EN 50126, EN 50128 and EN 50129, and EN 50128 is the railway software standard that EN 50716 replaced.

Its Live Traceability™ approach keeps upstream and downstream relationships in the data itself, so the same trace data produces the evidence those rows ask for without a rebuild of the matrix after each change. A traceability matrix export generates the relationship chain from user needs through verification, which is the RTM reviewers still expect. Pre-formatted templates export the DHF, the industry’s carried-over name for the design and development file, along with DO-178C and DO-254 audit artifacts, and the frameworks ship with out-of-the-box risk analysis reports. Before a change is approved, impact analysis lists the downstream items it would reach across several degrees of separation, and once it is made, suspect links flag every downstream test case and risk item. Coverage gap detection shows the requirements that still lack verification, and after each flag is cleared the next export reflects the change.

Testing Your Traceability Before the Next Requirement Change

Across the standards in the table, the hardest test of a trace comes on the day a requirement changes, when it has to show what the change reaches. Links declared by a model before authoring and kept current as work happens give that answer from the data, and a matrix rebuilt before each audit gives it only for the day it was rebuilt.

For programs where every requirement change has to be traced before it ships, Jama Connect supports this workflow with one current record of requirements, risks, tests, approvals and change history. A free 30-day trial shows each requirement’s chain of links, up to its user need and down to its test results, in one trace view.

Frequently Asked Questions About Traceability

Does traceability still apply when the team works in sprints?

Yes. Agile teams working in sprints still face traceability challenges alongside review, documentation and change control. The artifact names change, with user stories and acceptance criteria standing in for specification documents, but the obligation to show a complete chain in both directions is the same. With Traceable Agile™, requirement state lives in Jama Connect while sprint flow stays in Jira, synced through the Jama Connect Interchange™ add-on, so developers keep their tool and the chain stays intact.

How does traceability connect to SysML models in a model-based systems engineering (MBSE) program?

The Systems Modeling Language (SysML) relates model elements such as blocks to requirements through satisfy, verify and trace relationships, so the model itself can hold links that used to live in a separate document. SysML v2 and its modeling application programming interface (API) support programmatic interoperability between system models and other tools. Defense programs are asked to define an authoritative source of truth for their models and data, with traceability among the properties that define it, under the 2022 Digital Engineering Fundamentals issued for U.S. defense programs. Traceable MBSE™ syncs SysML diagrams and model data into Jama Connect so they can be traced, baselined and reviewed alongside requirements and tests.

What happens to traceability when a requirement has no parent?

DO-178C treats derived requirements, those arising from design decisions without a parent, as legitimate but requires that they be provided to the system processes, including the system safety assessment. Where a program’s traceability model requires an upstream link for that item type, a requirement created without one shows up as an exception until it is linked to a parent or recorded as derived.

What is the difference between traceability and a traceability matrix?

Traceability is the set of recorded links between requirements, design, tests and results, and a traceability matrix is one view of those links, generated at a point in time. A matrix can be exported from live trace data or assembled in a spreadsheet, and either version is only as current as the links were on the day it was produced. The strengths and limits of a matrix follow from that snapshot, so the links are what a team maintains and the matrix is what it generates when a reviewer asks.

If I want to learn more about traceability, what else should I read?

If requirements on your program change often, our guide to managing requirements volatility sets out seven strategies. For why links kept current as work happens hold up better than a matrix rebuilt before an audit, read live versus after-the-fact traceability.

This article was authored by Mario Maldari and updated on October 15, 2026.