Software Requirements

Specification

1
 What is a requirement?
 It may range from a high-level abstract
statement of a service (or a system quality-
constraint) to a detailed functional
specification.

 Requirements may serve dual function:

– May be the basis for a bid for a contract;
– May be the basis for the contract itself and therefore
must be defined in detail;

2
Software Requirements Specification: A Contract
Document
 Requirements document is a reference
document.
 SRS document is a contract between the
development team and the customer.
– Once the SRS document is approved by the
customer,
• any subsequent controversies are settled by
referring the SRS document.

3
SW Requirements Specification

 Purpose of SRS
– Interface (communication) between the
Customer, Analyst, designers, system
developers, testers, maintainers, ...
– agreement between Purchaser and Supplier
– firm foundation for the design phase
– support system testing activities
– support project management activities
– controlling the evolution of overall system
4
Users of a requirements
document
Specify the requirements and
System read them to check that they
customers meet their needs. T hey
specify changes to the
requirements

Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process

Use the requirements to

System
eng ineers understand what system is to
be developed

System test Use the requirements to

eng ineers develop validation tests for
the system

System Use the requirements to help

maintenance understand the system and
eng ineers the relationships between its
par ts

5
 Problems/Challenges of
requirements analysis
 Stakeholders don’t know exactly, that what they
really want.
 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting
requirements.
 Organisational and legal/political factors may
influence the system requirements.
 The requirements may change during the analysis
process. New stakeholders may emerge and the
business environment can also change.
6
 Example- ATM stakeholders
 Bank managers
 Bank customers
 Counter staff
 Database administrators
 Security managers
 Marketing department
 Hardware and software maintenance engineers
 Banking regulators
 Representatives of other banks
7
 SRS Document...
 The SRS document is known as black-box
specification:
– the system is considered as a black box whose
internal details are not known.
– only its (system’s) visible external (i.e.
input/output) behaviour is documented.
Input Data Output Data
S

8
 SRS Document...
 SRS document concentrates on:
– what needs to be done
– carefully avoids the solution (“how to do”)
aspects.
 The SRS document serves as a contract
– between development team and the customer.
– Should be carefully written

9
 SRS Document...
 The requirements at the first stage:
– written using end-user terminology.

– later a formal requirement specification

may be developed from it.

10
 Software Requirements
Specification (SRS)
 Defines the customer’s requirements in terms of :
– Functional (all required functions)
– Non functional:
Performance (efficiency, load etc.)
External interfaces
Design constraints
 Non-functional requirements, in some cases, may be more
critical than functional requirements. If these are not met, the
system may be useless.

11
 Functional and non-functional
requirements
 Functional requirements
– Statements of services/ functionalities, the system should
provide and how the system should behave in particular
situations.
– May also state what the system should not do.
 Non-functional requirements
– Quality Constraints on the services or functions offered by the
system such as timing constraints, constraints on the number
of users etc.
– Often apply to the system as a whole rather than
individual features or services.

12
 Functional Requirements
 Transformations (inputs, processing, outputs)
 Data
– Inputs and Outputs
– Stored data
 Nature of function: Mandatory/ Desirable/
Optional

17
 Performance Requirements
 Capacity
– no. of simultaneous users, processing
requirements for normal and peak loads,
storage capacity, spare capacity. (e.g.
bandwidth, os etc) (scalability) (Tool- e.g. -
Load Runner)
 Response time,
 System priorities for users (e.g. administrator
or simple user)
 System efficiency,
 Availability and Fault recovery,

18
Performance Requirements…
Best case, average case and worst case
analysis,
Dead lines / maximum limits
E.g. ATM, Defense applications, Medical
applications, any web based application
and RTS etc.
 All these requirements should be stated
in measurable terms so that they can be
verified.
19
External Interface Requirements
 User interfaces
– E.g. if display terminal used, specify required
screen formats, menus, report layouts, function
keys
 Hardware interfaces
– characteristics of the interface between the SW
product and HW components of the system
 Software interfaces
– specify the use (connectivity) of other SW
products eg. OS, DBMS, other SW packages
21
 Other Requirements
 Security requirements
 Safety requirements
 Environmental aspects
 Reusability
 Training
 …

24
 SRS Standards
 ANSI/IEEE SRS Standard 830-1984
 BS 6719: 1986
 European Space Agency Standards
(ESA PSS-05-0, Jan 1987)
 US DoD-Std-7935A
 ...

25
 SRS Prototype Outline
1. Introduction
2. General description
3. Specific Requirements
4. Appendices
Index

26
 SRS Prototype Outline…
[ IEEE SRS Standard ]

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Overview

27
 SRS Prototype Outline…
[ IEEE SRS Standard ]

2. General description
2.1 Product perspective
2.2 Product function summary
2.3 User characteristics
2.4 General constraints
2.5 Any Assumptions and dependencies

29
 Product Perspective
 State whether the product is independent and totally
self contained, or
 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. 30
 Product Functions
 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 )

31
 SRS Prototype Outline…
[ IEEE SRS Standard ]

3. Specific Requirements
- Functional requirements
- External interface requirements
- Performance requirements
- Design constraints
- Attributes eg. security, availability, maintainability.

- Other requirements
Appendices
Index
33
 Appendices
 Not always necessary
 It may include:
– sample I/O formats
– USE CASE Diagram, DFD, ERD documents
– results of user surveys, cost analysis studies
– supporting documents to help readers of SRS

38
Characteristics of a Good SRS
 It should be Unambiguous
 It should be Complete
 It should be Concise
 It should be Consistent
 It should be Traceable
 Usable till/during the Operation and
Maintenance phase etc.
 …
39
 Complete
 All significant requirements should be included.
 Definition of responses of the SW to all realizable
classes of input data in all situations.
 Full labeling and referencing of all figures, tables
etc. and definition of all terms and units of measure.

Consistent
 No two requirements are in conflict
 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
 Forward traceability: each requirement has a unique
name or reference number and it can be traced to
design documents, program implementation.
It should be properly reflected in your case study
also.
 Examples of Bad SRS
Documents
 Unstructured Specifications:
– Narrative essay --- one of the worst types of
specification document:
• Difficult to change,
• difficult to be precise,
• scope for contradictions, etc.

42
 Examples of Bad SRS
Documents…
 Noise:
– Presence of text containing information irrelevant to the
problem. (less imp things are given more emphasis)
 Silence:
– aspects important to proper solution of the problem are
omitted. (important things are not properly covered)

43
 Examples of Bad SRS
Documents…
 Overspecification:
– Addressing “how to” aspects
– For example, “Library member names should be
stored in a sorted descending order”
– Overspecification restricts the solution space for
the designer.
 Contradictions:
– Contradictions might arise
• if the same thing described at several places in
different ways.

44
 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.

47