0% found this document useful (0 votes)
19 views17 pages

Unit2-Lect2

Uploaded by

Abhinav T
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views17 pages

Unit2-Lect2

Uploaded by

Abhinav T
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 17

Software Requirement

Specification
Unit 2- Lecture 2
What is SRS?
• SRS stands for Software
Requirement Specification.

• It establishes the basis for


agreement between customers
and contractors or suppliers on
what the software product is
expected to do, as well as what
it is not expected to do.
Features of SRS
• Some of the features of SRS are -

It sets permits a rigorous


assessment of requirements before
design can begin.
It sets the basis for software design, test,
deployment, training etc.

It also sets pre-requisite for a good


design though it is not enough.
• A Software Requirements
Specification (SRS) is a complete
description of the behavior of the
system to be developed.

• It includes a set of use cases that


describe all the interactions the users
will have with the software.

• Use cases are also known as


functional requirements.

• In addition to use cases, the SRS also


contains nonfunctional (or
supplementary) requirements.
• Non-functional requirements
are requirements which impose
constraints on the design or
implementation (such as
performance engineering
requirements, quality standards,
or design constraints).
General Outline of an SRS
General Outline of an SRS

• Software Requirements
Specifications (SRS)

• Cover Page

• Revisions Page

• Table of Contents
• 1 INTRODUCTION

– 1.1 Product Overview

– 1.2 Purpose

– 1.3 Scope

– 1.4 Reference

– 1.5 Definition And Abbreviation


• 2 SPECIFIC REQUIREMENTS

– 2.1 External Interface Requirements


• 2.1.1 User Interfaces
• 2.1.2 Hardware Interfaces
• 2.1.3 Software Interfaces
• 2.1.4 Communications Protocols
• 2.1.5 Memory Constraints
• 2.1.6 Operation
• 2.1.7 Product function
• 2.1.8 Assumption and Dependency
– 2.2 Software Product Features

– 2.3 Software System Attributes

• 2.3.1 Reliability
• 2.3.2 Availability
• 2.3.3 Security
• 2.3.4 Maintainability
• 2.3.5 Portability
• 2.3.6 Performance

– 2.4 Database Requirements

• 3 ADDITIONAL MATERIALS
Goals of SRS
• A well-designed, well-written SRS
accomplishes four major goals.
• It provides feedback to the customer.

• It decomposes the problem into component


parts.

• It serves as an input to the design


specification.

• It serves as a product validation check.


What are the benefits of a
Great SRS?
• The IEEE 830 standard defines
the benefits of a good SRS:

• Establish the basis for


agreement between the
customers and the suppliers on
what the software product is to
do.

• Reduce the development effort.


• Provide a basis for estimating costs
and schedules.

• Provide a baseline for validation


and verification.

• Facilitate transfer.

• Serve as a basis for enhancement.


What should the SRS
address?
• The basic issues that the SRS
writer(s) shall address are the
following:
a)Functionality. What is the software
supposed to do?

b) External interfaces. How does the


software interact with people, the
system’s hardware, other hardware,
and other software ?
c) Performance. What is the
speed, availability, response
time, recovery time of various
software functions, etc.?

d) Attributes. What are the


portability, correctness,
maintainability, security, etc.
considerations?
• e) Design constraints imposed
on an implementation. Are there
any required standards in effect,
implementation language,
policies for database integrity,
resource limits, operating
environment(s) etc.?
What are the characteristics
of a great SRS?

• 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

You might also like