Traceability matrix

Question on softwaredioxide.com, posted October 2002

Questions:

• What is a traceability matrix?
• Where can I get information regarding traceability matrix?
• When is the requirement for implemention traceability matrix?
• Are there any companies that are implemention traceability matrix?

My reaction:

I think you can easily answer the questions yourself, if you understand the basic idea of traceability and of a traceability matrix. Traceability means that you would like to be able to trace back and forth how and where any workproduct fulfills the directions of the preceeding (source-) product. The matrix deals with the where. The how you have to do yourself, once you know the where.

Take e.g. the Requirement of UserFriendliness (UF). Since UF is a complex concept, it is not solved by just one design-solution and it is not solved by one line of code. Many partial design-solutions may contribute to this Requirement and many groups of lines of code may contribute to it.

A Requirements-Design Traceability Matrix puts on one side (e.g. left) the sub-requirements that together constitute the UF requirement, along with other (sub-)requirements. On the other side (e.g. top) you specify all design elements. Now you can connect at the crosspoints of the matrix, which design solutions solve (more, or less) any requirement. If a design solution does not solve any requirement, it should be deleted, as it is of no value.

Having this matrix, you can check whether any requirement has at least one design solution and by checking the solution(s) you may see whether the requirement is sufficiently solved by this (or the set of) connected design(s).

If you have to change any requirement, you can see which designs are affected. And if you change any design, you can check which requirements are affected and see what the impact is.

In a Design-Code Traceability Matrix you can do the same to keep trace of which code solves a particular design and which changes in design or code affect each other.