The Validation and Compliance Plan (VCP) defines the methodology, deliverables, and responsibilities for the validation of Qualer. The VCP also describes criteria for final acceptance of validation deliverables and system release, as well as the controls that Qualer has in place to maintain the the system in a validated state.
The Software Design Specification (SDS) describes the system elements, functions, and configuration necessary to properly operate the system within the functional requirements outlined in the FRS. By meeting the requirements outlined in this document, Qualer will correctly and reliably perform its intended functionality.
The Functional Requirement Specification (FRS) details the capabilities and functions that the Enterprise Asset Management Software must be capable of performing. This specification provides general, as well as specific, requirements to be used in the design, validation, and use of the system. The focus is on what the system must do. By meeting the requirements outlined in this document, the Qualer system will correctly and reliably perform its intended functionality.
The Installation and Operation Qualification (IOQ) protocol describes the testing methodology and test cases that provide the necessary documented evidence to assure that the Qualer has properly performed in accordance with defined system and regulatory requirements and Qualer procedures. These are the instructions our validation engineer follows to verify the installation and operation of Qualer end-to-end.
The Validation Summary Report (VSR) summarizes the results obtained during the execution of the Installation/Operational Qualification Protocol for the Qualer platform. The Validation Summary Report documents whether the system performed in accordance with its intended use as described in the Functional Requirement Specification and the Software Design Specification.
The Deviation Summary Report (DSR) documents any test steps from the IOQ that do not match the expected results, or it indicates that no deviations occurred during validation. The report outlines the root cause of the deviation and lays out the steps required to address and close each deviation.
The United States Code of Federal Regulations does not specifically require a Traceability Matrix (TX), but creating a traceability matrix is recognized as a validation best practice. It serves as a map for auditors to review the test case coverage from individual user, functional, and design requirements to the corresponding test cases that verify the system’s fitness for intended use.