SOFTWARE
REQUIREMENT
SPECIFICATION
(SRS)
SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
A software requirements
specification (SRS) is a description of
a software system to be developed.
Defines the customer’s requirements in terms of :
Function
Performance
External interfaces
Design constraints
SRS establishes basis of agreement
between the user and the supplier.
CHARACTERISTICS OF AN SRS
Correct
Complete
Unambiguous
Consistent
Verifiable
Traceable
Modifiable
Ranked for importance and/or stability
CHARACTERISTICS…
Correctness
Each requirement accurately represents
some desired feature in the final system
Completeness
All desired features/characteristics specified
Hardest to satisfy
Completeness and correctness strongly
related
Unambiguous
Each req has exactly one meaning
Without this errors will creep in
Important as natural languages often used
CHARACTERISTICS…
Verifiability
There must exist a cost effective way of checking
if sw satisfies requirements
Consistent
two requirements don’t contradict each other
Traceable
The origin of the req, and how the req relates to
software elements can be determined
Ranked for importance/stability
Needed for prioritizing in construction
To reduce risks due to changing requirements
COMPONENTS OF AN SRS
An SRS must specify requirements on
Functionality
Performance
Design constraints
External interfaces
FUNCTIONAL REQUIREMENTS
Heart of the SRS document; this forms
the bulk of the specs
Specifies all the functionality that the
system should support
Outputs for the given inputs and the
relationship between them
All operations the system is to do
Must specify behavior for invalid inputs
too
PERFORMANCE REQUIREMENTS
All the performance constraints on the
software system
Generally on response time , throughput
etc => dynamic
Capacity requirements => static
Must be in measurable terms
(verifiability)
Eg resp time should be xx 90% of the time 8
DESIGN CONSTRAINTS
Factors in the client environment that
restrict the choices
Some such restrictions
Standard compliance and compatibility
with other systems
Hardware Limitations
Reliability, fault tolerance, backup req.
Security
EXTERNAL INTERFACE
All interactions of the software with
people, hardware, and software
User interface most important
General requirements of “friendliness”
should be avoided
These should also be verifiable
SPECIFICATION LANGUAGE
Language should support desired
charateristics of the SRS
Formal languages are precise and
unambiguous but hard
Natural languages mostly used, with some
structure for the document
Formal languages used for special features
or in highly critical systems
Analysis
REQUIREMENTS VALIDATION
Specification
Lot of room for misunderstanding
Errors possible Validation
Expensive to fix req defects later
Must try to remove most errors in SRS
Most common errors
Omission - 30%
Inconsistency - 10-30%
Incorrect fact - 10-30%
Ambiguity - 5 -20%
REQUIREMENTS REVIEW
SRS reviewed by a group of people
Group: author, client, user, dev team
rep.
Must include client and a user
Process – standard inspection process
Effectiveness - can catch 40-80% of
req. errors
SUMMARY
Having a good quality SRS is essential
for Q&P
Key properties of an SRS: correctness,
completeness, consistency, traceablity,
unambiguousness
Specification
must contain functionality,
performance , interfaces and design
constraints
Mostly natural languages used
Validation - through reviews
14
THANK
YOU
FOR WATCHING
