CHAPTER THREE

REQUIREMENT ELICITATION

04/17/2021 By Aschalew 1
 1.An over view requirement elicitation
 Requirements elicitation is the practice of collecting the
requirements of a system from users, customers and other
stakeholders.
 The practice is also sometimes referred to as "requirement
gathering".
 Requirements elicitation is non-trivial because you can
never be sure you get all requirements from the user and
customer by just asking them what the system should do.
 Requirements elicitation practices include interviews,
questionnaires, user observation,
workshops, brainstorming, use cases, role playing
and prototyping.
04/17/2021 By Aschalew 2
 Cont’
 Before requirements can be analyzed, modeled, or
specified they must be gathered through an elicitation
process.
 Requirements elicitation is a part of the requirements
engineering process, usually followed by analysis and
specification of the requirements.
 Commonly used elicitation processes are the
stakeholder meetings or interviews.

04/17/2021 By Aschalew 3
04/17/2021 By Aschalew 4
 2.Requirements Elicitation Concepts

Topics
2.1. Functional requirements
2.2. Nonfunctional requirements
2.3.Correcteness,completeness,consistency,clarity,&
realism
2.4. Verifiability and tractability

04/17/2021 By Aschalew 5
 2.1 Functional requirements

 Functional requirement describe the things that the

system must DO. 
 Describe the interactions between the system and its
environment independent of its implementation.
 The environment includes the user and any other
external system with which the system interacts.
 Features and capability

04/17/2021 By Aschalew 6
 Cont’

Functional requirement example:

• Create, modify and maintain account
• Login in to the system
• Record patient information
• Display(view) patient information and clinic data’s
• Update patient information and clinic data’s
• Post programs(schedule), announcement and information
• Generate various report
• Search patient information.
• Log out from system.

04/17/2021 By Aschalew 7
 2.2 Non functional requirements

Nonfunctional requirements describe aspects of the system that are
not directly related to the
functional behavior of the system.

Unlike functional requirements.

categories of nonfunctional requirements:
–Usability
–Reliability/Dependability
•Safety
•Security
•Survivability

04/17/2021 By Aschalew 8
 Cont’
– Performance
• Response Time
• Availability
• Accuracy
– Supportability
• Adaptability
• Maintainability
• Portability
FURPS +Additional sub categories like:

04/17/2021 By Aschalew 9
 FURPS +
 Implementation requirements:
-Including the use of specific tools, programming languages,
or hardware platforms.
 Interface requirements:
-Constraints imposed by external systems, including legacy
systems and interchange formats.
 Operations requirements:
-Operational setting.
 Packaging requirements:
-Constraints on the installation media for setting up the
software
 Legal requirements:
-concerned
04/17/2021 with licensing, regulation,
By Aschalew and certification issues.
10
 2.3.Correcteness,completeness,consistency
clarity,& realism
• Completeness
– All possible scenarios through the system are described, including exceptions
• Consistency
– There are no contradicting requirements
• Clarity/Unambiguity
– The specification can only be interpreted one way
• Correctness
– if it represents accurately the system that the client needs and that the
developers intend to build
• Realism
– The system can be implemented within constraints
2.4. Verifiability and tractability
• Verifiability
– Tests can be designed to demonstrate the system fulfills its requirements
• Traceability
– Requirements can be traced to system functions
– System functions can be traced to requirements
– Dependencies among requirements, system functions, and everything else in between can be
tracked.
04/17/2021 By Aschalew 11
 3. Requirements Elicitation Activities

Topics :
• Identifying Actors
• Identifying Scenarios
• Identifying Use Cases
• Refining Use Cases
• Identifying Relationships Among Actors and Use Cases
• Identifying Initial Analysis Objects
• Identifying Nonfunctional Requirements

04/17/2021 By Aschalew 12
 Identifying Actors
Actors – person or machine using the system in a particular role
Actors usually correspond to existing roles within the client
organization
Related roles can be grouped together according to viewpoints
Questions for identifying actors:-
Which user groups are supported by the system to perform their
work?
Which user groups execute the system’s main functions?
Which user groups perform secondary functions, such as
maintenance and administration?
With what external hardware or software system will the system
interact?

04/17/2021 By Aschalew 13
 Identifying Scenarios
 Scenario
– “A narrative description of what people do and
experience as they try to make use of computer systems
and applications”
– Informal description of a single feature from the
viewpoint of a single actor
 Types of Scenarios
– As-is scenarios – describes current situation
– Visionary scenarios – describes future system
– Evaluation scenarios – describes user tasks for evaluating
the system (acceptance criteria)
– Training scenarios – introduces new users to the system
04/17/2021 By Aschalew 14
 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 system need to inform the
actor about? With what latency?

04/17/2021 By Aschalew 15
 Identifying Use Cases
 Use Case
– Specifies all possible scenarios for a given functionality
– Initiated by an actor
 Motivations for use cases
– Generalizing related scenarios help developers define the
scope of the system
– The role of each user of the system is clarified
 Use Case Descriptions
– Entry and exit conditions
– Flow of events
– Quality requirement
04/17/2021 By Aschalew 16
 Cont’
 Writing Guide
– Choose proper name – use verb phrases; indicate user’s
objective
– Name actors with noun phrases
– Clearly distinguish actors’ actions from system’s actions
– Use active voice to phrase steps in flow of events
– The causal relationship between steps should be clear
– Describe complete user transaction
– Describe exceptions separately
– Use cases should not exceed 2-3 pages – break up using
<<include>> and <<extends>> relationships
04/17/2021 By Aschalew 17
 Refining Use Cases
 Goal: completeness and correctness
 Refining use case descriptions leads to other use
cases and clarifies system boundaries
– Entry and exit conditions – additional use cases are
identified as entry and exit conditions are refined
– Flow of events – discussing flow of events clarifies
system boundaries
– Quality requirements – elicit nonfunctional requirements
in the context of this particular functionality
 Refinements
– Details of objects in the system
– Low-level interactions between actors and system
– Access rights
– Missing exceptions
– Common functionality among
04/17/2021 By Aschalew
use cases 18
 Relationships Between Actors and Use Cases
 Relationships between actors and use cases
– <<initiate>>
– <<participate>>
– Determines access rights
• Who can initiate a functionality
• Who else is involved in this functionality
 Relationships between use cases
– Heuristics for making use cases shorter and simpler to understand
– <<include>>
• For factoring out common functionality
• Explicitly invoked from the including use case
– <<extend>>
• For specifying exceptions
• Entry conditions of the extending use case determine when it is
used
– Caveat: use discretion when applying these decompositions (a few
longer use cases are sometimes easier to understand than many
short ones)
04/17/2021 By Aschalew 19
04/17/2021 By Aschalew 20
 <<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

04/17/2021 By Aschalew 21
 <<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 “ViewMap” describes behavior that can be used by
the use case “OpenIncident” (“ViewMap” is factored out)

04/17/2021 By Aschalew 22
 <Extend>> Association for Use Cases
• Problem:
– The functionality in the original problem statement needs to be extended.
• Solution:
– An extend association from a use case A to a use case B indicates that use case B is an
extension of use case A.
• Example:
– The use case “ReportEmergency” is complete by itself , but can be extended by the use
case “ConnectionDown”

04/17/2021 By Aschalew 23
04/17/2021 By Aschalew 24
04/17/2021 By Aschalew 25
04/17/2021 By Aschalew 26
04/17/2021 By Aschalew 27
04/17/2021 By Aschalew 28
04/17/2021 By Aschalew 29
04/17/2021 By Aschalew 30
04/17/2021 By Aschalew 31
 Managing Requirements Elicitation

Topics
 Negotiating specifications
 Maintaining traceability
 Requirements validation

04/17/2021 By Aschalew 32
04/17/2021 By Aschalew 33
04/17/2021 By Aschalew 34
04/17/2021 By Aschalew 35
04/17/2021 By Aschalew 36
04/17/2021 By Aschalew 37
04/17/2021 By Aschalew 38