0% found this document useful (0 votes)
386 views5 pages

SRS - Software Requirement Specification

The document is a software requirement specification (SRS) prepared by Krupali N Patel. It discusses the purpose and characteristics of an SRS. An SRS captures a complete description of how a system is expected to perform, including both user and system requirements. It precisely defines the software product and is used to understand all requirements to help with design. An SRS should be correct, complete, consistent, unambiguous, modifiable, verifiable, traceable, and testable. It is important as it provides a basis for agreement between users and developers and helps reduce development effort and costs.

Uploaded by

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

SRS - Software Requirement Specification

The document is a software requirement specification (SRS) prepared by Krupali N Patel. It discusses the purpose and characteristics of an SRS. An SRS captures a complete description of how a system is expected to perform, including both user and system requirements. It precisely defines the software product and is used to understand all requirements to help with design. An SRS should be correct, complete, consistent, unambiguous, modifiable, verifiable, traceable, and testable. It is important as it provides a basis for agreement between users and developers and helps reduce development effort and costs.

Uploaded by

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

08-11-2020

SRS- Software Requirement Specification

Prepared By
Krupali N Patel

Introduction
A software requirements specification (SRS) is a
document that captures complete description about
how the system is expected to perform. It is usually
signed off at the end of requirements engineering
phase.
SRS should include both a definition of user
requirement and a specification of the system
requirement.
The SRS fully describe what is software will do and
how it will be expected to perform.

1
08-11-2020

Purpose of SRS
The SRS precisely define the software product that will
be built
SRS used to know all the requirements for the
software development and thus that will help in
designing the software.
It provides feedback to the customer.

Purpose of SRS
Feedback: Provides a feedback, which ensures to the user
that the organization (which develops the software)
understands the issues or problems to be solved and the
software behavior necessary to address those problems.
Decompose problem into components: Organizes
the information and divides the problem into its
component parts in an orderly manner.
Validation: Uses validation strategies applied to the
requirements to acknowledge that requirements are
stated properly.
Input to design: Contains sufficient detail in the functional
system requirements to devise a design solution.
4

2
08-11-2020

Purpose of SRS
Basis for agreement between the user and the
organization: Provides a complete description of the
functions to be performed by the system. In addition, it
helps the users to determine whether the specified
requirements are accomplished.
Reduce the development effort: Enables developers to
consider user requirements before the designing of the
system commences. As a result, ‘rework’ and
inconsistencies in the later stages can be reduced.
Estimating costs and schedules: Determines the
requirements of the system and thus enables the
developer to have a ‘rough’ estimate of the total cost and
schedule of the project.
5

Characteristics / Features of SRS

3
08-11-2020

Characteristics / Features of SRS


Correct: should accurately reflect product functionality and
specification at any point of time.
Complete: should contain all the features requested by a
client.
Consistent: same abbreviation and conventions must be
followed throughout the document.
Unambiguous: should not be any confusion regarding
interpretation of the requirements.
Ranked for importance and/or stability: every
requirement is important. But some are urgent and must
be fulfilled before other requirements and some could be
delayed. It’s better to classify each requirement according
to its importance and stability.
7

Characteristics / Features of SRS


Modifiable: an SRS must clearly identify each and
every requirement in a systematic manner. If there are
any changes, the specific requirements and the
dependent ones can be modified accordingly without
impact the others.
Verifiable: an SRS is verifiable only if every stated
requirement can be verified. A requirement is
verifiable if there is some method to quantifiably
measure whether the final software meets that
requirement.
Traceable: an SRS is traceable if the origin of each of
its requirements is clear and if it makes it easy to
reference each requirement in future development.
8

4
08-11-2020

Characteristics / Features of SRS


Testability: An SRS should be written in such a way that it
is easy to generate test cases and test plans from the
document.
Understandable by the customer: An end user maybe an
expert in his/her specific domain but might not be an
expert in computer science. Hence, the use of formal
notations and symbols should be avoided to as much
extent as possible. The language should be kept easy and
clear.
Right level of abstraction: If the SRS is written for the
requirements phase, the details should be explained
explicitly. Whereas, for a feasibility study, fewer details can
be used. Hence, the level of abstraction varies according to
9
the purpose of the SRS.

Why SRS is so important


The users and the client get a brief idea about the software
while in the initial stages.
The purposes and the intentions as well as the expected
results are properly defined. It hence lays the outline for
software design.
The desired goals are defined thereby easing off the efforts
of the developers in terms of time and cost.
It forms a basis for the agreement between the client and
the developer.
It becomes easier while transferring and using the solution
elsewhere or with new customers as the basis of
functioning of the software is mentioned.
It acts as a material for reference at a later stage.
It acts as the basis for reviews.
10

You might also like