Software Requirements Document

Issue: Draft Rev. 0- Last modified: 21 April, 1997

This document is also available both as an MS-Word and an A4 PostScript files.

Document Change Record

1. Introduction

• 1.1 Purpose Of The Document
• 1.2 Scope Of The Software
• 1.3 Definitions, Acronyms And Abbreviations
• 1.4 References
• 1.5 Overview Of The Document

2. General Description

• 2.1 Relation to Current Projects
• 2.2 Relation to Predecessor and Successor Projects
• 2.3 Function and Purpose
• 2.4 Environmental Considerations
• 2.5 Relation to Other Systems
• 2.6 General Constraints

3. Specific Requirements

• 3.1 Functional Requirements
• 3.2 Performance Requirements
• 3.3 Interface Requirements
• 3.4 Operational Requirements
• 3.5 Resource Requirements
• 3.6 Verification Requirements
• 3.7 Acceptance Test Requirements
• 3.8 Documentation Requirements
• 3.9 Security Requirements
• 3.10 Portability Requirements
• 3.11 Reliability Requirements
• 3.12 Maintainability Requirements
• 3.13 Safety Requirements

4. Requirements Traceability Matrix

1. Introduction

1.1 Purpose Of The Document

The purpose of this document is to define the Software Requirements for the CMMS Upgrade project. It describes the functions that must be carried out by the CMMS.

1.2 Scope Of The Software

The main aim of a CMMS is to assist in the planning, management and administrative procedures required for effective maintenance.

A new system should replace the current CMMS package, RAPIER.

The baseline product (to be tested by pilot project) should be in production in a time scale of 9 months.

1.3 Definitions, Acronyms And Abbreviations

1.3.1 Definitions

Access State a value reflecting the accessibility of an equipment.

Action Codes used to signal actions done in a condensed way.

Activity a routine or job's single task including instruction and/or part lists executed by a specific human resource.

Asset a piece of equipment to be maintained.

Category a sub-division of a class.

Class a group of objects that are related, but not dependent on each other.

Contract an external enterprise commercial supply of parts and/or work.

Corrective Maintenance maintenance work needed for the correction of a malfunction.

Division, group, section and unit CERN's internal organisation structure.

Fixed Preventive Maintenance preventive maintenance with next scheduled date depending on last planned date.

Functional Position a functional position allows the definition of an asset in terms of the task it carries out.

Job work on a given asset, at a given time on a specific location.

Maintenance Responsibility Centre a organisational unit responsible for equipment maintenance.

Nested Routines a set of routines with one including the other.

Object an object of maintenance may be an asset, a system or a category.

Operational State a value reflecting the condition of an equipment.

Overridden Maintenance work that is not done on an equipment, due to the overlapping of planned jobs with the same purpose.

Picking List parts required to undertake an activity.

Predictive Maintenance maintenance work called for by the results of sensor measurements or specific equipment operating characteristics which indicate possible failures.

Preventive Maintenance rigidly scheduled pre-defined sets of maintenance tasks performed to counteract known sources of potential equipment failure.

Request Codes used to signal occurred events in a condensed way.

Rapier current CERN's CMMS; a product from SQL Systems.

Routine preventive maintenance work order. It includes lists of activities and objects to maintain under it.

System a gathering reflecting logical rather than physical relationships among assets.

Task each component of an activity; it may comprehend a list of instructions and/or parts .

Type a non-maintenance related category.

Variable Preventive Maintenance preventive maintenance with next scheduled date depending on last completion date.

Work Order a statement of required maintenance work on a specific piece of equipment.

Work Order Backlog a list of not completed work.

Work Order Status a value reflecting the state of the work order, e.g. accepted, refused, closed, etc.

1.3.2 Acronyms and abbreviations

AD Architectural Design; one of ESA PSS-05 software lifecycle phases

CERN European Laboratory for Particle Physics

CHF Swiss Franc

CMMS Computerised Maintenance Management System

DB Database

DBU Database User

DD Detailed Design and Production; one of ESA PSS-05 software lifecycle phases

EDH Electronic Document Handling

ESA European Space Agency

EUCLID CAD/CAM/CAE System (Matra Datavision)

MRC Maintenance Responsibility Centre

MS Windows Microsoft Windows Graphical User Interface

PM Preventive Maintenance

RDBMS Relational Data Base Management System

SR Software Requirements; one of ESA PSS-05 software lifecycle phases

SRD Software Requirements Documents

TBC To Be Confirmed

TCR Technical Control Room

URD User Requirements Documents

WWW World Wide Web

X-Windows X11 Graphical User Interface

1.4 References

Two classes of references are detailed in this document:

• Applicable documents are considered to govern or form a part of this SRD.
• Reference documents have a bearing on the content of the SRD, but they do not govern or form a part of it.

1.4.1 Applicable documents

Software Engineering Standards, ESA Board for Software Standardisation and Control,1994

CMMS Upgrade User Requirements Document, P. Martel, M. Symonds, 1996

1.4.2 Reference documents

ESA PSS-05-02 Issue 1, Guide to the User Requirements Definition Phase, October 1991

Software Engineering Guides, C.Mazza, J. Fairclough - Prentice-Hall, 1996

1.5 Overview Of The Document

Following the ESA guidelines [R1] [A1] the document structure is:

Chapter 2 describes the general factors that affect the product and its requirements. It does not state specific requirements; it only makes those requirements easy to understand.

Chapter 3 describes each of the user requirements following the ESA PSS-05 guidelines [R1].

The user requirements will be placed in a tabular format with the following attributes:

1. Identifier - This identifier is listed in the format:

<Functional Group>-<Requirement Number>

where the functional groups are as follows:

FR Functional Requirements

PR Performance Requirements

IR Interface Requirements

OR Operational Requirements

RR Resource Requirements

VR Verification Requirements

ATR Acceptance Testing Requirements

DR Documentation Requirements

SR Security Requirements.

POR Portability Requirements

QR Quality Requirements

RLR Reliability Requirements

MR Maintainability Requirements

SFR Safety Requirements

An example of FR-002 would mean that the requirement is an functional requirement and its number is two.

2. Description - This is a natural language statement of the requirement. It is intended that all such requirements are clear and verifiable.

3. Source - Identifies the origin of the requirement. In most cases this is a user requirement from the URD [A2].

Abbreviations used here are:

PJM - Pedro Martel

STD - Standard Requirement

4. Need - This shows whether the requirement is ESSential or DESirable. Essential requirements are those that are non-negotiable, others may be less vitally important and subject to negotiation.

5. Rank - For incremental delivery, each user requirement shall include a measure of priority so that the developer can decide a production schedule.

6. Stability - Some user requirements may be known to be stable over the expected life of the software others may be more dependant on feedback from the SR, AD and DD phases, or may be subject to change during the software life cycle. Such unstable requirements should be flagged. To Be Confirmed (TBC) will be used to indicate unstable requirements.

Chapter 4 contains a table summarising how each user requirement is met in the SRD.

2. General Description

2.1 Relation to Current Projects

There are no current projects with relevant significance to the CMMS Upgrade.

2.2 Relation to Predecessor and Successor Projects

The only predecessor project that has any bearing on the CMMS Upgrade is the current Maintenance Management Tool - RAPIER, that will be replaced by the new system. There are no know successor projects.

2.3 Function and Purpose

The system will provide a set of tools covering the following funcionalities:

• Asset management
• Work management
• Parts and stores management
• Budget management
• Report production
• Administration
• Analysis

2.4 Environmental Considerations

The environmental considerations relating to the CMMS are as follows:

• users of the system
• environment in the server system
• environment in the client system

2.4.1 Users of the system

Operators

a. Technicians Users who perform the maintenance work. Their interaction with the system includes the closing of a work order when the job is complete, quantity of parts used, the registry of meters' values, etc.

b. Store clerks Responsible for the maintenance of stock levels in accordance with current and future needs.

Each operator falls in to a different category which are as follows:

• Normal user. No ability to alter committed data.
• Supervisor. Ability to alter some committed data and to supply a first-level support to normal users.

TCR Operators

TCR Operators trigger and follow-up corrective work orders on malfunctioning equipment. They are the interface between people and corrective maintenance work.

Managers

Responsible for the planning of work, acceptation of work done, budget planning, etc.

Administrators

Administrators will be responsible for the operation of the system, from installation and customisation to problem reporting.

2.4.2 Environment on the server system

The CMMS server system will reside at CERN, in an ORACLE database server.

2.4.3 Environment on the client system

The CMMS clients will be of 3 types:

• a character based client, residing in the CERNSP UNIX machine,
• a MS-Windows client running at the user's PCs (through the use of the PC-NICE network facility) and
• a X-Window client running in the users workstations.

2.5 Relation to Other Systems

The other systems that the CMMS is related to are as follows:

• Reference Databases

The CMMS will interface with ORACLE Reference databases. These will be databases such as the one holding people and location's data.

• Electronic Document Handling

The CMMS will interface with EDH for purchase orders processing purposes.

• Automatic e-mail Sending

Certain job cards are printed in locations remote to the users they are intended for. The system shall be able to generate an e-mail message warning those users.

• Automatic Fax Sending

Some external contractors do not have access to a computer network and thus, may not receive the job cards via a printer. In this case a fax message with the job card shall be sent to the enterprise.

2.6 General Constraints

• The system shall use existing RAPIER data (or a migration/adaptation of it) as its initial database.
• The system shall use ORACLE as its RDBMS.

3. Specific Requirements

3.1 Functional Requirements

3.2 Performance Requirements

3.3 Interface Requirements

3.4 Operational Requirements

3.5 Resource Requirements

3.6 Verification Requirements

3.7 Acceptance Test Requirements

3.8 Documentation Requirements

3.9 Security Requirements

3.10 Portability Requirements

None

3.11 Reliability Requirements

3.12 Maintainability Requirements

3.13 Safety Requirements

None

4. Requirements Traceability Matrix

Pedro Martel - EST/ISS - Last modified: 11JUN97