User Requirements Specification defining

Define test cases based on user requirement specifications Define test data (real data, borderline data re statistics, stress data reverse data)... 

The information contained in User Requirements Specifications is often used to help determine the basic approach to validation to be taken for individual projects. Guidance on the scope of validation required for different types of computer systems is defined at the beginning of this chapter. A rationale must always be given supporting any validation decisions made during a validation project in the form of a separate document or included within the Validation Plan. 

An Outline Specification is usually required to sanction a project and authorize the allocation of a budget. It typically presents the business case for the computer system, defining key functionality and compliance requirements. This document may be used later on for developing the User Requirements Specification (URS) as discussed in Chapter 7. Where Commercial Off-The-Shelf (COTS) software and systems are being acquired, this document may be used as the URS. Outline Specifications must be reviewed and approved. 

OQ verifies that the control and monitoring instrumentation, as integrated with the process equipment and any associated computerized control system, meets the operational and functional requirements defined in the instrument application design documentation and/or computerized control system User Requirements Specification (URS). PQ verifies that the control and monitoring instrumentation, as integrated with the process equipment and any associated computerized control system, meets the operational and functional requirements defined in the instrument application design documentation and/or computerized control system URS, and prodnces pharmaceutical product consistently to specification. ... 

Focusing on the process control system validation, and following the traditional V-Model approach as defined within the GAMP Guide, the next step would be to develop the functional specification(s) for the system after approval of the User Requirements Specification. An alternative strategy to consider, particularly for brown field applications, is the development of a prototype before functional specifications are generated. 

The output of this activity will be the User Requirement Specifications (URS) or Project Definition that will be issued to the design consultant and evolved into a detailed design defining the assets required to meet the requirements. 

A Validation Plan should be established and approved. A User Requirements Specification should be prepared describing the general user requirements, input, calculations, and output from the spreadsheet. The classification of the spreadsheet could be defined in the Validation Plan, URS, or separately according to a defined SOP. The use of the spreadsheet as a GxP application should be logged in the site or facility system register. 

The first step in the evaluation process is to define and document the current system use and user requirement specifications. If the system will be changed in the foreseeable future, any resulting changes in the intended use of the system should be described as well. The definition should include a list of system functions, operational parameters and performance limits. For chromatography software required functions may include instrument control, data acquisition, peak integration through quantitation, file storage and retrieval and print-out of methods and data. If the system also includes spectrophotometric detectors, the functions for spectral evaluation should be specified as well. Table 2 lists items that should be included in the system documentation. 

Finally, the documentation should be evaluated in relation to the user requirement specifications, functional specifications and performance limits previously defined. There should be a direct link between the tests... 

Performance qualification ensures that the system behaves appropriately in the intended routine application and is checked against the user requirements specification. This step is performed by the end-user community and is the essential step toward the business acceptance of software. The performance qualification includes a subset of procedures used during the operational qualification to reduce duplication of effort by rewriting similar test cases and procedures. The procedures to use during the performance qualification typically focus on areas that pose the greatest risk if they were to operate incorrectly, the latter of which are defined during a risk assessment procedure. 

Design qualification (DQ) describes the user requirements and defines the functional and operational specifications of the instrument which are used for OQ testing. Table 9.1 shows an example of a DQ for an HPLC system used for method development. 

Validation life cycles (Figure 2.11) provide a methodical approach to ensuring that quality is "built in" to the software and hardware development from the User Requirements Specification (URS) through to final testing and ongoing operation and maintenance. A Validation Master Plan (VMP) must be developed to define the validation strategy, organization and roles and responsibilities for project participants. 

A risk assessment can be used quite naturally in the process of drafting a User Requirements Specification (URS) for equipment utilities. By clarifying the intended use of the equipment and investigating the hazards, their possible causes and ways to control them in the actual context, the URS will be a fine starting point for purchasing and for the subsequent qualification. The risk assessment is to be updated as sorai as actual brands and types of a specific piece of equipment have been chosen. As a conclusion a level of risk can be determined for specific equipment, placed in specific locations and used for weU-defined purposes. If such a level of risk is determined for several pieces of equipment in a department, it may serve other purposes as well, for instance prioritising validadmi and frequency of maintenance or determination of the replacement period for specific equipment. 

Software validation is not separately defined in the quality system regulation. The FDA considers software validation to be the confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled [14]. Software validations have special concerns on software installation, implementation, and utilization. A software validation consists in several tests, inspections, and verifications performed to assure the adequate installation and use of software and that the tasks performed meet all the specifications defined. Software validations must be performed under the environmental conditions to which software will be submitted. This is particularly important in medical devices that are used under special conditions, such as close to or inside the human body. 

Functional Requirements. Based on the user requirements, more detailed functional requirements can then be defined. Take as an example a gradient HPLC system with UV-Vis detection required to run a stability-indicating method. The functions of each of the hardware and software components required to perform the tasks in the user requirements should be specified. The functional specifications typically include ... 

Performance qualification (PQ) is a process used to verify that the chamber performs according to specifications under normal operating conditions as defined by user requirements. PQ tests should include ... 

The installation should be documented. The accuracy of software installation should be verified, and for networked systems, drawings with diagrams should be generated. The instrument should be tested for compliance to user requirements and functional specifications, as defined during the design qualification. Critical parameters should be tested before and during routine analysis. System suitability... 

Typically, managers, their peers, end-users, and those responsible for delivering the system, approve validation plans. Quality assurance may also sign the document. The validation project plan and the requirements specification deliverable, together define the technical and regulatory requirements applicable for a project. 

Custom-built systems produced for a customer specifically to meet a defined set of user requirements. The practices contained in this section apply to custom-built applications... 

The requirements specification deliverable must include an overview of the process in order to familiarize the application software developer with the user, process and data acquisition requirements of the system, as well as special considerations for the project. The system functionality must be well defined at the outset, in order to provide the prospective supplier/ integrator with enough information to provide a detailed and meaningful quotation. 

The FAT provides evidence that the hardware and software are fully integrated, that they operate as indicated in the computer system specification deliverable, and meet the expectations of the user as defined in the requirements specification deliverable. This final formal integration test should be completed in an environment very similar to the operational environment. The system can be subjected to a real-world environment by using emulators and/or simulators which mimic system interfaces. The user s representative should evaluate the supporting documents, the operation, system functionality, and system reliability. 

Bespoke Software GAMP (1996) A system produced for a customer, specifically to order, to meet a defined set of user requirements. [Note Bespoke code includes so-called standard software where the version of the software to be used has not been market-tested over a period of time by other customers.]... 

As discussed earlier, the validation plan is a document that should be well defined by existing SOPs written within either the Quahty Assurance Organization or the IT group. Unless the project is quite unique, the validation plan should follow the same general course. The user requirements and system specifications documents will impact this, of course, but the generation of this document, which also should be quite brief, should be straightforward. The key elements of the validation plan are given in Table 3.4. 

Whether for a completely new development, or for the simple purchase of a commercially available computerised system, the user requirements have to be defined and compiled in an as specific and complete manner as possible. The new HPLG system, e.g., should be able to detect the test item at a predefined sensitivity and to allow different calculation modes for study-specific... 

Defining user requirements and setting functional and performance specification... 

---