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). 

For simple analytical instruments, a simple table to summarize the qualification testing, acceptance criteria, results, and pass/fail decision of the tests will be sufficient since there are fewer tests that are required and the tests are usually relatively simple. For complex analytical systems, a more complex table often referred to as a traceability matrix which traces the requirements, testing, acceptance criteria, test results, and storage locations of the validation documents, test data, and other supporting documents is usually included in the summary report for easy reviewing and quick references. 

Test plan with test traceability matrix... 

Quality-related critical parameters, data, and functions are essential for specification and contract considerations, system design and development, qualification testing of the computer system, and PQ for the validation of the process. GMP-related system requirements need to be traceable throughout the specification, design, development, testing, and operation of a system. This can readily be achieved by having a traceability matrix that will identify corresponding sections and data in the key life-cycle documents. 

System Design Specifications Test Plan Traceability Matrix ... 

Here is an example of a traceability matrix as defined by the IEEE. By definition, a matrix records the relationship between two or more products of the development process for example, a matrix that records the relationship between the requirements and the design of a given software component (Std. 610.12-1990). 

As commonly used in CRS validation, a traceability matrix verifies the relationship between system specifications and testing protocols. The goal of matrixing is to establish the adequacy of protocols. More specifically, all specified system characteristics and functionality should correspond to verification and qualification testing in protocols. 

This example uses a small portion of a traceability matrix for validation of a database application, here named your CRS. ... 

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. 

Testing and verification of life-cycle phases (reviews of Reqnirements Specifications, design, code inspections, test traceability matrix from test cases back to reqnirement specifications, are there release criteria for the phases )... 

Part of a Combined Risk and Analysis and Traceability Matrix for a CDS... 

Reqnirements mnst be traceable through the life cycle to confirm that all reqnirements are fnlly dehned and tested. An effective method for this is the nse of a matrix. All requirements, GMP and non-GMP, are identihed and traced through the respective design and test documentation. A Reqnirements Traceability Matrix is a powerful tool to assist in the management of projects as well as serving its main pnrpose of demonstrating fnll and complete testing of requirements. 

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. 

Validation test planning for a database application has the same two principal foundation blocks as for any other type of application the traceability matrix and a risk assessment process. The... 

Any of the above strategies will have an impact on test planning, as they aU are intended to reduce unacceptable risk to a tolerable level. Regulators have consistently demonstrated that they believe that there needs to be demonstrable evidence that everything that should have been tested has been, and that the depth of testing needs to be justified. The traceability matrix provides the former, and a sound risk assessment practice satisfies the latter. 

These tools should not be considered limited in application to the initial validation effort. By keeping the traceability matrix up to date it becomes (and will remain) an important tool for assessing the impact of changes to the database, and both it and the risk assessment process are still important test planning tools as part of change control. Of course, sound change control practices are absolutely imperative for keeping an application validated. 

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. 

Testing Who develops test plans Are requirement specifications reviews and design inspections done periodically How is functional testing performed Who is testing (outside the development department) Are there test protocols Is there a test traceability matrix to ensure that all user requirements and product functions are tested Are there procedures for recording, storing and auditing test results Who approves test plans/protocols ... 

---