The article about traceability matrix with useful information as what actual traceability, use of traceability matrix in the testing phase, how to develop traceability matrix and use of traceability matrix.
What is traceability ?
Its simplest traceability allows to find our way around the project information. E.g. Suppose one high-level requirement may be divided 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 between them. In the detailed requirement specification you could add a column showing the high-level requirement associated with each of the detailed requirements.
When the high-level requirement is changed it will be necessary to find all of the obtain requirements and make sure that they are still valid. If you want to find all of the requirements obtain from a specific high-level requirement you must then search through every obtain requirements specification for those detailed requirements with the associated with high-level requirement. If you had only one detailed requirements specification this would be ok but what happens when you’ve gotten or more obtain specifications? It becomes a bit a difficult
Traceability Matrix in testing
Traceability Matrix gets involved in the broader picture of Testing?
The Traceability Matrix is created even before any test cases are prepared, because it is a complete list indicating what needs to be tested. Sometimes there is single test case for each requirement or multiple requirements can be validated by single test scenario. This is purely depends on kind of application that is available for across the testing.
Developing a Traceability Matrix
How can the Traceability Matrix developed?
In the design document, if there is a description of Design as A, which can be traced back to the Requirement Specification A, indirect that design A takes care of Requirement A. Similarly in the test plan, Test Case A takes care of testing the Design A, which in turn takes care of Requirement A.