Software Requirements Specification

(SRS)
For
<Project Name>
Revision History
Revision Author Date Description

[Template User Notes:

 Help Info is provided (in blue italics) to describe what each section should contain.
 Sample Text is provided (in green) in some sections to assist the author in standard
wording for common documentation.
 Title tags (in blue italics) must be replaced to match the project, e.g. <Project Name>.
 Help Info and Sample Text are included to provide guidance to the author and should be
deleted before publishing the document.]

Page ii
 Table of Contents

1 INTRODUCTION............................................................................................................................... 1

1.1 Document Purpose...................................................................................................................... 1

1.2 Acronyms, Definitions, Terminology............................................................................................. 1

1.3 References................................................................................................................................... 1

2 PROJECT SCOPE, ASSUMPTIONS, AND IMPACT......................................................2

2.1 Project Overview......................................................................................................................... 2

2.2 Scope Inclusions.......................................................................................................................... 2

2.3 Scope Exclusions.......................................................................................................................... 2

2.4 Assumptions................................................................................................................................ 2

2.5 Constraints.................................................................................................................................. 2

2.6 Dependencies/ Impacts............................................................................................................... 2

3 FUNCTIONAL REQUIREMENTS.................................................................................... 3

3.1 <Functional Requirement 1>........................................................................................................ 3

3.2 <Functional Requirement n>........................................................................................................ 4

4 NON-FUNCTIONAL REQUIREMENTS.......................................................................... 5

4.1 Performance & Scalability Requirements.....................................................................................5

4.2 Compatibility Requirements........................................................................................................ 5

4.3 External Interface Requirements.................................................................................................. 5

4.4 Security & Authentication Requirements.....................................................................................6

4.5 Interoperability Requirements..................................................................................................... 7

4.6 Development Requirements........................................................................................................ 7

4.7 Internationalization Requirements............................................................................................... 7

4.8 User Documentation and Help System Requirements...................................................................7

4.9 Reliability Requirements.............................................................................................................. 7

4.10 Accessibility Requirements.......................................................................................................... 7

5 ACTIVITY DIAGRAMS..................................................................................................... 8

Page iii
6 APPENDIX.......................................................................................................................... 8

6.1 Use Case Template....................................................................................................................... 8

6.2 User Story Template...............................................................................................................................9

Page iv
1 Introduction
1.1 Document Purpose
This document lists the requirements for the <Client Name> <Project Name> project.
The purpose of this document is to identify the system requirements and obtain sign-off
on all requirements before moving to the design phase. The Development team team will
use this document as the basis for the system design.

After sign-off, requested changes to requirements will be documented, including the

effect on the project costs, scope and timelines and presented to <Client> for approval.

These requirements were gathered during extended discussions with <Client Name> on
<Date>, and from documents provided by <Client Name> on <Date>.

1.2 Acronyms, Definitions, Terminology

[This sub-section must provide definitions for all the terms, acronyms, and abbreviations
used in this document.]

1.3 References
[This sub-section must provide a complete list of all references. Identify each document
by title, document number and the version. Specify the sources from which the references
can be obtained.]

Example:
1. <Document name> - <version XX.XX> – <Dated DD/MMM/YY>
2. <Document name> - <version XX.XX> – <Dated DD/MMM/YY>

Page 1
2 Project Scope, Assumptions, and Impact
[Describe what is to be accomplished via this project in terms of improved system
performance, client service, or task performance.]

2.1 Project Overview

[Provide an overview of the project including the goal of the project and the problem it is
attempting to solve.]

2.2 Scope Inclusions

[Provide a list of features/functionality and issues in the current system, which will be
addressed in this project. It may include a context diagram or a block diagram to
illustrate the scope of the system.]

2.3 Scope Exclusions

[List the features/functionality and issues that will not be addressed in this project.
Providing training for end users and user guide is not in scope for this project.]

2.4 Assumptions
[List any assumptions made during requirements analysis and functional specification.]

2.5 Constraints
[List any limitations identified in this project.]

2.6 Dependencies/ Impacts

[List the dependencies and impact of this project on other systems, and how other
systems will affect this project.]

Page 2
3 Functional Requirements
[This section captures the functional requirements of the system. Each function must be
explained in detail including process flows, screen layouts (if available) and a
description of how the function will work. Functions can be described in the form of
detailed textual use cases. Use cases for each function can be included within this section
or in a separate section towards the end of the document. Each function should also be
represented in the functionality matrix. Functional requirements should also include
validity checks on inputs, and responses to abnormal situations including: overflow,
communication facilities, error handling and recovery.]

3.1 <Functional Requirement 1>

[Define each function in detail including process flows, screen layouts (if available) and
a description of how the function will work. This requirement can be captured as a use
case or user story depending on the methodology followed. Copy the relevant sample
templates available in appendix and fill in accordingly.

Some generic functions that should be included are listed below. Review and include
these sections as appropriate to the project.
 System Administration
Include requirements to manage and administer the system – including database
maintenance for all system tables and parameters (add, update and delete) - e.g.
remote management, MMC integration management.
 Data Model
Include all data captured under this specific requirement, in the format shown
below.
Field Name Length Data Type Validation
<field name> <character length <data type of the <validations that
of the field> field> need to be
performed on the
field >

 Data Archival and Retention

Include any special data archival and retention requirements.
 User Profiles, Roles and Privileges
Include a definition of the typical users of the system, user access and privilege
settings, and user roles.
 Reporting Requirements
Include a definition of all reports required to manage the application. Reports
include both online reports and printed reports.]

Page 3
3.2 <Functional Requirement n>
[This section should be filled according to the guidelines given in section 3.1]

Page 4
4 Non-Functional Requirements

4.1 Performance & Scalability Requirements

Include all performance requirements known at this point. Include a reference to the
design document if performance requirements are further clarified in the design. Include
all UI performance (time to paint screens), response times, and average processing times.

Example:

Current User Load

Expected Growth
Number of Concurrent
Users
Transaction Size (files
sizes, etc.)
Maximum Average
Transaction Time
Acceptable

4.2 Compatibility Requirements

Include all compatibility requirements for hardware, software and operating systems.

Example:

OS versions to be Supported
Database Versions to be Supported
Communication Protocol
Platform Version to be Supported
Any Other External Systems or Standards

4.3 External Interface Requirements

Include any interface requirements that allow external systems to communicate with this
application or allow this application to communicate with external systems.

This section defines the interfaces that must be supported by the application. It should
contain adequate information, protocols, ports and logical addresses, etc., so that the
software can be developed and verified against the interface requirements.

Interface Category Interface Name Description

Hardware Interfaces

Page 5
This section defines any
hardware interfaces that
are to be supported by the
software, including logical
structure, physical
addresses, expected
behavior, etc.
Software Interfaces
This section describes
software interfaces to other
components of the software
system. These may be
purchased components,
components reused from
another application or
components being
developed for sub-systems
outside of the scope of this
document, but with which
this software application
must interact.
Communication Interfaces
Describe any
communication interfaces
to other systems or devices
such as local area
networks, remote serial
devices, etc.

4.4 Security & Authentication Requirements

 Data Storage Security

Describe any special requirements to protect data stored in the system, e.g.
database security, encryption, etc.

 Data Communication Security

Describe any special requirements to protect data in transit, e.g. use of SSL, use
of POST methods, etc.

 Authentication
Describe any special authentication requirements, e.g. NT authentication, etc.

Page 6
4.5 Interoperability Requirements
Describe (if any) the possibility of diverse systems and organizations working together in
the project.

4.6 Development Requirements

 Development Environment
Describe development software, hardware, tools and environmental requirements.

 Development Data
Describe the key data entities required to begin development – including outside
data sources, populated databases and/or data generation tools.

 Coding Standards
Describe the coding standards and naming conventions for this project or give a
reference to where the standards can be found (if a separate coding standards
document was created).

 Implementation Packaging Requirements

Describe special application module packaging requirements. For example, a
Java package must be named in a certain way for the client to group certain
functionality into certain packages.

4.7 Internationalization Requirements

Describe the extent of internalization required for the system (language, locales,
measurements, currency, etc.).

4.8 User Documentation and Help System Requirements

Describes the requirements, if any, for online user documentation, help systems, about
notices, etc

4.9 Reliability Requirements

Describe reliability requirements of the system.

4.10 Accessibility Requirements

Describe any specific accessibility requirements of the system.

Page 7
5 Activity Diagrams
[Include activity diagrams for each use case highlighted within the document.]

6 Appendix
[Include additional information related to the project that must be provided as part of
this document.]

6.1 Use Case Template

Use Case ID UC1 Level <Business or Functional>
Date Last Status <Draft, Completed or Reviewed>
Modified
Initiating Actor <The party that initiates the use case: Other Actors <Any external systems involved.>
Visitor, Member, System, etc.>
Included Use <Any included use cases.> Extended Use <Any extended use cases.>
Cases Cases
Use Case Overview
<The description briefly conveys the purpose of the use case. A single paragraph will suffice for the description.>
Pre-conditions
<Preconditions or constraints of a use-case are the state of the system that must be present prior to a use case being
performed.>
Business Rules
<Any business rules that apply to this use case that are not captured elsewhere. These can be rules that must be
carried out or enforced, but which do not get specified as explicit steps in the sequence.>
Main Event List/Flow of Events
<This use case starts when the actor does something. An actor always initiates use cases. The use case describes
what the actor does and what the system does in response. It needs to be phrased in the form of a dialog between the
actor and the system. The use case describes what happens inside the system, but not how or why.
Alternate Event List/Flow of Events
<Alternative Flow sub-sections are alternative behavior—each alternative flow represents alternative behavior
usually due to exceptions that occur in the main flow. When an alternative flow ends, the events of the main flow of
events are resumed unless otherwise stated. Alternative flows should convey business value. Simple error
conditions may not need to be called out as alternate flow steps, but more complex alternatives or exceptions should
be. Using alternative flows improves the readability of the use case, as well as preventing use cases from being
decomposed into hierarchies of use cases. >
Terminating Outcome Condition Affecting Terminating Outcome Post-conditions
<The result of the use case <What caused this outcome.>? <A post-condition of a use case is
from the actor’s point of a new possible state the system can
view.> be in immediately after a use case
has finished.>

This section can be critical for

test case development, and
description of all valid end
states

Notes/Issues
<Additional information, notes, or issues to be captured for this use case.>

Page 8
6.2 User Story Template

User Story ID <a suitable identifier for the User Story> Priority<prioritize the User Story
Eg: US1 based on a standard
ranking method>
User Story Name <an appropriate name for the User Story> Eg: Introducing a re-booking option in the
system
Date Last Modified <dd/mm/yyyy> or <mm/dd/yyyy> Status Eg: Draft, Completed or
Reviewed
Stakeholder(s) <the beneficiaries of the User Story> Eg: Customer, Member, System etc.
User Story Overview
[As a <user>, I want to <goal> in order to <value>]
Eg: As a Frequent Flier, I want to re-book a trip so that I save time in booking trips that I make frequently.
User Story Detail
<Specific details pertaining to the User Story can be described here>
Eg: A history of the trips I make should be recorded to facilitate the ease of re-booking.
Acceptance Criteria
<The criteria that has to be met in order to fulfill this requirement>
Eg: The dates will be displayed in the format “06/09/08”
Effort
<The amount of time/days required for the activities of this User Story>

Page 9