Software

S ft R
Requirements
i t
Specification
Software
S ft Requirements
R i t Specification:
S ifi ti AC
Contract
t t
Document
y Requirements document is a reference
f document.
y SRS document is a contract between the
d
development
l t tteam and
d th
the customer.
t
y Once the SRS document is approved by the
customer,
y any subsequent controversies are settled
byy referring
g the SRS document.
SW R
Requirements
i t SSpecification
ifi ti
y Purpose of SRS
y communication between the Customer, Analyst,
system developers, maintainers, ...
y contract between Purchaser and Supplier
y firm foundation for the design phase
y support system
y testing
g activities
y support project management and control
y controlling the evolution of the system
 SRS Document (CONT.)
y The SRS document
doc ment is kno
known
n as black-box
black bo
specification:
y the system is considered as a black box whose internal
details are not known.
y only its visible external (i.e. input/output) behavior is
documented.

I
Input
tDData
t O t t Data
Output D t
S
SRS Document (CONT.)
y SRS document concentrates on:
y what needs to be done
y carefully avoids the solution (“how to do”) aspects.
y The SRS document serves as a contract
y between development team and the customer.
y Should be carefully written
SRS Document (CONT.)
y The requirements at this stage:
y written using end-user
end user terminology
terminology.
y If necessary:
y later a formal
f requirement specification
f
may be developed from it.
 Software Requirements Specification
(SRS)

y Defines the customer’s requirements in terms of :

y Function
y Performance
y External
E l iinterfaces
f
y Design constraints

y The SRS is the basis of contract between the

purchaser and supplier
 Specification Principles
y Separate functionality from implementation
y Develop model of desired behavior of the system
y Establish the context in which s/w operates
y Define the environment in which system operates
y Create a cognitive model
y Specifications must be tolerant of incompleteness &
augmentable
y Content & structure of a specifications should be
amenable to changeg
What is not included in an SRS ?
 Project requirements
y cost, delivery schedules, staffing, reporting
procedures
 Design solutions
y partitioning of SW into modules, choosing data
structures
 Product assurance plans
y Quality Assurance procedures, Configuration
Managementt procedures,
M d V ifi ti & V
Verification Validation
lid ti
procedures
Benefits of SRS
y Forces the users to consider their specific
requirements carefully
y Enhances communication between the
Purchaser and System
S developers
y Provides a firm foundation for the system
d i phase
design h
y Enables planning of validation, verification,
and acceptance procedures
y Enables project planning eg. estimates of
cost and time
time, resource scheduling
y Usable during maintenance phase
Types of Requirements
y Functional requirements
y Non functional requirements
y Performance requirements
y Interface
I t f requirements
i t
y Design constraints
y Other requirements
 Functional Requirements
y Transformations (inputs, processing, outputs)
y Requirements for sequencing and parallelism
(dynamic requirements)
y Data
D t
y Inputs and Outputs
y Stored data
y Transient data
y Exception handling
y Nature
N t off function:
f ti M d t / Desirable/
Mandatory/ D i bl / O
Optional
ti l/
Volatile / Stable
Performance Requirements
q
y Capacity
y no. of simultaneous users, processing requirements
for normal and peak loads, static storage capacity,
spare capacity
y Response
R ti
time
y System priorities for users and functions
y System efficiency
y Availability
y Fault recovery

All these requirements should be stated in

measurable terms so that they can be verified.
Verifiable
y A requirement is verifiable if and only if there
exists some finite cost effective process with
which a person or machine can check that the
SW meets the requirement
requirement.
E t
External
l IInterface
t f Requirements
R i t
y User interfaces
y eg. if display terminal used, specify required screen
formats, menus, report layouts, function keys
y Hardware interfaces
y characteristics of the interface between the SW
product and HW components of the system
y Software interfaces
y specify the use of other SW products eg. OS,
DBMS, other SW packages
Design Constraints
y SW design constraints
y standards for design,
g coding, g naming, g etc.
y SW interfaces (to OS, DBMS, other SW)
y use a specific application package
y constraints on program size
size, data size etc
etc.
y HW design constraints
y specific
p type
yp of HW, reliability
y requirements
q
y HW interfaces
y requirements for spare capacity or spare
performance
Design Constraints (contd)
y User-interface design constraints
y features of operator/user with details of working
environment
y any special features required
Other Requirements
y Security
y Safety
y Environmental
y Reusability
y Training
y ...
SRS Standards
y ANSI/IEEE SRS Standard 830-1984
y BS 6719: 1986
y European Space Agency Standards
(ESA PSS-05-0, Jan 1987)
y US DoD-Std-7935A
y ...
 SRS Prototype
yp Outline
[ IEEE SRS Standard ]

1. Introduction
1.1 Purpose
p
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Overview
 SRS - Introduction Section
y Purpose
y delineate the purpose of the particular SRS
y specify the intended audience for the SRS
y Scope
y identify
y the SW p
products to be p
produced byy name
y explain what the SW product will do, and if necessary,
what it will not do
y describe the application of the SW being specified
specified. ie
ie.
benefits, objectives, goals as precisely as possible
y Overview
y describe what the rest of the SRS contains
y how the SRS is organized
SRS P
Prototype
t t O
Outline
tli
[ IEEE SRS Standard ]

2 General description
2.
2.1 Product perspective
2 2 Product function summary
2.2
2.3 User characteristics
2 4 General constraints
2.4
2.5 Assumptions and dependencies
Product Perspective
y State whether the product is independent and
totally self contained
y If the product is component of a larger system
then:
y describe the functions of each component of the larger
system and identify interfaces
y overview of the principal external interfaces of this
product
y overview of HW and peripheral equipment to be used
y Give a block diagram showing the major
components of the product, interconnections, and
external interfaces.
Product Functions
y Provide a summary of functions the SW will
perform
f
y The functions should be organized in such a
way that they are understandable by the user

User Characteristics
C
y Describe
D ib th
the generall characteristics
h t i ti off th
the
eventual users of the product. (such as
educational level
level, experience and technical
expertise )
General Constraints
y Regulatory policies
y HW limitations
y Interfaces to other applications
y Parallel operation
y Audit functions
y Control functions
y Criticality
y of the application
pp
y Safety and security considerations
 SRS Prototype Outline
[ IEEE SRS Standard ]

3. Specific Requirements
- Functional requirements
- External
E l iinterface
f requirements
i
- Performance requirements
- Design constraints
- Attributes eg. security, availability,
maintainability, transferability/conversion
- Other requirements
Appendices
pp
Index
Functional Requirements
y Introduction
y describe purpose of the function and the
approaches and techniques employed
y Inputs and Outputs
y sources of inputs and destination of outputs
y quantities,
quantities units of measure
measure, ranges of valid inputs
and outputs
y timing
g
Functional Requirements
y Processing
y validation of input data
y exact sequence of operations
y responses to abnormal situations
y any methods (eg. equations, algorithms) to be used
to transform inputs to outputs
External Interface Requirements
y User interfaces
y Hardware
H d iinterfaces
t f
y Software interfaces
y Communications
C interfaces
f
y Other requirements
y database:
d t b f
frequency off use, accessing
i capabilities,
biliti
static and dynamic organization, retention requirements
for data
y operations: periods of interactive and unattended
operations, backup, recovery operations
y site
it adaptation
d t ti requirements
i t
Appendices
y Not always necessary
y It may include:
y sample I/O formats
y DFD,
DFD ERD d
documents
t
y results of user surveys, cost analysis studies
y supporting documents to help readers of SRS
Ch
Characteristics
t i ti off a Good
G d SRS
y Unambiguous
g
y Complete
y Verifiable
y Consistent
y Modifiable
y Traceable
y Usable during the Operation and
Maintenance phase
Examples of Requirements statements
y The data set will contain an end of Ambiguous
file character.
y The product should have a good Non-verifiable
human interface.
y The program shall never enter an Non-verifiable
infinite loop
loop.
y The output of the program shall  Non-verifiable
usually be given within 10 secs.
y The output of a program shall be  Verifiable
given within 20secs of event X 60%
of the time.
time
Examples of Bad SRS
D
Documents
t
y Unstructured
U t t d Specifications:
S ifi ti
y Narrative essay --- one of the worst types of
specification doc
document:
ment
y Difficult to change,
y difficult to be precise
precise,
y difficult to be unambiguous,
y scope for
f contradictions,
t di ti etc.
t
Examples of Bad SRS
D
Documents
t
y Noise:
y Presence of text containing information irrelevant to
the problem.
problem
y Silence:
y aspects important to proper solution of the problem
are omitted.
Examples of Bad SRS
D
Documents
t
y Overspecification:
y Addressing “how to” aspects
y For example, “Library member names should be stored
in a sorted descending order”
y Overspecification restricts the solution space for the
designer.
y Contradictions:
y Contradictions might arise
y if the same thing described at several places in different ways.
Examples of Bad SRS
Documents
y Ambiguity:
y Literary expressions
y Unquantifiable aspects, e.g. “good user interface”
y Forward References:
y References to aspects of problem
y defined only later on in the text
text.
y Wishful Thinking:
y Descriptions
p of aspects
p
y for which realistic solutions will be hard to find.
 Complete

y All significant requirements are included

y Definition of responses of the SW to all
realizable classes of input data in all situations.
y Conformity to a standard
y Full labeling and referencing of all figures,
tables etc. and definition of all terms and units
of measure
Verifiable
y A requirement is verifiable if and only if there
exists some finite cost effective process with
which a person or machine can check that the
SW meets the requirement
requirement.

Consistent
y No two requirements are in conflict
Modifiable
y Structure and style of SRS is such that
changes to requirements can be made easily,
completely and consistently.
y SRS organisation
i ti -- table
t bl off contents,
t t index,
i d
explicit cross-referencing
y no redundancy y
Traceable
y An SRS is traceable if the origin of each
requirement is clear and it facilitates the
referencing of each requirement in future.
y Backward traceability
y requirement explicitly referencing its source in
previous documents
p
y Foward traceability
y each requirement has a unique name or reference
number and it can be traced to design documents,
program implementation.
SRS Review
y Formal Review done by
y Users, Developers,
Managers, Operations personnel

y To verify that SRS confirms to the actual user

requirements

y To detect defects early and correct them.

y Review typically done using checklists.

 Sample SRS Checklist
y Are all HW resources defined ?
y Have response times been specfied for
functions ?
y Have all the HW, external SW and data
interfaces been defined ?
y Is each requirement testable ?
y Is the initial state of the system defined ?
y Are the responses to exceptional conditions
specified ?
y Are possible future modifications specified ?