+64 4 499 1701
Mon - Fri: 07:00 am - 05:00 pm
Psoda is bridging the gap between physical and electronic kanban boards
Learn More
Psoda is bridging the gap between physical and electronic kanban boardsLearn More
Psoda Traceability Matrix Screenshot

Written by Bruce Aylward

Bruce is Chief Everything Officer at Psoda and an award winning ICT leader. After starting life as a rocket scientist he created Psoda and has been taking the product to the world for over 10 years.

I met a project manager today at a networking event. We did the normal introductions and I explained what we are doing at Psoda. Then he dropped the bombshell:

“So what is traceability anyway and what does it mean to me?”

At first I was shocked that a project manager wouldn’t know what traceability was. When I thought about it a bit more it made sense though because not all projects need traceability. On the other hand most projects can benefit from traceability.

What is traceability?

At its simplest traceability allows you to find your way around your project information. For example one high-level requirement may be broken into a number of detailed requirements. Traditionally the high-level requirement would live in a different document from the detailed requirements. To keep the relationship or traceability between these requirements you have to add a connection or trace between them. In the detailed requirement specification you could add a column showing the high-level requirement associated with each of the detailed requirements.

The only thing that is constant in a project is change. So when a high-level requirement is changed it will be necessary to find all of the derived requirements and make sure that they are still valid. If you want to find all of the requirements derived from a specific high-level requirement you must then search through every derived requirements specification for those detailed requirements with the associated high-level requirement. If you had only one detailed requirements specification this would be ok but what happens when you’ve got ten or more derived specifications? It becomes a bit of a pain.

Traceability Matrix

The next step is to create a traceability matrix. For example:

Example traceability matrix.

Place all of your requirements along both axis of a matrix. To show that requirement SEC_01.1 is derived from requirement SEC_01 you do the following:

    1. Find the row with SEC_01 in the left-hand column
    2. Follow that row to the right until you find the column with SEC_01.1 at the top
    3. In that cell you place and arrow to show the relationship or trace

Of course requirements cannot be derived from themselves so the diagonal of the matrix is blacked out. Ignoring the colour coding in the example above you have a basic traceability matrix.

To find all of the requirements that are derived from a high-level requirement you now only have to find the row for the high-level requirement and follow that row to the right. Each cell with an arrow in it will indicate a derived requirement.

What about finding any high-level requirements that have been forgotten and do not have any detailed requirements defined yet. If your requirements live in different documents as I described earlier you’d end up having to make a checklist of all the high-level requirements and then go through each of the detailed requirements and tick of all of the high-level requirements that have detailed requirements defined for them.

With the traceability matrix it is a simple matter of finding any rows that have no arrows in them at all. In the image above you can easily see that SEC_03 has no derived requirements. In Psoda the row is automatically coloured rose to highlight that this requirement has no derivatives for it. Alternatively you can easily find requirements that have no determinants or parent requirements associated with them. Just look out for columns with no arrows in them. Once again these columns are automatically highlighted in rose to make it even easier to spot them.


Of course you don’t have to stop with requirements. Depending on the type of project that you are running you may be creating test-cases to test the functionality as defined by the requirements. In this case you want to extend the traceability to those test-cases. In the image above the test-cases are identified with a TC_ prefix.

All the same principles we had just been discussing with regard to requirements now also applies to the relationship between requirements and test-cases. For example to find any requirements that do not have test-cases derived yet you just find rows with no arrows underneath the test-cases in the matrix.


Let’s get back to the problem of change. Your customer will change their mind about some of the high-level requirements half-way through the project. If you are running an agile project and haven’t elaborated those specific requirements yet then you’re ok. But more likely they will change their mind about the requirements that you have already done detailed analysis for and have all the design and test-cases written already.

In this case you will have to trawl through every project document trying to find all of the derived requirements, designs, test-cases and other project artifacts and then update those to reflect the changes to the higher-level requirements. But updating the derived requirements may impact other requirements, designs, test-cases, etc. again. You have to start again and find those secondary impacted items and update them accordingly. This process will have to be repeated until you’re sure that all the possible implications of the high-level changes have been identified.

Change is painful!!!

Psoda automatically determines all the project artifacts that are impacted when you change a requirement all the way down the traceability tree. In the earlier example traceability matrix the red arrows indicate that the parent requirement (in the left-hand column) has changed at some time. The trace is suspect, i.e. you need to treat the derived requirements or test-cases with suspicion. When the derived requirement or test-case is updated then the arrow goes back to green, i.e. no longer suspect.

It is now very easy to see which items still need to be updated due to a change in scope. In our example SEC_02 has been changed. Going along the SEC_02 row we see the arrows to SEC_02.1 and SEC_02.2 are red showing that the change still needs to be propagated. From SEC_02.1 and SEC_02.2 in turn we can see that TC_03 needs to be updated.

If you’re looking for an awesome tool to help you manage traceability, check out Psoda. You can try it free for 14 days. To sign up, click on the big red button at the top right hand corner of the page.


  • March 30, 2008

    Hung V. Nguyen

    I’ve just started to work on my graduation thesis of SCM. Can traceability be an adequate area of research to fit in my thesis? If yes, could you please suggest to me some directions. Thank you.

  • April 5, 2008

    Ron Miller

    I have to do a traceability matrix for an employee tracking system. We have several screens with different data on them and this data will update an emmployee master table. Essentially the only process involved here is editing the data to update the Employee table.
    For example the first screen would contain data like SSN, Birth date, Address, City state, U.S. Citizen (Y/N) Diresct Employee or Contractor, etc.
    Can you give me a sample of the Traceability Matrix that I will need for this application?

  • July 26, 2008

    Inder P Singh

    Thanks for the article on Traceability!

    However, I am not sure if I understand what you mean by “When I thought about it a bit more it made sense though because not all projects need traceability.” If we exclude trivial/ practice projects (where it might not be critical if each requirement has been implemented successfully or not), I think all projects need traceability (even if it implies creating traceability on the fly by going through all the project documentation).

    Even projects that follow the agile methodology need traceability. Of course, the way the traceability is handled/ implemented may differ in different agile projects. They may or may not use a traceability matrix.

    Thank you,

  • October 6, 2008

    Tejaswy K

    I understood what a traceability matrix does and why it is used. We have been given a project on Computerised banking system. Could you please give a sample example for this application?

  • April 7, 2009


    hello bruce…nice article…i am working on a research project (master thesis) which requires finding diffrent quality demands, quality attributes and metrics on user requirements to ensure high quality requirements…could you provide me some information about the quality attributes and metrics(boundary values) for the quality demand requirements should be traceable..thanx

  • April 8, 2009


    thanx bruce…very nice explanation..:)

  • April 8, 2009


    but i could not understand why you have choosen test coverage as G/F where F is the number of requirements with no dependants??

  • April 8, 2009


    thanx for the clarification it sounds more convincing 🙂

  • April 29, 2009


    hello bruce…i am not sure if i should ask this question under this heading..but as i have previously posted my questions here so feel more comfortable…well the problem is related to TBD’s in requirements..if we have to give a metric for TBD lets say percentage of total requirements marked with TBD should the different level at which TBD’s are present be considered for example if a requirement is divided into A and B where A is further divided into C and D and lets say B and D are marked (TBD) can we say that out of total 3 requirements 2 are marked with TBD or B should be given high weightage as it is at higher level??
    The problem is if at later point in time lets say B is divided into 4 out of which 3 are labelled TBD, now it is 4/6 which is same as previous one or may be worse in some cases, but actually it should be less because we have added some details to B??

  • May 6, 2009


    thanx bruce..well i was not sure if we wouild be able to predict the number of lowest level requirements when our high level reuirements are being written..but ya that assumption would be helpful..cheers//

  • May 25, 2009


    hello bruce can you tell me some freely available tools for measuring quality of requirements other then ARM.. thnx in adavance :)//

  • June 23, 2009


    Hi Bruce,

    This is a nice read. Could you please explain the types of traceability? Forward/Backward – vertical/horizontal.


  • July 14, 2009


    thnx bruce…well i have been struggling with this topic for long time…people in the companies blame each other for the defects in requirements..but i wonder will there be any solution to this problem..[:)]..but ya it is really interesting to play with requirements.

  • September 14, 2009


    Excellent article. I can’t seem to find the diagramme. It is linked as http://www.e-lm.com/images/traceabilitymatrix.jpg. Maybe an update of the link will help us see what you are referring to with the diagram.

  • February 11, 2010


    Hi Bruce,
    I would like to know more about the conflict arises during the course of project development, mainly among team members or team member conflict with Project manager. What is the best way of dealing with this and how to make healthy and productive env within the team.


  • October 24, 2016

    Joshua Glazebrook

    Very nice explanation on “what is traceability?”. For further explanation on what traceability is in the sense of horizontal or vertical traceability, as well as backwards and forwards traceability. See this document below

Post a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.