CHAPTER 3

Software Requirements and Specification

(SRS)

1
 Objectives
The objective of this chapter is to introduce software requirements and
to discuss the processes involved in discovering and documenting
these requirements. When you have read the chapter you will:

• understand the concepts of user and system requirements and why these requirements should be
written in different ways;
• understand the differences between functional and nonfunctional software requirements;
• understand how requirements may be organized in a software requirements document;
• understand the principal requirements engineering activities of elicitation, analysis and
validation, and the relationships between these activities;
• understand why requirements management is necessary and how it supports other requirements
engineering activities.
2
 CONTENTS
 Introduction
 An overview of requirements elicitation
 Requirements Analysis concepts
 Requirements elicitation concepts
 functional ,nonfunctional , pseudo requirements and design constraints
 correctness, completeness, consistency, clarity, and realism
 verifiability and traceability
 Requirements elicitation activities
 identifying actors ,scenarios ,use cases and relationships b/n use cases
 Managing requirements elicitation
3
• The requirements for a system are the descriptions of what
the system should do the services that it provides and the
constraints on its operation. These requirements reflect the
needs of customers for a system that serves a certain
purpose such as controlling a device, placing an order, or
finding information.
• The process of finding out, analyzing, documenting and
checking these services and constraints is called
requirements engineering (RE).
4
• Requirements specification is the process of writing down
the user and system requirements in a requirements
document.
• the user and system requirements should be clear,
unambiguous, easy to understand, complete, and
consistent.

5
 User requirements and system
requirements may be defined as follows:
1. User requirements are statements, in a natural language plus
diagrams, of what services the system is expected to provide to
system users and the constraints under which it must operate.
2. System requirements are more detailed descriptions of the
software system’s functions, services, and operational
constraints. The system requirements document (sometimes
called a functional specification) should define exactly what is to
be implemented. It may be part of the contract between the
system buyer and the software developers.
6
Example

7
 INTRODUCTION

A requirement
 is a feature the system must have or a constraint that must satisfy to be accepted
by the client.
 are the descriptions of the services provided by a system and its operational
constraints
 It is about WHAT not HOW
Requirement Engineering (RE)
 The process of discovering stakeholders (users) needs, and documenting these in a
form that is amenable to analysis, communication, and subsequent implementation.
 Concerned with the specification of the functions and constraints of a software
system.
 Represents a series of decisions that lead from recognition of a problem to be solved
8
to a detailed specification of the problem.
 REQUIREMENT ENGINEERING … CONT’D

 Spans the gap between the informal world of stakeholders needs and the formal
world of software behavior.
 Involves understanding and interpreting stakeholder terminology, concepts,
viewpoints, and goals.
RE involves:
• Understanding the difficulties people may have in describing their needs (cognitive
psychology).
• Observing human activities that helps to develop a richer understanding of how
computer systems may help or hinder those activities (anthropology).
• Understanding the political and cultural changes caused by computerization
(sociology).
• Communication skills (Linguistics). 9
10
 The Requirement Engineering
Process
• The process of establishing what services are required and the constraints on
the system’s operation and development
• Requirements engineering help software engineers to better understand the
problem they will work to solve. It encompasses the set of tasks that lead to
an understanding of what the business impact of the software will be, what
the customer wants and how end-users will interact with the software.

• Requirement Engineering Process

• Feasibility Study
• Requirements elicitation and analysis
• Requirements Specification
• Requirements Validation 11
The Requirements Engineering
Process
Require ments
Feasibility
elicitation and
study
analy sis
Require ments
specification

Feasibility Require ments

report validation

System
models
User and system
requirements

Require ments
document

12
 REQUIREMENT ENGINEERING … CONT’D

Establishing what the

customer requires from a
software system
What is it
13
 REQUIREMENT ENGINEERING … CONT’D

RE activities:
I. Requirement Elicitation
II. Requirement Analysis

14
 Requirements Analysis & Specification
Definitions
Requirements Analysis
 The process of studying and analyzing the customer and the user/stakeholder needs to
arrive at a definition of software requirements.1
Analyzing requirements: determining whether the stated requirements are unclear,
incomplete, ambiguous, or contradictory, and then resolving these issues
Requirements Specification
 A document that clearly and precisely describes, each of the essential requirements of
the software and the external interfaces.
• (functions, performance, design constraint, and quality attributes)
 Each requirement is defined in such a way that its achievement is capable of being
objectively verified by a prescribed method; for example inspection, demonstration,
analysis, or test. 15
 Requirements Analysis

• Requirements Analysis, determining whether the

stated requirements are clear, complete,
consistent and unambiguous.

16
 Requirements Analysis
• Stakeholder Identification
• Stakeholders are people or organizations that have a
valid interest in the system. They may be affected by it
directly or indirectly.
• Stake holders may include:
• Anyone who operates the system
• Anyone who benefits from the system
• Anyone involved in purchasing or procuring the system
• People opposed to the system (negative stakeholders)
• Organizations responsible for the system
17
• Stakeholder Interviews
• Interviews are a common technique used in requirement analysis.
• This technique can serve as a means of obtaining the highly
focused knowledge from different stakeholders perspectives

18
 Requirements Analysis
• Types of Requirements:
• Customer Requirements:
• Operational distribution or deployment: Where will the system
be used?
• Mission profile or scenario: How will the system accomplish
its mission objective?
• Performance and related parameters: What are the critical
system parameters to accomplish the mission?
• Utilization environments: how are the various system
components to be used?
• Effectiveness requirements: How effective or efficient must
the system be in performing its mission?
• Operational life cycle: How long will the system be in use by
the user?
• Environment: what environments will the system be expected
to operate in an effective manner? 19
 Requirements Analysis
• Types of Requirements:
Architectural Requirements:
• A formal description and representation of a system,
organized in a way that support reasoning about the
structure of the system which comprises system
components, the externally visible properties of
those components, the relationships and the
behavior between them, and provides a plan from
which products can be procured and systems
developed, that will work together to implement the
overall system.
20
 Requirements Analysis
• Types of Requirements:
• Functional Requirements:
• Defines functions of a software system or its
components. They may be calculations,
technical details, data manipulation and
processing and other specific functionality
that define “what a system is supposed to
accomplish?”
• They describe particular results of a system.
• Functional requirements are supported by 21
Non-functional requirements.
 Requirements Analysis
• Types of Requirements:
• Non-Functional Requirements:
• They are requirements that specify criteria that can be used
to judge the operation of a system, rather than specific
behavior.
• Functional requirements define what the system is supposed
to do, whereas non-functional requirements define how a
system is supposed to be.
• Non-functional requirements can be divided into two main
categories:
• Execution qualities, such as security and usability, which are
observable at runtime.
• Evolution qualities, such as testability, maintainability and 22
scalability.
Example: Cont…
Problem statement
• Idea: A Library Management System should be
designed. Information on books, CDs, DVDs,
Journals, etc. can be stored and retrieved.
• Possible Requirements: Functional Req.
• Searching by Title, Author, and/or ISDN should be possible
• User Interface should be web-based (accessible via WWW
Browser)
Implementation req.
• At least 20 transactions per seconds should be possible
• All services should be available within 10 minutesPerformance req.
Availability req.
• Users have no access to personal data of other users Problem
Statement 23

Security req.
 Requirements Specifications
• Requirements Specification is the direct result of a
requirement analysis and can refer to:
• Software Requirements Specification
• Hardware Requirements Specification

24
 Requirements Specifications
• A Software Requirements Specification (SRS) –is a
complete description of the behavior of a system to be
developed.
• It includes a set of use cases that describe all the
interactions the users will have with the software. In
addition to use cases, the SRS also contains non-
functional requirements (such as performance
requirements, quality standards, or design constraints)
25
 Requirements Specifications
• A Software Requirements Specification (SRS)
• The software requirement specification document enlists all necessary requirements
for project development. To derive the requirements we need to have clear and
thorough understanding of the products to be developed.
• A general organization of an SRS is as follows:
• Introduction
• Purpose, Scope, Definitions, System Overview, References
• Overall Description
• Product Perspective, Product functions, User characteristics, constraints,
assumptions and dependencies.
• Specific Requirements
• External Interface requirements, functional requirements, performance requirements,
design constraints, logical database requirement, software system attributes.

26
 Requirements Validation and
Verification
• Validation (& Verification), is the process of checking
whether the requirements, as identified, do not contradict
the expectations about the system of various stakeholders
and do not contradict each other.
• It is Requirements Quality Control

27
 Validation Vs. Verification
• Validation: “Am I building the right product?” checking a
work product against higher-level work products or
authorities that frame this particular product.
• Requirements are validated by stakeholders

• Verification: “Am I building the product right?” checking a

work product against some standards and conditions imposed
on this type of product and the process of its development.
• Requirements are verified by the analysts mainly
28
 Requirements management
• Requirements management is the process of managing
changing requirements during the requirements
engineering process and system development
• Requirements are inevitably incomplete and inconsistent
• New requirements emerge during the process as business needs
change and a better understanding of the system is developed
• Different viewpoints have different requirements and these are
often contradictory

29
 Requirements change

• The priority of requirements from different viewpoints

changes during the development process
• System customers may specify requirements from a
business perspective that conflict with end-user
requirements
• The business and technical environment of the system
changes during its development

30
31
 REQUIREMENT ELICITATION

Requirement Elicitation
Eliciting requirements: the task of communicating with
customers and users to determine what their requirements are.
sometimes also called requirements gathering.
Focuses on describing the purpose of the system
Results in the specification of the system that the client
understands
Tries to find out what problem needs to be solved and hence
identify system boundary. 32

The identification of stakeholders and user classes, goals and

 Requirements Elicitation
• It is the practice of obtaining the requirements of a system from
users, customers and other stakeholders. The practice is also
sometimes referred to as Requirement gathering.
• Requirements elicitation practice include the following:
• Interviews
• Questionnaires
• User observation
• Workshops
• Brain storming
• Use cases
• Role playing
• And prototyping 33
 Requirements Elicitation
• Problems of Requirement Elicitation
• Problems of scope: The boundary of system is ill-defined. Or
unnecessary details are provided.
• Problems of understanding: The users are not sure of what they
need, and don’t have full understanding of the problem domain.
• Problems of volatility: the requirements change overtime.

34
 Problems of requirements
elicitation
• Stakeholders don’t know what they really want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system
requirements.
• The requirements change during the analysis process. New
stakeholders may emerge and the business environment
change.

35
 REQUIREMENT ELICITATION … CONT’D

Elicitation Techniques
 Analysts can employ several techniques to elicit the requirements from the customer
 The choice of elicitation technique depends on time and resource available and the kind of
information that needs to be elicited.
 Traditional technique (generic data gathering)
• Use of questionnaires and surveys
• Interviews
• Analysis of existing documentation (organizational charts, process models,
standards, manuals of existing systems, etc.)
 Group elicitation technique
• focus groups (requirements workshops) and creating requirements
lists. 36

• brainstorming
 Elicitation Techniques… CONT’D

• Prototyping
• When there is a great deal of uncertainty about the requirements or when
early feedback from stakeholders is needed
• Can also be combined with other techniques. For example, using a prototype
to provoke discussion in a group elicitation technique.
• Model-driven
• Provide a specific model of the type of information to be gathered and use
this model to drive the elicitation process. These include goal-based methods
and scenario-based methods.
• Cognitive techniques
• Includes different techniques originally developed for knowledge acquisition
for knowledge-based systems. 37
 Elicitation Techniques… CONT’D

Generally there are different  Helpdesk and support team

source of requirements  Trainers and consultants
including:  Customer suggestions and
 interviews complaints
 Workshops  Improvements made by users
 Experiencing life as a user  Unintended uses of products
 Observing users at work  Comparable and rival products
 Acting out what needs to happen  Existing designs and specifications
 Prototypes  Badly written contracts
 Problem reports 38
 Gathering requirements from
stakeholders---

What is a stakeholder?
 A stakeholder is someone who has a justifiable claim to be allowed to
influence the requirements. Users are nearly always stakeholders. Other
stakeholders may include:
 People whose lives are affected by the system, such as clients and
suppliers
 Managers who are concerned for the system to succeed, although
they do not use it as such;
 Regulators such as local and state governments and standards bodies,
which are concerned about the effects the system may have in its
environment. 39
 REQUIREMENT ELICITATION … CONT’D

We focus on three methods for eliciting information and making

decisions with users and clients
Joint Application Design (JAD) focuses on building consensus
among developers, users, and clients by jointly developing the
system specification.
Knowledge Analysis of Tasks (KAT) focuses on eliciting
information from users through observation.
Usability testing focuses on validating the requirements elicitation
model with the user through a variety of methods 40
 Requirements elicitation concepts

Requirements Elicitation involves the identification of:

Functional requirements
Services the system should provide
What the system should do or not in reaction to particular
situations
Describe the interactions between the system and its environment
(e.g., user, external system) independent of its implementation.
Represented using use cases
41
 CONT’D

Non-functional requirements
 Describe user-visible aspects of the system that are not directly
related with the functional behavior of the system.
 Constraints on the services or functions offered by the system
 Include safety, performance, speed(response time), accuracy,
frequency, throughput.
 Generally termed as quality attributes
 Nonfunctional requirements can be elicited by investigating the
following issues.
42
 CONT’D

 User interface and human factors. What kind of interface should the system
provide? What is the level of expertise of the users?
 Documentation. What level of document is required? Should only user documentation
be provided? Should there be technical documentation for maintainers? Should the
development process be documented?
 Hardware considerations. Are there hardware compatibility requirements? Will the
system interact with other hardware systems?
 Performance characteristics. How responsive should the system be? How many
concurrent users should it support? What is a typical or extreme load?
 Error handling and extreme conditions. How should the system handle exceptions?
Which exceptions should the system handle? What is the worse environment in which
the system is expected to perform? Are there safety requirements on the system? 43
 CONT’D

 User interface and human factors. What kind of interface should the system provide?
What is the level of expertise of the users?
 Quality issues. How reliable/available/robust should the system be? What is the client’s
involvement in assessing the quality of the system or the development process?
 System modifications. What is the anticipated scope of future changes? Who will
perform the changes?
 Physical environment. Where will the system be deployed? Are there external factors
such as weather conditions that the system should withstand?
 Security issues. Should the system be protected against external intrusions or against
malicious users? To what level?
 Resource issues. What are the constraints on the resources consumed by the system?
44
 Requirements elicitation concepts… CONT’D

Pseudo requirements
 Requirements imposed by the client that restrict the implementation of the
system (e.g., language, platform)
“all related software associated with satwatch ,including the onboard
software , will be written using java ,to comply with current company
policy”
Design constraints
 Requirements are usually about “what”, this(Design constraints) is a “how”.
 Requirements elicitation results in the system specification. A system
specification document is prepared using actors, scenarios, and use cases.
45
 Requirements elicitation concepts… CONT’D

 Issues in a specification document: Characteristics of a Good Requirement

• Correctness, completeness, consistency, unambiguous, realistic, verifiability,
traceability
Correctness
• if every requirement included in the SRS represents something required in the
final system.
• If it represents the client’s view of the system
• Ensures that what is specified is done correctly
Completeness
• If everything the software is supposed to do is specified in the SRS.
• Ensures that everything is indeed specified 46
 Requirements elicitation concepts… CONT’D

Unambiguous
• If and only if every requirement stated has one and only one
interpretation
Consistency
• If there is no requirement that conflicts with another.
Inconsistency can be a reflection of some major problems.
Realistic
• If the SRS can be implemented within constraints (i.e., the
model describes a reality that can exist) 47
 Requirements elicitation concepts… CONT’D

Verifiability
The system specification is verifiable if, once the system is built, a repeatable
test can be designed to demonstrate that the system fulfills the requirement.
If and only if every stated requirement is verifiable (i.e., requirements should
have as little subjectivity(personal vision) as possible since subjective
requirements are difficult to verify).
• Example:
• Response time should be good.
• System must be able to process all the transactions quickly.
• Transaction should be processed in less than one second 98% of the
time
48
 Requirements elicitation concepts… CONT’D

Traceability
• Traceability is concerned with the relationships between
requirements, their sources and the system design
• If the origin of each of its requirements is clear and if it
facilitates the referencing of each requirement in future
development.
• Facilitates verification and validation
• Both direction - forward/backward
49
 FAQs

Reasons for project failure

 the ultimate causes for software projects failure is not getting requirements
right.
 Even if projects do not actually fail, lack of control is felt as budgets and
timescales expand while functionality is lost.
• Reasons for project failure
― Incomplete requirements 13.1 %
― Didn't involve users 12.4%
― Insufficient resources/schedule 10.6%
― Unrealistic expectations 9.9%
― Lack of managerial support 9.3%
50
 FAQs

Why do requirements matter? What are requirements for?

 Requirements are crucial to every project  To show what results stakeholders want
 Every project succeeds or fails on the
 To give stakeholders a chance to say
quality of its requirements.
what they want
 Requirements set the scope of all
subsequent work and tell the project team  To represent different viewpoints
what the users want.  To check the design
 Without good requirements, projects fail,
are late, come in over budget, or produce
 To measure progress
systems that are never used..  To accept products against precise
 Requirement issues should be fixed early, criteria
before design. 51
 Greenfield engineering, reengineering, and
interface engineering
Requirements elicitation activities can be classified into three categories, depending on
the source of the requirements.
 Greenfield engineering: the development starts from scratch, no prior system exists,
the requirements are extracted from the users and the client. A greenfield engineering
project is triggered by a user need or the creation of a new market.
 Re-engineering: project is the redesign and reimplementation of an existing system
triggered by technology enablers or by new information flow Sometimes, the
functionality of the new system is extended; however, the essential purpose of the
system remains the same. The requirements of the new system are extracted from an
existing system.
 Interface engineering: project is the redesign of the user interface of an existing
system. The legacy system is left untouched except for its interface, which is
52
redesigned and re-implemented.
 Requirements elicitation activities

Elicitation activities:
• Identifying actors
• Identifying scenarios
• Identifying use cases
• Identifying relationships among use cases
• Identifying non-functional requirements(contraints)

53
 Requirements elicitation activities… CONT’D

• Actors
• Represent external entities that interact with the system
• An actor can be human or external system
• Different actors interact through different interfaces
• Actors are role abstractions and do not necessarily directly map to
persons
• Serve both to define system boundaries and to find all the
perspectives from which the developers need to consider the
system
54
 Requirements elicitation activities… CONT’D

• Questions to identify actors

• Which user groups are supported by the system to perform their
work?
• Which user groups execute the system’s main function?
• Which user groups perform secondary functions such as
maintenance and administration?
• Will the system interact with any external hardware/software
system?
• After listing the potential actors, consolidate the list into a small 55
number of actors.
 Requirements elicitation activities… CONT’D

• An actor models an external entity which communicates with the system:

• User
• External system
• Physical environment
• An actor has a unique name and an optional description.
• Examples:
Passenger
• Passenger: A person in the train
• GPS satellite: Provides the system with GPS coordinates
• The use case model is the set of all use cases. It is a complete description
of the functionality of the system and its environment 56
 Requirements elicitation activities… CONT’D

• The next task is to determine the functionality that is accessible

to each actor. ……. Scenarios
Scenario
• A narrative description of what people do and experience as
they try to make use of computer systems and applications
• A concrete, focused, informal description of a single feature
of the system used by a single actor.
• Scenarios can have many different uses during the software
lifecycle
57
 Types of scenario

• As-is scenario
• Used in describing a current situation.
• E.g., during re-engineering the current system is understood by observing users
and describing their actions as scenarios.
• Visionary scenario
• describe a future system, either re-engineered or designed from scratch.
• Used both as a design representation and a communication medium
• Evaluation scenario
• Describes user tasks against which the system is to be evaluated
• Training scenario
• Step by step instructions designed to guide a novice user through a system 58
 Requirements elicitation activities… CONT’D

Questions for identifying scenarios

 What are the tasks that the actor wants the system to perform?
 What information does the actor access? who creates the data?
can it be modified or removed by whom?
 Which external changes does the actor need to inform the
system about? how often? when?
 Which events does the actor need to be informed by the
system about? With what latency?
59
Identifying relationships among actors and use cases

• Relationships among actors and use cases enable the developers and users to
reduce the complexity of the model and increase its understandability.
• Use case association = relationship between use cases
• Important types:
• Extends
A use case extends another use case
• Include
A use case uses another use case (“functional decomposition”)
• Generalization
An abstract use case has different specializations 60
 Extend relationships between use
cases

 A use case extends another use case if the extended use case may include the
behavior of the extension under certain conditions.
 Separating exceptional and optional flow of events from the base use case has
two advantages.
 First, the base use case becomes shorter and easier to understand.
 Second, the common case is distinguished from the exceptional case, which
enables the developers to treat each type of functionality differently (e.g.,
optimize the common case for response time, optimize the exceptional case
for clarity).
 Both the extended use case and the extensions are complete use cases of their
own. They must have an entry and an end condition and be understandable by
61
the user as an independent whole.
Extend relationships between use
cases

62
 <<Include>>: Functional Decomposition

• Problem:
• A function in the original problem statement is too complex to be
solvable immediately
• Solution:
• Describe the function as the aggregation of a set of simpler
functions. The associated use case is decomposed into smaller use
cases

63
 <<Include>>: Reuse of Existing
Functionality
• Problem:
• There are already existing functions. How can we
reuse them?
• Solution:
• The include association from a use case A to a
use case B indicates that an instance of the use
case A performs all the behavior described in the
use case B (“A delegates to B”)
• Example:
• The use case “View Map” describes behavior that
can be used by the use case “Open Incident”
(“View Map” is factored out)
• Note: The base case cannot exist alone. It is
always called with the supplier use case 64
 Generalization association in use cases

• Problem:
• You have common behavior among use cases and
want to factor this out.
• Solution:
• The generalization association among use cases
factors out common behavior. The child use cases
inherit the behavior and meaning of the parent use
case and add or override some behavior.
• Example:
• Consider the use case “ValidateUser”, responsible for
verifying the identity of the user. The customer might
require two realizations: “CheckPassword” and
“CheckFingerprint” 65
THANKS…!!

66