What is a traceability matrix ? Part two
In the first part we discovered the concept of traceability matrix. Today we’ll see the different kinds of matrix used to ensure the consistency of the project.
This article is available in French : “ Qu’est-ce qu’une matrice de traçabilité ?”
This is the second of a two parts article. The first part is available here.
Vocabulary
Before going further, let’s check some definitions of concepts we mention in this article:
Requirement
The requirement is a detailed description of a single element of the customer needs. It is like an item of the customer shopping list that can be checked as done.
Request for proposal (RFQ)
This is the document where the customer lists all the requirements describing his need.
Specification
A specification is the detailed description of an item of the solution. And so, what we call specifications is the document listing all the specifications matching the request for proposal.
The name of such item or document may vary depending on the field of activity of one company. We chose to use “specification” here as it is the most frequently used noun we encountered.
The other traceability matrices
We can change the point of view of the matrix to observe the project’s traceability from another angle to ease its management.
Upstream Traceability Matrix
We saw the customer’s point of view with the downstream traceability matrix. Let’s check the supplier’s with the Upstream Traceability Matrix.
On the left, we list the supplier’s specifications in the order they appear in the specification document delivered to the customer, avoiding making duplicates.
On the right, facing each specification, we list all the requirements it covers. This time, it is OK if there are duplicated requirements. It tells that one requirement is covered by several specifications, proving the supplier’s solution is strong and relevant.
This point of view shows if all the specifications cover the requirements and how many requirement are covered by each specification (we will see that sometimes a specification covers nothing)
So in the project’s roadmap, specifications covering the highest number of requirements can be prioritized. In our example, it can be strategic to develop supplier specification 1 to rapidly cover several requirements. Consequently, we can faster reach the minimum valuable product to show the customer. Then we iterate upon it by adding more and more features (aka specifications).
Non-covering specification matrix
It happens that the supplier designs additional specifications covering no requirement. Strange isn’t it?!
Not necessarily. Those orphan specifications may describe constraints for the supplier independent from the customer’s need. But the supplier want to mention them on the specification document to share them with its customer.
For example, the supplier is used to a software, he can tell his customer he will use it through a specification. So that specification will be mandatory without covering any need.
Or the supplier has a special discount for specific components, so he tells thought a specification that he will use this brand over another.
Last example: reading the RFQ, the supplier identifies a hidden need that doesn’t appear in the customer’s requirements. He can add it in his specifications.
He could put those orphan specifications in the upstream matrix, but they would face no requirement. That could bring doubt upon the document: is it a mistake? Is it normal?
To avoid those questioning, the best is to create a new table listing only those non-covering specifications.
Evolutions
It is inevitable! Whether the RFQ or the specification document are intended to evolve. Because the need is more mature, because of the discussions and new ideas come out or bring corrections…
In the document revision #2, some requirements have been updated. But not all of them. So what? Should we read the whole document again? The 200 pages? To only find 3 or 4 modifications?! No! Because there is an evolution matrix!
This matrix doesn’t connect two different documents, it links two revisions of the same document! For example, let’s imagine the RFQ has had 3 modifications as follow:
Warning! There are some tiny new details!
We always have the requirement title (or ID). But there is now a comment column. An update can be of several kind, some are obvious, some can easily be missed. That is why having a comment column can bring highlights.
A deletion
The customer has simply deleted a requirement. It was no longer required or what it described was non longer needed. A deletion in a 200 pages document might be missed. But its impact on the project might be huge because all the specifications that used to cover it are no longer needed either. Therefore they have to be deleted too to avoid useless costs. Besides the planning may be updated too!
I highly advise to keep this deleted requirement in the downstream matrix. But instead of keeping the covering specification, replace them with the comment “deleted” in the specification column. It might be redundant but at least it won’t be forgotten.
An update
A previously existing requirement has been updated. It shall be highlighted because this evolution might have an impact on all the specifications that used to cover the previous revision of this requirement.
We can add a revision number to the requirement’s ID to show its level of update : “Customer requirement 3.2 “.
Besides, this would be a good practice to add this revision number to all the requirements. By convention, the original revision of a requirement would be the number 1 : “Customer requirement X.1 “ (You can choose .0 as the number of the first iteration. It doesn’t really matter, as long as you stick to your convention through the project).
A new one
The customer has added a new requirement to detail his need. Just like the other evolutions, without further indication a new requirement can be missed in a 200 hundred page document. Because a new requirement imply the definition of new specifications, its creation shall appear in the evolution matrix, otherwise you may fall through the net. Or as we say in french you get a “trou dans la raquette” (a hole in the racket).
Long story short, any evolution described in the evolution matrix can, and shall, be also described in the other traceability matrices. It will produce duplicated information but allows you to double-check the consistency of your documents. If you find a loss going from one to another, then there might be a bug in the project. If there isn’t, then you have a very clear view on the project’s management.
OK but what if there is a third revision of the document?
We still talk about the evolution matrix between two revisions of the same document. First of all, it is totally fine to have a third, a fourth, etc revision of a document. Documentation is a living entity, the blueprint of your project. On some projects, I have already had up to seven revisions for the same document, it’s usual business.
So if you have a third revision (v3) then you should make an evolution matrix showing the updates between v2 and v3.
It is not mandatory, but it can be helpful to keep all the evolution matrixes in every new revision. Like this, you’ll have a complete historic of your document without having to open all the previous revisions to have the big picture. But beware, in the end, it might be a lot of matrixes!
The Fantastic Matrixes and where to find them
Let’s draw another table to explain where and how to draw those matrixes:
Conclusion
The traceability matrix is a very powerful tool! It provides an exhaustive view on the customer’s need’s coverage; ensures that nothing is forgotten and allows the project to be customer’s-evolution-proof and makes it resilient.
But what if I told you we only scratched the surface ?
Indeed, we considered the links between the customer’s requirements and the supplier’s specifications. But in the process of a project, this is just the first step. Then more detailed specifications can be written (functional specifications for example) then design document, validation plan, etc. All of them are connected and the links between all those documents shall be tracked too for the same reasons.
Here is for example a schematic view of the documents and their links we can have for a software development project following the V-model of management.
In those two articles we have just talked about the green little connection between the first documents of a project (see in the top left corner of the figure)!
But no more drama. The concepts presented here are relevant for all the links. Some of them may require some adjustments. We may have some slightly different matrixes for them. But let’s stop here for the moment.
The more complex or the bigger a project is, the more documents it has. It will require more and more strictness to build the matrixes without forgetting anything and ensure the customer’s need is 100% covered. Among other issues, building trusted matrixes and getting a consistent documentation is why we created Naept which does it automatically (and so much more!).
What about you?
Did you know the concept of traceability matrix?
How to you check you coverage of the customer need?
Do you use other kind of matrices?
How do you manage your documentation evolutions?
Do you have specific software solutions?
Originally published at https://www.naept.com on September 25, 2020.
