What is a traceability matrix? Part one

In a customer request for proposal, the need is usually given through a list of requirements. The supplier sends back a proposal showing his solution through a list of specifications. The coverage between requirements and specifications can take different shapes:

• 1 to 1: one specification covers one requirement
• 1 to many: several specifications are used to cover only one requirement
• Many to 1: several requirements are covered by one specification.

But in practice, it is rather a mix of the three leading to a maze of coverage. Fortunately the traceability matrix shows up to bring some order.

This article is available in French : “ Qu’est-ce qu’une matrice de traçabilité ?”
This is the first of a two parts article.

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 need. 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 them here as they are the most frequently used nouns we encountered.

Traceability, this entangled mess

A document size can vary a lot depending on the different fields of activity it deals with. To explain this, I will take an example I know well. Consider a request for proposal (RFQ) about an aeronautic calculator. Please don’t leave yet! I’ll make it clear.

In a plane, there are dozens of calculators. Those are computers without a screen or a keyboard. They manage everything, from the air conditioning to the brakes, the doors, the electrical power distribution, etc. Whether their tasks are complex or very complex, their request for proposal can easily reach a hundred pages and hundreds of requirements. Several expertises are involved to describe all the requirements. For example:

• electronics for the circuit boards
• mechanics for the case housing the circuit boards
• developers for the embedded firmware of the circuit boards
• etc.

Then this RFQ is sent to a supplier. He will study it with his teams to build the specifications. Sometimes several requirements can be covered by the same specification.

Many to one

Customer requirement 1: the circuit board shall be hermetically protected
Customer requirement 2: the case shall have the following measurements : X, Y, Z

Supplier specification 1: the case shall be from the brand B and the model M

Therefore the supplier specification hits two birds with one stone because the chosen case matches both the requirements.

One to many

But sometimes, it is the other way around! The requirement is so complex, it requires several specification to be fully covered:

Customer requirement 3: the circuit board shall be fully operational while the plane is flying (it’d better be).

Supplier specification 2: the electronic components of the circuit board shall be from the S series. The S series components stay operational even at temperatures below -50°C (this is the outdoor temperature at cruising altitude).

Supplier specification 3: the case shall have an S shield to protect the circuit board from electromagnetic fields.

Supplier specification 4: the case shall be mounted on suspending plot to protect the circuit board from mechanical vibrations.

So we see here that the complexity of the coverage between requirements and specifications can quickly increase. Just like a spaghetti dish!

It is highly advised to track every coverage links between requirements and specifications using a table. It will allow us to check if no requirement has be left aside, to check that the specifications match the need and have a precise estimate of the project costs. This is what we call a traceability matrix!

OK but how exactly ?

A traceability matrix is an two-columns table where are exhaustively listed every coverage link between every requirements and every specifications. Our previous example would give the following matrix:

Downstream traceability matrix

On the left, there is the list of the customer’s requirements in the same order they appear in the RFQ. There are given by their title only (or their ID) to avoid an overloaded table.
On the right, for each requirement, the list of the covering customer specifications.

It is very important that on the left column, each requirement appears once and only once. The purpose here is to ensure every requirement is covered by at least one specification.
On the contrary, on the right column, we observe the supplier’s specification 1 is listed twice. This is absolutely normal as this specification matches both customer requirement 1 and customer requirement 2.

We can say this matrix adopts the customer’s point of view. It goes from the RFQ to the specifications, that is why it is called the Downstream Traceability Matrix. Once completed, we know exactly the coverage of the customer need. And if one requirement as no specification match, we know the specification document isn’t complete.

But be careful as the devil always hides in the details! The traceability matrix can only tell if a requirement is covered by a specification. I cannot tell if this specification IS ENOUGH to cover the requirement.
Let’s consider again the customer requirement 3. We see it is covered by the following specifications:

• Supplier specification 2
• Supplier specification 3
• Supplier specification 4

For example, if the supplier specification 4 is omitted, from the matrix point of view, the customer requirement is still covered. But in reality, without the specification 4, the product wouldn’t match the need.

To conclude, the traceability matrix is very powerful to check the coverage quantitatively. But it remains the supplier’s job to ensure the quality of his specification coverage.

This is the end of the first part. In the second part of the article, we’ll see what are the other matrices we can use to ensure the consistency of the traceability.

Originally published at https://www.naept.com on September 11, 2020.