Traceability provides the means to ensure that “the intended product is correctly packaged and deployed.” In software CM, traceability answers many questions, including the following: Who changed a particular file?, Why was the file changed?, and Is the change in the latest build?
Higher level advantages accrue when we can view traceability across all artifacts. We might find ourselves asking what new features are in this release, which update broke the build, and whether or not the product quality is sufficient to be released.
To remain competitive, the product team must be able to receive an instant response to such questions; a complete traceability capability will provide the answers.
I’ve seen too many tools that say they provide traceability when really what they mean is if you work hard to enter your data, the tools will let you work hard to get it out in some fashion (See the LinkedIn comments on “What Tooling is Available for Requirements Traceability”). Too much work!
Good traceability requires three components:
Leave out any of these and you’re sunk. You’re either missing data, can’t trust your data, or can’t use your data effectively.
When you address the first component, tools, and data schema, you must support relationships between customer requirements and engineering features and problems (Engineering Change Requests, or ECRs), between ECRs and updates (i.e., change packages), and between updates and builds. On the verification side, test cases must link to requirements, unit tests to updates, and test results to test cases and builds. Everything must be linked to its owner. This is a simple, but capable, traceability model for software CM.
The second component requires good tools that automatically populate data wherever possible. When a tester enters test results, the tools ensure that the results are tagged with the current build context. A good tool will force me to click on a requirement to create a feature and so link it to that requirement. A developer won’t just check out a file, but he does so against a specific (perhaps implied) update. These data captures improve the quality and completeness of traceability data.
The third component requires effective, easy queries and efficient dashboards that simplify data navigation. Can I click on a requirements sub-tree to ask “Which requirements are missing test cases?” Can I bring up a “build comparison dashboard” that lets me select two builds while showing me the differences, in terms of problems, features, and source updates?
If it’s easy to do, I’ll do it. If not, I won’t use the traceability data, no matter how good—especially in an agile shop! With the right links and tools, you will watch your productivity and quality improve. Read more in my CM Journal article, “The Journey through Traceability to Process Control.”
