REQUIREMENTS TRACEABILITY MATRIX

The purpose of the RTM is to help ensure the object of the requirements conforms to the requirements by associating each requirement with the object via the traceability matrix.

A traceability matrix is used to verify that all stated and derived requirements are allocated to system components and other deliverables (forward trace).

Forward Traceability through the SDLC

The matrix is also used to determine the source of requirements (backward trace). Requirements traceability includes tracing to things other than software that satisfy the requirements such as capabilities, design elements, manual operations, tests, etc.

The traceability matrix is also used to ensure all requirements are met and to locate affected system components when there is a requirements change. The ability to locate affected components allows the impact of requirements changes on the system to be determined, facilitating cost, benefit, and schedule determinations.

Traceability Strategy

The extent of the RTM depends on what will be managed. Considerations include contractual requirements, risk, and overhead costs relative to the budget. The traceability strategy is devised by graphing relationships between work products. Conduct a proof of concept for your strategy using your selected RM tool.

Software is developed in stages, each with work products that can be associated with work products of the previous stage, creating the ability to trace from the requirements through the work products and from the work products back to the requirements. What work products are required depends on the organization's standards and development practices. In general:

The need (requirement) for a new system or modification to the current system is identified. The need is analyzed to further define the requirement.

A feasibility study should be performed to answer questions in more detail such as: what needs to be done, what is the value of doing it, what business goals are supported, how can it be done, what are the alternatives, and what are the risks. The results are documented in a business case. Requirements at this stage are insufficiently detailed to build or modify a system.

A project may then be initiated based on the selected alternative from the business case. Ideally, the requirements traceability matrix (RTM) is started now. The high level requirements are linked to the business goals. As work products are created throughout development, the RTM will be updated to provide full traceability.

An Operations Concept document may be created to convey uses of the system and to set the system and project boundaries. A top-level architecture document may also be developed.

System functional requirements are documented in three phases: identification, analysis, and baseline establishment.

During the identification phase, the developer/maintainer reviews the documents provided by the customer to identify the specific system functional and performance groups into which the requirements fall. The requirements may be further categorized into subgroups. Interviews, prototyping, and a variety of techniques may be used to identify requirements.
The requirements are analyzed to ensure they are complete, consistent, testable, and feasible within budget and technical constraints. The requirements are also reviewed to eliminate redundancy. Acceptance criteria for each requirement are developed. A draft system specification is produced.
After approval, the requirements and associated documentation are formalized as the functional baseline.

Design, code, test, manuals, and other work products are developed in accordance with the requirements. As they are developed, work products in the functional baseline may be updated or modified in accordance with the organization's configuration management process. Traceability is used throughout to verify that goals and requirements are being met.

(Also see: 5 key requirement concepts)