The latest release of Contour, our requirements management tool, incorporates some new features that got me thinking about traceability.
At Jama we use relationship and traceability interchangeably. To us the term “relationship†is much easier to understand than “directional trace†even though it may not be technically correct. (Contour can be set to use whatever term you like).
Traceability sounds complicated, especially if it’s bi-directional traceability. I think that for many organizations the vocabulary is a barrier to understanding and implementing traceability. If it’s not easy to talk about, one would think it’s a pain to implement.
What is traceability?
Traceability is setting up relationships between items in your project that provide value to the team. A common scenario is to setup a relationship from the stakeholder request to the requirement and from the requirement to the design document.
Bi-directional traceability simply means the link goes two ways. If you can see that a requirement is related to a story card, you should see that the story card is related back to the requirement.
These relationships provide quite a bit of valuable information. First, if the project team needs to change the design, they know immediately which stakeholder to talk with. If the stakeholder changes their mind about the requirement, the team knows the exact requirement and design document that need to be updated.
I mentioned the “add value to the team†part because you can get carried away with setting up relationships. For some teams, such as those developing life critical systems, tracing to the code level is critical. If something was changed in the software that’s flying the plane I’m in, I want to be absolutely sure the project team knew every line of code that was affected and what needed re-testing.
For the majority of teams, I suggest tracing between the most critical items on the project. For example, if you are on the hook for an RFP or contract with a client, trace from those items to features and on to use cases and test cases. This required minimal time to setup and provides a great way to demonstrate that the software or product your team is building fulfills the original requirements – and was truly tested, especially if you integrate with an automated test tool.
I suggest tracing to change requests as well. This way every feature being developed ties back to either the original contracted scope – or a change request. This is a great guard against dreaded and costly “scope creepâ€.
Another challenge with traceability is it’s cumbersome to track manually. Unfortunately many of the enterprise RM tools continue to complicate things and make traceability difficult. For the most part these are old applications that have been bought and sold over the years so they’ve missed opportunities for usability updates.
Of course I’m biased toward our own tool, Contour, but we’ve worked to simplify the traceability process. Our goal is to enable more teams to benefits from trace relationships. We’ll continue working with users and continue improving the process of linking items.
This post is getting long so I’ll come back to discuss the new features – “Impact Analysis†and “Changes with Impact†in my next posts.
RSS