Software development blogs and media outlets the world over have been discussing the topic of traceability extensively for ages. Still, we're seeing continuous interest in ensuring traceability. And for good reason: there's no silver bullet solution to this problem that's becoming more and more difficult as the complexity of development lifecycles is growing.
What's traceability?
First off, let's tackle the fundamentals. While there are countless definitions out there, the IEEE Standard Glossary of Software Engineering Terminology aptly defines traceability as:
“The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.”
So the basic objective of traceability is to link user needs to work items across the development project, all the way through to test cases and releases. If you manage to clearly link your requirements to tasks, to source code, to documentation, to test cases and releases, you have complete (forward) traceability. Ideally, this will allow you to track things the other way around, letting you trace back each and every feature in your product to an initial user requirement (backward traceability). Traceability is a cornerstone of modern requirements management.
Sure enough, in the case of simple projects, with no more than a few simple user requirements, this shouldn't be a problem. As you start adding sophisticated features of elaborate software or devices, geographically dispersed teams, various suppliers, interconnected lifecycles and so on, that's when traceability starts to get tricky.
Complexity or traceability: do you have to pick one?
And this is really the key to the continued interest in traceability. With the advancements of the software development industry; with the possibilities opened by connectivity to the Internet of Things; with the reaction time cut by Agile; with devices getting smarter and smarter through embedded microcomputers – development projects are getting more and more complex. And with increased complexity comes the greater difficulty of maintaining traceability.
Related webinar: Agile Requirements & Development Management from User Story to Test Case
This is the point where you'll probably start thinking whether the MS Office documents and spreadsheets that your team has learned to live with are really going to work out in the long run. More and more companies respond to that question by migrating to dedicated tools that help them achieve end-to-end traceability in their projects. The sooner you switch to a smart application that helps you ensure complete traceability by managing your requirements and other work items, the sooner you can start reaping the benefits, saving yourself a good deal of trouble in the process.
Full transparency: historical, artifact and project traceability
To explain why traceability is really that important, we're going to be borrowing codeBeamer's multi-layered approach that differentiates 3 levels of traceability:
Historical (item) traceability
The history of each and every work item should be tracked, so that changes can be controlled and all versions browsed.
Artifact (lifecycle) traceability
As mentioned above, development artifacts should be referenced to each other. The linked artifacts should outline the whole development process, providing end-to-end traceability throughout the lifecycle. For instance, user stories should be linked to requirements, tasks, source code, documentation, test cases, and releases.
Project traceability
The third and highest level of traceability results in complete project transparency. All the details of the entire process and work history should be stored and accessible any time – for example, codeBeamer uses baselines to take snapshots of your project, with all its work items (and their change history), all the documents, data, comments, communication, etc.
Thus, you'll have a high-level overview of how your projects are progressing, as well as detailed insights on each and every item, and how they're progressing through the development lifecycle.
Why bother with traceability?
Considering the benefits associated with traceability, it's no wonder that most development teams strive to achieve it:
- Traceability helps impact analysis and change management – when requirements are changed, the affected work items are easier to identfy
- Similarly, any (planned) feature in your final product can be traced back to user requirements, to minimize overhead in terms of costs and time
- When a defect is detected, its causes can be easily identified by tracing the problem back to its roots. In case the issue is caused by imperfect requirements or design for example, these can be fixed instead of just treating the symptoms – then, these changes can be analyzed to see what other items are impacted.
Overall, it's not surprising that the topic of traceability continues to be one of the most widely discussed topics. In fact, with the increasing popularity of IoT, it's likely to gain more importance and coverage in the future. As project complexity drives the need for requirements management tools, more and more companies realize the benefits of adopting an advanced ALM solution such as codeBeamer to manage requirements throughout the development lifecycle. And with our free 30-day trial, you really don't have much to lose.
Download our ebook:
10 Success Factors of Future-proof Requirements Management
