Software Requirements Specification

Software Requirements Specification: A Contract

Document

Requirements document is a reference

document.
SRS document is a contract between the
Software Requirements development team and the customer.
Specification – Once the SRS document is approved by the
customer,
• any subsequent controversies are settled by
referring the SRS document.

1 2

SW Requirements Specification SRS Document (CONT.)

The SRS document is known as black-box
Purpose of SRS specification:
– communication between the Customer, Analyst, – the system is considered as a black box whose
system developers, maintainers, ... internal details are not known.
– contract between Purchaser and Supplier – only its visible external (i.e. input/output) behavior
– firm foundation for the design phase is documented.
– support system testing activities Input Data Output Data
– support project management and control S
– controlling the evolution of the system

3 4

SRS Document (CONT.) SRS Document (CONT.)

SRS document concentrates on: The requirements at this stage:
– what needs to be done – written using end-user terminology.
– carefully avoids the solution (“how to do”)
aspects.
If necessary:
– later a formal requirement specification
The SRS document serves as a contract
may be developed from it.
– between development team and the customer.
– Should be carefully written

5 6

1
 Software Requirements Specification

Specification Principles
Software Requirements
Specification (SRS) Separate functionality from implementation
Develop model of desired behavior of the system
Defines the customer’s requirements in terms of : Establish the context in which s/w operates
– Function Define the environment in which system operates
– Performance Create a cognitive model
– External interfaces Specifications must be tolerant of incompleteness
– Design constraints & augmentable
Content & structure of a specifications should be
The SRS is the basis of contract between the amenable to change
purchaser and supplier
7 8

What is not included in an SRS ? Benefits of SRS

Project requirements Forces the users to consider their specific
– cost, delivery schedules, staffing, reporting requirements carefully
procedures Enhances communication between the Purchaser
and System developers
Design solutions
Provides a firm foundation for the system design
– partitioning of SW into modules, choosing data
phase
structures
Enables planning of validation, verification, and
Product assurance plans acceptance procedures
– Quality Assurance procedures, Configuration Enables project planning eg. estimates of cost and
Management procedures, Verification & time, resource scheduling
Validation procedures
Usable during maintenance phase
9 10

Functional Requirements
Types of Requirements
Transformations (inputs, processing, outputs)
Functional requirements Requirements for sequencing and parallelism
Non functional requirements (dynamic requirements)
– Performance requirements Data
– Interface requirements – Inputs and Outputs
– Design constraints – Stored data
– Transient data
– Other requirements
Exception handling
Nature of function: Mandatory/ Desirable/
Optional / Volatile / Stable
11 12

2
 Software Requirements Specification

Performance Requirements
Capacity Verifiable
– no. of simultaneous users, processing
requirements for normal and peak loads, static A requirement is verifiable if and only if
storage capacity, spare capacity there exists some finite cost effective
Response time process with which a person or machine can
System priorities for users and functions check that the SW meets the requirement.
System efficiency
Availability
Fault recovery

All these requirements should be stated in

measurable terms so that they can be verified. 13 14

Design Constraints
External Interface Requirements
SW design constraints
User interfaces – standards for design, coding, naming, etc.
– eg. if display terminal used, specify required – SW interfaces (to OS, DBMS, other SW)
screen formats, menus, report layouts, function – use a specific application package
keys – constraints on program size, data size etc.
Hardware interfaces HW design constraints
– characteristics of the interface between the SW – specific type of HW, reliability requirements
product and HW components of the system – HW interfaces
Software interfaces – requirements for spare capacity or spare
performance
– specify the use of other SW products eg. OS,
DBMS, other SW packages
15 16

Design Constraints (contd) Other Requirements

User-interface design constraints Security
– features of operator/user with details of Safety
working environment
Environmental
– any special features required
Reusability
Training
...

17 18

3
 Software Requirements Specification

SRS Prototype Outline

SRS Standards
[ IEEE SRS Standard ]
ANSI/IEEE SRS Standard 830-1984
BS 6719: 1986 1. Introduction
1.1 Purpose
European Space Agency Standards
1.2 Scope
(ESA PSS-05-0, Jan 1987)
1.3 Definitions, Acronyms and Abbreviations
US DoD-Std-7935A 1.4 References
... 1.5 Overview

19 20

SRS - Introduction Section

Purpose
SRS Prototype Outline
– delineate the purpose of the particular SRS
[ IEEE SRS Standard ]
– specify the intended audience for the SRS
Scope 2. General description
– identify the SW products to be produced by name
2.1 Product perspective
– explain what the SW product will do, and if
necessary, what it will not do 2.2 Product function summary
– describe the application of the SW being specified. ie. 2.3 User characteristics
benefits, objectives, goals as precisely as possible 2.4 General constraints
Overview 2.5 Assumptions and dependencies
– describe what the rest of the SRS contains
– how the SRS is organized
21 22

Product Perspective Product Functions

State whether the product is independent and totally
self contained
If the product is component of a larger system then:
– describe the functions of each component of the
larger system and identify interfaces
– overview of the principal external interfaces of this
product
– overview of HW and peripheral equipment to be
used
Give a block diagram showing the major components
of the product, interconnections, and external
interfaces.
Provide a summary of functions the SW will
perform
The functions should be organized in such a way
that they are understandable by the user
User Characteristics
Describe the general characteristics of the eventual
users of the product. (such as educational level,
experience and technical expertise )
23 24

4
 Software Requirements Specification

SRS Prototype Outline

General Constraints [ IEEE SRS Standard ]

Regulatory policies 3. Specific Requirements

HW limitations - Functional requirements
- External interface requirements
Interfaces to other applications
- Performance requirements
Parallel operation - Design constraints
Audit functions - Attributes eg. security, availability,
Control functions maintainability, transferability/conversion
Criticality of the application - Other requirements
Safety and security considerations Appendices
Index
25 26

Functional Requirements
Functional Requirements
Introduction
– describe purpose of the function and the Processing
approaches and techniques employed – validation of input data
Inputs and Outputs – exact sequence of operations
– sources of inputs and destination of outputs – responses to abnormal situations
– quantities, units of measure, ranges of valid – any methods (eg. equations, algorithms) to be
inputs and outputs used to transform inputs to outputs
– timing

27 28

External Interface Requirements

Appendices
User interfaces
Hardware interfaces
Not always necessary
Software interfaces
It may include:
Communications interfaces
– sample I/O formats
Other requirements
– DFD, ERD documents
– database: frequency of use, accessing capabilities,
static and dynamic organization, retention – results of user surveys, cost analysis studies
requirements for data – supporting documents to help readers of SRS
– operations: periods of interactive and unattended
operations, backup, recovery operations
– site adaptation requirements 29 30

5
 Software Requirements Specification

Characteristics of a Good SRS Examples of Requirements statements

Unambiguous The data set will contain an end of Ambiguous
file character.
Complete Non-verifiable
The product should have a good
Verifiable human interface.
The program shall never enter an Non-verifiable
Consistent
infinite loop.
Modifiable The output of the program shall Non-verifiable
Traceable usually be given within 10 secs.
The output of a program shall be Verifiable
Usable during the Operation and given within 20secs of event X 60%
Maintenance phase of the time.

31 32

Examples of Bad SRS Examples of Bad SRS

Documents Documents
Unstructured Specifications: Noise:
– Narrative essay --- one of the worst types of – Presence of text containing information irrelevant to the
specification document: problem.
• Difficult to change, Silence:
• difficult to be precise, – aspects important to proper solution of the problem are
omitted.
• difficult to be unambiguous,
• scope for contradictions, etc.

33 34

Examples of Bad SRS Examples of Bad SRS

Documents Documents
Overspecification: Ambiguity:
– Addressing “how to” aspects – Literary expressions
– For example, “Library member names should be – Unquantifiable aspects, e.g. “good user
stored in a sorted descending order” interface”
– Overspecification restricts the solution space for the Forward References:
designer. – References to aspects of problem
Contradictions: • defined only later on in the text.
– Contradictions might arise Wishful Thinking:
• if the same thing described at several places in different – Descriptions of aspects
ways.
• for which realistic solutions will be hard to find.
35 36

6
 Software Requirements Specification
Complete
All significant requirements are included
Definition of responses of the SW to all realizable
classes of input data in all situations.
Conformity to a standard
Full labeling and referencing of all figures, tables
etc. and definition of all terms and units of measure
37
Modifiable
Structure and style of SRS is such that changes to
requirements can be made easily, completely and
consistently.
– SRS organisation -- table of contents, index,
explicit cross-referencing
– no redundancy
39
SRS Review
Formal Review done by Users, Developers,
Managers, Operations personnel
To verify that SRS confirms to the actual
user requirements
To detect defects early and correct them.
Review typically done using checklists.
41
Verifiable
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.
Consistent
No two requirements are in conflict
38
Traceable
An SRS is traceable if the origin of each
requirement is clear and it facilitates the
referencing of each requirement in future.
Backward traceability
– requirement explicitly referencing its source in
previous documents
Foward traceability
– each requirement has a unique name or
reference number and it can be traced to design
documents, program implementation.
40
Sample SRS Checklist
Are all HW resources defined ?
Have response times been specfied for functions ?
Have all the HW, external SW and data interfaces
been defined ?
Is each requirement testable ?
Is the initial state of the system defined ?
Are the responses to exceptional conditions
specified ?
Are possible future modifications specified ?
42