Requirements Traceability Matrix

In order to provide a compliant-ready product, the manufacturer must make sure that the features required for compliance are built into the product. For verification purposes, a requirements traceability matrix should be created to match the appropriate tests for each of these requirements. An excerpt of an actual matrix is show in the following table (Table 2). 

Complete A Requirements Traceability Matrix (RTM) should be developed to confirm that all relevant aspects of the URS have been brought forward into the Functional Specification and Design Specifications. This includes both positive and negative requirements (the latter often overlooked), i.e., what the software is snpposed to do and what it is NOT supposed to do ... 

A Requirements Traceability Matrix (RTM) or equivalent mechanism for establishing and maintaining requirement traceability should be put in place for projects for use during operation and maintenance. This mechanism should provide a method of tracing a requirement from the URS through the Design and Development and User Qualification phases. It provides assurance that all system requirements have been included in the design and tested to verify correct operation. 

Wherever possible, the Functional Specification should follow the same stmcture of the URS (see Appendix 8B), and can refer to the URS rather than duplicate information. A Requirements Traceability Matrix can be developed as described later in this chapter. Compliance, orrrissions, and nonconformances with respect to the URS should all be readily identifiable. 

Architectural Designs should clearly identify the use of COTS software and hardware. Many modem computer systems make extensive use of COTS products. Architectural Designs should be included in the Requirements Traceability Matrix (RTM) as they will provide the vital linkage... 

The Requirements Traceability Matrix (RTM) initially developed for the Design Review should be extended to track which tests cover which aspects of the specification. 

The Requirements Traceability Matrix (RTM) should be updated with details of test speeifiea-tions and test reports. It should be possible to track a user requirement through Functional Specification, Design, System Build, Development Testing, and User Qualification. 

A Design Review should be conducted before testing begins. This will normally involve developing a Requirements Traceability Matrix (RTM). If no detailed design information is available then cross-references should be made between the newly prepared System Specification, available operator manuals, and user procedures. Source Code Reviews will be expected for custom (bespoke) software under the control of the pharmaceutical or healthcare company, and redundant code identified should be removed. 

Certificates of analysis confirming the final product resulting from these weighings can also be retained as further inferred evidence of the quality of the weighing IPC system. Completing the PQ allows the completion of the Requirements Traceability Matrix. Full traceability from specification through testing should be demonstrated at this point. 

A requirements trace matrix (RTM) is a tool to map requirements. However, these can become large and difficult to maintain. An alternative approach is to provide implicit traceability by having a common structure and numbering system for all system design and test documentation. The one area where this is often difficult to achieve is with the User Requirements Specification (URS). The URS often covers not only the DCS requirements but those of the wider project, and is also produced before the system vendor has been selected. In this case a requirements traceability matrix should be generated to confirm requirements relevant to the DCS are addressed within the functional specifications. 

It is not typical to receive a separate functional and design specification these are often included as part of the building s environmental control package. If this proves to be the case, then it is not necessary to rewrite these specifications. The recommended approach is to create a matrix that references those parts of the environmental control package that are relevant to the computer system validation requirements for the critical functions. Also, ensure that this matrix is mapped back to the URS in order to ensure that the URS is met. This matrix will form the basis of the Requirement Traceability Matrix (RTM), which is intended to assure that all requirements have been addressed, that the functionality is appropriate, consistent, and meets predefined standards, and that the system is appropriately tested. The functional/design specification or the relevant sections of the environmental control package should typically address ... 

With the increased complexity of the spreadsheet application, and the hierarchy of specification and design documentation, it becomes very important to ensure there is good traceability between requirements and testing. For this reason the use of a Requirements Traceability Matrix (RTM) is recommended. 

The completed FDS should be verihed that it is consistent within itself and with SOPs implementing the business process transactions, and that it fulhlls the requirements of the URS. The activity is often referred to as a Design Review (DR) or Design Qualihcation (DQ). The use of a requirements traceability matrix (RTM) should be considered to demonstrate how URS elements are addressed in the functional specihcation and design documentation. This RTM can later be extended to trace test specihcations and results. 

---