What is traceability ?
The relative form of ‘Traceable’; the dictionary meaning says “capable of being traced” i.e. the series of footprints, the track or the path, anything which can help what we are looking for. On the software engineering, an important aspect is ‘trace the requirement’.
So, what is the need to ‘trace the requirement’? because there is a possibility, that on the subsequent phases of the development and testing we may miss the track and that way we reach to a destination (product), we are not suppose to (deliver). Either, we move on a completely off the track, stopped before the destination (missing requirement) OR moved ahead of the same (deliver extra functionality), not realizing, we have already crossed our destination long back. So, traceability helps sticking to the track and the destination.
Speaking specifically on the requirements aspect, traceability is all about discovering and maintaining relationships between important facets of Requirement, such as the following:
- Relation to Business Objectives
- Relation or Dependency with other requirement
- Relation to team deliverables like use cases or test cases
- Relation to solution components
How to conduct?
Traceability can be bidirectional, which means,
- trace requirements back to the business need OR
- trace requirements forward through design and implementation
Depending on how we are covering, the requirement traceability matrix (RTM), alternatively known as coverage matrix, can be prepared using the following two key elements:
- Identify and index the piece of requirement, design definitions, test cases etc.
- Establish the references e.g. for each piece of requirement, there must be a test case; alternatively, if there is a test case, it must be to validate a written piece of requirement.
Below is an example of how RTM may look like;
|Requirement Specification||Design Specification||Test cases|
By now, we could have understood the importance and the benefits “traceability” brings in with the software development;
It’s a great technique to manage the scope and the efforts. To elaborate, this ensures that all the piece of requirement is captured and understood by the design and development team, and same goes with the QA team as well. So, there is NO missing requirement and there is NO extra functionalities (not mentioned on the Functional Specifications) added by development team.
This technique also helps in analyzing the impact a new change brings in. With a traceability matrix in place, it becomes easier to identify which all development components may need a change or which all test cases need to be updated with a change in requirement.
So, go for it and prepare an RTM on your project and let us know how this was beneficial or if any challenges involved. We would love to hear from you.
Please put down your thoughts on the comment section. Thank you !!