Design Review (DR/DQ)

At the Design Review/Design Qualification (DR/DQ) stage, it is necessary to:

1. Confirm that specifications and project documentation meet the project goals and regulatory requirements.
2. Confirm that the identified risk mitigation measures have been implemented in the system design.
3. Ensure the correct translation of requirements from high-level specifications into low-level specifications.

During the Design Review (DR), various levels of project specifications are verified, and if required by the software category, source code is reviewed. The Design Review (DR) is analogous to Design Qualification (DQ) in traditional validation. Specification Review corresponds to traditional DQ in terms of documentation format and procedure, while Source Code Review is a distinct activity performed according to a separate procedure that differs from traditional DQ.

The following procedure is used during Specification Review:

• Documentation model: protocol – report
• The review is conducted by sequentially checking and filling out control points with acceptance criteria in the protocol based on the specifications being reviewed.
• Any deviations found are recorded in the "Deviation List (Log)" section of the protocol.
• The completed protocol becomes the report.
• If no deviations are found, or they are resolved, or not GxP critical, the Specification Review is considered successfully completed.

Specifications

When moving from high-level to low-level specifications, the following types can be distinguished:

• Requirements Specification defines the commercial requirements for the system and essentially serves as a contractual specification establishing the acceptance criteria for the system.
• Goals Specification is generally more detailed and defines what the system should do and how well it should perform:
  1. The goals specification corresponds to the system testing level in the V-model.
  2. The goals specification not only describes the system's capabilities but also sets the qualitative characteristics of its functioning.
  3. The goals specification is developed based on the requirements specification/URS.
  4. During the review of the goals specification, one of the key tasks is to verify the correct "translation" of requirements from the requirements specification/User Requirements Specification (URS).

In the IT industry, the review of goals specifications usually considers the following aspects:

• Facility
• Volume
• Stress
• Usability
• Security
• Performance
• Storage
• Configuration
• Compatibility/Conversion
• Installation
• Reliability
• Recovery
• Serviceability/Maintenance
• Documentation
• Procedure

Functional Specifications provide an exact description of how the system interacts with users and/or the process, as applicable:

1. Functional specifications correspond to the functional testing level in the V-model.
2. Functional specifications should include a complete list/description of the individual system functions and corresponding user interface elements (input/output elements).
3. Functional specifications are developed based on the goals and requirements specifications/URS.
4. During the review of functional specifications, the accuracy of translating requirements from the goals and requirements specifications/URS is verified.

The specialists at Tarqvara Pharma Technologies have years of experience in conducting qualification, validation, and acceptance tests within the pharmaceutical industry, in full compliance with international, European, and national GMP/GxP regulations and standards.

See also:
Qualification / Validation / Commissioning
Computerized Systems Validation (CSV)
Acceptance Tests (FAT/SAT)
Risk-Oriented Approach