Ten Commandments of Traceability
How did traceability become so revered and hated at the same time? Is it just because it’s hard? Are the people who come up with it hard-nosed? Are the folks who complain about it just hard-headed? Or are the activities performed and constraints imposed in the name of traceability simply stated too “hard and fast” with little room for flexibility.
Like it or not, many interpret traditional traceability and CM as rigidly mandating the following “ten commandments” upon the development process:
- Thou shalt create and maintain linkages between every requirement to all other requirements that it impacts or decomposes into
- Thou shalt create and maintain linkages between every requirement and every configuration item that participates in realizing the requirement
- Thou shalt create and maintain linkages from every requirement to all design elements and interfaces that describe or model its implementation
- Thou shalt create and maintain linkages from every design element and interface to every source code line and module that implements all or part of the design element
- Thou shalt create and maintain linkages from every requirement and interface and module and subroutine to every test-case and test-module and test-subroutine that verifies the requirement is correctly implemented in the product
- Thou shalt track and record every request for change (be it for corrective, perfective, adaptive, or preventive purposes) and not allow any changes to any artifact without first ensuring that the change was approved and developer was authorized to make it
- Thou shalt create and maintain linkages from every change-request to every corresponding piece of documentation and code/test that is created or modified, along with who made the change, when, where, and why and with verifiable (via audit) evidence that the proper process and procedures were executed to ensure mandated appropriate levels of control and peer review.
- Thou shalt create an maintain linkages from each change request to its corresponding tasks and the corresponding changes for each task
- Thou shalt create and maintain linkages from each change and change-request into the sets of artifacts, elements, codelines, builds, projects, and variants into which it is incorporated
- Thou shalt keep all the above data consistent, correct, and complete at all times, and use it to generate any reports or audits necessary upon demand
Most of these are things that can and should be accomplished if traceability exists. Many of them seem much harder or more effort intensive than they really are (or need to be). In other cases, the relative ease or difficulty may be matter of the level of detail to which something should be traced. If things are done without keeping in mind the intended purpose and business use of traceability, then many complaints and inefficiencies can result.
Nine Gripes against Traceability
So what exactly are the things that so many developers, and more recently, some of the agile and lean camps don’t like about traceability? Common complaints are as follows (decide for yourself whether they are invalid or justified, or if there is a better and easier way:
- It causes more artifacts, more overhead and more work to create and maintain traceability matrices that are going to get hopelessly out of date because changes are inevitable
- It encourages “analysis paralysis” and heavy “up front” planning and design
- It imposes unnecessary restrictions upon the speed and productivity of development
- It is a fool’s errand that amounts to smoke and mirrors to provide an illusion about control and certainty regarding mostly redundant pieces of information already in the code and the tests.
- It goes against the values in the “Agile Manifesto” because traceability emphasizes comprehensive documentation