VAL-145 Development of A Functional Requirement Specification for Computer Systems

5.1 FRS Document Requirements

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

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

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

5.1.3 The start of the document should provide:

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

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

5.1.3.3 Table of Contents.

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

5.1.5 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.2 FRS Contents

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

5.2.1 Introduction

This section shall provide a brief description of the purpose of the FRS. This introduction should include the relationship to other documents.

5.2.2 Project Overview

5.2.2.1 Purpose and Scope of the Required System

Provide a brief description of the System, its installation site and intended use.

5.2.2.2 Objectives and Goals of Project

Provide any organizational goals and objectives to be met.

5.2.2.3 Codes, Policies and Standards

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

5.2.2.4 Schedule

Non conformances with the requirements of the User Requirement Specification.

5.2.3 Background Information

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

5.2.3.1 Existing System Replacement or Enhancement

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.

5.2.3.2 Integration With Other Systems

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.

5.2.3.3 System Capacity

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

5.2.3.4 System Lifecycle

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

5.2.3.5 Operational Skills

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

5.2.4 Functional Requirements

5.2.4.1 Function Section

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.2.4.2 Data Section

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

˜ Definition:  the data should 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.2.4.3 Interfaces Section

This Section shall 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 shall contain the following sub-sections:

˜ Interface with users:  this should 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 should 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.2.4.4 Glossary Section

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

5.2.4.5 Appendices

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

5.2.5 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.2.6 Security Requirements

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

5.2.6.1       Physical Security of Hardware

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

5.2.6.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.2.6.3 Data

Security measures should describe who has authorized access to and/or alteration of  data.  The System 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.2.6.4 Software

Authorized access to software for modification.

5.2.7 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.