UK English
American English
Afrikaans
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:
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.
Test-cases
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.
Change
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.
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.
Hi Hung, I am not sure if I am the best person to ask this question. You may have to refer to your thesis advisor in this case.
In my opinion you could probably not use traceability by itself as a research area. I would suggest that you rather look at the wider question of managing the scope of a software project and how traceability (and more particularly the traceability matrix) allows you to understand and manage that scope. Together with this comes the issue of managing change to the project scope and understanding the impact that change will have.
You could for example compare the effectiveness of different software development methodologies and how each copes with change, say Agile vs. the more traditional waterfall methodology.
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?
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,
Hi Inder,
I was thinking about smaller projects that may not need a traceability matrix. For example an SME evaluating different accounting packages. In this case the SME may typically have only one layer of requirements to evaluate the accounting package against.
Agile projects is an interesting case. Most developers believe that NO documentation is required when they run agile projects.
Although this may seem the case the first time round, the cracks start appearing when major changes are required e.g. during a maintenance release.
Unless the original developers are around to help sort things out (i.e. the documentation lives in their heads) it becomes a major exercise the re-analyse the code to understand the impact of these changes and not to introduce a host of new defects.
This is where the real power of traceability and the traceability matrix lies. People who have just joined a project can easily look at a particular requirement and directly trace where it came from and what other requirements are dependent on this one.
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?
Hi Tejaswy,
So you are looking for an example of a traceability matrix for a Computerised Banking System?
To start with, can you give me a few high-level business requirements for the system…
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
Hello Arpy,
Each requirement should be traceable in two directions:
Source(s) – i.e. where did this requirement come from e.g. RFP or customer change request. If a requirement does not have at least one source then you have to question whether it is a valid requirement of the system.
Dependant(s) – i.e. other requirements and/or test-cases that depend on this particular requirement and will be impacted if this requirement should change. If a requirement has no dependants then either it must still be broken down into more detailed requirements and/or test-case(s) need to be defined for this requirement.
From this we can define the following quality attributes:
A – Number of sources for each requirement
B – Number of dependent requirements for each requirement
C – Number of dependent test-cases for each requirement
D – Total number of requirements
E – Count of requirements with no sources
F – Count of requirements with no dependants
G – Count of requirements with only test-case dependants
These last two values can be used to calculate the test coverage of the project: TC = G/F
The ideal values for these quality attributes are:
A >= 1
B + C >= 1
E = 0
F = 0
TC = 100%
Once other quality factor of traceability is that you don’t have any loops, i.e. none of the dependants of a requirement can also be a source for that requirement.
Using set theory this can be stated as follows:
- Let R be a particular requirement
- Let U be all of the dependants of R, including all their dependants and so on down to the bottom of the tree
- Let V be all of the sources of R, including their sources and so on all the way to the top of the tree
Then the intersection of U and V should be empty, i.e. they should have no shared elements. This should be true for all requirements of the project.
thanx bruce…very nice explanation..:)
but i could not understand why you have choosen test coverage as G/F where F is the number of requirements with no dependants??
Hi Arpy,
You are quite right. I was obviously typing too fast
It should’ve been:
TC=G/(F+G)
The assumption is that all requirements should have either dependant requirements (i.e. further breakdown) or test-case dependants (i.e. the requirement needs to be tested). So the total number of requirements that should have test-cases are the sum of all those that have test-cases already and those requirements that do not have any dependants yet, so should have test-cases.
Of course there is an argument that some requirements may have both dependant requirements and test-cases.
thanx for the clarification it sounds more convincing
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??
Hi Arpy,
I assume that with the TBD metric you are trying to measure the amount of work remaining.
I don’t think that using a blanket % of requirements with the TBD flag set. From your example requirement A is split into C and D. Assuming that C and D are of a similar size and D is flagged TBD then 50% of the work remain. If we use a blanked % of requirements then that would give 66% TBD.
What is happening here is that you are double counting. A contains C and D so when we count A as TBD then we are essentially counting C and D again.
I would suggest that we only want to count the requirements that are not split into smaller requirements (i.e. F from our previous discussion). Of course this assumes that the higher-level requirements such as requirement A does not contain any additional functionality that is not in the detailed requirements.
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//
hello bruce can you tell me some freely available tools for measuring quality of requirements other then ARM.. thnx in adavance
//
Hi Arpy,
I think that measuring the true quality of requirements is a very subjective thing and that automated tools will not do a great job. Besides the fact that the customer requirements are going to change over the lifecycle of the project so maybe longevity might be the best measure of quality
I don’t have a list of any tools for measuring requirement quality on hand. Your best bet is to google for some.
Hi Bruce,
This is a nice read. Could you please explain the types of traceability? Forward/Backward – vertical/horizontal.
Regards,
Neo
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.
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.
Hi Garth,
Thanks for letting me know that the image had disappeared. I’ve updated the article with a new image and references.
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.
Thanks
Hi NPHARI,
I am not sure how this relates to a Traceability Matrix
You may be best asking this question on a project management forum such as ProjectsAtWork.
Kind regards,
Bruce