0% found this document useful (0 votes)
98 views6 pages

Supplementary Specifications

This document provides supplementary specifications for a software project, including: 1. Non-functional requirements such as usability, reliability, performance, supportability and external interfaces. 2. Common functional requirements that apply across the system. 3. Revision history and distribution lists for review and approval of the document. The document defines key quality attributes and interfaces to ensure the system meets requirements. It also establishes processes for document control and stakeholder sign-off.

Uploaded by

Hà Hải
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
98 views6 pages

Supplementary Specifications

This document provides supplementary specifications for a software project, including: 1. Non-functional requirements such as usability, reliability, performance, supportability and external interfaces. 2. Common functional requirements that apply across the system. 3. Revision history and distribution lists for review and approval of the document. The document defines key quality attributes and interfaces to ensure the system meets requirements. It also establishes processes for document control and stakeholder sign-off.

Uploaded by

Hà Hải
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

[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

You might also like