Enterprise Services
Showing results for 
Search instead for 
Do you mean 

The Four Laws of Traceability

‎07-21-2014 05:59 AM - edited ‎09-30-2015 07:05 AM

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


Author’s note: My blogs address the challenges that limit applications solution delivery success, and how to overcome them.



ski trails - compressed.jpgThe first blog I wrote 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.


Other blog postings by Jim Hughes, which address the challenges that limit applications solution delivery success, and how to overcome them:



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.

About the Author


Jim has been with HPE for almost 35 years and leads a matrixed global Strategic Capabilities Management team. His specific focus is on the Business Analysis capability. Jim is also a member of a team within the US Public Sector division of HPE, responsible for delivering application software to Federal and State governments. 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 lives in Toronto, Canada.

Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all