CHAPTER-THREE

Requirement Elicitation

SE Lecture Note 10/16/2023

 Outlines

 Requirement elicitation

 Requirement validations

 Types of requirements

 Functional requirement
 Non-functional requirement

 Analysis concepts, activities and models

 Identifying actors, scenarios, use cases,

SE Lecture Note 10/16/2023

 Introduction
A requirement: is a feature that the system must have or a constraint that it
must satisfy to be accepted by the client.
Requirements engineering: is the process of identifying stakeholders and
their needs, modeling and documenting them.
Requirements engineering includes two main activities:-
 Requirements elicitation: is the process of discovering specification of
the system that the client understands .
 Requirement Analysis: which results into an analysis model that the
developers can unambiguously interpret the requirement.

SE Lecture Note 10/16/2023

 Software Lifecycle Activities

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By

class...
class...
class... ?
class....?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Cases
Objects

SE Lecture Note 10/16/2023

 Requirements 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 system specification and serves as a contract
between the client and the developers.
 The system specification is structured and formalized during analysis to
produce an analysis model.
 Both system specification and analysis model represent the same information.

SE Lecture Note 10/16/2023

Cont…
 They differ only in the language and notation they use.
 The system specification is written in natural language, where as the analysis model is
usually expressed in a formal or semiformal notation.
 The system specification supports the communication with the client and users.
 The analysis model supports the communication among developers.
 Requirements elicitation and analysis focus only on the user’s view of the system:-
 The system functionality.
 The interaction between the user and the system.
 The errors that the system can detect and handle.

SE Lecture Note 10/16/2023

 :problem
statement

Requirements Requirements
elicitation Specification

:nonfunctional
requirements

:functional
model

Analysis Analysis Model

:dynamic model

UML Activity Diagram :analysis object

model
 Elicitation Techniques

Observation:
 To understand the activity, task, tools used, and events performed by others.
Questionnaires:
 an incredible method to find solutions to questions you can’t answer by yourself.
Interviewing:
 To Talk with stakeholders who you think can give essential knowledge into the
requirements
Brainstorming:
 To generate new ideas and find a solution for a specific issue
Prototyping:
 Valuable device for business analysts to decide whether the solution being created is
actually what the stakeholder’s demand
Document analysis:
 Extremely valuable requirements elicitation method which is generally utilized in the IT
industry.
SE Lecture Note 10/16/2023
 Technique Good for Kind of data Plus Minus

Questionnaires Answering specific Quantitative and Can reach many people with The design is crucial.
questions qualitative data low resource Response rate may be
low. Responses may not
be what you want
Interviews Exploring issues Some quantitative Interviewer can guide Time consuming.
but mostly interviewee. Encourages Artificial environment
qualitative data contact between developers may intimidate
and users interviewee

Focus groups Collecting multiple Some quantitative Highlights areas of Possibility of dominant
and workshops viewpoints but mostly consensus and conflict. characters
qualitative data Encourages contact between
developers and users

Naturalistic Understanding context Qualitative Observing actual work gives Very time consuming.
observation of user activity insight that other techniques Huge amounts of data
cannot give
Studying Learning about Quantitative No time commitment from Day-to-day work will
documentation procedures, regulations, users required differ from documented
and standards procedures

SE Lecture Note 10/16/2023

 Requirement validation

 Involves checking if the specification is correct, complete, consistent, unambiguous, and

realistic.
 It is a quality assurance step, usually performed after requirements elicitation or after analysis
 Correctness : A specification is correct if it represents the client’s view of the system.
 Completeness: all possible scenarios through the system are described.
 Consistency: the system specification is consistent if it does not contradict itself.
 Clarity: there are no ambiguities in the requirements.
 Realism: requirements can be implemented and delivered.
 Traceability: Each system function can be traced to a corresponding set of functional
requirements.

SE Lecture Note 10/16/2023

Cont…

 As the definition of the system matures and stabilizes, developers and the client
agree on a system specification in the form of use cases.
 Depending on the source of the requirements, requirements elicitation activities

can be classified into three:

 Greenfield engineering - the development starts from scratch, no prior system exists.

 A reengineering project- redesign and reimplementation of an existing system.

 An interface engineering project- redesign of the user interface of an existing system.

SE Lecture Note 10/16/2023

Cont…

 Guidelines of requirement elicitation :

 Assess the business and technical feasibility for the proposed system
 Indentify the people who will help to specify requirements
 Define the technical environments(computing architecture, OS,
telecommunication needs, etc)
 Identify domain constrains that limit the functionality or performance of
the system or product.
 Define one or more requirement elicitation methods(Interviewing,
observation, etc)

SE Lecture Note 10/16/2023

Cont…

Define requirements from different point of views, be sure to identify the

rational for each requirements that is recorded
Identify ambiguous requirements
Create user scenarios to help customers/users to identify key requirements
Identify the customers, users or other stockholders who participate in the
system

SE Lecture Note 10/16/2023

Cont…

 Requirements elicitation includes the following activities:-

 Identifying actors- During this activity, developers identify the different
types of users the future system will support.
 Identifying scenarios- developers observe users and develop a set of

detailed scenarios for typical functionality provided by the future system.

 Identifying use cases- Once developers and users agree on a set of

scenarios, developers derive from the scenarios a set of use cases that
completely represent the future system.

SE Lecture Note 10/16/2023

Cont…

Refining use cases- developers ensure that the system specification is

complete, by detailing each use case and describing the behaviour of the
system in the presence of errors and exceptional conditions.
Identifying relationships among use cases- developers consolidate the use
case model by eliminating redundancies. This ensures that the system
specification is consistent.
Identifying non-functional requirements- developers, users, and clients
agree on aspects that are visible to the user but not directly related to
functionality.

SE Lecture Note 10/16/2023

 Type of Requirements
Functional requirements:
 describe the interactions between the system and its environment.
 The environment includes the user and any other external system that
interact with the system.
 Describe user tasks that the system needs to support
 Example: the following is an example of functional requirements
Example # 1
A user shall be able to log into the system using their username and
password.
In this example, the function is “login” and the behavior is “The system
shall allow a user to login using their username and password.”
SE Lecture Note 10/16/2023
Cont…
Example # 2
The system shall calculate the sales tax for the user’s purchase.
In this example, the function is “calculate sales tax” and the behavior is
“The system shall calculate the sales tax by multiplying the purchase
price by the tax rate.”

SE Lecture Note 10/16/2023

 Cont…
Non-functional requirements:
user visible aspects of the system not directly related to functional behavior.
It includes quantitative constrains such as response time, accuracy etc.
 The response time must be less than 1 second
 The accuracy must be within a second
 The system should be available 24 hours of a day
 Example of non-functional requirements for SatWatch is:
 The battery life of SatWatch is limited to 5 years.

SE Lecture Note 10/16/2023

 Types of Nonfunctional Requirements

Quality requirements Constraints or Pseudo requirements

 Usability  Implementation
 Reliability  Interface
 Robustness
 Operation
 Safety
 Performance  Packaging
 Response time  Legal
 Scalability
 Throughput
 Licensing
 Availability
 Certification
 Supportability  Regulation
 Adaptability
 Maintainability
SE Lecture Note 10/16/2023
 Functional Vs Non-Functional Requirements

Parameters Functional Requirement Non-Functional Requirement

Requirement It is mandatory It is non-mandatory
Capturing type It is captured in the use case. It is captured as a quality attribute.
End-result Product feature Product properties
Helps you verify the functionality of the Helps you to verify the performance
Objective
software. of the software.
Concentrates on the user's
Area of focus Focuses on user requirement
expectation and experience.
Documentation Describe what the product does Describes how the product works

SE Lecture Note 10/16/2023

 Requirements elicitation activities
 Requirements elicitation activities include:-
Identifying actors
Identifying scenarios
Identifying use cases
Identifying relationships among use cases
Identifying participating objects
Identifying non-functional requirements

SE Lecture Note 10/16/2023

 Cont…

 Identifying actors
 Actors represent external entities that interact with the system.
 An actor can be human or an external system.

 In the SatWatch example;

 The watch owner
 The GPS satellites , and
 The Wi-Fi watch serial device are actors.

SE Lecture Note 10/16/2023

Cont…
 Fig-1: Actors for SatWatch system

They all have specific interactions

with the SatWatch:
The watch owner wears and
looks at her watch;
The watch monitors the signal
from the GPS satellites;
The Wi-Fi Watch downloads new
data into the watch.

SE Lecture Note 10/16/2023

Cont…
 Example-2:Consider a distributed information system for fire accident
management.
 It includes many actors, such as:-
 Field Officer- who represents the police

 Fire officers -who are responding to an incident.

 Dispatcher- the police officer responsible for answering 911 calls and
dispatching resources to an incident.

SE Lecture Note 10/16/2023

Cont…
 When identifying actors, developers can ask the following questions:
Which user groups are supported by the system to perform their work?
Which user groups execute the system’s main functions?
Will the system interact with any external hardware or software system?
Which user groups perform secondary functions, such as maintenance
and administration?

SE Lecture Note 10/16/2023

Cont…
 Identifying scenarios
 A scenario is a concrete, focused, informal description of a single feature of
the system from the viewpoint of a single actor.
A narrative description of what people do and experience as they
try to make use of computer systems and applications
 Example of scenario for the Distributed information system for incident
response.
 In this scenario, a police officer reports a fire and a Dispatcher initiates the
incident response.

SE Lecture Note 10/16/2023

Cont…
Scenario name warehouseOnFire
Participating actor instances Bob, Alice: Field Officer John: Dispatcher

Flow of events 1. Bob, driving down main street in his patrol car notices
smoke coming out of a warehouse. His partner, Alice,
activates the “Report Emergency” function from her
FRIEND laptop.
2. Alice enters the address of the building, a brief
description of its location...
3. John, the Dispatcher, is alerted to the emergency by a
beep of his workstation...
4. Alice receives the acknowledgment.

SE Lecture Note 10/16/2023

Cont…
 Scenarios can have many different uses during requirements elicitation and during
other activities of the life cycle.
As-is scenario:
 Used in describing a current situation. Usually used in re-engineering projects. The user
describes the system.
Visionary scenario:
 Used to describe a future system.
 Usually used in greenfield engineering and reengineering projects.
 Can often not be done by the user or developer alone
Evaluation scenario:
 User tasks against which the system is to be evaluated.
Training scenario:
 Step by step instructions that guide a novice user through a 10/16/2023
SE Lecture Note
system
Cont…

 Questions for identifying scenarios

What are the tasks that the actor wants the system to perform?
What information does the actor access? Who creates that 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?

SE Lecture Note 10/16/2023

Cont…
 Developers use existing documents about the application domain to answer these
questions.
 These documents include:-
 User manuals of previous systems,
 Procedures manuals,
 Company standards, user notes,
 User and client interviews.
 The emphasis of actor identification and scenario identification is for developers to:
 Understand the application domain and
 To define the right system.
 Once developers identified and described actors and scenarios, developers formalize
scenarios into use cases.
SE Lecture Note 10/16/2023
Cont…

 Identifying use cases

 A scenario is an instance of a use case, that is, a use case specifies all

possible scenarios for a given piece of functionality.

 A use case is initiated by an actor.
 After its initiation, a use case may interact with other actors as well.
 The following description depicts the use case ReportEmergency of

which the scenario warehouseOnFire is an instance.

SE Lecture Note 10/16/2023

Cont…
Use case name ReportEmergency
Participating actor FieldOfficer and Dispatcher.
Flow of events 1. The FieldOfficer activates the “Report Emergency” function of her
terminal.
2. FRIEND responds by presenting a form to the officer.
3. The FieldOfficer fills the form...
4. The Dispatcher is notified....
5. The Dispacher fill in the incident database and allocate resources...
6. The Dispatcher sends acknowledgment to the
FieldOfficer.

Exit condition The FieldOfficer receives the acknowledgment and the selected
response.

SE Lecture Note 10/16/2023

Cont…
 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
To increase its understand ability.
 We use communication relationships between actors and use cases to
describe the system in layers of functionality.
 We use extend relationships to separate exceptional and common flows of
events.
 We use include relationships to reduce redundancy among use cases.

SE Lecture Note 10/16/2023

Cont…
 Communication relationships between actors and use cases
 Communication relationships between actors and use cases represent the flow of
information during the use case.
 The relationships between actors and use cases are identified when use cases
are identified.

SE Lecture Note 10/16/2023

Cont…

 Extend relationships between use cases

 An extend relationship indicates that an instance of an extended use case

may include (under certain conditions) the behaviour specified by the

extending use case.

 Fig 4: Example of use of extend relationship (UML use case diagram).

SE Lecture Note 10/16/2023
Cont…
 ConnectionDown extends the OpenIncident and AllocateResources use cases.
 In the textual representation of a use case, we represent extend relationships as entry
conditions of the extending use case.

Use case name ConnectionDown

Participating actor FieldOfficer and Dispatcher.
Entry condition This use case extends the OpenIncident and
the AllocateResources use cases. It is initiated
by the system whenever the network
connection between the FieldOfficer and
Dispatcher is lost.
Flow of events ….

SE Lecture Note 10/16/2023

Cont…
 Include relationships between use cases
 Redundancies among use cases can be factored out using include
relationships.

 Fig 5: Example of include relationships among use cases.

SE Lecture Note 10/16/2023
Cont…

 ViewMap describes the flow of events for viewing a city map (e.g.,
scrolling, zooming, query by street name)
 It is used by both OpenIncident and AllocateResources use cases.
 Generalization relationships
 Generalization/specialization relationships are a third mechanism for

reducing the complexity of a model.

SE Lecture Note 10/16/2023

Cont…
Fig 6:An example of a generalization relationship (UML use case diagram).

 The Authenticate use case is a high-level use case describing, in general terms, the process of
authentication.
 AuthenticateWithPassword and AuthenticateWithCard are two specializations of Authenticate.
SE Lecture Note 10/16/2023
Cont…

 Identifying participating objects

 During requirements elicitation, participating objects are generated for each
use case.
 For example, here is the initial participating objects identified for the
ReportEmergency use case:-
 Dispatcher - Police officer who manages Incidents.

 EmergencyReport - Initial report about an Incident from a FieldOfficer to a

Dispatcher.
 FieldOfficer - Police or fire officer on duty.

 Incident Situation - requiring attention from a FieldOfficer.

SE Lecture Note 10/16/2023

Cont…

 Identifying non-functional requirements

 Non-functional requirements describe user-visible aspects of the system that are

not directly related to the functional behaviour of the system.

 Non-functional requirements can be elicited by investigating the following

issues:
 User interface and human factors: what kind of interface should the
system provide?
 Hardware considerations: are there hardware compatibility requirements?
• Will the system interact with other hardware systems?

SE Lecture Note 10/16/2023

Cont…
 System modifications: What is the anticipated scope of future changes?
 Who will perform the changes?

 Performance characteristics: How responsive should the system be?

 How many concurrent users should it support?

 Error handling and extreme conditions: How should the system handle
exceptions?
 Quality issues: How reliable /available /robust should the system be?

 Security issues: Should the system be protected against external intrusions or

against malicious users?
 To what level?

SE Lecture Note 10/16/2023

 Cont… Chapter-Four

SE Lecture Note 10/16/2023