© PHI Learning Private Limited
Fundamentals of
Software Engineering
FIFTH EDITION
RAJIB MALL
Professor
Department of Computer Science and Engineering
Indian Institute of Technology Kharagpur
© PHI Learning Private Limited
Requirements Specification
and Analysis II
© PHI Learning Private Limited
SRS Document (Contd.)
Four important parts:
G Functional requirements,
G External Interfaces
G Non-functional requirements,
G Constraints
© PHI Learning Private Limited
Functional Requirements
Specifies all the functionality that the system should
support
G Heart of the SRS document:
G Forms the bulk of the Document
Outputs for the given inputs and the relationship
between them
Must specify behavior for invalid inputs too!
© PHI Learning Private Limited
Functional Requirement Documentation
Overview
G describe purpose of the function and the approaches
and techniques employed
Inputs and Outputs
G sources of inputs and destination of outputs
G quantities, units of measure, ranges of valid inputs and
outputs
G timing
© PHI Learning Private Limited
Functional Requirement Documentation
Processing
G validation of input data
G exact sequence of operations
G responses to abnormal situations
G any methods (eg. equations, algorithms) to be used to
transform inputs to outputs
© PHI Learning Private Limited
Nonfunctional Requirements
Characteristics of the system which can not be expressed
as functions:
G Maintainability,
G Portability,
G Usability,
G Security,
G Safety, etc.
© PHI Learning Private Limited
Nonfunctional Requirements
Reliability issues
Performance issues:
G Example: How fast can the system produce results?
• At a rate that does not overload another system to
which it supplies data, etc.
• Response time should be less than 1sec 90% of the
time
• Needs to be measurable (verifiability)
© PHI Learning Private Limited
Constraints
Hardware to be used,
Operating system
G or DBMS to be used
Capabilities of I/O devices
Standards compliance
Data representations by the interfaced system
© PHI Learning Private Limited
User interfaces
Hardware interfaces
Software interfaces
Communications interfaces with other systems
File export formats
External
Interface
Requirements
© PHI Learning Private Limited
Goals of Implementation
Goals describe things that are desirable of the system:
G But, would not be checked for compliance.
G For example,
• Reusability issues
• Functionalities to be developed in future
© PHI Learning Private Limited
IEEE 830-1998 Standard for SRS
Title
Table of Contents •Describe purpose of the system
•Describe intended audience
1. Introduction
G 1.1 Purpose •What the system will and will not do
G 1.2 Scope
G 1.3 Definitions. Acronyms, •Define the vocabulary of the SRS (may also be in
appendix)
and Abbreviations
G 1.4 References •List all referenced documents and their sources SRS (may also be in appendix)
G 1.5 Overview
•Describe how the SRS is organized
2. Overall Description
3. Specific Requirements
Appendices
Index
© PHI Learning Private Limited
IEEE 830-1998 Standard – Section 2 of SRS
Title
•Present the business case and operational concept of the system
Table of Contents •Describe external interfaces: system, user, hardware, software, communication
•Describe constraints: memory, operational, site adaptation
1. Introduction
2. Overall Description
G 2.1 Product Perspective •Summarize the major functional capabilities
G 2.2 Product Functions
G 2.3 User Characteristics •Describe technical skills of each user class
G 2.4 Constraints
G 2.5 Assumptions and Dependencies
3. Specific Requirements •Describe other constraints that will limit
developer’s options; e.g., regulatory policies;
4. Appendices target platform, database, network,
development standards requirements
5. Index
© PHI Learning Private Limited
IEEE 830-1998 Standard – Section 3 of SRS (1)
…
1. Introduction Specify software requirements in sufficient
detail so that designers can design the system and
2. Overall Description testers can verify whether requirements met.
3. Specific Requirements
State requirements that are externally perceivable by
G 3.1 External Interfaces
users, operators, or externally connected systems
G 3.2 Functions Requirements should include, at the least, a
description of every input (stimulus) into the system,
G 3.3 Performance Requirements
every output (response) from the system, and all
G 3.4 Logical Databasefunctions
Requirements
performed by the system in response to an
input
G 3.5 Design Constraints
G 3.6 Software System Quality Attributes
G 3.7 Object Oriented Models
4. Appendices
5. Index
© PHI Learning Private Limited
IEEE 830-1998 Standard – Templates
Section 3 (Specific Requirements)can be organized in several
different ways based on
G Modes
G User classes
G Concepts (object/class)
G Features
G Stimuli
© PHI Learning Private Limited
Example Section 3 of SRS of
Academic Administration Software
SPECIFIC REQUIREMENTS
3.1 Functional Requirements
3.1.1 Subject Registration
G The subject registration requirements are concerned with
functions regarding subject registration which includes
students selecting, adding, dropping, and changing a subject.
F-001:
G The system shall allow a student to register a subject.
F-002:
G It shall allow a student to drop a course.
F-003:
G It shall support checking how many students have already
registered for a course.
© PHI Learning Private Limited
Design Constraints (3.2)
3.2 Design Constraints
C-001:
G AAS shall provide user interface through standard web
browsers.
C-002:
G AAS shall use an open source RDBMS such as Postgres
SQL.
C-003:
G AAS shall be developed using the JAVA programming
language
© PHI Learning Private Limited
Non-functional requirements
3.3 Non-Functional Requirements
N-001:
G AAS shall respond to query in less than 5 seconds.
N-002:
G AAS shall operate with zero down time.
N-003:
G AAS shall allow upto 100 users to remotely connect to
the system.
N-004:
G The system will be accompanied by a well-written user
manual.
© PHI Learning Private Limited
Functional Requirements
It is desirable to consider every system as:
G Performing a set of functions {fi}.
Each function fi considered as:
G Transforming a set of input data to corresponding
output data.
Input Output
Data
Data
fi
© PHI Learning Private Limited
Example: Functional Requirement
F1: Search Book
G Input: Author Book
Name Details
• an author’s name: f1
G Output:
• details of the author’s books and the locations of
these books in the library.
© PHI Learning Private Limited
Functional Requirements
Functional requirements describe:
G A set of high-level requirements
G Each high-level requirement:
• takes in some data from the user
• outputs some data to the user
G Each high-level requirement:
• might consist of a set of identifiable sub-functions
© PHI Learning Private Limited
Functional Requirements
For each high-level requirement:
G A function is described in terms of:
• Input data set
• Output data set
• Processing required to obtain the output data set
from the input data set.
© PHI Learning Private Limited
Is it a Functional Requirement?
A high-level function is one:
G Using which the user can get some useful piece of
work done.
Can the receipt printing work during withdrawal of
money from an ATM:
G Be called a functional requirement?
A high-level requirement typically involves:
G Accepting some data from the user,
G Transforming it to the required response, and then
G Outputting the system response to the user.
© PHI Learning Private Limited
Use Cases
A use case is a term in UML:
G Represents a high level functional requirement.
Use case representation is more well-defined and has
agreed documentation:
G Compared to a high-level functional requirement and
its documentation
G Therefore many organizations document the functional
requirements in terms of use cases
© PHI Learning Private Limited
Example Functional Requirements
Req. 1:
G Once user selects the “search” option,
• he is asked to enter the key words.
G The system should output details of all books
• whose title or author name matches any of the key
words entered.
• Details include: Title, Author Name, Publisher
name, Year of Publication, ISBN Number, Catalog
Number, Location in the Library.
© PHI Learning Private Limited
Example Functional Requirements
Req. 2:
G When the “renew” option is selected,
• The user is asked to enter his membership number
and password.
G After password validation,
• The list of the books borrowed by him are
displayed.
G The user can renew any of the books:
• By clicking in the corresponding renew box.
© PHI Learning Private Limited
High-Level Function: A Closer View
A high-level function:
G Usually involves a series of interactions between the
system and one or more users.
Even for the same high-level function,
G There can be different interaction sequences (or
scenarios)
G Due to users selecting different options or entering
different data items.
© PHI Learning Private Limited
Examples of Bad SRS Documents
Unstructured Specifications:
G Narrative essay — one of the worst types of
specification document:
• Difficult to change,
• Difficult to be precise,
• Difficult to be unambiguous,
• Scope for contradictions, etc.
© PHI Learning Private Limited
Examples of Bad SRS Documents
Noise:
G Presence of text containing information irrelevant to
the problem.
Silence:
G Aspects important to proper solution of the problem
are omitted.
© PHI Learning Private Limited
Examples of Bad SRS Documents
Overspecification:
G Addressing “how to” aspects
G For example, “Library member names should be stored
in a sorted descending order”
G Overspecification restricts the solution space for the
designer.
Contradictions:
G Contradictions might arise
• if the same thing described at several places in
different ways.
© PHI Learning Private Limited
Examples of Bad SRS Documents
Ambiguity:
G Literary expressions
G Unquantifiable aspects, e.g. “good user interface”
Forward References:
G References to aspects of problem
• defined only later on in the text.
Wishful Thinking:
G Descriptions of aspects
• for which realistic solutions will be hard to find.
© PHI Learning Private Limited
Examples of Bad SRS Documents
Ambiguity:
G Literary expressions
G Unquantifiable aspects, e.g. “good user interface”
Forward References:
G References to aspects of problem
• defined only later on in the text.
Wishful Thinking:
G Descriptions of aspects
• for which realistic solutions will be hard to find.
© PHI Learning Private Limited
Suggestions for Writing Good Quality Requirements
Keep sentences and paragraphs short.
Use active voice.
Use proper grammar, spelling, and punctuation.
Use terms consistently and define them in a glossary.
To see if a requirement statement is sufficiently well
defined,
G Read it from the developer’s perspective
© PHI Learning Private Limited
Suggestions for Writing Good Quality Requirements
Split a requirement into multiple sub-requirements:
G Because each will require separate test cases and
because each should be separately traceable.
G If several requirements are strung together in a
paragraph, it is easy to overlook one during
construction or testing.
© PHI Learning Private Limited
SRS Review
needs
Review done by the Developers
along with the user representatives. Gathering
To verify that SRS confirms to the Analysis
actual user requirements
Specification
To detect defects early and correct them.
Review typically done using standard Review
inspection process:
SRS Document
G Checklists.
© PHI Learning Private Limited
A Sample SRS Checklist
Have response times been specified 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 ?
© PHI Learning Private Limited