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?
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.
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.
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:
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.