What is traceability and why is it important?

Traceability is a sub-discipline of requirements management within software development and systems engineering and it mainly serves the purpose of accelerating and improving development activities. As a result, it also prevents software defects by visualizing relationships between components. Let’s describe a few use cases to better explain traceability and why and how you can use it to your benefit.

Tracing back your change requests

Software teams change or improve their code on a daily basis, sometimes this is initiated from a change request (CR). A CR might originate from a customer demand to change the behavior of the system, just as product management or end-users of your product can initiate such a change Request. Or maybe it’s the customer support team that comes up with bright product improvement ideas.

That’s where the benefits of traceability come in. Depending on how your development process is organized, a CR request will likely trigger various activities. Assuming your process is well organized you will be able to track all these activities that took place from the initial CR down to the end of the release of the changed product. When the product requires an update, the elements that need iteration can easily be tracked back to their source.

Easier compliance to industry standards

If you’re a company that builds systems for a safety critical Industry like Medical, Automotive, Avionics or Industrial, then it is essential to setup the development process in accordance with the established safety standards and regulations, or at least start the process to becoming so. For automotive, one of these standards is the ISO 26262. Companies in all industries must comply with similar safety standards that are relevant to their industry and traceability is key.

Software Requirements Specification

Projects usually start from an idea, after which there is a long way – often longer than expected – between idea and product release. When it comes to software development, writing the Software Requirements Specification is a good start. Once you are able to describe the exact functionality of the system you can start finetuning by defining an architecture that matches these specifications. The architecture is defined for both the hardware and software components. By decomposing the system requirements you can further clarify the various functions.

When these requirements are logically linked to each other (different levels) it becomes possible to estimate/calculate the impact of a change to the system, this visibility will help to define the project priorities.

At a certain stage the software and hardware functions will be created. As they are linked to (software) requirements a traceability report can be generated to provide full traceability uncovering functions (code) for which no requirements can be found. This code should either be removed or the requirement must be created. This kind of traceability report provides instant insights on the project status and progress made over time.

Traceability can be manually established with a simple tool like Excel, but as projects evolve into dynamic systems a more automated approach, like an ALM tool, offers significant benefits. ALM systems provide an overview of the functionality and support during the entire software development cycle (SDLC) and provides additional features of interest to all stakeholders within the project, like the estimation of cost and time needed to develop the product. Other features that might make you consider using ALM software is the ability to prioritize features based on a product’s key market preposition, better understanding of the problems at hand and how to solve them, as well as easy task management and quicker deployment.