Appendix D2 FS.pdf

GAMP 4 Guide Page 1 Validation of Automated Systems December 2001

Appendix D2

1 Introduction

This is an example procedure for the production of Functional Specifications.

The Functional Specification defines a system to meet the user's needs, as described in a User Requirements

Specification [1].

2 Scope

This procedure applies to the production of all Functional Specifications. If a Functional Specification does not conform

to this procedure, then the reason for this shall be documented in the Quality and Project Plan.

3 Procedure

3.1 General Guidelines

A Functional Specification defines what the system should do, and what functions and facilities are to be provided. It

provides a list of design objectives for the system.

The following guidelines should be followed during the production of the specification: .

All limitations should be explicitly defined

.Ambiguity, duplication, and contradiction should be avoided .Consistent naming conventions should be used

.Each function and facility described should be testable

.The Functional Specification should be clear enough to enable design to proceed without frequent consultation

with the user

The specification shall be structured in a way that permits traceability of individual requirements.

A Guideline for Design Review and Requirements Traceability Matrix is given in Appendix M5.

3.2 Contents of the Document

This Section defines which Sections shall be included in the specification. All Sections shall be present. Ifno

requirement has been specified, then the Section shall state 'Not Applicable'.

GAMP 4 Guide P age , Validation of Automated Systems December 2001

Appendix D2

3.2.1 Introduction Section

This Section shall contain the following information:

Who produced the document, under what authority, and for what purpose

The contractual status of the document

Relationship to other documents

3.2.2 Overview Section

This Section shall state the essential system functions and interfaces to the outside world. It should cover the following:

.Key objectives and benefits

.Reference to relevant GxP regulations

.High level description: this should give a breakdown into the main sub-systems The main interfaces from the system to

other systems or the environment

.Assumptions: this should state any design or implementation assumptions or limitations ( e.g., use ofstandard

packages, operating system, hardware)

.Non-conformance with User Requirements Specification: any divergence between the Functional Specification and the

User Requirements Specification should be noted

3.2.3 Functions 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

3.2.4 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

GAMP 4 Guide Page 3 Validation of Automated Systems December 2001

Appendix D2

3.2.5 Interfaces Section

This Section shall define any system interfaces, defining how the systems or sub systems 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 ofroles, e.g., operator, administrator, clerk, or system manager.

Topics to consider include facilities available, types of peripherals, general format of displays 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 messages Direct access to internal data

.Error handling, recovery, and reporting

Security

3.2.6 Non-functional Attributes Section

This Section shall define how the system will meet non-functional requirements. It shall contain the following sub-

sections:

.Availability (e.g., reliability, redundancy, error checking, stand-by operation)

.Maintainability ( e.g., expansion and enhancement possibilities, spare capacity, likely changes in environment,

lifetime)

3.2.7 Glossary Section

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

3.2.8 Appendices

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

4 References [ I] Appendix D I -Example Procedure for the Production of a User Requirements Specification

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: