By Karthik.

s(09msc016)
Priyadarshini.a(09msc028)
Content:
 What is srs?
 Software requirements
 Component of SRS
 Characteristic of srs
 Structure of srs
 Example
 A Software Requirements Specification (SRS) - a
requirements specification for a software system - is a
complete description of the behavior of a system to be
developed.
 Finial output of requirement analysis phase.
 Find out problem – analysis – srs.
Software requirements
 requirements: specify what to build
 tell "what" and not "how"
 tell the system design, not the software design
 tell the problem, not the solution (in detail)
Requirements definition

1. The software must provide a means of repr esenting and

1. accessing external files created by other tools.

Requirements specification

1.1 The user should be provided with facilities to define the type of
1.2 external files.
1.2 Each external file type may have an associated tool which may be
1.2 applied to the file.
1.3 Each external file type may be represented as a specific icon on
1.2 the user’s display.
1.4 Facilities should be provided for the icon repr esenting an
1.2 external file type to be defined by the user.
1.5 When a user selects an icon repr esenting an external file, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.
 User requirements
 Statements in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers.
 System requirements
 A structured document setting out detailed
descriptions of the system’s functions, services and
operational constraints. Defines what should be
implemented so may be part of a contract between
client and contractor.
Component of SRS
 Functionality
 Performance requriment
 Design constraint
 External interface requriment
Functionality

 Requriments specifies which output should be

produced from given input.
 Describe relationship between input & output.
 Functional requriment:
 Define system Functionality expected by the user
 Eg: Input data, source, unit of measure.
 Non Functionality requriment:
 Requriment of non Functional nature
 Eg: ,portability
Performance requriment

 Requriment releated to the performance of the system.

 Static requriment:
Does not impose constrains. Eg: No of files.

 Dynamic requriments:
Specify the constraint.
Eg: Response time
Design constraint

 Requriment releated to design constaint.

Eg: resource limit, operating environment, security

requriment.
External interface requriment
 Specifies user interface & user manual.
 Specify how to make system to interact with
software / hardware or user.
An SRS should be:
a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable
a) Correct
• An SRS is correct if every requirement stated in
it is one that the software will meet.
• There is no tool or procedure that ensures
correctness, but the customer or user can
determine if the SRS correctly reflects the actual
needs.
b) Unambiguous
• An SRS is unambiguous only if every requirement stated
in it has only one interpretation. As a minimum this
requires that each characteristic of the final product be
described using a single unique term.
• Representations that improve the requirements
specification for the developer may be counterproductive
in that they diminish understanding to the user and vice
versa.
• Care should therefore be taken to ensure natural
language is used so that terms are understandable to both
developer and user.
c) Complete
An SRS is complete only if it includes the following
elements:
i) All significant requirements
ii) Definition of the responses of the software to all classes of
input data. It is important to specify the responses to
both valid and invalid input values.
iii) Full labels and references to all figures, tables, and
diagrams in the SRS and definition of all terms and units
of measure
d) Consistent
Consistency refers to internal consistency. It is internally consistent
only if no subset of individual requirements described in it conflict.
For example:
i) Characteristics may conflict (ie, one requirement may state that all
users need a password whilst another states they do not).
ii) Actions may conflict (ie one requirement states that two inputs
should be added whilst another states they should be multiplied).
iii) Different terms are used for the same thing (ie, one requirement may
describe a user input as a prompt whilst another may describe it as a
cue).
e) Ranked for importance and/or stability
Typically all of the requirements that relate to a software product
are not equally important. Some requirements may be essential
(especially for life critical systems) while others may be desirable.

An SRS is ranked for importance and/or stability if each

requirement in it has an identifier to indicate either the importance
or the stability of a particular requirement.

Necessity can be ranked as essential (requirements must be provided),

conditional (requirements would enhance the product) and optional
(requirement may or may not be worthwhile).
Stability can be expressed in terms of the number of expected changes to
any requirement based on knowledge of forthcoming events that
effect the organisation
f) Verifiable
An SRS is verifiable only if every requirement in it is verifiable.

Nonverifiable requirements include statements such as “works

well”, “good human interface” and “shall usually happen”. These
requirements cannot be verified because it is impossible to define the
terms “good” “well” or “usually”.

An example of a verifiable statement is:

“Output of the program shall be produced within 20 s of event x
60% of the time; and shall be produced within 30 s of event x 100%
of time”

If a method cannot be devised to determine whether the software

meets a particular requirement then that requirement should be
removed or revised.
g) Modifiable
An SRS is modifiable only if it’s structure and style are such that
any changes to the requirements can be made easily, completely and
consistently while retaining the structure and style. Modifiability
generally requires an SRS to:
i) Have an easy-to-use organisation with a table of contents, an index,
and cross-referencing.
ii) Not be redundant (i.e., the same requirement should not appear in
more than one place in the SRS).
Redundancy itself is not an error, but it can lead to errors when a
redundant document is updated as the requirement may only be
updated in one of the places where it appears. The document would
then be inconsistent. Whenever redundancy is necessary, the SRS
should include cross-references to make it modifiable.
iii) Express each requirement separately, rather than intermixed with
other requirements.
h) Traceable
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.
The following two types of traceability are recommended:
i) Backward traceability (i.e. to the previous stages of development).
This depends upon each requirement explicitly referencing its source
in earlier documents.
ii) 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.
The forward traceability of the SRS is especially important when the
software product enters the operation and maintenance phase. As
code and design documents are modified, it is essential to be able to
ascertain the complete set of requirements that may be affected by
these modifications.
 Structure of SRS
1.Introduction
1.1 purpose
1.2 scope
1.3 definition
1.4 referenece
2. Overall description
2.1 product perspective
2.2 product function
2.3 user characteristic
2.4 general constraint
2.5 assumption and dependencies
3. Specific requriment
3.1 external interface requriment
3.1.1 user inteface
3.1.2 hardware interface
3.1.3 software interface
3.2 functional requriment
3.3 performance requriment
3.4 design constraint
3.5 other requriments
Example: Online web store
SRS

1. Introduction
1.1 Purpose
This is the Software Requirements Specification for
GAMMA-J’s Web Store. This Web Store is designed to
allow new online store owners a quick and easy means
to setup and perform sales and other core business over
the internet. This document will outline all of the
functions, capabilities and requirements for Version 1
of GAMMA-J’s Web Store. Version 1 is planned for
implementation on a “plug and play” USB Key.
1.2 Project Scope
According to GAMMA-J’s Functional Needs
Statement this Web Store will.
Manage customer accounts
Manage an online store inventory
Manage a customer’s “Shopping Cart”
Confirm Orders
1.3 References
This document draws insight from the Web
Store System Overview, Functional Needs
Statement, and Stakeholder Goals List.
2. Overall Description
2.1 Product Perspective
Web Store is a new system designed for users new to the online E-commerce. This will be a
plug and play device with its own CPU and operating system.
2.2 Product Features
Account Management (AM) (High Priority): AM allows users to create, edit, and view
accounts information. It also allows the user to login/out of the system.
Search Engine (SE) (Medium Priority): SE is the tool that assists the user in finding a specific item in
the database.
Product Management (PM) (High Priority): PM allows sales personnel to manage the product line
shown on the web site.
Shopping Cart (SC) (Medium Priority): SC is temporary storage for customers shopping on the web..
Purchasing and Payment (PP) (High Priority): PP is used to approve and transfer payment from buyers
when purchasing items in the cart.

2.3 User Classes

System Administrator
Sales Personnel
Customer:
2.4 Operating Environment
OE-1: Web Store shall operate with the internet browsers
OE-2: Web Store shall operate with Slackware Linux 2.6
OE-3: The system shall use SQL based database
2.5 Design and Implementation Constraints
CO-1: Must use a SQL based database
CO-2: Compatibility is only tested and verified for Microsoft Internet Explorer version 6
and7,
2.6 Assumptions and Dependencies
Assume the delivery of development, test and evaluate samples
3. System Features
3.1 Customer Accounts
3.1.1 Description
Customers will be able to create accounts to store their profiles
3.2 Inventory Management
3.3 Shopping Cart
3.4 Order Confirmation
3.5 Interface
The interface will be presented to the customer in a web browser
4. External Interface Requirements
4.1 User Interfaces
5. Quality Attribute Requirements
5.1 Performance Requirements
 The system shall be able to retrieve 200 products per
second.
 · The system shall be able to add product to shopping
cart in less than 2ms.
 · The system shall be able to search for a specified
product in less than 1 second
 5.2 Safety Requirements
 · The system will do periodic backups through a live
internet connection
 5.4 Availability Requirements
 · The system shall have an availability of 99.99%.
 6. Other Requirements
 · The system hardware shall be fixed and
patched via an internet connection.
 · The system shall adhere to the following
hardware requirements:
 · 4GB Flash ram chip
 · 128MB SDRAM
 · OS: Apache web server
 · Database: MySQL