Requirements Traceability Difference Matrix
Purpose
A systematic method for linking each requirement from system documentation to the hardware and/or software that performs the requirement. A compliance matrix is formed showing the top-level requirement and its association with lower-level requirements and system hardware/software.
Requirements Traceability Analysis and the Requirements Traceability Difference Matrix
When defining a system, requirements start with a high-level functional specification that eventually generates many lower-level hardware and software specifications. Each of the functional requirements ("parent requirements") within the high-level specs. have associated low-level requirements ("child" requirements) further describing the details of how the function is to be implemented. A requirements Traceability Analysis is performed to assure that all requirements are implemented into the system as either hardware, software or both. An effective Traceability Analysis also should show the hierarchy between requirements, any differences between the "parent-child" functionality and if any requirements are "orphaned" otherwise, having no parent requirements.

IDA has developed a new tool for representing all this information called a Requirements Traceability Difference Matrix. The Requirements Traceability Difference Matrix format graphically shows how each requirement is hierarchically related between the parents and the children and any differences or issues between the parent-child requirements within the function or other system functions - all in a single matrix. This graphical depiction provides the Systems Engineer a roadmap between system hardware and software specs, back to all the functional specifications that defined it and quickly indicates any orphaned requirements. The Requirements Traceability Difference Matrix also serves a second purpose when performing future system upgrades or changes. If any of the requirements change, the Requirements Traceability Difference Matrix can graphically indicate all the affected requirements above or below the change in hierarchy that may necessitate further review or re-design of the system. This tool is especially useful by both the Systems Engineering and the Quality Departments when considering the effects of upgrades and changes.