Skip to main content

What Is Traceability? Benefits and Challenges in Software Development

Florian Antony Florian Antony 5 min read
What Is Traceability? Benefits and Challenges in Software Development

Standards like Automotive SPICE, ISO 26262, IEC 61508, and DO-178B enforce traceability as a mandatory part of the development process. But traceability can deliver far more than just proving standard compliance. This article explains what traceability is and how it helps you survive complex projects.

What is traceability?

Literally, traceability is the ability to follow a trace. In software development and systems engineering, a “trace” is the relationship between two development work items — also known as artifacts. Traceability is therefore the ability to create and analyse relationships between artifacts. Artifacts can be requirements, test cases, elements of a system or software model, documents, code fragments, and more.

Common examples: “a requirement is verified by a test case” or “a requirement is fulfilled by a component.”

To make such relationships traceable, you create links between pairs of artifacts. These links have a semantic direction — expressed by phrases like “is verified by” or “is fulfilled by.” Despite this direction, links should be analysable bidirectionally: you can check whether a test case exists for a requirement, and conversely justify why a test case was written at all.

The best-known way to establish traceability is a requirements traceability matrix (RTM). Much has been written about RTMs — we cover how to build one step by step in our guide to requirements traceability matrices. Here I’ll focus on what you can do once the data is in place.

Traceability benefits

Traceability structures your project data as semantic relationships between artifacts. That unlocks two categories of analysis.

What is linked?

Tracing existing links — either direct links as shown in a traceability matrix, or chains of links — is called impact analysis. It looks at individual artifacts and their connections. It helps answer questions like:

  • “Which parts of the system are affected by this change request?”
  • “A test fails. Which requirements are not met correctly?”

What is not linked?

Missing links indicate open work items. If a requirement has no link to a test case, it probably hasn’t been tested — or hasn’t been implemented yet. The analysis of missing links is called coverage analysis: a requirement is “covered by a test case” if it is linked — directly or indirectly — to one. Coverage analysis is a reliable indicator of project progress.

What else can traceability data tell us?

Impact and coverage analysis evaluate the mere existence of links. When you also factor in link semantics, artifact status, and other attributes, the power increases significantly. Consider this scenario:

  • Requirements are linked to a system containing effort estimates for implementation and testing (e.g. a project management tool or bug tracker).
  • Coverage analysis already tells you which requirements are untested. The same approach identifies which requirements have been implemented.

From this you can not only track progress at the requirements level but also calculate remaining effort directly — giving you a reliable indicator for whether the next milestone is achievable. The best decisions are based on real data, not assumptions.

A prerequisite for traceability is that every artifact has a unique identifier. Once that’s in place, the resulting graph of artifacts and links can be used — much like hyperlinks in a browser — for navigation across tool boundaries. The animation below shows navigation from C code in an IDE, through model elements in MATLAB Simulink, to requirements in IBM DOORS.

Animation showing cross-tool navigation from IDE source code via Simulink model elements to requirements in IBM DOORS

Challenges in the field of traceability

The purpose of traceability is to structure project data and generate fact-based insights for evaluating and controlling large, complex projects. Several trends make this increasingly necessary:

  • Project complexity grows fast. More and more systems become intelligent, and intelligent systems interact. This means more complex software and more external interfaces. An empirical study from 2013 confirmed this trend — and the situation has only intensified since.
  • Project size grows fast. Systems are not just becoming intelligent but autonomous. Deep learning and neural networks require large volumes of accompanying artifacts (training data, test cases). In the automotive industry, autonomous driving projects are 100 times larger than typical ECU projects.
  • Standards are getting increasingly important. Maturity models like Automotive SPICE and standards like ISO 26262 help teams improve processes and demonstrate process maturity to customers. Because traceability directly supports this, it is a mandatory component of fulfilling many of these standards.

Meeting these challenges requires traceability benefits that go beyond data analysis. Here are some examples — each a real implementation challenge:

  • Tool synchronisation. Based on traceability data, requirements can be displayed inside a modelling tool for linking — and even edited there and written back to the requirements management tool.
  • Artifact history. Traceability data enables comparisons of individual artifacts (“requirement 345 changed — here’s the delta”) and aggregated comparisons (“since last week: 23 new requirements, test coverage up from 83% to 92%”).
  • Reports with drill-down functionality. Drill-downs — navigating from aggregate data to details — are enormously helpful for managing complexity. For the 92% coverage example, a drill-down might list uncovered requirements per subsystem and then per individual requirement.
  • Fast and consistent link creation. When automated link derivation isn’t possible, links must be created manually — often in large numbers. Tool support for efficient, consistent linking is essential.

Animation showing bulk link creation in itemis ANALYZE for fast and consistent artifact linking

Conclusion

Traceability helps you structure and analyse project data — across tool boundaries. This is especially valuable in heterogeneous tool landscapes. Rapidly growing project sizes and insufficient tool interoperability make the challenge real. A dedicated traceability tool that integrates your existing toolchain is what turns traceability from a compliance burden into a genuine project advantage.


Requirements traceability in practice — How end-to-end traceability works in regulated projects, which tools have proven themselves, and when the RTM approach reaches its limits: Requirements Traceability at itemis →

Florian Antony

Principal Software Engineer & IT Consultant

Florian Antony is Principal Software Engineer and IT Consultant at itemis. His focus is on software architecture, security engineering and traceability for complex development environments. With many years of experience in automotive and technology projects, he supports companies in implementing the ISO 26262 and ISO/SAE 21434 standards as well as in developing sustainable tool and platform solutions.

More Articles on This Topic

Compliance Was Never About the Document
Blog Requirements traceability

Compliance Was Never About the Document

AI can now produce TARAs, traceability matrices, and safety cases that are structurally complete and terminologically correct. That surfaces a question worth asking: what, exactly, is being verified? The problem is not AI-generated documentation. It is compliance processes that optimize for artifacts instead of the properties those artifacts were supposed to encode.

Read Article
Florian Antony Florian Antony 6 min read