0% found this document useful (0 votes)
122 views6 pages

Validation and Verification of Software Systems - 0

This document provides guidance for validating and verifying software systems used at the Cambridge Clinical Trials Unit (CCTU). It outlines templates and documents to define software requirements and functional specifications, as well as plan and perform installation qualification, operational qualification, and performance qualification to ensure software meets requirements. The validation and verification process compares realized software outputs to expected outputs documented in requirements and specifications.

Uploaded by

Mahesh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
122 views6 pages

Validation and Verification of Software Systems - 0

This document provides guidance for validating and verifying software systems used at the Cambridge Clinical Trials Unit (CCTU). It outlines templates and documents to define software requirements and functional specifications, as well as plan and perform installation qualification, operational qualification, and performance qualification to ensure software meets requirements. The validation and verification process compares realized software outputs to expected outputs documented in requirements and specifications.

Uploaded by

Mahesh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Cambridge Clinical Trials Unit Box 401

Standard Operating Procedure CCTU/SOP056


Validation and Verification of Software Systems

1. Scope
This SOP applies to software used within the CCTU that requires validation and
verification to evidence that it is fit for its intended purpose.
The SOP also applies to purchased software as well as software written in-
house where the data the system contains is used for the formal statistical
analysis for the trial.

2. Purpose
The purpose of this SOP is to provide an overview of how to use the various
templates and documents available to undertake the validation and verification
process

3. Definitions and Abbreviations


The headings below contain the definitions of terms and meaning of
abbreviations used within the document.

3.1. Definitions
Term Definition
Cambridge Sponsored by Cambridge University Hospitals NHS Foundation
Sponsored Trust (CUH); or the University of Cambridge (UoC); or jointly
by CUH and UoC
OR
Sponsored by: Cambridge University Hospitals NHS Foundation
Trust (CUH) or CUH jointly with the University of Cambridge
or Cambridgeshire & Peterborough NHS Foundation Trust
(CPFT) or CPFT jointly with the University of Cambridge
Validation The assurance that a system meets the needs of the customer
and other identified stakeholders
Verification The evaluation of whether a system complies with the
requirements and specification of the system
Software The business needs for the system are defined in terms of the
Requirements user, system and interface needs of the system.
Functional A functional specification documents the operations and
Specification activities that a system must be able to perform.
Installation Installation Qualification verifies the proper installation and
Qualification configuration of a system
Operational Operational Qualification verifies the proper functioning of a
Qualification system
Performance Performance Qualification validates that a system performs
Qualification according to the user requirements of the system and is
therefore fit for purpose

CCTU/TPL005/V2
Cambridge University Hospitals NHS Foundation Trust Page 1 of 6
Validation and Verification of Software Systems
CCTU/SOP056 Version 2 Approved 08/08/2019 Last Reviewed 08/08/2019
Cambridge Clinical Trials Unit Box 401

Story In software development a story or user story is a term used to


describe the processes that a user needs to perform in order to
undertake their job function.
Vendor software Software purchased from a software creator outside of the trial
team
In-house software Bespoke software written by or for the trial team

3.2. Abbreviations
Abbreviation Meaning
SR Software Requirements
FS Functional Specification
IQ Installation Qualification
OQ Operational Qualification
PQ Performance Qualification

4. Undertaken by
CCTU staff wishing to provide assurance that a system is operating according to
its specification and requirements and that it is fit for its intended purpose.

5. Items Required
 CCTU/TPL041 Software Requirements Template
 CCTU/TPL042 Functional Specification Template
 CCTU/TPL043 Software Validation and Verification Plan Template
 CCTU/TPL044 Installation Qualification Template
 CCTU/TPL045 Operational Qualification Template
 CCTU/TPL046 Performance Qualification Template

6. Summary of Significant Changes


1. Clarification of the scope of the SOP
2. Requirements when using vendor software
3. Further detail in Upgrades and Revisions

7. Method
The following sections provide a description of the processes to be followed
when implementing this document’s procedures.

7.1. Expectation
The following sections outline the supporting documents that should be
completed in order to define the software business needs, as well as test that
the provided software meets these business needs. This will provide assurance
that a system is operating according to its specification and requirements and
that it is fit for its intended purpose.

CCTU/TPL005/V2
Cambridge University Hospitals NHS Foundation Trust Page 2 of 6
Validation and Verification of Software Systems
CCTU/SOP056 Version 2 Approved 08/08/2019 Last Reviewed 08/08/2019
Cambridge Clinical Trials Unit Box 401

The process of verifying and validating software comprises of a set of


procedures that compares the realised output of software development with the
expected output. This requires the expected output is documented clearly and
provides sufficient detail to the developer whilst keeping the language in the
everyday or job-specific domain

7.2. Software Requirements


Software Requirements (SR) are written by system stakeholders and define the
business needs that users require from the system. These are written prior to
the existence of the system, although this is not a strict requirement.
An example of this may be where a simple system exists but requires further
development and the users and developers require a formal document to help
understand the system due to the expected increase in complexity.
The document will cover many aspects of the system, but a key part is the
documentation of User, System and Interface requirements. Refer to the
Software Requirements Template CCTU/TPL041.
The SR document provides the basis of the future testing process to test that
the system produced matches the defined business needs.
Once agreed by stakeholders the SR document must be approved and signed
off.

7.3. Functional Specification


The Functional Specification (FS) details the operations and activities that a
system must be able to perform.
It covers aspects of the system that must be documented. At its core it
documents the list of stories that specify the functions of the system that
enable a user to perform their job role and provides a mapping between the SR
and technical functions that the system must perform.
Refer to the Functional Specification Template CCTU/TPL042
The FS document also provides a basis for future testing. It is used to verify
that the implementation of the system performs according to the specification.
Once agreed by stakeholders, the document must be approved and signed off.

7.4. Plan the Validation and Verification Process


Use CCTU/TPL043 the Software Validation and Verification Plan Template to
record the process to be followed and document all the necessary deliverables,
time-lines etc. so that the process will be understood by all those involved.
The plan ensures that the process is smooth and timely and all the compliance
requirements for the process are met.
Once agreed by stakeholders, the document should be approved and signed off.

7.5. Installation Qualification


The Installation Qualification (IQ) is a process that verifies that the system has
been installed and configured according to the requirements of the system.
It is used to document that all necessary precursory steps have been taken to
ensure that the available system is in a known state prior to any further
testing. Refer to the Installation Qualification Template CCTU/TPL044.

CCTU/TPL005/V2
Cambridge University Hospitals NHS Foundation Trust Page 3 of 6
Validation and Verification of Software Systems
CCTU/SOP056 Version 2 Approved 08/08/2019 Last Reviewed 08/08/2019
Cambridge Clinical Trials Unit Box 401

Once testing is complete and all items have passed, the document must be
approved and signed off.

7.6. Operational Qualification


The Operational Qualification (OQ) is undertaken to demonstrate that the FS is
adhered to by the system under test.
It is undertaken by the developer and provides evidence that the individual
components and modules that together comprise the system are implemented
correctly according to the FS.
This process is usually undertaken prior to the release of the system.
The documented tests may be run manually. They may also be the output from
industry standard methods of running automated tests, for example unit tests
and integration tests.
Test coverage should be sufficient to ensure the system is fit-for-purpose.
Refer to the Operational Qualification Template CCTU/TPL045.
Once testing is complete and all items have passed, the document must be
approved and signed off.

7.7. Performance Qualification


The Performance Qualification (PQ) process tests that the system performs
according to expectation in a real-world setting.
It validates that the system produced is fit for its intended purpose and that the
requirements have been met.
This process is undertaken once the IQ and OQ have been performed and
provides evidence of user acceptance testing undertaken by the stakeholders of
the system. Refer to the Performance Qualification Template CCTU/TPL046.
Once testing is complete and all items have passed, the document must be
approved and signed off.

7.8. Vendor and In-house software


For best practice, any software written in-house should be supported by
evidence that it is operating correctly and is fit-for-purpose.
For software developed in-house where the data it contains are used for the
formal analysis of the trial outcomes, the full suite of documentation MUST be
completed and should document and test all pertinent aspects of the software.
However, for purchased software the vendor will usually have gathered their
own requirements, created their own functional specification and performed
operational qualification prior to selling their software. These documents should
be available from the vendor on request. Users of the software MUST undertake
the installation and performance qualification to ensure the software meets the
requirements and is operating as expected.

7.9. Final Approval


After completion of the PQ, the system developed is available for use.
There is no final approval document as such, but upon request each of the
individual parts of the validation and verification process should be available for
inspection.

CCTU/TPL005/V2
Cambridge University Hospitals NHS Foundation Trust Page 4 of 6
Validation and Verification of Software Systems
CCTU/SOP056 Version 2 Approved 08/08/2019 Last Reviewed 08/08/2019
Cambridge Clinical Trials Unit Box 401

For vendor systems, usually some formal method of approval would be required
to inform the vendor that users are content that the provided software is fit-
for-purpose. For example, for remotely hosted applications the final release of
the revised software may not be available until formal approval is made.

7.10. Upgrades and Revisions


After initial release, the system will usually be subject to revision as a result of
bug fixes, code improvements and new requirements. All of these change
requests should be fully documented with details of the change required, who
made the request, how the request was handled and the final outcome.
All the required specification and qualification documents should be available
and these should accurately reflect the new specification and implementation of
the system. The documents should clearly show which version of the system is
being tested.

8. Monitoring Compliance with and the Effectiveness of


this Document
a. Process for Monitoring Compliance and Effectiveness
As part of routine monitoring visits, audit and inspection
b. Standards/Key Performance Indicators
This process forms part of a quality management system and is reviewed
according to CCTU procedures. Standard Operating Procedures are reviewed
every two years.

9. References
The Institute of Clinical Research, Abbreviations used in Clinical Trials.
MHRA, Good Clinical Practice “Grey Guide”

10. Associated Documents


NA

11. Equality and Diversity Statement


This document complies with the Cambridge University Hospitals NHS
Foundation Trust service equality and diversity statement.

12. Disclaimer
It is the user’s responsibility to check against the electronic library that this
printed out copy is the most recent issue of this document.

Review date 2 years (or earlier in light of new evidence) from approval date
Owning department: CCTU QA
Supersedes: CCTU/SOP056V1

CCTU/TPL005/V2
Cambridge University Hospitals NHS Foundation Trust Page 5 of 6
Validation and Verification of Software Systems
CCTU/SOP056 Version 2 Approved 08/08/2019 Last Reviewed 08/08/2019
Cambridge Clinical Trials Unit Box 401

Local reference: CCTU/SOP056V2

CCTU/TPL005/V2
Cambridge University Hospitals NHS Foundation Trust Page 6 of 6
Validation and Verification of Software Systems
CCTU/SOP056 Version 2 Approved 08/08/2019 Last Reviewed 08/08/2019

You might also like