System Name (System Id) - Template

Requirements Specification for

< System Name (System ID)> - Template

Release No. < >

Date: DD-MMM-YYYY

Document / Name / Title / Signature / Date
Prepared by:
Reviewed by:
Approved by User Manager*:

* System Owner or Project Owner for Infrastructure project

IT Internal Only / Name / Title / Signature / Date
Project Manager
The technical requirements have been supplemented by the following IT parties:
IT Reps. / Name / Title / Date
OPS
TSL
SE
SS (Security)
TP
Others

All rights reserved. Permission to reproduce this document or to prepare derivative works from this document for internal use is granted, provided that the copyright statement is included with all reproductions and derivative works.

Requirement Specification Template v1.2.doc / Page 1 of 9
< SYSTEM NAME (SYSTEM ID)> - TEMPLATE
RELEASE NO. < >

Document Change Record

Version
Number / Description of Change / Sections Amended / Person Making Change / Date

Distribution List

< Name of System Owner >

< Name of User Manager >

< Name of Reviewer(s) >

< Name of Other Team Member(s) >

IT Technical Library

Attachment

< Technical requirements specification if specified in a separated document>

< List of other attachments, if required >

TABLE OF CONTENTS

< Please insert here the TOC if the document has more than 10 pages. >

APPENDIX (OPTIONAL)

· Screen Layout

· Report Layout

· Logical Data model

1 Introduction

1.1 Objectives of the System

< State the objectives of the system/service to be delivered and the major benefits expected to be achieved. These should be expressed in qualitative and quantitative terms as much as possible.

e.g. To improve the efficiency of the Human Resources Unit by reducing the time required to perform the monthly pay-roll from 2 days to 4 hours. >

1.2 Scope of the System/ Enhancement

< Provide a context diagram which shows a high level view of the system boundary and its interfaced systems and/or manual processes. Also, if the new system involves hardware/equipment installation, location should be clearly stated, e.g. information booths. >

1.2.1 Process Description

< For business application, this is mandatory. To describe the whole overall picture of the application which takes part in the existing business flow.

1.2.2 User Characteristics

< Describe the characteristics of different user groups, stakeholders, user roles and end-users of the system. State also their locations, if required. >

1.2.3 Constraints and Limitation

< List the constraints and any pre-requisite conditions identified relating to the proposed system, it may include, but not limited to the following:

· Use of equipment, e.g. existing hardware, proprietary software packages.

· Manual and clerical procedures.

· Operational.

· Input and output, e.g. method and media of input/output.

· Business organization and policy. >

1.3 System Classification & service window

< This section is mandatory for new system or any change to existing system. Refer to the embedded CIA template to classify the system in terms of Confidentiality, Integrity, and Availability and check the following box accordingly. >

High / Medium / Low
Confidentiality / 
Integrity / 
Availability / 

Service Window

 / A / 00:00 ~24:00 Monday-Sunday
B / 08:00 ~20:00 except Saturday Sunday Bank Holiday
C / 09:00 ~18:00 except Saturday Sunday Bank Holiday

1.4 References

IT015 Information Security Policy and Standards

IT034 Operations Management Framework

< List the referenced policy, standards, procedures, or guidelines for preparing this document. >

1.5 Glossary

< Glossary >

2 Description of BUSINESS Requirements

2.1 Business Functional Requirements

< A use case view may be used here for describing the functional requirements. For each function, a unique ID should be assigned for ease of reference and traceability throughout the project. >

Starting with unique Requirement ID

<Req-F-1> Name of Function

Description: To describe the function and the sub-flow of this function.

Inputs: To describe the input to the function. The input can be either from real user or from other functions or subsystems.

Outputs: To describe the output of the function. It can be either output to user or to an external subsystem.

(Optional) Exceptional Output: To list out the output of the exceptional case.

(Optional) Validation Rules:

2.2 Other Business Requirements

Starting with unique Requirement ID

<Req-NF-1> Name of Other Business Requirement

< This section defines other business non-functional requirements including performance, operational, safety, user security groups, user training, specific location, etc. defined by the business users.>

2.2.1 Performance Requirements

Starting with unique Requirement ID <Req-NF-XX>

Response time: State the response for a transaction (average, maximum).

e.g. 90% of transactions are responded within 3 seconds time. Corresponding tool/method for measurement has to be considered.

Capacity: State the number of customers or transactions the system can accommodate:

· Average transaction rate

· Peak transaction rate and time

· Number of maximum concurrent users and the expected growth rate

2.2.2 Business Operational Requirements

Starting with unique Requirement ID <Req-NF-XX>

Data Backup, Archive & Retention: Refer to IT034 and specify the package required for backup arrangements and backup frequency for the data, including data retention needs. State if any special arrangement is required, including archiving requirements.

System robustness & resilience: For critical airport operations, state here if any special requirement to minimize the business operations under system failure conditions. This may be specific to zones, locations, types of data or minimum capacity, etc. For High Availability system, need for disaster recovery should be assessed and specified

3 Description of TECHNICAL Requirements

3.1 Data/database requirements

< This section defines the database requirements derived from the user requirements. For example, the capacity of the database to fulfill the performance requirements, unstructured data storage, RDMS required, Middleware supported, etc.>

Starting with unique Requirement ID

<Req-D-1> Description of the interface derived from <Req-xxx>

Description: Describe the database services required, such as unstructured database storage, RDMS required, Middleware supported, etc.

3.2 Interface requirements < if Applicable >

< This section defines the interfaces to be supported by the system. It should contain adequate specificity, protocols, ports and logical addresses, etc. >

Starting with unique Requirement ID

<Req-I-1> Description of the interface derived from <Req-xxx>

Description: Describe the interfaced system, the required link(s) and the transaction type with the interface. State clearly whether transactions are initiated by users or automatically by system.

Input/ Output: Specify the data input from /output to the system, including the format and media.

Timeliness of Exchange (Optional): Specify the expected response time, frequency and volume of transactions, etc.

3.3 Security, Audit & Control Requirements

< If system information is classified as “Confidential”, more security controls may be required. Reference can be made to IT015. >

Starting with unique Requirement ID <Req-S-1> derived from <Req-xxx>

It may include:

· User authentication & Password

· System access

· Audit trial

· Data encryption in transmission/ storage, etc.

3.4 Platform & Infrastructure Requirements

Starting with unique Requirement ID <Req-T-1> derived from <Req-xxx>

3.4.1 Connectivity

< Describes the access requirements, which may include:

· Dedicated link

· Web access via Internet, Intranet, or Extranet

· Wireless access

· Specific sites & location

· Remote access

· Bandwidth, etc >

3.4.2 Services

< Describes the specific types of service required, which may include:

· Mail

· File transfer

· Domain Name service

· O/S service

· Web Application Deployment Infrastructure

· Directory service

· Storage service e.g. NSI

· Time service

· PDA

· Fax service

· SMS, etc >

3.5 Operational & Supportability Requirements

3.5.1 Operational Requirements

Starting with unique Requirement ID <Req-O-1> derived from <Req-xxx>

System Backup: State the backup arrangements and backup frequency for the system/application.

Data Backup, Archive & Retention: Refer to Section 2.2.2 (if any) or refer to IT034 and specify the package required for backup arrangements and backup frequency for the data, including data retention needs. State if any special arrangement is required, including archiving requirements.

Restore & Recovery: State need for any special recovery arrangement under various system failure conditions, e.g. Disaster recovery need for High Availability system.

System Monitoring: State the system monitoring & detection need for system usage, network traffic, virus, failure status of particular device or server process, etc.

Service Level & Support (for contractor/vendor): Describe the required maintenance services agreement. It may include, but not limited to the following:

· warranty

· support hours (remote or on-site) should align with the System Availability

· spare parts, etc

3.5.2 Supportability Requirements

Starting with unique Requirement ID <Req-D-1> derived from <Req-xxx>

Training: List the training required for the support and usage of the system and the group(s) to be trained. This may include operational staff training, or IT Helpdesk training.

Documentation: List the documentation required for the support and usage of the system, e.g. O&M Manual, Administration Guide, User Manual, Training packages or vendor manuals.

Delivery Instructions (Optional): Describe any special arrangements required for installation and software distribution, etc

3.6 Other Requirements (IF applicable)

Starting with unique Requirement ID <Req-O-1> derived from <Req-xxx>

< The following requirements should also be considered especially for project which involve acquisition of an integrated solution, special display device, non-standard hardware, and/or equipment for public access, etc. >

3.6.1 Hardware Requirements

Starting with unique Requirement ID <Req-H-1> derived from <Req-xxx>

3.6.2 Location for installation

Starting with unique Requirement ID <Req-L-1> derived from <Req-xxx>

– End of Requirements –

RELEASE NO. < >

< SYSTEM NAME (SYSTEM ID)> - TEMPLATE
Ver 1.2

Please delete the following pages when preparing your document.

How to Use This Document

< This is a template for developing the Requirements Specification for IT projects. Notes on how to complete various sections within this template are marked in blue and enclosed within “<“ and “>“ signs. Please remove them once you have completed your document.

For new system or major upgrade, all sections should be completed. For minor enhancement, project manager should assess different sections and state “N/A” or “No change”.

To facilitate editing of the document, please amend the following fields of the file’s properties so that the changes can be reflected automatically in document’s header and footer areas:

“Title” for “System Name (System ID)”

“Subject” for “Release No.”

“Keyword” for “Document Version No.”

Press F9 to refresh the field content if necessary. >

Change Record of This Template

Version
Number / Description of Change / Sections Amended / Person Making Change / Date
1.0 / Initial version / Janet Lam / 7-Oct-02
1.1 / Fine tune after actual implementation of SDM, add CIA template as requested by SS. Add 2.6 for hardware requirements. / 1.3, 2.5.3, 2.5.4, 2.6 / Janet Lam / 25-Jul-03
1.2 / Revamp all sections / All / Janet Lam / 25-Jan-07
File Ref.: Requirement Specification Template v1.2d.doc
Page 3 of 9 / Copyright © by Airport Authority Hong Kong