[C LICK HERE AND TYPE P ROJECT N AME ]

S UPPLEMENTARY S PECIFICATIONS

Version <current version>

Page 1 of 6
 Supplementary Specifications

Revision History

Date Version Summary of Change Author

<dd/Mmm/ <x.y> <Section> - <Change> <First Name +
yyyy> Last Name>
12 Apr 2014 0.1 Initial version Thuy Tran
15 May 2014 0.2 Update upon review with internal team: Thuy Tran
Section 3 – Updated flow diagram #
Section 4 - Removed flow #
Section 1 – Add new rule XYZ
1 Jun 2014 0.3 Update upon review with customer: Thuy Tran
Section 2 – Change field label from A to B
Section 4 - Update flow # - step #

Distribution for Review/Approval

Name Title & Company Issue Issue Review Approval

Version Date Date Date
<First Name + <Title> - <Company> <x.y> <dd/ <dd/ <dd/
Last Name> Mmm/ Mmm/ Mmm/
yyyy> yyyy> yyyy>

Page 2 of 6
 Supplementary Specifications

Contents
1 Introduction.....................................................................................................4
1.1 Purpose..........................................................................................................4
1.2 Scope............................................................................................................. 4
1.3 References.....................................................................................................4
2 Non-Functional Requirements........................................................................4
2.1 System Requirements....................................................................................4
2.2 Usability..........................................................................................................4
2.3 Reliability........................................................................................................4
2.4 Performance...................................................................................................5
2.5 Supportability..................................................................................................5
2.6 External Interfaces..........................................................................................5
2.7 Documentation Requirements........................................................................6
2.8 Design Constraints.........................................................................................6
2.9 Licensing Requirements.................................................................................6
3 Common Functional Requirements................................................................6

Page 3 of 6
 Supplementary Specifications

1 Introduction
1.1 Purpose
<State the purpose of this Supplementary Specifications:
- Define non-functional requirements of a system such as Usability, Reliability,
Performance, Supportability, etc.
- Define all common functional requirements of a system
>
1.2 Scope
<A brief description of the scope of this document>

1.3 References
<Provide a complete list of all documents referenced somewhere in this document. Each
document should be identified by ID, Name, Published Version (optional), Author, and
Storage Location (optional)>

2 Non-Functional Requirements
2.1 System Requirements
<Examples:
- Devices on which end users run the system (e.g. PCs, tablets, mobile
phones, special devices for disabilities)
- Operating Systems
- Screen resolutions (minimum, most popular)
- Browsers (and version)>

2.2 Usability
<Examples:
- How easy a user can use a system: a training is required or system can
self-explain to users?
- How many GUI themes for various kinds of users>

2.3 Reliability
<Examples:
- Availability – specify time that system is available for usage, maintenance access,
degraded mode operations, etc.
- Mean Time Between Failures (MTBF) – this is usually specified in hours but it could
also be specified in terms of days, months or years.
- Mean Time To Repair (MTTR) – how long is the system allowed to be out of
operation after it has failed?

Page 4 of 6
 Supplementary Specifications

- Accuracy – accuracy (by some known standard) that is required in the systems
output.
- Maximum bugs or defect rate – usually expressed in terms of bugs/KLOC
(thousands of lines of code), or bugs/function-point.
- Bugs or defect rate – categorized in terms of minor, significant, and critical bugs: the
requirement(s) must define what is meant by a “critical” bug (e.g., complete loss of
data or complete inability to use certain parts of the functionality of the system).>

2.4 Performance
<Examples:
- Response time for a transaction (average, maximum)
- Throughput (e.g., transactions per second)
- Capacity (e.g., the maximum number of customers or transactions the system can
accommodate)
- Degradation modes (what is the acceptable mode of operation when the system has
been degraded in some manner)
- Resource utilization: memory, disk, communications, etc.>

2.5 Supportability
<Examples:
- Coding conventions
- Naming conventions
- Common libraries
- Service oriented design>

2.6 External Interfaces

<This section defines all types of external interfaces that system will integrate with
such as:
- Hardware interfaces
- Software interfaces
- Industry standards (e.g. HL7 for Healthcare domain, SCORM for e-
Learning domain)
- Communication interfaces to other systems or devices (e.g. local network,
remote network, etc.)>

2.7 Design Constraints

<Examples:
- Architecture

Page 5 of 6
 Supplementary Specifications

- Programming languages
- 3rd party components>

2.8 Documentation Requirements

<Examples:
- Online help system
- Contextual help system
- User manual>

2.9 Licensing Requirements

<This section lists all components and softwares that are required license purchase to be
used when system is developed and go-live.>

3 Common Functional Requirements

<This section includes all functional requirements that are applied more than one place
in system.>

Page 6 of 6