DOC

System Validation Report - cetorpdk

By Luis Stevens,2014-03-28 07:13
13 views 0
System Validation Report - cetorpdkSystem

Based on Nordtest

    NT Techn Report 535 System Validation Report Page 1 of 20

System Product:

    Preface

    This computer system validation method, based on the “Nordtest Method of Software Validation” NT

    Tech Report 535, is basically developed to assist accredited laboratories in validation of computer systems for calibration and testing. The actual report is provided via a Word 2000 template “System

    Validation Report.dot” which is organized in accordance with the life cycle model used in the valida-tion method. There are two main tasks associated with each life cycle phase: ; Preliminary work. To specify/summarize the requirements (forward/reverse engineering for

    prospective/retrospective validation), to manage the design and development process, make the

    validation test plan, document precautions (if any), prepare the installation procedure, and to plan

    the service and maintenance phase.

    ; Peer review and test. To review all documents and papers concerning the validation process and

    conduct and approve the planned tests and installation procedures.

    The report template contains 5 sections:

    1. Objectives and scope of application. Tables to describe the computer system, to list the involved

    persons, and to specify the type of system in order to determine the extent of the validation. 2. System life cycle overview. Tables to specify date and signature for the tasks of preliminary work

    and the peer reviews assigned to each life cycle phase as described above. 3. System life cycle activities. Tables to specify information that is relevant for the validation. It is

    the intention that having all topics outlined, it should be easier to write the report. 4. Conclusion. Table for the persons responsible to conclude and sign the validation report. 5. References and annexes. Table of references and annexes.

    Even if possible, it is recommended not to delete irrelevant topics but instead mark them as excluded from the validation by a “not relevant” or “not applicable” (n/a) note – preferably with an argument

    so it is evident that they are not forgotten but are deliberately skipped. It is the intention that the validation report shall be a “dynamic” document, which is used to keep track on all changes and all additional information that currently may become relevant for the computer system and its validation. Such current updating can, however, make the document more difficult to read, but never mind it is the contents, not the format, which is important.

    Table of contents

    System Product: ................................................................................................................................1

    Preface ...............................................................................................................................................1

    1 Objectives and scope of application ........................................................................................2

    2 System life cycle overview .......................................................................................................3

    3 System life cycle activities .......................................................................................................5

    3.1 Requirements and system acceptance test specification ...................................................5

    3.2 Design and implementation process ..................................................................................9

    3.3 Inspection and testing ...................................................................................................... 13

    3.4 Precautions ....................................................................................................................... 15

    3.5 Installation and system acceptance test ........................................................................... 16

    3.6 Performance, servicing, maintenance, and phase out ..................................................... 18

    4 Conclusion ............................................................................................................................. 20

    5 References and annexes ........................................................................................................ 20

    2. edition, February 2004 784776057.doc

Based on Nordtest

    NT Techn Report 535 System Validation Report Page 2 of 20

1 Objectives and scope of application

    This section describes the computer system in general terms. It includes objectives and scope of appli-cation and, if relevant, overall requirements to be met (such as standards and regulations). All persons who are involved in the validation process and are authorized to sign parts of this report should be listed in the Role / Responsibility table. The report could hereafter be signed electronically

    with date and initials of those persons at suitable stages of the validation process. The type of the system elements are outlined in order to determine the extent of validation and testing.

    1.1 Objectives and scope of application

    General description

    Scope of application

    Product information

    Overall requirements

1.2 Role / Responsibility Title and Name Initials

    System owner

    System administrator

    Application administrator

    System user

    Quality responsible

    Requirements team...

Development team...

Peer review team...

Testing team...

1.3 System elements

    Hardware (equipment, server, etc.): Environment (building, room, laboratory, etc.):

    Off-the-shelf , well known manufacturerPractically no effect on the system's function

    Off-the-shelf , less known manufacturerMinor effect on the system's function

    Specially produced hardwareMajor effect on the system's function

    Comments: Comments:

    The user will be able to operate the system correctly after some "ordinary" training

    The user must be an expert and/or receive special training to operate the system correctly Comments:

2. edition, February 2004 784776057.doc

Based on Nordtest

    NT Techn Report 535 System Validation Report Page 3 of 20

1.4 Type of software

    Purchased Software: Self-developed software:

    Configurable software packageCompiled executable program (e.g. C/C++) Commercial off-the-shelf softwareSpreadsheet (macro code, Add-In, etc.) Tool to assist in the software developmentSimple spreadsheet (no macro code) Subcontracted software developmentTool to assist in development or testing Source code available and knownIncludes purchased software components Only partial validationSubcontracted software validation Comments: Comments:

    2 System life cycle overview This section outlines the activities related to the phases in the life cycle model used in the validation

    process. The numbers refer to the corresponding subsections in section 3. Each activity contains a field

    for the preliminary task to be performed, a field for the validation method, and fields to specify the

    date and signature when the work is done. Activity 2.1 Requirements and system acceptance test specification Date / Initials Task 3.1.1 Requirements specification Method 3.1.1 Peer review Check 3.1.1 Requirements specification approved Task 3.1.2 System acceptance test specification Method 3.1.2 Peer review Check 3.1.2 System acceptance test specification approved

    Activity 2.2 Design and implementation process Date / Initials Task 3.2.1 Design and development planning Method 3.2.1 Peer review Task 3.2.2 Design input Method 3.2.2 Peer review Task 3.2.3 Design output Method 3.2.3 Peer review Task 3.2.4 Design verification Method 3.2.4 Peer review 2. edition, February 2004 784776057.doc

Based on Nordtest

    NT Techn Report 535 System Validation Report Page 4 of 20

    Activity 2.2 Design and implementation process Date / Initials Task 3.2.5 Design changes

    1. Description:

    2. Description:

    3. ...

    Method 3.2.5 Peer review

    1. Action:

    2. Action:

    3. ...

    Activity 2.3 Inspection and testing Date / Initials Task 3.3.1 Inspection plan Method 3.3.1 Inspection Check 3.3.1 Inspection approved Task 3.3.2 Test plan Method 3.3.2 Test performance Check 3.3.2 Test approved

    Activity 2.4 Precautions Date / Initials Task 3.4.1 Registered anomalies Method 3.4.1 Peer review Task 3.4.2 Precautionary steps taken Method 3.4.2 Verification of measures

    Activity 2.5 Installation and system acceptance test Date / Initials Task 3.5.1 Installation summary Method 3.5.1 Peer review Task 3.5.2 Installation procedure Method 3.5.2 Verification and test of installation Task 3.5.3 System acceptance test preparation Method 3.5.3 System acceptance test Check 3.5.3 System acceptance test approved

    Activity 2.6 Performance, servicing, maintenance, and phase out Date / Initials Task 3.6.1 Performance and maintenance Method 3.6.1 Peer review 2. edition, February 2004 784776057.doc

Based on Nordtest

    NT Techn Report 535 System Validation Report Page 5 of 20

Activity 2.6 Performance, servicing, maintenance, and phase out Date / Initials

    Task 3.6.2 New versions

    1. Version:

    2. Version:

    3. ...

    Method 3.6.2 Peer review

    1. Action:

    2. Action:

    3. ...

    Task 3.6.3 Phase out

    Method 3.6.3 Peer review

3 System life cycle activities

    This section contains tables for documentation of the system validation activities. Each subsection is numbered in accordance with the overview scheme above. The tables are filled in with information about the tasks to be performed, methods to be used, criteria for acceptance, input and output required for each task, required documentation, the persons that are responsible for the validation, and any other information relevant for the validation process. Topics excluded from being validated are ex-plicitly marked as such.

    3.1 Requirements and system acceptance test specification

    The requirements describe and specify the computer system completely and are basis for the develop-ment and validation process. A set of requirements can always be specified. In case of retrospective validation (where the development phase is irrelevant) it can at least be specified what the system is purported to do based on actual and historical facts. The requirements should encompass everything concerning the use of the system.

    Topics 3.1.1 Requirements specification

    Objectives

    Description of the computer

    system to the extent needed

    for design, implementation,

    testing, and validation.

    Version of requirements

    Version of, and changes

    applied to, the requirements

    specification.

    Input

    All inputs the computer

    system will receive. Includes

    ranges, limits, defaults, re-

    sponse to illegal inputs, etc.

    2. edition, February 2004 784776057.doc

Based on Nordtest

    NT Techn Report 535 System Validation Report Page 6 of 20

    Topics 3.1.1 Requirements specification Output

    All outputs the computer

    system will produce.

    Includes data formats, screen presentations, data

    storage media, printouts,

    automated generation of documents, etc.

    Functionality

    All functions the computer

    system will provide. Includes

    performance requirements,

    such as data throughput,

    reliability, timing, user interface features, etc.

    Traceability

    Measures taken to ensure that critical user events are recorded and traceable (when, where, whom, why).

    Hardware control

    All device interfaces and equipments to be supported.

    Limitations

    All acceptable and stated limitations in the computer

    system.

    Safety

    All precautions taken to pre-

    vent overflow and malfunc-

    tion due to incorrect input or

    use.

    Default settings

    All settings applied after power-up such as default input values, default instru-

    ment or program control settings, and options selected

    by default. Includes infor-

    mation on how to manage and maintain the default settings.

    2. edition, February 2004 784776057.doc

Based on Nordtest

    NT Techn Report 535 System Validation Report Page 7 of 20

    Topics 3.1.1 Requirements specification Version control

    How to identify different

    versions of the computer

    system and to distinguish

    output from the individual

    versions.

    Dedicated platform

    The hardware and software operating environment in which to use the computer

    system. E.g. laboratory or office computer, the actual operating system, network,

    third-party executables such as Microsoft Excel and

    Word, the actual version of the platform, etc.

    Installation

    Installation requirements, e.g. installation kit, support, media, uninstall options, etc.

    How to upgrade

    How to upgrade to new

    versions of e.g. service packs, Microsoft Excel and

    Word, etc...

    Special requirements

    Requirements the laboratory is committed to, security, confidentiality, change

    control and back-up of

    records, protection of code and data, precautions, risks

    in case of errors in the computer system, etc.

    Documentation

    Description of the modes of operation and other relevant

    information about the

    computer system.

    User manual

    User instructions on how to use the computer system.

    2. edition, February 2004 784776057.doc

Based on Nordtest

    NT Techn Report 535 System Validation Report Page 8 of 20

    Topics 3.1.1 Requirements specification On-line help

    On-line Help provided by

    Windows programs.

    Validation report

    Additional documentation stating that the computer

    system has been validated to the extent required for its

    application.

    Service and

    maintenance

    Documentation of service and support concerning

    maintenance, future updates,

    problem solutions, requested modifications, etc.

    Special agreements

    Agreements between the supplier and the end-user

    concerning the computer

    system where such

    agreements may influence the computer system devel-

    opment and use. E.g. special

    editions, special analysis, extended validation, etc.

    Supplier audit

    Formal assessment to verify that the supplier is qualified.

    Phase out

    Documentation on how (and when) to discontinue the use of the computer system, how

    to avoid impact on existing

    systems and data, and how to recover data.

    Errors and alarms

    How to handle errors and alarms.

The system acceptance test specification contains objective criteria on how the computer system

    should be tested to ensure that the requirements are fulfilled and that the computer system performs as

    required in the environment in which it will be used. The system acceptance test is performed after the

    2. edition, February 2004 784776057.doc

Based on Nordtest

    NT Techn Report 535 System Validation Report Page 9 of 20

computer system has been properly installed and thus is ready for the final acceptance test and

    approval for use.

    Topics 3.1.2 System acceptance test specification Objectives

    Description of the operating

    environment(s) in which the

    computer system will be

    tested and used.

    Scope

    Scope of the acceptance test. E.g. installation and version, startup and shutdown,

    common, selected, and

    critical requirements, and

    areas not tested.

    Input

    Selected inputs the computer

    system must receive and

    handle as specified.

    Output

    Selected outputs the

    computer system must

    produce as specified.

    Functionality

    Selected functions the

    computer system must

    perform as specified.

    Personnel

    Description of operations the actual user(s) shall perform

    in order to make evident that the computer system can be

    operated correctly as

    specified and documented.

    Errors and alarms

    How to handle errors and

    alarms.

    3.2 Design and implementation process The design and implementation process is relevant when developing new systems and when handling

    changes subjected to existing systems. The output from this life cycle phase is a program approved and

    accepted for the subsequent inspection and testing phase. Anomalies found and circumvented in the

    design and implementation process should be described in section 3.4, Precautions.

    2. edition, February 2004 784776057.doc

Based on Nordtest

    NT Techn Report 535 System Validation Report Page 10 of 20

Topics 3.2.1 Design and development planning

    Objectives

    Expected design outcome,

    time schedule, milestones,

    special considerations, etc.

    Design plan

    Description of the computer

    system e.g. in form of flow-

    charts, diagrams, notes, etc.

    Development plan

    Development tools,

    manpower, and methods.

    Review and acceptance

    How to review, test, and

    approve the design plan.

The design input phase establishes that the requirements can be implemented. Incomplete, ambiguous,

    or conflicting requirements are resolved with those responsible for imposing these requirements. The

    input design may be presented as a detailed specification, e.g. by means of flow charts, diagrams,

    module definitions etc.

    Topics 3.2.2 Design input

    Requirements analysis

    Examinations done to ensure

    that the requirements can be

    implemented.

    System modules

    Description of the system

    modules to be implemented.

    Review and acceptance

    How to review, test, and

    approve the Design Input

    section.

The design output must meet the design input requirements, contain or make references to acceptance

    criteria, and identify those characteristics of the design that are crucial to the safe and proper func-

    tioning of the product. The design output should be validated prior to releasing the computer system

    for final inspection and testing.

    2. edition, February 2004 784776057.doc

Report this document

For any questions or suggestions please email
cust-service@docsford.com