Typical URS Contents
Previous Topic  Next Topic 




Below is a typical URS contents list, mostly From GAMP

Whilst useful, a problem is that is does not readily provide a structure that matches the S88 models.

And it does not show functional versus non functional requirements, indeed it mixes them up.

With Functional Requirements based on the S88 models the operational, functional and data aspects of an entity (such as a Unit or an Equipment module) are contained together, whereas the URS below has them in different sections. See also Specification Sections and Modules

Download Word URS Template

1 Introduction

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.

2 Overview

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

2..1 Background

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

2.2 Key objectives and benefits

2.3 Main functions and interfaces.

3. Operational Requirements

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

The following sub-sections shall be included:

3.1. Functions

This sub-section shall define the required system functions, modes of operation, and behavior. It should address the following:

  Functions required. Information on the process or existing manual system should 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.

  Failure. Action required in case of selected software or hardware failure.

  Safety and security.

3.2 Data

This sub-section shall state the data handling requirements. It should address the following:

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

  Capacity requirements

  Access speed requirements

  Archive requirements

3.3. Interfaces

This sub-section shall define any system interfaces. It shall contain the following sub-sections:

1. Interface with users. These should be defined in terms of roles (e.g. plant operator, warehouse administrator, manager etc.) and/or functions as appropriate.

2. Interface with other systems.

3. Interface with equipment (e.g. sensors/actuators). This includes I/O listings for process control systems.

3.4. Environment

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

1. Layout. The physical layout of the plant or other work place may have an impact on the system (e.g. long distance links, space limitations).

2. Physical conditions (e.g. dirty, dusty or sterile environment etc.).

4. Constraints

This section shall define the constraints on the specification of the system. It shall contain the following sub-sections:

4.1 Time scales, and milestones

as appropriate.

4.2 Compatibility.

This shall take into account any existing systems or hardware, and any company or plant strategy.

4.3 Availability.

This shall state reliability requirements, and maximum allowable periods for maintenance or other down-time.

4.4 Procedural constraints

(e.g. statutory obligations, legal issues, working methods and user skill levels).

4.5 Maintenance

(e.g. ease of maintenance, expansion capability, likely enhancements, expected lifetime, long term support).

5 Life-cycle

This section shall define any requirements concerning the development life-cycle. It shall contain the following sub-sections:

5.1 Development

(e.g. procedures for project management and quality assurance, mandatory design methods).

5.2 Testing

(e.g. special testing requirements, test data, load testing, Simulation).

5.3.Delivery.

This section shall define what deliverables are required. It should address the following:

  How deliverable items are to be identified.

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

  Documents. What the supplier is expected to deliver (e.g. functional specification, testing specifications, design specifications etc.).

  Data to be prepared or converted.

  Tools.

  Training courses.

  Archiving facilities.

5.4 Support.

This section shall define what support is required after acceptance.

6 Glossary

This section shall contain definitions of terms which may be unfamiliar to the reader of the URS.

7 Appendix  - Functional Requirements Model