CHAPTER THREE

REQUIREMENT ELICITATION

OOSE
REQUIREMENT ELICITATION 1
OVER VIEWS
 Requirements elicitation is the process of
gathering and defining the requirements for a
software system.
 It’s goal is to ensure that the software
development process is based on a clear and
comprehensive understanding of the customer’s
needs and requirements.
 Requirements elicitation involves the
identification, collection, analysis, and refinement
of the requirements for a software system.
 Focuses on describing the purpose of the system.

OOSE
REQUIREMENT ELICITATION 2
CONT….
 Requirements elicitation and analysis focus only on the
user’s view of the system.
 Such as:
◦ The system functionality,

◦ The interaction between the user and the system,

◦ The errors that the system can detect and handle,

◦ The environmental conditions in which the system

functions are part of the requirements.
OOSE
REQUIREMENT ELICITATION 3
CONT…
 Requirements elicitation includes the
following activities:
◦ Identifying actors
◦ Identifying scenarios
◦ Identifying use cases
◦ Refining use cases
◦ Identifying relationships among use cases
◦ Identifying nonfunctional requirements

OOSE
REQUIREMENT ELICITATION 4
Requirement Elicitation Activities
Identifying actors
 Actors represent external entities that
interact with the system.
 An actor can be human or an external
system.
 During this activity,
 developers identify the different types of users the
future system will support.
 Generalize the users type for the modeling purpose.
 Give proper representation for the actors
OOSE
REQUIREMENT ELICITATION 5
CONT…
 For example in Sat watch system these
actors can participate:
 The watch owner(User of the Watch)
 GPS (location indicator time zone change)
 WebifyWatch (new data from web)
 Actors are role abstractions and do not
necessarily directly map to persons.
 The same person can fill the role of Field
Officer or Dispatcher at different times.
OOSE
REQUIREMENT ELICITATION 6
CONT…

OOSE
REQUIREMENT ELICITATION 7
 Identifying scenarios

 A scenario is “a narrative description of

what people do and experience as they try
to make use of computer systems and
applications”.
 During this activity, developers observe
users and develop a set of detailed
scenarios for typical functionality provided
by the future system.
 Scenarios are concrete examples of the
future system in use. OOSE
REQUIREMENT ELICITATION 8
CONT…
 Developers use these scenarios to
communicate with the user and deepen
their understanding of the application
domain.
 A scenario is a concrete, focused,
informal description of a single feature of
the system from the viewpoint of a single
actor.

OOSE
REQUIREMENT ELICITATION 9
CONT…

OOSE
REQUIREMENT ELICITATION 10
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.
 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.
 Whereas scenarios are concrete examples
illustrating a single case, OOSE
REQUIREMENT ELICITATION 11
 CONT…
 use cases are abstractions describing all
possible cases.
 When describing use cases, developers
determine the scope of the system.

OOSE
REQUIREMENT ELICITATION 12
CONT…

OOSE
REQUIREMENT ELICITATION 13
Refining use cases

 During this activity,

 developers ensure that the
requirements specification is
complete by detailing each use
case and describing the behavior
of the system in the presence of
errors and exceptional
conditions. OOSE
REQUIREMENT ELICITATION 14
CONT…
Some aspects in Refinement of use case:
 The elements that are manipulated by the
system are detailed.
 The low-level sequence of interactions between
the actor and the system are specified.
 Access rights (which actors can invoke which
use cases) are specified.
 Missing exceptions are identified and their
handling specified.
 Common functionality among use cases are
factored out OOSE
REQUIREMENT ELICITATION 15
 Identifying relationships among use
cases
 During this activity,
 developers identify dependencies
among use cases.
 They also consolidate the use case
model by factoring out common
functionality.
 This ensures that the requirements
specification is consistent
OOSE
REQUIREMENT ELICITATION 16
CONT…
 Common relationships between
actors and use cases:
◦ Communication relationships
represent the flow of information during the
use case.
◦ 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.

OOSE
REQUIREMENT ELICITATION 17
CONT…

OOSE
REQUIREMENT ELICITATION 18
CONT…

OOSE
REQUIREMENT ELICITATION 19
CONT…
 Includerelationships between
use cases
◦ Redundancies among use cases can
be factored out using include
relationships.
◦ Used when there is a need to have
some other use cases under the
main use case
OOSE
REQUIREMENT ELICITATION 20
OOSE
REQUIREMENT ELICITATION 21
Requirements Elicitation
Concepts
 Functional Requirements
 Nonfunctional Requirements
 Completeness, Consistency, Clarity,
and Correctness
 Realism, Verifiability and Traceability

OOSE
REQUIREMENT ELICITATION 22
CONT…
 Additional Requirements
◦ Implementation requirements are
constraints on the implementation of the
system, including the use of specific tools,
programming languages, or hardware
platforms.

OOSE
REQUIREMENT ELICITATION 23
CONT…
 Interface requirements are constraints
imposed by external systems, including
legacy systems and interchange formats.
 Operations requirements are
constraints on the administration and
management of the system in the
operational setting.

OOSE
REQUIREMENT ELICITATION 24
CONT…
 Legal requirements are
concerned with licensing, regulation,
and certification issues.
 The copyright of the system and
related concepts can be included

OOSE
REQUIREMENT ELICITATION 25
CONT…
 Packaging requirements are
constraints on the actual delivery
of the system (e.g., constraints on
the installation media for setting
up the software).
 What the software can have as
resource when deployed.
OOSE
REQUIREMENT ELICITATION 26
Managing Requirements
Elicitation
 Includes the activities such as:
◦ Negotiating Specifications with
Clients: Joint Application Design
◦ Maintaining Traceability
◦ Documenting Requirements
Elicitation

OOSE
REQUIREMENT ELICITATION 27
Negotiating Specifications with
Clients:
Joint Application Design
 focuses on building consensus among developers,
users, and clients by jointly developing the
requirements specification.
 Users, clients, developers, and a trained
session leader sit together in one room to present
their viewpoints, listen to other viewpoints,
negotiate, and come to a mutually acceptable
solution.
 Discussion will be recorded as JAD Document.

OOSE
REQUIREMENT ELICITATION 28
CONT…
 JAD is composed of five
activities:-
A. Project definition
B. Research
C. Preparation
D. Session
E. Final document
OOSE
REQUIREMENT ELICITATION 29
CONT…
A. Project definition
◦ During this activity, the JAD facilitator
interviews the project manager and the
client to determine the objectives and
the scope of the project.
◦ The findings from the interviews are
collected in the Management Definition
Guide.

OOSE
REQUIREMENT ELICITATION 30
 CONT…
B. Research
◦ During this activity, the JAD facilitator
interviews present and future users, gathers
information about the application domain, and
describes a first set of high-level use cases.
◦ The JAD facilitator also starts a list of problems
to be addressed during the session.
◦ The results of this activity are a Session Agenda
and a Preliminary.
◦ Specification listing work flow and system
information. OOSE
REQUIREMENT ELICITATION 31
CONT..
C. Preparation
◦ The JAD facilitator prepares the session.
◦ The JAD facilitator creates a Working Document,
an agenda for the session, slides or flip charts
representing information gathered during the
Research activity.
◦ The JAD facilitator also selects a team composed
of the client, the project manager, selected users,
and developers.
◦ All stakeholders are represented, and the
participants are able to make binding decisions. 32
D. Session
◦ the JAD facilitator guides the team in
creating the requirements specification.
◦ A JAD session lasts for 3 to 5 days.
◦ The team defines and agrees on the
scenarios, use cases, and user interface
mock-ups.
◦ All decisions are documented by a scribe.
OOSE
REQUIREMENT ELICITATION 33
CONT…
E. Final document
◦ The JAD facilitator prepares the Final Document,
revising the working document to include all
decisions made during the session.
◦ The Final Document represents a complete
specification of the system agreed on during the
session.
◦ The Final Document is distributed to the session
participants for review.
◦ The participants then attend a 1- to 2-hour meeting
to discuss the reviews and finalize the document.
OOSE
REQUIREMENT ELICITATION 34
Maintaining Traceability
 The ability to follow the life of a
requirement.
 This includes:-
◦ Tracing where the requirements came from
◦ who originated it
◦ which client need does it address
◦ To which aspects of the system and the project it
affects
◦ which components realize the requirement
◦ which test case checks its realization
OOSE
REQUIREMENT ELICITATION 35
Documenting Requirements
Elicitation
 The results of the requirements elicitation
and the analysis activities are documented
in the Requirements Analysis
Document (RAD).
 This document completely describes the
system in terms of functional and
nonfunctional requirements.
 The audience for the RAD includes the
client, the users, the project management,
the system analysts. OOSE
REQUIREMENT ELICITATION 36
CONT…

OOSE
REQUIREMENT ELICITATION 37
38
39
OOSE
REQUIREMENT ELICITATION 40