Scribd
Upload
147 views15 pages

SRS3

Software Requirement Specification Presentation. Includes definition, characteristics, components presentaion summery

Uploaded by

saurabh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
147 views15 pages

SRS3

Software Requirement Specification Presentation. Includes definition, characteristics, components presentaion summery

Uploaded by

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

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

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy