Requirements Specification Template

Requirements Specification, <Project Name>
Version x.x
DOCUMENT INFORMATION
Category
Information
Customer
Project
Document
Document Version
Identifier
Author(s)
Approver(s)
Issue Date
Document Location
1.
2.
3.
Distribution
DOCUMENT REVIEW INFORMATION

Review Date
Reviewer
Name
Version
Reference / Evidence
DOCUMENT REVISION HISTORY

Author
Date
Version
Description(Change made, Sec Ref,

CR#)
Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Unauthorized copy or use of this document is strictly prohibited

Version x.x
DEFINITION OF TERMS, ACRONYMS AND ABBREVIATIONS

This section should provide the definitions of all terms, acronyms, and abbreviations
required to interpret these terms properly. This information may be provided by
reference to the project Glossary.
Term
Description
ASP
Active Server Pages

ii

Version x.x
LIST OF FIGURES
Figure #
Figure Name

Page #
iii

Version x.x
LIST OF TABLES
Table #
Table Name

Page #
iv

Version x.x
LIST OF APPENDICES
Appendix #
Appendix Name

Page #

Version x.x
Table of Contents
DOCUMENT INFORMATION......................................................................................
DOCUMENT REVIEW INFORMATION............................................................................
DOCUMENT REVISION HISTORY................................................................................
DEFINITION OF TERMS, ACRONYMS AND ABBREVIATIONS....................................................
LIST OF FIGURES...............................................................................................
LIST OF TABLES.................................................................................................
LIST OF APPENDICES............................................................................................
1. Introduction...............................................................................................1
2. Project Overview.........................................................................................1
2.1. Business Process Overview...................................................................1
2.2. Current System...................................................................................1
2.3. Proposed System.................................................................................1
2.3.1. Main Objectives.........................................................................1
2.3.2. Client, Customer and other Stake holders.....................................1
2.3.3. Users.......................................................................................1
3. Requirements Grading.................................................................................1
3.1. Approval Status...................................................................................1
4. Functional Requirement...............................................................................2
4.1. Key Requirements................................................................................2
4.2. Rationale for Alternate Requirements.....................................................2
4.3. Acceptance Criteria..............................................................................3
4.4. Requirements Providers........................................................................3
5. Relevant Facts and Assumptions....................................................................3
6. Non functional Requirement..........................................................................3
6.1. Performance Requirements...................................................................3
6.2. Operational Requirements.....................................................................3
6.2.1. Physical Environment (optional)...................................................3
6.2.2. Technological environment..........................................................4
6.2.3. Partner Applications (optional).....................................................4
6.3. Usability Requirements (optional)..........................................................4
6.4. Interface Requirements........................................................................4
6.5. Operational Concepts and Scenarios.......................................................5
6.6. Security Requirements (optional)...........................................................5
7. System Constraints and Limitations...............................................................5
7.1. Risk Analysis.......................................................................................5
8. Open Issues...............................................................................................5
9. Future Requirements...................................................................................6
10. References.................................................................................................6
10.1.Documents (optional)...........................................................................6
10.2.Personnel............................................................................................6
DOCUMENT INFORMATION......................................................................................
DOCUMENT REVIEW INFORMATION............................................................................

vi

Version x.x
DOCUMENT REVISION HISTORY................................................................................

DEFINITION OF TERMS, ACRONYMS AND ABBREVIATIONS....................................................
LIST OF FIGURES...............................................................................................
LIST OF TABLES.................................................................................................
LIST OF APPENDICES............................................................................................
1. Introduction...............................................................................................1
2.2. Current System...................................................................................1
2.3. Proposed System.................................................................................1
2.3.1. Main Objectives.........................................................................1
2.3.3. Users.......................................................................................1
3.1. Approval Status...................................................................................1
4.3. Requirements Providers........................................................................3
6.1. Performance Requirements (optional).....................................................3
7.1. Risk Analysis.......................................................................................5
8. Open Issues...............................................................................................5
10. References.................................................................................................5
10.2.Personnel............................................................................................5
DOCUMENT
DOCUMENT
DOCUMENT
INFORMATION....................................................................
REVIEW INFORMATION....................................................
REVISION HISTORY..........................................................
DEFINITION OF TERMS, ACRONYMS AND ABBREVIATIONS...........................

LIST OF FIGURES........................................................................................
LIST OF TABLES..........................................................................................
LIST OF APPENDICES...................................................................................

vii

Version x.x
1. Introduction...............................................................................................1
2.2. Current System...................................................................................1
2.3. Proposed System.................................................................................1
2.3.1. Main Objectives.........................................................................1
2.3.3. Users.......................................................................................1
3.1. Approval Status...................................................................................1
6.1. Performance Requirements (optional).....................................................3
7.1. Risk Analysis.......................................................................................4
8. Open Issues...............................................................................................4
10. References.................................................................................................5
10.2.Personnel............................................................................................5

viii

Version x.x
1.
Introduction
The purpose of this document is to define project requirements in order to
obtain signoff of the customer and the software developer. The developers use
this document while working through the different phases of the SDLC. This
Document will be the basis of the FS Document. Documenting and controlling
the customer requirements (RS) is a prerequisite for using them as the basis
for planning, performing and tracking the software projects activities
throughout the software life cycle.
2.
Project Overview
A brief description of the project is stated initially. Background of the Client
and a short description of the work context and the situation that triggered
the development effort. It should also describe the basic purpose of the
project.
2.1. Business Process Overview

A brief description and diagrammatic representation of the business process
showing the major processes and their inter-relationship.
2.2. Current System

Description about existing system goes here. This subsection also gives an
overview of the flaws in the current system
2.3. Proposed System

A brief description of the proposed system, in reference to the flaws in the
existing system is given under this section. It should also give an over view of
the solution that we intend to implement in order to remove the flaws.
2.3.1. Main Objectives

Define the main objectives or goals of the project. Define acceptance criteria if
possible.
2.3.2. Client, Customer and other Stake holders

Define clients, customers and users of the project.
2.3.3. Users
Describe the users of the project in detail (nature of their job, age etc). If there
are more than one user then categorize them.
3.
Requirements Grading
Each requirement will be graded according to the following categories.
3.1. Approval Status

Set after negotiation and review by the project management team.


Version x.x
4.
Proposed
Used to describe requirements that are under discussion but

have not yet been reviewed.
Approved
Requirements that are feasible and have been approved.
Pending
Requirements pending to be finalized later.
Rejected
Requirements rejected by the client
Functional Requirement
A textual description of the requirements related to the customers business.
This should contain a list of all the business events related to the business
process and cover:
All external events
Temporal events
Requirements should be divided if the Project is to be delivered in Phases.

Each phase should have a separate matrix for the requirements (Optional).
Phase 1 (if the project is divided into phases)
Sr.
#
Requirement
Source of Information
Status
1.
Requirement no 1 goes here
Additional important information like

source
of
information,
associated
documents etc.
Dependencies: All constraints, pre-conditions, post-conditions, input, dependencies of this

requirement are listed here.
1.1
Requirement no 1.1 describes a subset of above

requirement

2.
Requirement no 2 goes here

Phase 2
4.1. Key Requirements

Requirements that have strong influence on cost, schedule, functionality, risk,
or performance should be identified
Sr.
#
Requirement
Influence
4.2. Rationale for Alternate Requirements

This section will be updated only when a requirement will be replaced by an
alternate requirement at a later stage of the project
Sr.
#
of
original
requirement
Original
Requirement
Sr. # of Alternate
requirement
Alternate
Requirement

Rationale for
Alternate

Version x.x
4.3. Acceptance Criteria

This section should give a description of the application flow. The basic
functionality that would define the acceptance criteria of the application.
4.4. Requirements Providers

Requirements Providers List
S.No.
Name
Designation
1
2
3
4
5
6
7
8
9
10
5.
Date Status
Comments
Closed
Pending
Relevant Facts and Assumptions

A list of the assumptions that the developers are making. These might be
about the intended operational environment, but can be about anything that
has an effect on the product.
6.
Non functional Requirement
6.1. Performance Requirements (optional)

The performance characteristics of the system that are required by the
business should be outlines in this section.
Performance characteristics include the speed, precision, capacity, safety, and
reliability of the software. These characteristics define the performance of the
project.
6.2. Operational Requirements

6.2.1. Physical Environment (optional)
This section specifies the physical environment in which the product will
operate.


Version x.x
It will highlight conditions that might need special requirements, preparations

or training. These requirements ensure that the product is fit to be used in its
intended environment.
Examples:
The product shall be used in noisy conditions with a lot of dust.
The product shall be usable in dim light.
The user while using the system is, standing up, outside in cold, rainy conditions shall
use the product.
The work environment Isis the product to operate in some unusual

environment? Does this lead to special requirements? Also see section 6.3
Usability Requirements.
6.2.2.
User Environment
6.2.3.
This section specifies the user environment that may include the following
scenarios e.g., operating system, machines, Hardware, No of users, and other
applications that may interface.
6.2.4. Technological environment
Hardware requirements needed to run the system. This includes the server
and client configuration including physical network.
Software requirements needed to run the system. This includes the
software required on both server and client machines.
Communications Interfaces: Describe any communications interfaces to
other systems or devices such as local area networks, remote serial
devices.
6.2.5. Partner Applications (optional)

Description of other applications that the product must interface with.
Requirements for interfacing to other applications often remain undiscovered
until implementation time. Avoid a high degree of rework by discovering these
requirements early.
Examples:
We must be able to interface with any html browser.

The new version of the spreadsheet must be able to access data from the previous 2
versions.
6.3. Usability Requirements (optional)

A set of prototypes screen that represents the look and feel required by the
user. It should describe the customers requirement for navigation and ease of
use for the intended users.
This section should also include all of those requirements that affect
usability. Examples:
Specify requirements to conform to common usability standards e.g.,
IBMs CUA standards, or the GUI standards published by Microsoft for
Windows 95.


Version x.x
6.4. Interface Requirements:

This section talks about the interfaces related to requirements collection.
Following are the types of interfaces
User interfaces:
External Interfaces:
Internal Interfaces:
Database Interfaces:
Note: Please refer to Interface classifications document in PAD for more details.
6.5. Operational Concepts and Scenarios

Identify and develop scenarios, consistent with a level of detail in the
stakeholder needs, expectations, and constraints, in which the proposed
product is expected to operate.
The issues to be addressed by Operational Concepts and Scenarios are
manifold and include the following.
Capture the needs of many stakeholders
Translate the needs of the user community, and their detailed operational
knowledge of the problem, into a language understood by system
developers.
Provide a system description in a format and language that can act as a
basis for system designers to employ their technical and commercial skills
while providing a description that is still clearly understood by the user
community.
Produce an output that is useable throughout the life of a project.
A further benefit of an Operational Concepts and Scenarios written early in a

program is that it can be used as the basis for good systems engineering by:
Providing a means of testing the stability of customer requirements and
initial requirements derived by the designer and so providing confidence
that all future work is based on a solid foundation
Providing a logical foundation for developing performance measures
Presentation of initial design inputs and requirements within structured

format which can be built upon as the project progresses.
Providing a vision of a proposed solution for use in the design phase of the
project and for later phases
Moreover Operational concepts and Scenarios should be developed jointly by

customers and designers in order to produce successful and optimal solutions.


Version x.x
6.6. Security Requirements (optional)

Specification of who (as role) has authorized access to the system (features)
and under what circumstances that access is granted. Depth at which security
implementation is required.
7.
System Constraints and Limitations

System constrains, for example:
Software Constraints
Hardware Constraints
Design Constraints
Cultural Constraints (includes language, religion etc.)
Legal Constraints
Environmental constraints (e.g. the environment where the software will

be installed, It could be a noisy environment, which may require that there
is no sound event in the project).
User constraints (for Ex. The project is developed for children, so it may be
required that the project has more graphic controls rather than textual
controls).
Off the shelf components that might be used in the project may have their
constraints which are consequently transferred to the project.
Any constraints that are related to verification and validation should be
defined.
7.1. Risk Analysis

Perform an analysis of the constraints and identify the potential problems that
may arise in the project due to the constraints.
8.
Open Issues
This Section contains certain issues that have been raised and do not have a
conclusion and they might make significant difference to the product. To bring
uncertainty out in the open and provide objective input to risk analysis. For
example:
9.
Our investigation into whether or not the new version of the processor will
be suitable for our application is not yet complete.
The government is planning to change the rules about who is responsible
for gritting the motor ways, but we do not know what the changes might
be.
Future Requirements
This section has the future requirements that the customer would like to have
in his project. Mentioning the functionality here would help the developers to
leave room for the future requirements in the project.


Version x.x
10. References
10.1. Documents (optional)
This section should provide a complete list of all documents referenced at
specific point in time. Each document should be identified by title, report
number (if applicable), date, and publishing organization. Specify the sources
from which the references can be obtained. This information may be provided
by reference to an appendix or to another document.
Reference
No.
1.
Title of Document
Reference document #1
2.
10.2. Personnel
This section gives a list of all personnel, who contributed to the RS, from the
client end. This will help in tracking the right source if there is a need to
elaborate a certain requirement.


Requirements Specification Template

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirements Specification Template

Uploaded by

Copyright:

Available Formats

Requirements Specification, <Project Name>

DOCUMENT REVIEW INFORMATION

DOCUMENT REVISION HISTORY

Description(Change made, Sec Ref,

Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Requirements Specification, <Project Name>

DEFINITION OF TERMS, ACRONYMS AND ABBREVIATIONS

Active Server Pages

Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Requirements Specification, <Project Name>

Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Requirements Specification, <Project Name>

Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Requirements Specification, <Project Name>

Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Requirements Specification, <Project Name>

Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Requirements Specification, <Project Name>

DOCUMENT REVISION HISTORY................................................................................

DEFINITION OF TERMS, ACRONYMS AND ABBREVIATIONS...........................

Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Requirements Specification, <Project Name>

Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Requirements Specification, <Project Name>

2.1. Business Process Overview

2.2. Current System

2.3. Proposed System

2.3.1. Main Objectives

2.3.2. Client, Customer and other Stake holders

3.1. Approval Status

Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Requirements Specification, <Project Name>

Used to describe requirements that are under discussion but

Requirements that are feasible and have been approved.

Requirements pending to be finalized later.

Requirements rejected by the client

All external events

Requirements should be divided if the Project is to be delivered in Phases.

Requirement no 1 goes here

Additional important information like

Dependencies: All constraints, pre-conditions, post-conditions, input, dependencies of this

Requirement no 1.1 describes a subset of above

Dependencies: All constraints, pre-conditions, post-conditions, input, dependencies of this

Requirement no 2 goes here

Dependencies: All constraints, pre-conditions, post-conditions, input, dependencies of this

4.1. Key Requirements

4.2. Rationale for Alternate Requirements

Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Requirements Specification, <Project Name>

4.3. Acceptance Criteria

4.4. Requirements Providers

Relevant Facts and Assumptions

Non functional Requirement

6.1. Performance Requirements (optional)

6.2. Operational Requirements

Copyright NetSol Technologies (Pvt.) Ltd. All rights reserved

Requirements Specification, <Project Name>

It will highlight conditions that might need special requirements, preparations

The product shall be used in noisy conditions with a lot of dust.

The product shall be usable in dim light.

The work environment Isis the product to operate in some unusual

6.2.4. Technological environment

6.2.5. Partner Applications (optional)

We must be able to interface with any html browser.