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. Hence the traceability matrix should be created. Traceability matrix establish the relationship between the high level requirements and the detail/derived requirements.
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 tick 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 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.
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.
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.