Requirements

Specification and Analysis

II

1
 SRS Document (CONT.)

• Four important parts:

– Functional requirements,

– External Interfaces

– Non-functional requirements,

– Constraints
 Functional Requirements
• Specifies all the functionality that the system
should support
– Heart of the SRS document:

– Forms the bulk of the Document

• Outputs for the given inputs and the

relationship between them

• Must specify behavior for invalid inputs too!

 Functional Requirement
Documentation
• Overview
– describe purpose of the function and the
approaches and techniques employed
• Inputs and Outputs
– sources of inputs and destination of outputs
– quantities, units of measure, ranges of valid
inputs and outputs
– timing
 Functional Requirement
Documentation
• Processing
– validation of input data
– exact sequence of operations
– responses to abnormal situations
– any methods (eg. equations, algorithms)
to be used to transform inputs to outputs
 Nonfunctional Requirements
• Characteristics of the system which can not be
expressed as functions:
•Maintainability,
•Portability,
•Usability,
•Security,
•Safety, etc.
 Nonfunctional Requirements
• Reliability issues
• Performance issues:
– 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)
 Constraints
• Hardware to be used,
• Operating system
– or DBMS to be used

• Capabilities of I/O devices

• Standards compliance
• Data representations by the interfaced
system
• User interfaces External Interface
Requirements
• Hardware interfaces
• Software interfaces
• Communications interfaces
with other systems
• File export formats
 Goals of Implementation
• Goals describe things that are desirable
of the system:
– But, would not be checked for compliance.
– For example,
•Reusability issues
•Functionalities to be developed in future
• Title
IEEE 830-1998 Standard for SRS
• Table of Contents •Describe purpose of the system
•Describe intended audience

• 1. Introduction
– 1.1 Purpose •What the system will and will not do

– 1.2 Scope
•Define the vocabulary of the SRS (may also be in
– 1.3 Definitions. Acronyms, and appendix)
Abbreviations
– 1.4 References •List all referenced documents and their sources SRS (may also be in appendix)

– 1.5 Overview
• 2. Overall Description •Describe how the SRS is organized

• 3. Specific Requirements
• Appendices
• Index
 IEEE 830-1998 Standard – Section 2 of
• Title SRS
• Table of Contents •Present the business case and operational concept of the system
•Describe external interfaces: system, user, hardware, software, communication
• 1. Introduction •Describe constraints: memory, operational, site adaptation

• 2. Overall Description
– 2.1 Product Perspective •Summarize the major functional capabilities

– 2.2 Product Functions

– 2.3 User Characteristics •Describe technical skills of each user class

– 2.4 Constraints
– 2.5 Assumptions and Dependencies
•Describe other constraints that will limit
developer’s options; e.g., regulatory policies;
• 3. Specific Requirements target platform, database, network,
development standards requirements
• 4. Appendices
• 5. Index
 IEEE 830-1998 Standard – Section 3 of SRS (1)
• …
• 1. Introduction Specify software requirements in sufficient
• 2. Overall Description detail so that designers can design the system and
testers can verify whether requirements met.
• 3. Specific Requirements
– 3.1 External Interfaces State requirements that are externally perceivable by
users, operators, or externally connected systems
– 3.2 Functions
Requirements should include, at the least, a
– 3.3 Performance Requirements
description of every input (stimulus) into the system,
every output (response) from the system, and all
– 3.4 Logical Database Requirements
functions performed by the system in response to an
input
– 3.5 Design Constraints
– 3.6 Software System Quality Attributes
– 3.7 Object Oriented Models
• 4. Appendices
• 5. Index
 IEEE 830-1998 Standard – Templates

• Section 3 (Specific Requirements)can be

organized in several different ways based on
– Modes
– User classes
– Concepts (object/class)
– Features
– Stimuli
 Example Section 3 of SRS of
• SPECIFIC REQUIREMENTS Academic Administration
3.1 Functional Requirements
Software
3.1.1 Subject Registration
– The subject registration requirements are concerned with
functions regarding subject registration which includes students
selecting, adding, dropping, and changing a subject.
• F-001:
– The system shall allow a student to register a subject.
• F-002:
– It shall allow a student to drop a course.
• F-003:
– It shall support checking how many students have already
registered for a course.
 Design Constraints (3.2)
• 3.2 Design Constraints
• C-001:
– AAS shall provide user interface through standard web
browsers.
• C-002:
– AAS shall use an open source RDBMS such as Postgres SQL.
• C-003:
– AAS shall be developed using the JAVA programming
language

16
 Non-functional requirements
• 3.3 Non-Functional Requirements
• N-001:
– AAS shall respond to query in less than 5 seconds.
• N-002:
– AAS shall operate with zero down time.
• N-003:
– AAS shall allow upto 100 users to remotely connect to
the system.
• N-004:
– The system will be accompanied by a well-written user
manual.
 Functional Requirements
• It is desirable to consider every system as:
– Performing a set of functions {fi}.
• Each function fi considered as:
– Transforming a set of input data to
corresponding output data.

Input Output
Data fi Data
 Example: Functional
Requirement
• F1: Search Book
Author Book
– Input: Name f1 Details

• an author’s name:
– Output:
•details of the author’s books and the
locations of these books in the library.
 Functional Requirements
• Functional requirements describe:
– A set of high-level requirements
– Each high-level requirement:
• takes in some data from the user
• outputs some data to the user
– Each high-level requirement:
• might consist of a set of identifiable sub-functions
 Functional Requirements
•For each high-level requirement:
– 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.
 Is it a Functional Requirement?
• A high-level function is one:
– Using which the user can get some useful
piece of work done.
• Can the receipt printing work during withdrawal
of money from an ATM:
– Be called a functional requirement?
• A high-level requirement typically involves:
– Accepting some data from the user,
– Transforming it to the required response, and
then
– Outputting the system response to the user.
 Use Cases
• A use case is a term in UML:
– Represents a high level functional
requirement.
• Use case representation is more
well-defined and has agreed
documentation:
– Compared to a high-level functional requirement
and its documentation
– Therefore many organizations document the
 Example Functional
• Req. 1: Requirements
– Once user selects the “search” option,
•he is asked to enter the key words.
– 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.
 Example Functional
• Req. 2: Requirements
– When the “renew” option is selected,
• The user is asked to enter his membership number and
password.
– After password validation,
• The list of the books borrowed by him are displayed.
– The user can renew any of the books:
• By clicking in the corresponding renew box.
 High-Level Function: A Closer View
• A high-level function:
– Usually involves a series of interactions between
the system and one or more users.
• Even for the same high-level function,
– There can be different interaction sequences (or
scenarios)
– Due to users selecting different options or
entering different data items.
 Examples of Bad SRS Documents
• Unstructured Specifications:
– 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.
 Examples of Bad SRS
Documents
• Noise:
– Presence of text containing information
irrelevant to the problem.

• Silence:
– Aspects important to proper solution of the
problem are omitted.
 Examples of Bad SRS
• Overspecification: Documents
– 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.
 Examples of Bad SRS Documents
• Ambiguity:
– Literary expressions
– Unquantifiable aspects, e.g. “good user interface”
• Forward References:
– References to aspects of problem
• defined only later on in the text.
• Wishful Thinking:
– Descriptions of aspects
• for which realistic solutions will be hard to find.
 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,
– Read it from the developer’s perspective
 Suggestions for Writing Good Quality
Requirements

• Split a requirement into multiple

sub-requirements:
– Because each will require separate test
cases and because each should be
separately traceable.
– If several requirements are strung together
in a paragraph, it is easy to overlook one
during construction or testing.
 SRS Review
need
• Review done by the Developers s

along with the user representatives. Gathering

• To verify that SRS confirms to the Analysis

Specificati
actual user requirements on

• To detect defects early and correct Review

them. SRS
Document

• Review typically done using standard

inspection process:
– Checklists.
 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 ?
Thank You!!