Requirements Traceability When Maintaining Software: Measured Benefits

Process standards like Automotive SPICE, ISO 26262, IEC 61508, and DO-178B all demand traceability documentation. As a result, all relevant links between requirements and other artifacts in the software development process must be maintained.

Once these trace links are in place, they unlock additional value. Developers and testers can use them to navigate between related artifacts. QA leads and project managers can use them for impact analysis on change requests and all kinds of coverage analysis — implementations covered by tests, requirements covered by implementations, and more.

But can the benefits be quantified? How much does a development team actually benefit from requirements traceability when maintaining software systems?

Do development teams benefit from requirements traceability?

Prof. Dr. Patrick Mäder et al. conducted an empirical evaluation to answer this question. The controlled experiment involved 71 subjects re-performing real maintenance tasks on two third-party development projects — a total of 461 tasks solved.

The findings are striking: subjects with traceability performed on average 24% faster on a given task and produced on average 50% more correct solutions. Traceability doesn’t just save effort — it measurably improves the quality of software maintenance.

Study details

Two existing open-source systems were chosen as subjects: GanttProject (a cross-platform project scheduling tool in Java) and iTrust (a web-based medical records application in Java). Both are of significant size, as shown in the table below.

The experiment included eight distinct tasks — four per software system. For GanttProject, real bug reports from the issue tracker were used. For iTrust, change requests were derived by comparing older and current versions of use case specifications.

Correctness was measured at three levels: incorrect, partly correct, and fully correct. Solutions were accepted if they resolved the bug or achieved the desired outcome, even when the approach differed from the original developers’ solution.

To control what participants could do, a specific tool with integrated development and traceability support was provided. Traces appeared in a separate window, labelled with the artifact names they connected. Clicking a trace opened the related source file and highlighted the traced portion. Traces were also highlighted in the file tree.

Performance results

Subjects without traceability spent an average of 889 seconds per task. Subjects with traceability spent only 678 seconds — a 24% reduction in task completion time.

For correctness: participants without traceability produced correct solutions 50% of the time. With traceability, that figure rose to 74% — 50% more correct solutions.

Participants were also asked open questions about the experience. Many were positive:

• “Traceability really helped me.”
• “With traces available, I found the code sufficiently documented and have no improvement suggestions.”
• “Traceability put my focus on the relevant parts of the code and prevented me from wasting my time with understanding irrelevant code.”
• “Traceability made solving the tasks much easier.”

Several participants requested richer trace documentation:

• “Sometimes traces confused me. It would be nice to have comments for them.”
• “Provide an overview and information on traced methods.”

Other suggestions:

• “Trace more directly to the impacted code and not only to a method’s corpus.”
• “Allow to search within the traced code.”
• “Provide a visual overview of documents and highlight relevant regions.”

Conclusion

Traceability led to a 24% efficiency gain and 50% more correct solutions. All but two participants reported feeling supported by traceability during the tasks.

It’s important to note that this study covered only a subset of traceability usage scenarios. In a related survey on “Usage Scenarios for Requirements Traceability in Practice” by Patrick Mäder et al., 29 distinct usage scenarios were identified across six groups:

• Requirements Engineering and Management
• Project Management
• Compliance Demonstration
• Design and Implementation
• Testing
• Maintenance and Evolution

When asked why they applied traceability in their projects, participants pointed overwhelmingly to development activities (80%) — confirming that better tool support would unlock even greater benefits.

The data is clear: the quality of tool support has a direct impact on the benefits teams can realise from traceability. A dedicated traceability tool that scales with your project isn’t a nice-to-have — it’s what makes the difference between traceability as overhead and traceability as a competitive 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 →