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.
The next step is to create a traceability matrix. For example:
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:
- Find the row with SEC_01 in the left-hand column
- Follow that row to the right until you find the column with SEC_01.1 at the top
- 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.
Follow this link for more information about the Psoda traceability matrix.