VAL-140 Development of a User and Functional Requirement Specification

5.1 URS Development Guidelines

The following guidelines are to be followed to develop the required URS document:

5.1.1  The document must be issued a unique document number and must be version controlled.

5.1.2 The URS must express the required user requirements and not the methods or solutions to implement the required functions.

5.1.3 The URS should refer to and interpret the relevant GxP regulations. This is to assist the project team and suppliers to deliver a compliant system meeting GxP requirements. Each requirement statement is to be uniquely referenced to aid traceability.

5.1.4 Requirements should not be duplicated or contradicted throughout the document.

5.1.5 Each requirement should be testable or verifiable in some way.

Note: The URS requirement should be linked to the final PQ (Performance Qualification) protocol for the system, which tests the system in its operating environment, including the associated procedures.

5.1.6 The URS should distinguish between essential requirements (musts) and non essential requirements (wants).  These requirements should be clear priorities within the URS document.

5.1.7 The URS should refer to and interpret the relevant GxP regulations.  This is to assist the project team and suppliers to deliver a compliant system meeting GxP requirements.

5.2 URS Document Content

The URS must include each of the sections and sub sections below. If no requirements have been specified then section should include the statement “Not applicable to this URS” and include a brief reason for this omission.

5.2.1 Cover Sheet

The cover of the document needs to include:

– The name(s), signature(s), date and position of the personnel involved in the preparation of the specification.

– The name(s) and signature(s) date and position of the personnel reviewing / approving the specification.

5.2.2 Introduction

This section needs to contain the following information:

– Who produced the document and for what purpose.

– A brief statement to state the URS has been reviewed (by whom) and approved, and the next stage of the system development process can proceed.

– Relationship to other documents.

– Table of Contents.

5.2.3 Overview

This section shall give an overview of the system explaining why it is required, and what is required of it.  It needs to contain the following sub-sections:

– Background (e.g. corporate strategies, previous studies).

– Key objectives and benefits.

– Main functions and interfaces.

– Applicable GxP requirements.

– Other applicable regulations.

5.2.4  Operational Requirements

This Section needs to state the operational requirements: system functions, data, and interfaces. It shall also define the environment in which the system must operate. Critical requirements need to be specifically identified as such. Process descriptions and flowcharts may be included as appropriate.

Special consideration will be given to GxP requirements. These should be clearly defined with reference to the relevant regulations where possible.

The following sub-sections shall be included:

5.2.4.1 Functions

The sub-section needs to define the required system functions, modes of operation, and behavior. It must address the following:

– Functions required: information on the process or existing manual system is to be included here, if not covered adequately elsewhere.

– Calculations, including all critical algorithms.

– Modes of operation (e.g. start-up, shutdown, test, fallback).

– Performance and timing requirements. These should be quantitative and unambiguous.

– Action required in case of failure.

– Safety.

– Security.

– Data

This sub section shall state the data handling requirements. It needs to address the following:

– Definition of the data, including identification of critical parameters, valid data ranges and limits.

– Capacity requirements.

– Access speed requirements.

– Archive requirements.

– Data security and integrity.

5.2.4.2 Interfaces

This sub-section needs to define any system interfaces. It must contain the following sub-sections:

– Interface with user: these should be defined in terms of roles, (e.g. plant operator, warehouse administrator, system manager) or functions as appropriate.

– Interface with other systems.

– Interface with equipment, such as sensors and actuators. This may include I/O listings for process control systems.

5.2.4.3 Environment

This sub-section must define the environment in which the system is to work. It shall contain the following sub-sections:

– Layout: the physical layout of the plant or other work place may have an impact on the system, such as long distance links or space limitations.

– Physical conditions (e.g. dirty, dusty, or clean environment).

5.2.4.4 Constraints

This sub-section must define the constraints on the specification of the system.  It needs to cover the following:

– Timescales and milestones: as appropriate.

– Compatibility: this shall take into account any existing systems or hardware and any user company strategy or policy.

– Availability: this will state reliability requirements and define any maximum allowable periods for maintenance or other downtime.

– Procedural constraints: such as statutory obligations, legal issues, working methods and user skill levels.

– Maintenance: including ease of maintenance, expansion capability, likely enhancements, expected lifetime and long term support.

5.2.5 Life Cycle

This Section is to define any requirements concerning the validation life cycle.  It needs to contain the following sub-sections:

5.2.5.1  Development (e.g. minimum standards to be met by supplier’s methodology, procedures for project management and Quality Assurance, mandatory design methods).

5.2.5.2  Testing (e.g. special testing requirements, test data, load testing and required simulations).

5.2.5.3  Delivery: this sub-section shall define what deliverables are required. It should address the following:

5.2.5.4   How deliverable items are to be identified.

5.2.5.5  In what form deliverables are to be supplied (e.g. format and media).

5.2.5.6  Documents: what the supplier is expected to deliver (e.g. functional specification, testing specifications).

5.2.5.7  Data to be prepared or converted.

5.2.5.8  Tools.

5.2.5.9   Training courses.

5.2.5.10   Archiving facilities.

5.2.5.11   Support: this sub-section needs to define what support is required after acceptance.

5.2.6 Glossary

This section needs to contain definitions of any terms that may be unfamiliar to the readership of the document.

5.3  FRS Document Guidelines

5.3.1  The FRS document needs at a minimum to contain the following information. Other sections may be included which are individual requirements for a specific Project.

5.3.2  Each internally generated FRS is to be issued with a unique number.

5.3.3  If the FRS document is supplied by an external supplier, it is to be registered with a unique number.

5.3.4  The start of the document should provide:

– The name(s), signature(s), date and position of the personnel involved in the preparation of the specification.

– The name(s), signature(s), date and position of the personnel approving the specification.

– Table of Contents.

5.3.5  An Amendment List must be included to document any changes made to the specification.

5.3.6 The management of changes should be clearly described.  If for any reason the approved FRS is subject to change, the change control procedure must be used.

5.4  FRS Document Content

The following steps (Steps 5.4.1 to 5.4.7) of this procedure detail the contents for each of the sections. For internally developed FRS documents, all sections must be present, but if no requirement has been specified, then the section needs to state “Not applicable”. For FRS documents supplied by external vendors, the equivalent information detailed in Steps 5.4.1 to 5.4.7 should be included in the FRS.

5.4.1  Introduction

This section needs to provide a brief description of the purpose of the FRS. This introduction will need to include the relationship to other documents.

5.4.2   Overview

– Provide a brief description of the required system, its installation site and intended use.

– Provide any organizational goals and objectives to be met.

– List all codes, policies, procedures and standards to be complied with throughout the development, design, construction, implementation and testing of the required System.

– Schedule – Non conformances with the requirements of the User Requirement Specification.

5.4.3  Background Information

This section needs to cover the following and any other information relevant to the specific Project:

– If the required system is to replace or enhance an existing system, provide a brief description of the latter, emphasizing any weaknesses which it is required to eliminate or enhance.

– Specify any connections or integration there may be between the required System and other Systems / equipment, manual or automated, both within the organization and outside.

– A brief description of these systems / equipment should be included, describing how the system or sub systems interact, what they each provide and what they require.

– Document System capacity and whether the System should be capable of any future expansion.

– Document what the minimum expected lifecycle (in years) of the System is.

– Document the level of education, training and experience required to operate the System.

5.4.4  Functional Requirements

5.4.4.1  Functions

This Section shall take the high level description, and break it down as far as the level of the individual functions. It shall describe the functions and facilities to be provided, including specific modes of operation.

The following aspects should be addressed:

– The objective of the function or facility, and the details of its use, including interface with other parts of the system. Critical calculations and algorithms should be highlighted.

– Performance; response, accuracy, and throughput.  These should be quantitative and unambiguous.

– Safety and security – The topics may include:  action in case of selected software or hardware failures, self checking, input value checking, redundancy, access restrictions, time-outs and data recovery.

– Functions which are configurable and any limits within which the configuration can take place.

– Traceability to specific requirements in the User Requirements Specification.

5.4.4.2  Data

This Section needs to define the data on which the system is to work. The following aspects need to be addressed:

– Definition: the data to be defined in a hierarchical manner with complex objects being built up from simpler objects (e.g. files of records; complex types defined in terms of simple types). Critical parameters should be highlighted.

– Access (e.g. which sub-systems need read or write access to each data item, access method, speed and update time, read / write interlocks).

– Data capacity, retention time, and details of data archiving.

– Data integrity and security.

5.4.4.3  Interfaces Section

This Section is to define any system interfaces, defining how the system or sub-system interact, what they each provide, and what they require. For GxP regulated systems, the security of the interfaces is of critical importance. This Section needs to contain the following sub-sections:

– Interface with users: this is to be defined in terms of roles; e.g. operator, administrator, clerk, or system manager.  Topics to consider include facilities available, types of peripherals, general format of display and reports, error handling and reporting, and security.

– Interface with equipment, such as sensors and plant equipment.

– Interface with other systems: this needs to cover the nature of the interaction and the methods and rules governing the interaction.

Topics to consider for both equipment and system interfaces are listed below:

– Data transmitted and received

– Data type, format, ranges, and meaning of values

– Timing

– Rates of data transfer

– Communications protocol:  initiation and order of execution

– Any data sharing, creation, duplication, use storage or destruction

– Mechanisms for invocation and interruption

– Communication through parameters, common data areas, or message

– Direct access to internal data

– Error handling, recover and reporting

– Security

5.4.5  Glossary Section

This section shall contain definitions of any terms that may be unfamiliar to the readership of the document.

5.4.6  Appendices

Where appropriate; e.g. small systems, appendices may be provided to define hardware and software specifications.

5.4.7   Software Development

A brief statement describing the requirements of the Vendor / developer to provide written assurance that software development, modification and testing complies with appropriate software guidelines for the development, supply and maintenance of software or equivalent.

These requirements also apply to internal software development or modification.

5.4.8  Security Requirements

Security measures must be considered for the proposed System. Consideration must be given to the following:

5.4.8.1 Physical Security of Hardware

Include information regarding locking of computer hard drive, limited access to computer facility, etc.

5.4.8.2  Access

A hierarchy of permitted access to enter, amend, read or print data should be established based on job responsibility and authority.  Include the number of security levels the system shall support; e.g. Operators, Supervisors, Administrator, etc.

Suitable methods of preventing unauthorized access should be available; example passwords, bar codes or automatic log off due to a specified number of log in attempts, etc.

Regular change of access codes must be in place possibly by means of an automatic prompt from the System.

5.4.8.3  Data

Security measures need to describe who has authorized access to and/or alteration of data. The System needs to should create a complete record (non mutable audit trail) of all entries and amendments to the database.  This audit trail can either be manual or electronic (preferable) and must include identification of the original data, the new entry, the date of the change, by whom and reason for change.

Subject to the format and method of transfer of data, security measures are to be established to ensure integrity of the data whilst in use or archived.  (Measures should be in place to ensure data is secured against theft, loss or alteration).

5.4.8.4  Software

Authorized access to software for modification.

5.4.9  Backup and Recovery Requirements

The requirements for Backup of data and Recovery from a System failure (includes power failure, communication breakdown between interfaces and equipment) need to be identified in this section.  Issues which should be covered are:  frequency of backup, adequate identification and storage of backup media, contingency plans if the system is not operational for an extended period of time.