What is Traceability in Software Engineering?

The article was originally published on 06/17/2019 and was updated on 10/18/2024

In software engineering, convoluted code can behave in seemingly nonsensical ways. Software engineering often lacks interconnection between existing requirements, the source of those requirements, and the underlying system infrastructure. This situation is a source of frustration for users, developers, and software engineers alike. Traceability in software engineering provides the framework you need for establishing clarity and consistency and also, providing regulatory compliance. Traceability will enable you to keep track of each element and create consistent links between them throughout the development lifecycle. This article explores the notion in a little more depth. What is traceability in software engineering? What about Requirements traceability?

1. Definition and Purpose of Traceability in Software Engineering

2. Requirements traceability in Software Engineering

3. The Characteristics of quality traceability

4. Finding a solution to achieve requirements traceability in software engineering

Definition and Purpose of Traceability in Software Engineering

Traceability in software engineering describes the extent to which documentation or code can be traced back to its point of origin. The goal of traceability is to provide better quality and consistency in product development. It brings the ability to verify the history, location, and application of an item by means of documented identification.

In complex system industries like aerospace or defense, traceability is often a legal constraint to prove standard compliance of deliverables from stakeholder requirements to qualified products. Not only is traceability mandated for safety-critical systems but without it, it is quite challenging to maintain consistency from early user requirements to the final phase of tested and delivered products.

Requirements traceability in Software Engineering

The now widely democratized use of modeling in engineering makes classic approaches less relevant as surrogate assets are imported from authoring tools.

Using requirements tooling as the only focal point of traceability implies flattening authored models and counterproductive mass conversions during design phases. By formally recording the relationships between all elements in the engineering process, we can identify the impact a change in one element will have across the whole project. This impact analysis immediately identifies which parts of the architecture, design, tests, or software need to be changed in order to adapt to a requested or mandated change.

It is still very common for a project to be forced to retroactively and manually recreate traceability at the end of the project in order to deliver it. This assignment requires engineers to stop all other activities, or may even require hiring external resources, to create Excel spreadsheets (or other documents) to capture the links across engineering artifacts and software. Not only does this make the engineering team less effective and responsive rather than proactive, but it typically results in unexpected supplementary expenses.

So, requirements traceability allows teams to benefit from early impact analysis.

The Characteristics of quality traceability

Any type of traceability is better than no traceability. However, there's a broad spectrum here, with some companies leveraging standard spreadsheets as tracing matrices while others opt for third-party solutions. Despite this variation, several characteristics describe quality traceability solutions:

Origin Points — Who proposed specific requirements? When were they implemented? Tying current requirements back to their origin points provides the framework for critical cross-linking and references.
Key Associations — How are requirements interrelated? How does changing or adding code impact overall software functionality? Quality traceability details any dependent associations between existing requirements and ensures new requirements are similarly detailed.
Forward and Back — In practice, this means that existing requirements tie back to preceding requirements, effectively creating a "chain" to origin points, while also ensuring previous requirements "fall forward" to describe next-in-line requirements.
Technical Specificity — In addition to basic descriptions, quality traceability solutions must include connections to relevant code sections, their location, and any critical testing performed.
Auditability — Ultimately, traceability must provide assurances that stakeholder expectations have been met and that no unspecified features have been added to (current) end results.

Finding a solution to achieve requirements traceability in software engineering

It’s time that we increase engineering productivity while enabling standards compliance. Requirements traceability tools make it easier to establish trace relationships between artifacts.

Some all-in-one solutions such as IBM ELM provide integrated tools that work together to deliver full traceability across the engineering process.

However, for teams working in specialized solutions such as Jira for change management, IBM DOORS Next for requirements management, and Siemens Polarion Test Management, providing traceability capabilities is not as easy as it seems.

With OSLC Connect for Jira, you can bridge the traceability gap across your development applications. Build relationships between Jira issues, DNG requirements, and Polarion test cases, and provide complete traceability across your artifacts.