Requirements Traceability Matrix RTM

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