Applications Services Blog
Get the latest thought leadership and information about the role of Applications Services in an increasingly interconnected world at the HP Blog Hub.

Focus on Fundamentals (#25) – The Four Laws of Traceability


By: James (Jim) R. Hughes, Global Business Analysis Capability Leader, Hewlett Packard Company

 

Author’s note: The Focus on Fundamentals blog series addresses the challenges that limit applications solution delivery success.

 

 

ski trails - compressed.jpgThe first blog I wrote in this Focus on Fundaments series was on the topic of traceability—End-to-end Traceability. It is time to re-visit the topic of traceability.

 

There are four Laws of Thermodynamics which describe and regulate how physical systems behave. In the same way, there are four Laws of Traceability which describe and regulate how application development projects should manage traceability if they want to be successful.

 

0th Law of Traceability – No Artifact May Exist in Isolation

There can be no uncaused first causes among the artifacts in a system development project. Business (scope/high level) requirements exist at the top of a configuration item hierarchy. However they do not exist of their own accord. Rather, they exist to satisfy needs of users, and each of them maps to a cause outside of the requirements documented in the requirements management (RM) tool. For example, a requirement which states, “The system shall provide the ability to receive payments with any of three (Amex, Visa, MasterCard) standard credit cards.” will be sourced from and mapped to an RFP statement, to an organization’s business policy or procedure, or to the minutes of a requirements elicitation session.

 

Every artifact produced by the project that is not a business requirement will be explicitly traced to one or more other artifacts in the system traceability matrix. Widows (i.e., artifacts with parents, but without dependents) can exist in the system analysis and development tool repositories only if they are in a draft status, have an explicit statement indicating that they are out of scope or deferred, or are at the lowest level of the taxonomic hierarchy (e.g., detailed requirements during the analysis phase, or derived work products such as code modules and training modules, or individual test cases).

 

Orphans (i.e., artifacts with no parents) cannot legitimately exist anywhere in the system analysis and development tool repositories. From the moment any artifact is identified, created, and defined, it should be linked into the end-to-end traceably matrix and associated with the appropriate parent(s). For example, when a code module is checked into a source code management tool, it should be associated with a design component, which in turn is associated with a detailed requirement (e.g., a narrative statement, a use case, or business rule).

 

1st Law of Traceability – Every Artifact Must Trace to Requirements

This Law of Traceability follows logically from the previous. The creation of a traceability matrix does not apply to requirements only. Even though we often use the term ‘requirements traceability’ that does not mean that only requirements should be traced. It means that every artifact created by a system development project must be linked (directly or indirectly) to requirements in the end-to-end traceably matrix.

 

Since artifacts (requirements, source code, test plans, help modules, etc.) may be stored in different repositories, system development teams should have a means of associating artifacts among the repositories. This can be accomplished with a single logical Configuration Management Data Base (CMDB) which stores attribute data about all artifacts with links to their instantiation, through a federated CMDB, or through a set of routines which generate a current end-to-end view from multiple repositories as an iteration or release is assembled.

 

2nd Law of Traceability – Traceability Must be Current

Creation of a traceability matrix should never be a post hoc event, completed during a system documentation phase. Creation and maintenance of the relationships in the traceability matrix must be built into the discipline of every role in a system development project (e.g., when a requirement is created, a code module is checked in, a test case is added, or a training module is checked in). It should never be a ‘catch-up’ activity.

 

If a single repository isn’t being used or a federated CMDB isn’t in place, then the generated traceability matrix should always be as current as the most recent build. This applies whether a team is working in a traditional ‘waterfall’ development mode, using iterative or agile processes, or configuring a COTS product.

 

3rd Law of Traceability – No Excuse is Acceptable

There is no excuse for not having an up-to-date traceability matrix. The often heard excuse that maintaining a traceability matrix requires too much effort (and costs too much) is bogus! Once creation and maintenance of traceability relationships is built into every artifact development process, the cost per artifact is negligible. And, the total cost of doing it right from the start is a fraction of what it costs to create a traceability matrix at the end of a project when knowledge leaks have already been experienced during project ramp-down.

 

If these four Laws of Traceability are not applied with strict commitment and discipline, projects cannot:

  1. Create consistent system builds—they cannot be sure they have all the necessary components, nor the correct version of each component.
  2. Manage scope effectively—they cannot determine if a new requirement explicitly fulfills a business need and is within scope.
  3. Define ‘done’ accurately—they cannot be sure that the delivered components fulfill the approved business requirements.
  4. Complete impact assessments reliably—they cannot determine if they have identified all the components which could be affected by a proposed change and what the cost of the change will be.

It continues to amaze me that project teams appear not to have an understanding of value of traceability. But there is hope. We can learn from our errors and apply the four Laws of Traceability.

 

Previous Focus on Fundamental blogs by Jim Hughes:

Previous blogs in the Producing Quality Software series by Jim Hughes

Other blogs by Jim Hughes:

About the Author

 

Jim-150X210.jpgJames (Jim) R. Hughes, Global Strategic Capability Leader, Hewlett Packard Company

Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Analysis and Configuration Management. Jim also manages a team within the US State, Local, and Education division of HP. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He currently lives in Toronto, Canada.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Ana...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation