Requirements Traceability Matrix

As far as software projects are concerned, a requirement is that parameter to which the outcome of a project (whether in the form of a product or service) is supposed to conform. As a discipline, requirements management is concerned with documenting, prioritizing, tracing, analyzing and agreeing on project requirements. Thereafter, control and communication of changes and important information to stakeholders of the particular project in question are taken care of. One very important aspect of software project management is Configuration Management which deals with management of alterations/modifications in project hardware, software, firmware, documentation and measurements. Such modifications follow the path of changes and it becomes imperative to mark all such significant stages of change which is what baseline identification is all about. A requirements traceability matrix is a tracking document which is used to correlate two baseline documents that call for many-to-many relationship in order to ascertain the relationship's totality. In short, it maps the requirements with the test cases.

How to Draft a Requirements Traceability Matrix

Requirement traceability matrices are often used to determine whether the requirements of the ongoing project are being met or not. An RTM is also used to create a Request for Proposal, project plan tasks and deliverables documents. Let's take a look at the typical steps involved in drawing up an RTM.

• Draft a template depending upon your project requirements. You can take the help of many free RTM templates that are available online.
• Take all the required data from your business requirements catalog and transfer it to the template.
• Mark each requirement with a different identification sign and put each sign against the corresponding requirement.
• Include the use case ID into the RTM if you have made use of them while developing the requirements.
• Incorporate the System Requirements Specification ID in the RTM even though you yourself haven't created them.
• Appropriately include the testing data into the requirement traceability matrix in such a way that the different types of tests and changes made in the project gets accounted for.
• Run a double check to see if your RTM shows each specific deliverable requirement right from the point of conception throughout the entire testing phase.

An RTM should be such that it ensures that nothing is given the green flag to proceed for production/development in a haphazard manner and your project manager gets all the information he needs from you ready and in order! Now that we have been through all necessary steps for creating an RTM, let us proceed to see what one is expected to look like.

Requirements Traceability Matrix Example

The following Requirements Traceability Matrix template would clear up any doubts regarding how an RTM looks like and how it should be drafted.

Requirement Identifiers		Requirements Tested	Req. 1 UC 1.1	Req. 1 UC 1.2	Req. 1 Tech 1.1	Req. 1 Tech 1.2
Test Cases	409	4	2	3	1	1
Implicitly Tested	25	-	-	-	-	-
1.1.1	2	-	*	-	*	-
1.1.2	1	-	*	-	-	-

That was Requirements Traceability Matrix for débutante software testing engineers! Make sure you include all those parameters which are the bare necessities and do not overcrowd the RTM as it would look too heavy to serve the purpose of simple traceability. It is always good to keep a regularly updated RTM by your side to know how the project is progressing. If you are aware of software testing basics, I'm sure figuring out how to draft your own RTM would be a cakewalk! All the best!