J.E.D.I
3.5 Requirements Traceability Matrix RTM
The Requirements Traceability Matrix RTM is a tool for managing requirements that can be used not only in requirements engineering but through out the software
engineering process. It attempts to whitebox the development approach.
The whitebox approach refers to the development of system requirements without considering the technical implementation of those requirements. Similar with UML, this
approach uses the concept of perspectives. There are three, namely, conceptual, specification and implementation. But in terms of requirements, we deal with the
conceptual and specification.
The Conceptual Perspective deals with the “concepts in the domain”. The Specification Perspective deals with interfaces. As an example, concepts within the domain of the case
study are athletes, coaches, squad and teams. Interfaces deal with how the concepts system elements interact with one another such as promoting or demoting an athlete.
Components of Requirements Traceability Matrix
There are many variations on the components that make up the RTM. Those listed in Table 11 are the recommended initial elements of the RTM.
RTM Component
Description
RTM ID This is a unique identification number for a
specific requirements. Choose a code that is easily identifiable.
Requirements This is a structured sentence describing the
requirements in a “shall” format, ie, the “the system shall...”, “the user shall...” or
“selecting an item shall...”
Notes These are additional notes of the
requirements. Requestor
This is the person who requested the requirement.
Date This is the date and time the requirement
was requested by the requestor.
Priority This is the priority given to the requirements.
One can use a numbered priority system, the Quality Function Deployment, or MoSCoW
Technique.
Table 12 Initial RTM Components
Software Engineering 113
J.E.D.I
While the above elements are the initial RTM, one can customize the matrix to tie the requirements with other work products or documents. This is really where the power of
the RTM is reflected. One may add other elements. An example is shown in Table 12.
Additional RTM
Component Description
Relative to RTM ID
This is the RTM ID that specifies if the current RTM is directly or indirectly related to
other requirements.
Statement of Work
SOW This is a description that relates the
requirements directly back into a specific paragraph within the Statement of Work
SOW. A SOW is a document that specify the nature of the engagement of the
development team with their clients. It lists the work products and criteria that will
define the quality of the work products. It helps in guiding the development team in
their approach in delivering the requirements.
Table 13 Additional RTM Components
The components and the use of the RTM should be adapted to the needs of the process, project and product. It grows as the project moves along. As software engineers, you
can use all components, remove components or add components as you seem fit.
Consider an example of the RTM for the development of the system for the Ang Bulilit Liga: Club Membership Maintenance as shown in Table 13. The organization is use case-
driven.
Software Engineering 114
J.E.D.I
RTM ID Requirement
Notes Requestor
Date Priority
Use Case 1.0
The system should be able to maintain an
athletes personal
information. RJCS
061205 Should
Have
Use Case 2.0
The system should be able to allow the coach to
change the status of an athlete.
RJCS 061205
Should Have
Use Case 3.0
The system should be able to view the athletes
personal information. RJCS
061205 Should
Have
Use Case 1.1
The system should be able to add an athletes
record. RJCS
061305 Should
Have
Use Case 1.2
The system should be able to edit an athletes
record. RJCS
061305 Should
Have
Use Case 1.3
The system should be able to remove an
athletes record RJCS
061305 Should
Have
Table 14 Sample Initial RTM for Club Membership Maintenance
Software Engineering 115
J.E.D.I
3.6 Requirements Metrics