Srs Template

Chapter 3
Software Requirement
Specification
Document No.
Version No.
Created on: 10 January 2002
Last modified on: 1 April 2002 - 6:30 PM
Last modified by: Maryum Zaidi
Chapter 3 Software Requirement Specification
Table of Contents
Software Requirement Specification.......................................................................................................................... 38
Abstract............................................................................................................................................................................ 38
Objectives........................................................................................................................................................................ 38
Introduction..................................................................................................................................................................... 38
FEATURES OF AN SRS............................................................................................................................................... 38
Document Structure ....................................................................................................................................................... 41
SRS Document Template ............................................................................................................................................. 42
Section 1: Introduction..................................................................................................................................... 42
Section 2: Overall description ........................................................................................................................ 42
Section 3: External interface requirements................................................................................................... 42
Section 4: System features .............................................................................................................................. 42
Section 5: Use case model............................................................................................................................... 42
Section 6: Nonfunctional requirements......................................................................................................... 42
Section 7: Graphical User Interface............................................................................................................... 43
Section 8: Data Dictionary .............................................................................................................................. 43
Description of SRS template........................................................................................................................................ 44
SECTION 1: INTRODUCTION ..................................................................................................................................... 45
1.1 Vision Statement...........................................................................................................................................45
1.1.1 Software Purpose...................................................................................................................... 45
1.1.2 Software Scope..................................................................................................................................... 45
1.1.3 Software Perspective........................................................................................................................... 45
1.2 Document conventions and definitions.....................................................................................................45
1.3 Intended audience and reading suggestions............................................................................................45
1.4 References......................................................................................................................................................45
SECTION 2: O VERALL DESCRIPTION ....................................................................................................................... 46
2.1 User characteristics.....................................................................................................................................46
2.2 Operating environment................................................................................................................................46
2.3 Design and implementation constraints...................................................................................................46
2.5 Assumptions and dependencies..................................................................................................................46
SECTION 3: EXTERNAL INTERFACE REQUIREMENTS............................................................................................ 47
3.1 Hardware Interfaces ....................................................................................................................................47
3.2 Software Interfaces.......................................................................................................................................47
3.3 Communications Interfaces ........................................................................................................................47
SECTION 4: SYSTEM FEATURES............................................................................................................................... 48
Template for representing system features .....................................................................................................48
SECTION 5: U SE CASE M ODEL ................................................................................................................................ 49
5.1 Use Case Diagram.......................................................................................................................................49
5.2. Use Case Description.................................................................................................................................49
SECTION 6: ELABORATED USE CASES.................................................................................................................... 51
TEMPLATE FOR ELABORATED USE CASES.............................................................................................................. 51
SECTION 7: U SER INTERFACE .................................................................................................................................. 52
TEMPLATE FOR USER INTERFACE DESCRIPTION .................................................................................................. 52
SECTION 8: NONFUNCTIONAL REQUIRE MENTS..................................................................................................... 53
8.1 Business Rules...............................................................................................................................................53
8.2 Performance Requirements.........................................................................................................................53
8.3 Safety Requirements.....................................................................................................................................53
8.4 Security Requirements.................................................................................................................................53
8.5 Software Quality Attributes........................................................................................................................53
Manual for the Software Development Standardization 36

8.6 User Documentation....................................................................................................................................53

SECTION 9: DATA DICTIONARY .............................................................................................................................. 54
9.1 Data 1 ...........................................................................................................................................................54
9.2 Data 2 ...........................................................................................................................................................54
9.n Data n ...........................................................................................................................................................54
Template for Data Dictionary...........................................................................................................................54
SECTION 10: TRACEABILITY MATRIX..................................................................................................................... 55
Technology Options ...................................................................................................................................................... 56
EXISTING SYSTEM ..................................................................................................................................................... 56
PERFORMANCE ........................................................................................................................................................... 56
NUMBER OF CONCURRENT USERS .......................................................................................................................... 56
DATA VOLUME........................................................................................................................................................... 56
A VAILABILITY ........................................................................................................................................................... 56
U SABILITY.................................................................................................................................................................. 56
COST ESTIMATE SHEET ............................................................................................................................................ 57

Software Requirement
Specification
Abstract
Software Requirement Specification (SRS) is a fundamental document, which forms the
foundation of software development process. SRS not only lists the requirements of a
system but also has a description of its major features. These recommendations extend
the IEEE standards and include use cases and sequence diagrams to incorporate UML
standards. The recommendations would form basis for providing clear visibility of the
product to be developed serving as baseline for execution of a contract between client
and developer.
Objectives
These recommendations are designed to serve as a reference for standardized preparation
of SRS for software projects. The body of this document contains various templates that
would help guide this process and provide the software engineers with conc rete
framework to accomplish their task. The idea is to help and assist the software engineers
and to promote a scalable structured format to ensure uniformity of concept and practice.
Introduction
Typically, SRS constitutes the agreement between clients and developers regarding the
contents of the software product that is going to be developed. SRS should accurately and
completely represent the system requirements as it makes a huge contribution to the
overall project plan. The software being developed may be a part of the overall larger
system or may be a complete standalone system in its own right. If the software is a
system component, the SRS should state the interfaces between the system and the
software portion.
Features of an SRS
SRS comprise specifications for a software product, program, or set of programs that
perform a certain function in a specific environment. Some integral features a typical
SRS should support are:
1. Functionality
What the software is supposed to do.

2. External Interfaces
How the system interacts with the people using it, or with other systems that
would use it, or other hardware that would invoke it.
3. Performance
Speed, availability, response time, recovery time, recovery time of various
software functions etc.
4. Attributes
What is the portability, correctness, maintainability and security considerations
etc.
5. Design Constraints
Standards to be followed, resource limits, operating environme nts, policies for
database integrity etc.
6. Non functional Requirements
Non functional requirements are the business rules, software quality attributes,
safety requirements, security requirements and performance parameters etc.
To ensure an error and ambiguity free SRS, it is imperative to identify all major
characteristics of a good SRS. Essentially, SRS should comprehensively cover every
requirement that the software has to meet. It is important to note that while writing SRS,
the terminology used for a particular component should be consistent throughout the
document. Every term should represent only one meaning to avoid confusion. It is
recommended that language and grammar of SRS be reviewed by an expert to eliminate
ambiguity.
While writing SRS, conceptual confusions and differences in thought s could create
conflicts in its contents. Generally there are three major types of conflicts in an SRS,
which are as follows:
1. Specified characteristics of real-world objects might conflict. For example.

a. Format of an output report might be described in one requirement as
tabular but in another as textual.
b. One requirement might state that all lights would be green while another
might state that there is a combination of red, yellow and green lights.
2. There may be logical or temporal conflict between two specified actions. For
example.
a. One requirement might specify that the program would add two inputs and
another might specify that the program would multiply them.
b. One requirement might state that ”A” must always follow “B,” while
another might require that “A and B” occur simultaneously.
3. Two or more requirements might describe the same real-world object but use
different terms for that object. For example, a program’s request for a user input
might be called a “prompt” in one requirement and a “cue” in another. Usage of
standard terminology and definitions promotes consistency.

Each requirement in SRS should be identified to clarify the difference between necessary
and optional components. Clarity ensures better understanding and correct design in the
later stages of development.
An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the
referencing of each requirement in future development or enhancement documentation.
Nevertheless a quality SRS ensures end-to-end traceability. End-to-end traceability might
be explained by chunking it into backward and forward traceability, which are given
below:
• Backward traceability (i.e., to previous stages of development). This depends

upon each requirement explicitly referencing its source in earlier documents.
• Forward traceability (i.e., to all documents spawned by the SRS). This depends
upon each requirement in the SRS having a unique name or reference number.
It is recommended that UML notation be followed in the SRS document. It would not
only preserve the universality of the concept, but would also be understandable to a
diverse audience at the same time.

Document Structure
Vision Statement
(Purpose, Scope,
Perspective description)
User Constraints Assumptions

characteristics
System Features
1
Nonfunctional
requirements
1
Use case
Diagram 1
n n
m n User Interface
Data dictionary Sequence
diagrams

SRS Document Template

Title
Section 1: Introduction
1.1 Vision Statement
1.1.1 Software Purpose
1.1.2 Software Scope
1.1.3 Software Perspective
1.2 Document conventions and definitions
1.3 Intended audience and Reading suggestions
1.4 References
Section 2: Overall description

2.1 User characteristics
2.2 Operating environment
2.3 Design and implementation constraints
2.4 Database considerations
2.5 Assumptions and dependencies
Section 3: External interface requirements

3.1 Hardware interfaces
3.2 Software interfaces
3.3 Communication interfaces
Section 4: System features

4.1 System feature 1
4.2 System feature 2
.
.
.
4.n System feature n
Section 5: Use case model

5.1 Use case diagram
5.2 Use Case Description
5.2.1 Use Case 1
5.2.2 Use Case 2
.
.
.
5.2.n Use Case n
Section 6: Nonfunctional requirements

6.1 Performance requirements
6.2 Safety requirements
6.3 Security requirements

6.4 Software quality attributes

6.5 Business rules
6.6 User documentation
Section 7: Graphical User Interface

7.1 Introduction
7.2 GUI description(s)
Section 8: Data Dictionary

8.1 Data Item 1
8.2 Data Item 2
.
.
.
8.n Data Item n

Description of SRS template

The template is self-explanatory, however the following description would remove any
ambiguity about what should be written under each heading and why.
<Document Title>
Document No.
Version No.
Created on:
Last modified on:
Last modified by:

Section 1: Introduction
1.1 Vision Statement
1.1.1 Software Purpose

Write the name, release number, version number and brief system description. Tick the appropriate check
box to indicate whether the software being developed is a complete standalone system, a subsystem, or a
revision of an existing system.
Name
Release No.
Version No.
System Subsystem Revision
Description
1.1.2 Software Scope

Provide a short description of the software being specified and its purpose, including benefits and goals.
Relate the software to corporate goals or business strategies.
1.1.3 Software Perspective

Describe the context and origin of the product being specified in the SRS. State whether this product is the
next member of a product family, the next release of a mature product, a replacement for existing
applications, or a new, self-contained product. If this SRS defines a component of a larger system, state
how this software relates to the overall system and identify the overall system interfaces between the two.
1.2 Document conventions and definitions

List all,
• Typographic conventions used in the SRS other than the ones not mentioned in the glossary of
terms.
• Text styles, highlighting other than those specified in the glossary.
• Significant notations used and what they mean in the context of this document.
1.3 Intended audience and reading suggestions

Provide a description of the intended audience i.e., the personnel who will be reading this document.
Suggested readings should emphasize exploration of references used and case study enclosed.
1.4 References
Provide all text and electronic document resources to which the SRS refers.

Section 2: Overall description

This section presents high-level overview of the product being specified and the environment in which it
will be used, the anticipated users of the product and the known constraints, assumptions and
dependencies.
2.1 User characteristics

Provide the various user classes that you anticipate will use this product and describe their characteristics.
Distinguish the most important user classes for this product from those whom it is less critical to satisfy.
2.2 Operating environment

Describe the environment in which the software will operate, including the hardware platform, operating
system ad versions, and other software components or applications with which it must coexist.
2.3 Design and implementation constraints

Identify any issues that will restrict the options available to the developers and describe why they are
constraints. Constraints may include the following
• Specific technologies, tools, programming languages, and databases that must be used or avoided
• Required development conventions or standards
• Corporate policies and government rules that influence design and implementation phases.
• Hardware limitations, such as timing requirement or memory specifications or constraints.
• Standard data interchange formats
• Transaction rate required
• Local and network security
• Downtime in terms of:
o Existing environment
o Support
• Scalability in terms of hardware and performance.
2.5 Assumptions and dependencies

List any assumed factors that could affect the requirements stated in the SRS. These could include
commercial components that you plan to use, or issues around the development or operating environment.
The project could be affected if these assumptions are incorrect, are not shared, or change.
Also, identify any dependencies the project has on external factors. For example, if you expect to integrate
into the system some components that are being developed by another project, you are dependent upon that
project to supply the correctly operating components on schedule.

Section 3: External interface requirements
This section is intended to specify any requirements that ensure that the new product will connect properly
to external components. Place a context diagram showing the external interfaces at a high level of
abstraction. Place detailed descriptions of the data and control components of the interfaces in the data
dictionary. If different portions of the product have different external interfaces incorporate an instance of
this section within the detailed requirements for each such portion.
3.1 Hardware Interfaces

Describe the characteristics of each interface between the software and hardware components of the
system. This description might include the supported device types, the nature of the data and control
interactions between the software and the hardware, and communication protocols to be used.
3.2 Software Interfaces

Describe the connections between this product and other external software components (identified by name
and version), including databases, operating systems, tools, libraries, and integrated commercial
components. Identify and describe the purpose of the data items or messages exchanged among the
software components. Describe the services needed and the nature of the inter-component communications.
Identify data that will be shared across software components. If the data-sharing mechanism must be
implemented in a specific way, such as a global data area in a multitasking operating system, specify this
as an implementation constraint.
3.3 Communications Interfaces

Describe the requirements associated with any communication functions the product will use, including e-
mail, web browser, network communications standards or protocols, electronic forms, and so on. Define
any pertinent message formatting. Specify communication security or encryption issues, data transfer rates,
and synchronization mechanisms.

Section 4: System features

A feature is a set of logically related functional requirements that provides a capability to the user and
enables the satisfaction of a business requirement. This recommendation emphasizes that each requirement
be portioned as a set of small problem statements that would later serve as a take-up point for use case
identification. For example, spellchecker is a usual feature available with all word processors.
Template for representing system features

4.1.1 System Feature 1
Write the name of the feature. Describe the features briefly so as to give the gist of the matter. The same
procedure is repeated for each system feature.
4.1.2 System Feature 2
Feature Description.
.
.
.
4.1.n System Feature n
Feature Description.

Section 5: Use Case Model

After enlisting systems features, the next step would be to elaborate these in terms of some use cases. The
purpose of use case is to capture all Functional Requirements of the proposed software system with
particular focus on the value added to each individual user or to each external system. The use case model
acts as the main statement of the functional requirements.
In general terms, the purpose of use case analysis is to document the business process that is to be
supported by the system under development. However, to effectively develop a well-organized application
for that process, use case model must have a much more specific purpose. Use cases must document the
business process to be supported in such a way as to facilitate the identification of operations that support
the business process. Use cases must achieve the following goals in order to be effective for this stated
purpose.
1. Use cases must be an Effective Communication Tool
2. Use cases must be scoped to a Specific Business Goal, which means they must identify Business
Decisions and Actions.
5.1 Use Case Diagram

A Use Case represents a discrete unit of interaction between a user (human or machine) and the system.
The use cases identified after users’ interview should be depicted in the use case diagram. The Unified
Modeling Language (UML) graphical notations should be employed to produce these diagrams. These
notations have been standardized and published by Object Management Group (OMG).
5.2. Use Case Description

Each Use Case has a description, which describes the functionality that will be built in the proposed
system. The Use Case description generally includes:
1. Basic Information:
i. Actors
ii. Purpose
iii. Cross References
2. Primary Course of Events: It is the most important part of uses case description and describes the
interaction between the actor and the system. It describes the most common or typical sequence of
events. Exceptions to this flow are identified in next section.
3. Alternate Courses: In this section the alternate or exceptions to the primary course are identified.
4. Sequence Diagram: This is graphical representation of primary course of events.

Template for Use case description
<Name of the use case>
Basic Information
Actors: <List of actors (external agents), indicating who initiated the use case>
Purpose: <Briefly describe high level description of use case>
Cross References: <Related use cases, which use or are used by this use case>
Feature: <Feature from which the use case is driven>
Typical Course of Events

List all events of the use case in bulleted form. Give only an abstract description of what use case
is all about.
Alternate Course of Events

List alternate/exception with line number, where they arise.

Section 6: Elaborated Use Cases

Adopt the following scheme for listing elaborated use cases:
6.1 Use case 1

Description.
6.2 Use case 2
Description.
.
.
.
6.n Use case n
Description.
Template for Elaborated use cases
<Use case name>

Use case reference Write use case reference number.
Pre-condition
Step# Action Software Reaction
Numbered actions of the actors Numbered description of system responses
Scenario Notes
Write concurrency of actions, additional, optional, branching or iterative steps. Refer to
specific action number to ensure understandability.
Post Conditions
Step# Description
Sequentially list conditions expected at the completion of the use case.
User Interface reference List user interface(s) that are related to this use case. Use
numbered list in case of more than one user interface
elements.
Sequence Diagram (preferably on next page)

Shows a user or actor, and the objects and components they interact with in the execution of a
use case.
Concurrency and Response

Give an estimate of the following
♦ Number of concurrent users
♦ Expected response time of the use case

Section 7: User Interface

Give a detailed account of user interfaces included in this project.
Template for User Interface Description
User Interface Title

Interface No. Write the reference number assigned to this UI.
Use case Reference Refer to the use case invoking this UI.
Snapshot
Include a labeled snapshot of the user interface.
Data dictionary reference

Label Data dictionary identifier
Refer to fields in data dictionary

Section 8: Nonfunctional requirements

Write all the nonfunctional requirements other than external interface requirements and constraints in this
section.
8.1 Business Rules

List any operating principles about the product, such as which individuals or roles can perform which
functions under specific circumstances. These are not functional requirements in themselves, but they might
imply certain functional requirements to enforce the rules. Mention all users who will be accessing the
software and describe their respective rights.
8.2 Performance Requirements

State any product performance requirements for various usage scenarios, and explain their rationale to
help the developers make suitable design choices. Specify the number of concurrent users or operations to
be supported, response times for systems. Specify memory capacity requirements and quantify the
performance requirements as specifically as possible.
8.3 Safety Requirements

Specify the requirements that are concerned with possible loss, damage, or harm that could result from the
use of the product. Define any safeguards or actions that must be taken, as well as potentially dangerous
actions that must be prevented. Identify any safety certifications, policies, or regulations to which the
product must conform.
8.4 Security Requirements

Specify any requirements regarding security, integrity, or privacy issues that affect the use of the product
and protection of the data used or created by the product. Define all user authentication or authorization
requirements, if any. Identify any security or privacy policies or certifications the product must satisfy.
8.5 Software Quality Attributes

Specify any additional product quality characteristics that will be important to either customers or
developers. These characteristics should be specific, quantitative, and verifiable when possible. Also,
indicate the relative preferences for various attributes, such as ease of use over ease of learning, or
portability over efficiency.
8.6 User Documentation

List the user documentation components that will be delivered along with the software, such as user
manuals, online help, and tutorials. Identify any known user documentation delivery formats or standards.

Section 9: Data Dictionary

The convention recommended for writing the data dictionary is as follows.
9.1 Data 1
Description.
9.2 Data 2
Description.
.
.
.
9.n Data n
Description.
Template for Data Dictionary
<9.n Data n>

Name Give primary name of the data or control item, the data store
or an external entity.
Alias Write other names used for the first entry.
Where-used/how-used List all processes that use the data or control item and how it
is used (e.g., input to process, output from the process, as a
store, as n external entity)
Content description Notation for representing content.
Supplementary information Other information about data types, preset values,

restrictions or limitations etc.
The notation to develop content description is given below.
Data construct Notation Meaning
= is composed of
Sequence + and
Selection [|] either-or
Repetition {}n n repetitions of
() optional data
*…* delimits comments

Section 10: Traceability matrix

Sr. # Feature Use case UI ID Priority Build Use Case Cross reference
ID Number (Related Use Cases)
The columns carry the following meaning:
♦ Feature: Lists system features based on which use cases are built.
♦ Use Case ID: Write the ID of the use case for easy lookup
♦ UI ID: Write the user interface ID for this use case.
♦ Priority: Give an appropriate rating to each use case according to its priority
♦ Build Number: Write the reference number to which this feature belongs.
♦ Use Case Cross Ref: Write the related use cases separated with commas.

Technology Options
Technology options and recommendation are derivatives of the non functional
requirements discussed in the software requirement specifications.
Existing system
Give a description of the existing system. Define whether the new system being developed is a part of the
existing system, is an add-on or an integrated component.
Draw a diagram showing the detailed system architecture. If the system being developed has no
relationship with the existing system, mention it clearly.
Performance
Mention the average response time for the system. Show a breakup of the system into use cases and
mention response time for each use case. Some use cases may require more time than others, nevertheless
it should be within realistic limits.
Number of Concurrent users

Mention the number of concurrent users. Show a breakup of the system into use cases and predict how
many users will be using each GUI at the same time. Also, mention how many users will be accessing the
system at one instant. Explicitly mention how many users can access the database concurrently.
Data volume
Mention the following.
Period Total No. of No. of records in largest Avg. No. of records Size of DB in terms of
tables in DB table in DB per table bytes of data
Availability
Mention the permitted downtime of the system in terms of average and maximum downtime.
Usability
Mention the network latency of the system. Mention if the system will be a web based system

Technology Option Selection process map
PC 2
PC 1
S/w cost
H/w cost
S/w Licensing cost
Bids
1…n options for

h/w & s/w
Cost Estimate Sheet
1. Software development cost

2. Packaged software
3. Hardware
4. Network
5. Client
6. Misc.
Per unit cost =
Total cost =

Srs Template

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Srs Template

Transféré par

Droits d'auteur :

Formats disponibles

Chapter 3

Manual for the Software Development Standardization 36

8.6 User Documentation....................................................................................................................................53

Manual for the Software Development Standardization 37

Manual for the Software Development Standardization 38

1. Specified characteristics of real-world objects might conflict. For example.

Manual for the Software Development Standardization 39

• Backward traceability (i.e., to previous stages of development). This depends

Manual for the Software Development Standardization 40

User Constraints Assumptions

Manual for the Software Development Standardization 41

SRS Document Template

Section 2: Overall description

Section 3: External interface requirements

Section 4: System features

Section 5: Use case model

Section 6: Nonfunctional requirements

Manual for the Software Development Standardization 42

6.4 Software quality attributes

Section 7: Graphical User Interface

Section 8: Data Dictionary

Manual for the Software Development Standardization 43

Description of SRS template

Manual for the Software Development Standardization 44

1.1 Vision Statement

1.1.1 Software Purpose

1.1.2 Software Scope

1.1.3 Software Perspective

1.2 Document conventions and definitions

1.3 Intended audience and reading suggestions

Manual for the Software Development Standardization 45

Section 2: Overall description

2.1 User characteristics

2.2 Operating environment

2.3 Design and implementation constraints

2.5 Assumptions and dependencies

Manual for the Software Development Standardization 46

Section 3: External interface requirements

3.1 Hardware Interfaces

3.2 Software Interfaces

3.3 Communications Interfaces

Manual for the Software Development Standardization 47

Section 4: System features

Template for representing system features

Manual for the Software Development Standardization 48

Section 5: Use Case Model

5.1 Use Case Diagram

5.2. Use Case Description

Manual for the Software Development Standardization 49

Template for Use case description

<Name of the use case>

Typical Course of Events

Alternate Course of Events

Manual for the Software Development Standardization 50

Section 6: Elaborated Use Cases

6.1 Use case 1

Template for Elaborated use cases

<Use case name>

Sequence Diagram (preferably on next page)

Concurrency and Response

Manual for the Software Development Standardization 51

Section 7: User Interface

Template for User Interface Description

User Interface Title