Scribd
Upload
100 views

UNIT-2 Prepared by Sathish Kumar/Mit

An SRS document forms an agreement between customers and developers, reduces future reworks, provides a basis for estimating costs and schedules, and facilitates validation and verification. It should be concise, implementation-independent, traceable, modifiable, identify responses to undesired events, and be verifiable. Attributes of bad SRS documents include over-specification, forward references, wishful thinking, and irrelevant noise. An SRS clearly documents functional requirements, non-functional requirements, design constraints, external interfaces, and implementation goals.

Uploaded by

Anbazhagan Selvanathan
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
100 views

UNIT-2 Prepared by Sathish Kumar/Mit

An SRS document forms an agreement between customers and developers, reduces future reworks, provides a basis for estimating costs and schedules, and facilitates validation and verification. It should be concise, implementation-independent, traceable, modifiable, identify responses to undesired events, and be verifiable. Attributes of bad SRS documents include over-specification, forward references, wishful thinking, and irrelevant noise. An SRS clearly documents functional requirements, non-functional requirements, design constraints, external interfaces, and implementation goals.

Uploaded by

Anbazhagan Selvanathan
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/ 16

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.

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