SRS

UNIT-2
PREPARED BY
SATHISH KUMAR/MIT
 Why Spend Time and Resource to Develop an SRS
Document?
• Forms an agreement between the customers
and the developers
• Reduces future reworks
• Provides a basis for estimating costs and
schedules
• Provides a baseline for validation and
verification
• Facilitates future extensions
Characteristics of a Good SRS Document
• skill of writing a good SRS- - gained experience
• IEEE Recommended Specifications[IEEE830]
• Concise:
• Implementation-independent: (what & how)
• Traceable: (current phase and previous phase)
• Modifiable:
• Identification of response to undesired events:
• Verifiable: (library automation)
 Attributes of Bad SRS Documents
• Over- specification: restricts the freedom
• of the designers
• Forward references
• Wishful thinking:
• Noise: The term noise refers to presence of
material not directly relevant to
• the software development process.
 Important Categories of Customer
Requirements
• An SRS document should clearly document the
following aspects of a software:
• • Functional requirements
• • Non-functional requirements
• — Design and implementation constraints
• — External interfaces required
• — Other non-functional requirements
• Goals of implementation.
 Non-functional requirements
• requirements of the customer that cannot be
expressed as functions.
• Non-functional requirements usually address
aspects concerning external interfaces,
• User interfaces, maintainability, portability,
usability, maximum number of concurrent
users, timing, and throughput (transactions
per second, etc.).
 Functional requirements
• The functional requirements of the system,
should clearly describe each functionality that
the system would support along with the
corresponding input and output data set.

• The functional requirements capture the

functionalities required by the users from the
system
• A high-level function is one using which the user
can get some useful piece of work done.

• Can the printing of the statements of the ATM

transaction during withdrawal of money from an
ATM be called a useful piece of work?

• Each high-level requirement typically involves

accepting some data from the user through a user
interface, transforming it to the required
response, and then displaying the system
response in proper format.
 How to Document the Functional
Requirements?
• (Withdraw cash from ATM):

• R.1: Withdraw cash

• R.1.1: Select withdraw amount option

• Input: “Withdraw amount” option selected Output: User prompted to
enter the
• account type
• R.1.2: Select account type
• I n p u t : User selects option from any one of the followings—
• savings/checking/deposit.
• Output: Prompt to enter amount
 Organisation of the SRS Document
• Introduction
• Purpose:
• Project scope:
• Environmental characteristics
• Overall description of organisation of SRS document
– Product perspective
– Product features:
– User classes:
– Operating environment:
– Design and implementation constraints
– User documentation:
 FORMAL SYSTEM SPECIFICATION
• The mathematical basis of a formal method is
provided by its specification language.
• Syntactic domains- alphabet of symbols and a
set of formation rules.
• Semantic domains-Abstract data type
specification languages are used to specify
algebras, theories, and programs.
• Satisfaction relation-
 Operational Semantics
• single run of the system and how the runs are
grouped together to describe the behaviour of
the system.
• Linear semantics- (possibly infinite) of events
• Branching semantics- nodes of the graph
• Maximally parallel semantics-concurrent
actions
• Partial order semantics- a precedence ordering
 AXIOMATIC SPECIFICATION
• first-order logic is used to write the pre- and post-
conditions to specify the operations of the
system in the form of axioms.
• Establish the range of input values over which the
function should behave correctly.
• Specify a predicate defining the condition

• Combine all of the above into pre- and post-

conditions of the function.
 EXECUTABLE SPECIFICATION AND 4GL

• 4GLs are successful because there i s a lot of

large granularity commonality across data
processing applications which have been
identified and mapped to program code.
• software reuse
• rewriting 4GL programs in 3GLs results in
• up to 50 per cent lower memory usage.