Connect the Dots: 5 Tips on Traceability to Skillfully Control Change and Improve Quality
by John Simpson and Eric Winquist
What is traceability? It sounds complicated. Why do teams do it? It sounds like a lot of work. Is it really worth the effort? Good questions. The short answer: Yes. And, here’s why it’s so important: Change happens.
If managed poorly, change will wreak havoc on even the most talented and experienced development teams. If managed skillfully, using tools like traceability, teams are better equipped to assess the impact of changes, track the full history, keep everyone in sync and (deep breath) consistently improve the quality of the products being built – every project, every release. Sign me up.
| Attachment | Size |
|---|---|
| 5_Tips_on_Traceability.pdf | 387.57 KB |
It Is Complicated
And it is tedious, and no-one (I have met) wants to do it, although we know that it is necessary.
Biggest downfalls with traceability tools:
- how do you stop users from tracing the wrong things? Users will trace anything to anything, for the most tedious of reasons. Does your tool allow me to stop test cases being traced from a project vision, for example?
- security. Can I configure the tool so that only the assigned roles are allowed to create their assigned trace relationships? Testers trace test cases for example.
- the majority of my traceability relationships are not in text form. I need to know if any component in a diagram changes, what are the impacts to the requirements? Can I link activities to textual use cases, for example?
Recent releases of Rational tools have even made inroads to address the final bullet.
But the biggest omission has to be the ability to configure your process within your requirements management tool - first bullet. I consider this to be akin to allowing developers to deploy code using any compiler and coding standards that they wish.