Requirement

Elicitation and
Analysis
Learning goals

 Understand what requirements elicitation is and why its needed

 Understand the main activities of requirements elicitation
 Apply the main activities of requirements elicitation
 Understand the terms: problem statement and requirements
 Understand scenarios and use cases
Example-1

 Write a program that will read a list of 100

positive integers and display the average of those
values.
Example-2

 Writea program that will read the CGPA of

each student in a particular class. Based on
the CGPA assign students to CCM,DAB, and
other events happening every semester.
Example-3

 Assume that a bank maintains 2 kinds of Accounts for customers, one class called
as savings account and other class called as current account. The savings account
provides deposit, simple interest and withdrawal facilities. The current account
provides deposit, withdrawal facilities but no interest. Include necessary methods
in order to achieve the following tasks.

 a. Accept deposit from a customer and update the balance.

 b. Calculate simple interest & update the balance

 c. Permit withdrawal and update the balance.

 d. Display the balance for current account and savings account

Requirements Elicitation
Requirement?
Requirement?

 An essential thing

 A feature that the system/application must have.

 A constraint that must satisfy/accepted by the client

Requirement? (Contd..)

 An essential thing-An ATM card

 A feature that the system/application must have –Magnetic

tape/Chip

 A constraint that must satisfy/accepted by the client. –card

accepted by Machine
Requirement engineering

 Tasks /techniques/Process that led to an understanding and defining

the requirements of the system is called requirements engineering

 Includes two main activities

 Requirements Elicitation

 Requirements Analysis
Elicitation ?

 Means “to bring out, to evoke, to call forth”

 is a part of the requirements engineering process
 the process of discovering the requirements for a system by
communication with customers, system users
and others who have a stake in the system development” .-
 sometimes referred to as "requirement gathering".
 It is needed to know what the users really need.
Requirement Elicitation
 Requirements elicitation focuses on describing the purpose of the system.

 The client, the developers, and the users identify a problem area and define a
system that addresses the problem

 Such a definition is called a requirements specification and serves as a contract

between the client and the developers.

 The requirements specification is structured and formalized during analysis.

Source of requirements
Requirement Elicitation and Analysis
(Contd..)
Problem Statement

 Describes requirements, subsystem decomposition, and communication

infrastructure
 Describes the current situation, the functionality it should support, and
environment in which the system will be deployed
 Contains mutual understanding of the problem to be addressed by the system
 Its neither a precise nor complete specification but a high level summary of the
customer’s wishes
Requirements

 Requirements are textual descriptions of the desired functionality of the

system and its properties. They can be divided into two major categories
applying the acronym FURPS

Functional requirements: (F)

 A single function of a system or its component
 e.g. “A student can see all courses of the current semester in his major and
minor subject.”

Non-functional requirements (URPS):

 Aspects of the system that are not directly related to its functional behavior
 e.g. “interface look, response time, security issues”
Functional Requirements

 A functional requirement describes what a software system

should do

 Defines the external behavior of the system.

Examples of functional requirements

 FR1: Search for available courses: A student can see all courses of the current
semester in his major and minor subject. He is able to join the course which
saves it into his course list. He can also drop a course.
 FR2: Check course details: A student can see details about a course such as the
course times, the
location of the lecture hall on a map and other course attendees including their
name and picture.
 FR3: Update profile: A student can update his profile settings and his profile
picture. He can also change the notification settings.
 FR4: Add comments: A student can add comments about a course and thus
start a discussion.
Others can like the comment and write follow-up comments.
Non-Functional Requirements

 Defines the quality attributes or the constraints of the system.

 Some examples of quality attributes include security, performance,

availability.,

 Describes the aspects of the system that are not directly related to its
functional behavior.
Non-functional requirements

 Also called quality requirements and can be described by the acronym URPS
 Usability: human factors, aesthetics, consistency, documentation,
responsiveness
 Reliability: availability, failure frequency, robustness
 Performance: speed, efficiency, resource consumption
 Supportability: maintainability, testability, flexibility
Examples of non-functional requirements
 NFR1: The app should be intuitive to use and the user interface
should be easy to understand.
 All interactions should be completed in less than three clicks.
 NFR2: Conformance to guidelines: The design of the app should
conform to the usability Guidelines for the chosen operating system.
Constraints
 Also called pseudo requirements:
 Implementation: constraints on the implementation of the system, including the
use
of specific tools, programming languages, or hardware platforms.
 Interface: constraints imposed by external systems, including legacy systems and
interchange formats
 Operations: constraints on the administration and management of the system in
the
operational setting
 Packaging: constraints on the actual delivery of the system (e.g., constraints on
the
installation media for setting up the software).
 Legal: concerned with licensing, regulation, and certification issues
Activities during Requirements Elicitation (Contd..)

 Identifying actors: Identify the different types of users the future

system will support
 Identifying scenarios: Develop a set of detailed scenarios for typical
functionality provided by the future system
 Identifying use cases: Derived from scenarios a set of use cases that
completely represent the future system is created
Activities during Requirements Elicitation (Contd..)

 Refining use cases: Detailing each use case and describing the
behavior of the system in the presence of errors and exceptional
conditions
 Identifying relationships among use cases: Identify dependencies
among use cases found during “identifying use cases”
 Identifying nonfunctional requirements: Agree on aspects that are
visible to the user, but not directly related to functionality
Requirement Validation

 Completeness
 Consistency
 Clarity
 Correctness
Requirement specifications

 Realistic-if a system can be implemented within constraints

 Traceability- ability to trace

 Verifiable

 “The product shall respond to the user within 1 second for most cases”
Use Case Diagram
Thank You