Werabe University IT Department

Chapter Three
Requirements Elicitation
3.1 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 aims at defining the
requirements of the system under construction. Requirements engineering includes
two main activities; requirements elicitation, which results in the specification of the
system that the client understands, and analysis, which results into an analysis
model that the developers can unambiguously interpret. Requirements elicitation is
the more challenging of the two because it requires the collaboration of several groups
of participants with different backgrounds. On the one hand, the client and the users
are experts in their domain and have a general idea of what the system should do.
However, they often have little experience in software development. On the other
hand, the developers have experience in building systems but often have little
knowledge of the everyday environment of the users.
 Scenarios and use cases provide tools for bridging this gap since both scenarios and
use cases are written in natural language, a form that is understandable to the user.
 In this chapter, we focus on scenario-based requirements elicitation. Developers
elicit requirements by observing and interviewing users. Developers first represent the
user’s current work processes as as-is scenarios and then develop visionary scenarios
describing the functionality provided by the future system. The client and users
validate the system description by reviewing the scenarios and by testing small
prototypes provided by the developers. As the definition of the system matures and
stabilizes, developers and the client agree on a system specification in the form of use
cases.
 Requirements elicitation is about communication among developers, clients, and
users for defining a new system. Failure to communicate and understand each other’s
domain results in a system that is difficult to use or that simply fails to support the
user’s work. Errors introduced during requirements elicitation are expensive to
correct, as they are usually discovered late in the process, often as late as delivery.
Such errors include missing functionality that the system should have supported,
functionality that was incorrectly specified, user interfaces that are misleading or
unusable, and functionality that is obsolete. Requirements elicitation methods aim at
improving communication among developers, clients, and users.

3.2 An Overview of 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.

Object Oriented System Analysis & Design 1

 Werabe University IT Department

 The system specification is structured and formalized during analysis. Both system
specification and analysis model represent the same information. They differ only in
the language and notation they use. The system specification is written in natural
language, whereas 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. They are
both models of the system in the sense that they attempt to accurately represent the
external aspects of the system. Given that both models represent the same aspects of
the system, requirements elicitation and analysis occur concurrently and iteratively.
 Requirements elicitation and analysis focus only on the user’s view of the system.
For example, the system functionality, the interaction between the user and the
system, the errors that the system can detect and handle, and the environmental
conditions in which the system functions, are part of the requirements. The system
structure, the implementation technology selected to build the system, the system
design, the development methodology, and other aspects not directly visible to the
user are not part of the requirements

 We focus on three methods for eliciting information and making decisions with users
and clients
o Joint Application Design (JAD) focuses on building consensus among
developers, users, and clients by jointly developing the system specification.

o Knowledge Analysis of Tasks (KAT) focuses on eliciting information from

users through observation.

o Usability testing focuses on validating the requirements elicitation model

with the user through a variety of methods.
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;

Object Oriented System Analysis & Design 2

 Werabe University IT Department

 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.
 People in the development organization may be stakeholders if they are
responsible for the safe and continued operation of the system, or for its
maintenance. A user organization is wise to involve its developers in this
way.
 Techniques for capturing requirements include interviewing users and other
stakeholders, holding workshops, observing users at work, searching likely
documents, and seeing the changes that users have made to existing systems.
Problem reports and suggestions from existing systems can be valuable sources of
requirements, provided you find out and record how important each proposed
requirement is to its users.
3.3 Requirements Elicitation Concepts
 Functional requirements
 Nonfunctional and pseudo requirements
 Levels of descriptions
 Greenfield engineering, reengineering, and interface engineering
3.3.1 Functional Requirements
 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.
 Example, the following is an example of functional requirements for SatWatch, a
watch that resets itself without user intervention:

Object Oriented System Analysis & Design 3

 Werabe University IT Department

 The above functional requirements only focus on the possible interactions

between SatWatch and its external world (i.e., the watch owner, GPS, and
WebifyWatch). The above description does not focus on any of the
implementation details (e.g., processor, language, display technology)
3.3.2 Nonfunctional and Pseudo Requirements
 Nonfunctional requirements: describe user-visible aspects of the system that are not
directly related with the functional behavior of the system. Nonfunctional
requirements include quantitative constraints, such as response time (i.e., how fast
the system reacts to user commands) or accuracy (i.e., how precise are the system’s
numerical answers). The following are the nonfunctional requirements for SatWatch:

 Pseudo requirements: are requirements imposed by the client that restricts the
implementation of the system. Typical pseudo requirements are the
implementation language and the platform on which the system is to be
implemented. For life-critical developments, pseudo requirements often include
process and documentation requirements (e.g., the use of a formal specification
method, the complete release of all work products). Pseudo requirements have
usually no direct effect on the users’ view of the system.
 The following are the pseudo functional requirements for SatWatch:

3.3.3 Levels of Description

 In general, there are four levels of description, which can uniformly be described
with use cases. We list them below from most-general to most-specific:
 Work division. This set of use cases describes the work processes of the
users that are relevant to the system. The part of the process supported by
the system is also described, but the focus is on defining the boundaries
between the users and the system.

Object Oriented System Analysis & Design 4

 Werabe University IT Department

 Application-specific system functions. This set of use cases describes the

functions that the system provides that are related to the application
domain.
 Work-specific system functions. This set of use cases describes the
supporting functions of the system that are not directly related with the
application domain. These include file management functions, grouping
functions, undo functions, and so on. These use cases will be extended
during system design, when we are discussing known boundary conditions,
such as system initialization, shutdown, and exception handling policies.
 Dialog. This set of use cases describes the interactions between the users
and the user interface of the system. The focus is on designing resolving
control flow and layout issues.
3.3.4 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 redesigned and re implemented.

3.4 Requirements Elicitation Activities

 In this section we discuss heuristics and methods for extracting requirements
from users and modeling the system in terms of these concepts. Requirements
elicitation activities include:
 Identifying actors
 Identifying scenarios
 Identifying use cases
 Refining use cases
 Identifying relationship among use cases
 Identifying participating objects
 Identifying nonfunctional requirements

Object Oriented System Analysis & Design 5

 Werabe University IT Department

3.4.1 Identifying Actors

 Actors represent external entities that interact with the system. An actor can be
human or an external system.
 The first step of requirements elicitation is the identification of actors. This
serves both to define the boundaries of the system and to find all the perspectives
from which the developers need to consider the system. When the system is
deployed into an existing organization (such as a company), most actors usually
exist before the system is developed: they correspond to roles in the organization.
 When identifying actors, you have to ask the following questions:

 In the SatWatch example, the watch owner, the GPS satellites, and the
WebifyWatch serial device are actors. They all interact and exchange information
with the SatWatch. Note, however, 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 WebifyWatch downloads new data into the
watch. Actors define classes of functionality.

 WatchOwner moves the watch (possibly across time zones) and consults it to
know what time it is. SatWatch interacts with GPS to compute its position.
WebifyWatch upgrades the data contained in the watch to reflect changes in
time policy (e.g., changes in daylight savings time start and end dates).
 Consider a more-complex example, FRIEND, a distributed information system
for accident management. It includes many actors, such as FieldOfficer, who
represents the police and fire officers who are responding to an incident, and
Dispatcher, the police officer responsible for answering 911 calls and
dispatching resources to an incident.

Object Oriented System Analysis & Design 6

 Werabe University IT Department

3.4.2 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”. A scenario is a
concrete, focused, informal description of a single feature of the system from
the viewpoint of a single actor.
 Below is an example of scenario for the FRIEND system, an information system
for incident response. In this scenario, a police officer reports a fire and a
Dispatcher initiates the incident response. Note that this scenario is concrete,
in the sense that it describes a single instance. It does not attempt to describe
all possible situations in which a fire incident is reported.

 Below is a selected number of scenario types:

 As-is scenarios describe a current situation. During reengineering, for
example, the current system is understood by observing users and
describing their actions as scenarios. These scenarios can then be validated
for correctness and accuracy with the users.
 Visionary scenarios describe a future system, either re-engineered or
designed from scratch. Visionary scenarios are used both as a design
representation by developers as they refine their idea of the future system
and as a communication medium to elicit requirements from users.
Visionary scenarios can be viewed as an inexpensive prototype.
 Evaluation scenarios describe user tasks against which the system is to be
evaluated. The collaborative development of evaluation scenarios by users
and developers also improves the definition of the functionality tested by
these scenarios.

Object Oriented System Analysis & Design 7

 Werabe University IT Department

 Training scenarios are tutorials used for introducing new users to the
system. These are step by step instructions designed to hand-hold the user
through common tasks.

 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 and cheat sheets, user and
client interviews. Developers should always write scenarios using application
domain terms, as opposed to their own terms. As developers gain further insight
in the application domain and the possibilities of the available technology, they
iteratively and incrementally refine scenarios to include increasing amounts of
detail. Drawing user interface mock-ups often helps to find omissions in the
specification and help the users build a more concrete picture of the system.

3.4.3 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. A use case
represents a complete flow of events through the system in the sense that it
describes a series of related interactions that result from the initiation of the use
case.
 Below is example from the friend system for use case: ReportEmergency

Object Oriented System Analysis & Design 8

 Werabe University IT Department

3.4.4 Refining Use Cases

 The use of scenarios and use cases to define the functionality of the system
aims at creating requirements that are validated by the user early in the
development. As the design &implementation of the system starts, the cost of
changing the system specification and adding new unforeseen functionality
increases. Although requirements change until late in the development,
developers and users should strive to address most requirements issues early.
This entails lots of changes and experimentation during requirements elicitation.
Note that many use cases are rewritten several times, others substantially
refined, and yet others completely dropped. In order to save time, a lot of the
exploration work can be done using scenarios and user interface mock-ups. The
following heuristics can be used for writing scenarios and use cases.
 Once the system specification becomes stable, traceability and redundancy
issues can be addressed by consolidating and reorganizing the actors and use
cases.

Object Oriented System Analysis & Design 9

 Werabe University IT Department

3.4.5 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.
 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.

3.4.5.1 Communication Relationships between Actors and Use Cases

 Communication relationships between actors and use cases represent the flow of
information during the use case. Sometimes the actor who initiates the use case
should be distinguished from the other actors with whom the use case communicates.
Thus, access control (i.e., which actor has access to which class functionality) can be
represented at this level. The relationships between actors and use cases are
identified when use cases are identified.
3.4.5.2 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 the user as an independent whole.
 In the FRIEND example, assume that the connection between the
FieldOfficer station and the Dispatcher station is broken while the
FieldOfficer is filling the form (e.g., the FieldOfficer’s car enters a tunnel).
The FieldOfficer station needs to notify the FieldOfficer that his form was
not delivered and what measures he should take. The ConnectionDown use
case is modeled as an extension of ReportEmergency.

Object Oriented System Analysis & Design 10

 Werabe University IT Department

3.4.5.3 Include Relationships between Use Cases

 Redundancies among use cases can be factored out using include
relationships. Assume, for example, that a Dispatcher needs to consult the
city map when opening an incident (e.g, in order to assess which areas are
at risk during a fire) and when allocating resources (e.g., to find which
resources are closer to the incident). In this case, the ViewMap use case
describes the flow of events required when viewing the city map and is used
by both the OpenIncident and the AllocateResources use cases

 Factoring out shared behavior from use cases has many benefits, including
shorter descriptions and fewer redundancies.
 Behavior should only be factored out into a separate use case if it is shared
across two or more use cases.
Extend versus include relationships
 The main distinction between these constructs is the direction of the
relationship. In the case of an include relationship, the conditions under
which the target use case is initiated are described in the initiating use case,
as an event in the flow of events. In the case of an extend relationship, the
conditions under which the extension is initiated are described in the
extension as an entry condition.

3.4.6 Identifying Participating Objects

 Once use cases have been consolidated, developers identify the participating
objects for each use case.
 The participating objects correspond to the main concepts in the application
domain. Developers identify, name, and describe them unambiguously and
collate them into a glossary.
 During requirements elicitation, participating objects are generated for each
use case.

Object Oriented System Analysis & Design 11

 Werabe University IT Department

 If two use cases refer to the same concept, the corresponding object should be
the same. If two objects share the same name and do not correspond to the
same concept, one or both concepts are renamed to acknowledge and
emphasize their difference. This consolidation eliminates any ambiguity in the
terminology used.

 Often, in the requirements elicitation activity, shifting perspectives introduces

modifications in the system specification (e.g., finding new participating objects
triggers the addition of new use cases; the addition of new use cases triggers the
addition or refinement of new participating objects). This instability should be
anticipated and encourage shifting perspectives. For the same reasons, time-
consuming tasks, such as the description of exceptional cases and refinements
of the user interfaces, should be postponed until the set of use cases is stable.

3.4.7 Identifying Nonfunctional Requirements

 Nonfunctional requirements describe user-visible aspects of the system that
are not directly related to the functional behavior of the system. Nonfunctional
requirements span a number of issues, from user interface look and feel to
response time requirements to security issues. Nonfunctional requirements are
defined at the same time as functional requirements are, because they have as
much impact on the development and cost of the system.

Object Oriented System Analysis & Design 12

 Werabe University IT Department

 Nonfunctional requirements can be elicited by investigating the following

issues.
 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?
 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?
3.5 Managing Requirements Elicitation
 Use case modeling by itself, however, does not constitute requirements elicitation.
Even after they become expert use case modelers, developers still need to elicit
requirements from the users and converge onto an agreement with the client.
 The following are methods for eliciting information from the users and negotiating
an agreement with a client.
 eliciting requirements from users: Knowledge Analysis of Tasks (KAT)
 negotiating a specification with clients: Joint Application Design (JAD)
 validating requirements: usability testing
 documenting requirements elicitation

Object Oriented System Analysis & Design 13

 Werabe University IT Department

3.5.1 Eliciting Information from Users: Knowledge Analysis of Tasks

 The Knowledge Analysis of Tasks (KAT) is a task analysis method proposed by
Johnson [Johnson, 1992]. It is concerned with collecting data from a variety of
sources (e.g., protocol analysis, standard procedures, textbooks, interviews),
analyzing these data to identify individual elements involved in the task (e.g.,
objects, actions, procedures, goals, and subgoals), and constructing a model of
the overall knowledge used by people accomplishing the task of interest.

 KAT is an object-oriented analysis technique in that it represents the application

domain in terms of objects and actions.
 KAT can be summarized by the five following steps:
1. Identifying objects and actions. Object and actions associated with
objects are identified using similar techniques as object identification in
object-oriented analysis, such as analyzing textbooks, manuals, rule books,
reports, interviewing the task performer, observing the task performer.
2. Identifying procedures. A procedure is a set of actions, a precondition
necessary to triggering the procedure, and a post condition. Actions may be
partially ordered. Procedures are identified by writing scenarios, observing
the task performer, asking the task performer to select and order cards on
which individual actions are written.
3. Identifying goals and sub goals. A goal is a state to be achieved for the
task to be successful. Goals are identified through interview during the
performance of a task or afterward. Sub goals are identified by
decomposing goals.
4. Identifying typicality and importance. Each identified element is rated
according to how frequently it is encountered and whether it is necessary
for accomplishing a goal.
5. Constructing a model of the task. The information gathered above is
generalized to account for common features across tasks. Corresponding
goals, procedures, and objects are related using a textual notation or a
graph. Finally, the model is validated with the task performer.
3.5.2 Negotiating Specifications with Clients: Joint Application Design
 (JAD) is a requirements method developed at IBM at the end of the 1970s.
 Its effectiveness lies in that the requirements elicitation work is done in one
single workshop session in which all stakeholders participate. Users, clients,
developers, and a trained session leader sit together in one room to present their
viewpoint, listen to other viewpoints, negotiate, and agree on a mutually
acceptable solution.
 JAD is composed of five activities
1. Project definition. During this activity, the JAD facilitator interviews
managers and clients to determine the objectives and the scope of the
project. The findings from the interviews are collected in the Management

Object Oriented System Analysis & Design 14

Werabe University IT Department

Definition Guide. During this activity, the JAD facilitator forms a team
composed of users, clients, and developers. All stakeholders are
represented, and the participants are able to make binding decisions.
2. Research. During this activity, the JAD facilitator interviews present and
future users, gathers domain information, and describes the work flows.
The JAD facilitator also starts a list of issues that will need to be
addressed during the session. The primary results of the research activity
are a Session Agenda and a Preliminary Specification listing work flow
and system information.
3. Preparation. During this activity, the JAD facilitator prepares the
session. The JAD facilitator creates a Working Document, first draft of the
final document, an agenda for the session, and any number of overhead
slides or flip charts representing information gathered during the
Research activity.
4. Session. During this activity, the JAD facilitator guides the team in
creating the system specification. A JAD session lasts for 3–5 days. The
team defines and agrees on the work flow, the data elements, the screens,
and the reports of the system. All decisions are documented by a scribe
filling JAD forms.
5. 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’s participants for review. The participants then meet for a
1to 2 hour meeting to discuss the reviews and finalize the document.

Object Oriented System Analysis & Design 15