Chapter 3

Requirement Elicitation
3.1 An Overview of Requirements Elicitation
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 in 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,
but 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. A scenario describes an example of system use
in terms of a series of interactions between the user and the system. A use case is an abstraction that describes a
class of scenarios. 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, then develop
visionary scenarios describing the functionality to be 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 requirements specification in the
form of functional requirements, nonfunctional requirements, use cases, and scenarios.
Requirements elicitation is about communication among developers, clients, and users to define a new system.
Failure to communicate and understand each others’ domains 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.
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 (Chapter 5, Analysis) to produce an analysis model (see Figure 3-1). Both requirements
specification and analysis model represent the same information. They differ only in the language and notation they use;
the requirements specification is written in natural language, whereas the analysis model is usually expressed in a formal
or semiformal notation. The requirements 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 represent accurately 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.

Figure 3-1 Products of requirements

elicitation and analysis (UML activity
diagram).

SE, Ch - 3, Requirements Elicitation Page 1 of 15

 During requirements elicitation, developers access many different sources of information, including client-
supplied documents about the application domain, manuals and technical documentation of legacy systems
that the future system will replace, and most important, the users and clients themselves. Developers interact
the most with users and clients during requirements elicitation. We focus on two methods for eliciting
information, making decisions with users and clients, and managing dependencies among requirements and
other artifacts:
• Joint Application Design (JAD) focuses on building consensus among developers, users, and clients by
jointly developing the requirements specification.1
• Traceability focuses on recording, structuring, linking, grouping, and maintaining dependencies among
requirements and between requirements and other work products.
1. Note that the use of the term “design” in JAD is a misnomer: it has nothing to do with our use of the term in the subsequent
chapters on system and object design.

3.2 Functional Requirements and Nonfunctional requirements

3.2.1 Functional Requirements
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. For example, Figure 3-2 is an example of functional requirements for SatWatch, a watch that resets
itself without user intervention:
SatWatch is a wrist watch that displays the time based on its current location. SatWatch uses GPS satellites (Global
Positioning System) to determine its location and internal data structures to convert this location into a time zone.
The information stored in SatWatch and its accuracy measuring time is such that the watch owner never needs to reset the
time. SatWatch adjusts the time and date displayed as the watch owner crosses time zones and political boundaries. For
this reason, SatWatch has no buttons or controls available to the user.
SatWatch determines its location using GPS satellites and, as such, suffers from the same limitations as all other GPS
devices (e.g., inability to determine location at certain times of the day in mountainous regions). During blackout periods,
SatWatch assumes that it does not cross a time zone or a political boundary. SatWatch corrects its time zone as soon as
a blackout period ends.
SatWatch has a two-line display showing, on the top line, the time (hour, minute, second, time zone) and on the bottom
line, the date (day, date, month, year). The display technology used is such that the watch owner can see the time and date
even under poor light conditions.
When political boundaries change, the watch owner may upgrade the software of the watch using the WebifyWatch
device (provided with the watch) and a personal computer connected to the Internet.
Figure 3-2 Functional requirements for SatWatch.
The above functional requirements focus only 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.2.2 Nonfunctional Requirements
Nonfunctional requirements describe aspects of the system that are not directly related to the functional
behavior of the system. Nonfunctional requirements include a broad variety of requirements that apply to
many different aspects of the system, from usability to performance.
The FURPS+ model provides additional categories of requirements typically also included under the
general label of nonfunctional requirements:
• Usability is the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a
system or component. Usability requirements include, for example, conventions adopted by the user
interface, the scope of online help, and the level of user documentation. Often, clients address usability
issues by requiring the developer to follow user interface guidelines on color schemes, logos, and fonts.

SE, Ch - 3, Requirements Elicitation Page 2 of 15

• Reliability is the ability of a system or component to perform its required functions under stated conditions
for a specified period of time. Reliability requirements include, for example, an acceptable mean time to
failure and the ability to detect specified faults or to withstand specified security attacks. More recently, this
category is often replaced by dependability, which is the property of a computer system such that reliance
can justifiably be placed on the service it delivers. Dependability includes reliability, robustness (the
degree to which a system or component can function correctly in the presence of invalid inputs or stressful
environment conditions), and safety (a measure of the absence of catastrophic consequences to the
environment).
• Performance requirements are concerned with quantifiable attributes of the system, such as response
time (how quickly the system reacts to a user input), throughput (how much work the system can
accomplish within a specified amount of time), availability (the degree to which a system or component
is operational and accessible when required for use), and accuracy.
• Supportability requirements are concerned with the ease of changes to the system after deployment,
including for example, adaptability (the ability to change the system to deal with additional application
domain concepts), maintainability (the ability to change the system to deal with new technology or to fix
defects), and internationalization (the ability to change the system to deal with additional international
conventions, such as languages, units, and number formats). The ISO 9126 standard on software quality
[ISO Std. 9126], similar to the FURPS+ model, replaces this category with two categories:
maintainability and portability (the ease with which a system or component can be transferred from one
hardware or software environment to another).
2. FURPS+ is an acronym using the first letter of the requirements categories: Functionality, Usability, Reliability, Performance, and
Supportability. The + indicates the additional subcategories. The FURPS model was originally proposed by [Grady, 1992]. The
definitions in this section are quoted from [IEEE Std. 610.12-1990].

The FURPS+ model provides additional categories of requirements typically also included under the
general label of nonfunctional requirements:
• Implementation requirements are constraints on the implementation of the system, including the use of
specific tools, programming languages, or hardware platforms.
• 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.
• Packaging requirements are constraints on the actual delivery of the system (e.g., constraints on the
installation media for setting up the software).
• Legal requirements are concerned with licensing, regulation, and certification issues. An example of a legal
requirement is that software developed for the U.S. federal government must comply with Section 508 of
the Rehabilitation Act of 1973, requiring that government information systems must be accessible to people
with disabilities.
Nonfunctional requirements that fall into the URPS categories are called quality requirements of the
system. Nonfunctional requirements that fall into the implementation, interface, operations, packaging, and
legal categories are called constraints or pseudo requirements. Budget and schedule requirements are
usually not treated as nonfunctional requirements, as they constrain attributes of the projects (see Chapter 14,
Project Management). Figure 3-3 depicts the nonfunctional requirements for SatWatch.
Quality requirements for SatWatch
• Any user who knows how to read a digital watch and understands international time zone abbreviations should be able
to use SatWatch without the user manual. [Usability requirement]
• As the SatWatch has no buttons, no software faults requiring the resetting of the watch should occur. [Reliability
requirement]
• SatWatch should display the correct time zone within 5 minutes of the end of a GPS blackout period. [Performance

SE, Ch - 3, Requirements Elicitation Page 3 of 15

 requirement]
• SatWatch should measure time within 1/100th second over 5 years. [Performance requirement]

• SatWatch should display time correctly in all 24 time zones. [Performance requirement]

• SatWatch should accept upgrades to its onboard via the Webify Watch serial interface. [Supportability requirement]
Constraints for SatWatch
• All related software associated with SatWatch, including the onboard software, will be written using Java, to comply
with current company policy. [Implementation requirement]
• SatWatch complies with the physical, electrical, and software interfaces defined by WebifyWatch API 2.0. [Interface
requirement]
Figure 3-3 Nonfunctional requirements for SatWatch.
3.3 Additional Requirement elicitation concepts
Requirements are continuously validated with the client and the user. Validation is a critical step in the
development process, given that both the client and the developer depend on the requirements specification.
Requirement validation involves checking that the specification is complete, consistent, unambiguous, and
correct.
It is complete if all possible scenarios through the system are described, including exceptional behavior (i.e.,
all aspects of the system are represented in the requirements model). The requirements specification is
consistent if it does not contradict itself. The requirements specification is unambiguous if exactly one
system is defined (i.e., it is not possible to interpret the specification two or more different ways). A
specification is correct if it represents accurately the system that the client needs and that the developers
intend to build (i.e., everything in the requirements model accurately represents an aspect of the system to
the satisfaction of both client and developer). These properties are illustrated in Table 3-1 Above.
The correctness and completeness of a requirements specification are often difficult to establish, especially
before the system exists. Given that the requirements specification serves as a contractual basis between the client
and the developers, the requirements specification must be carefully reviewed by both parties. Additionally,
parts of the system that present a high risk should be prototyped or simulated to demonstrate their feasibility
or to obtain feedback from the user. In the case of SatWatch described above, a mock-up of the watch would
be built using a traditional watch and users surveyed to gather their initial impressions. A user may remark that
she wants the watch to be able to display both American and European date formats.
Three more desirable properties of a requirements specification are that it be realistic, verifiable, and traceable.
The requirements specification is realistic if the system can be implemented within constraints. The
requirements specification is verifiable if, once the system is built, repeatable tests can be designed to
demonstrate that the system fulfills the requirements specification. For example, a mean time to failure of a
hundred years for SatWatch would be difficult to verify (assuming it is realistic in the first place). A
requirements specification is traceable if each requirement can be traced throughout the software development
to its corresponding system functions, and if each system function can be traced back to its corresponding set
of requirements. Traceability includes also the ability to track the dependencies among requirements, system
functions, and the intermediate design artifacts, including system components, classes, methods, and object
attributes. Traceability is critical for developing tests and for evaluating changes. When developing tests,
traceability enables a tester to assess the coverage of a test case, that is, to identify which requirements are
tested and which are not. When evaluating changes, traceability enables the analyst and the developers to
identify all components and system functions that the change would impact.

SE, Ch - 3, Requirements Elicitation Page 4 of 15

3.4 Requirements Elicitation Activities
Requirements elicitation activities include
• Identifying Actors
• Identifying Scenarios
• Identifying Use Cases
• Refining Use Cases
• Identifying Relationships Among Actors and Use Cases
• Identifying Initial Analysis Objects
• Identifying Nonfunctional Requirements
3.4.1 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 WebifyWatch serial device are actors
(see Figure 3-4). They all exchange information with the SatWatch. Note, however, that they all have specific
interactions with 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.

Figure 3-4 Actors for the SatWatch system.

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. FRIEND supports both actors by keeping track of incidents, resources,
and task plans. It also has access to multiple databases, such as a hazardous materials database and emergency
operations procedures. The FieldOfficer and the Dispatcher actors interact through different interfaces:
FieldOfficers access FRIEND through a mobile personal assistant, Dispatchers access FRIEND through a
workstation (see Figure 3-5).
Actors are role abstractions and do not necessarily directly map to persons. The same person can fill
the role of FieldOfficer or Dispatcher at different times. However, the functionality they access is
substantially different. For that reason, these two roles are modeled as two different actors.

Figure 3-5 Actors of the FRIEND system. FieldOfficers not only have access to different functionality, they use
different computers to access the 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.
During the initial stages of actor identification, it is hard to distinguish actors from objects. For example, a

SE, Ch - 3, Requirements Elicitation Page 5 of 15

 database subsystem can at times be an actor, while in other cases it can be part of the system. Note that once
the system boundary is defined, there is no trouble distinguishing between actors and such system components
as objects or subsystems. Actors are outside of the system boundary; they are external. Subsystems and objects
are inside the system boundary; they are internal. Thus, any external software system using the system to be
developed is an actor. When identifying actors, developers can ask the following questions:

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?

In the FRIEND example, these questions lead to a long list of potential actors: fire fighter, police officer,
dispatcher, investigator, mayor, governor, an EPA hazardous material database, system administrator, and so
on. We then need to consolidate this list into a small number of actors, who are different from the point of
view of the usage of the system. For example, a fire fighter and a police officer may share the same interface to
the system, as they are both involved with a single incident in the field. A dispatcher, on the other hand, manages
multiple concurrent incidents and requires access to a larger amount of information. The mayor and the
governor will not likely interact directly with the system, but will use the services of a trained operator instead.
Once the actors are identified, the next step in the requirements elicitation activity is to determine the
functionality that will be accessible to each actor. This information can be extracted using scenarios and
formalized using use cases.
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” [Carroll, 1995]. A scenario is a concrete, focused, informal description of a
single feature of the system from the viewpoint of a single actor. Scenarios cannot (and are not intended to)
replace use cases, as they focus on specific instances and concrete events (as opposed to complete and general
descriptions). However, scenarios enhance requirements elicitation by providing a tool that is understandable
to users and clients.
Figure 3-6 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. In particular, scenarios cannot contain descriptions
of decisions. To describe the outcome of a decision, two scenarios would be needed, one for the “true” path,
and another one for the “false” path.

Figure 3-6 warehouseOnFire scenario for the ReportEmergency use case.

SE, Ch - 3, Requirements Elicitation Page 6 of 15

 In requirements elicitation, developers and users write and refine a series of scenarios in order to gain a
shared understanding of what the system should be. Initially, each scenario may be high level and incomplete,
as the warehouseOnFire scenario is. The following questions can be used for identifying scenarios.
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?

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 into 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 to build a more concrete picture of the system.
In the FRIEND example, we identify four scenarios that span the type of tasks the system is expected to support:
• warehouseOnFire (Figure 3-6): A fire is detected in a warehouse; two field officers arrive at the scene
and request resources.
• fenderBender: A car accident without casualties occurs on the highway. Police officers document the
incident and manage traffic while the damaged vehicles are towed away.
• catInATree: A cat is stuck in a tree. A fire truck is called to retrieve the cat. Because the incident is low
priority, the fire truck takes time to arrive at the scene. In the meantime, the impatient cat owner climbs
the tree, falls, and breaks a leg, requiring an ambulance to be dispatched.
• earthQuake: An unprecedented earthquake seriously damages buildings and roads, spanning multiple
incidents and triggering the activation of a statewide emergency operations plan. The governor is notified.
Road damage hampers incident response.
The emphasis for developers during actor identification and scenario identification is to understand the
application domain. This results in a shared understanding of the scope of the system and of the user work
processes to be supported. Once developers have identified and described actors and scenarios, they formalize
scenarios into use cases.
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 its initiation.
Figure 3-7 depicts the use case ReportEmergency of which the scenario warehouseOnFire (see Figure 3-6) is
an instance. The FieldOfficer actor initiates this use case by activating the “Report Emergency” function of
FRIEND. The use case completes when the FieldOfficer actor receives an acknowledgment that an incident
has been created. The steps in the flow of events are indented to denote who initiates the step. Steps 1 and 3 are
initiated by the actor, while steps 2 and 4 are initiated by the system. This use case is general and
encompasses a range of scenarios. For example, the ReportEmergency use case could also apply to the
fenderBender scenario. Use cases can be written at varying levels of detail as in the case of scenarios.

SE, Ch - 3, Requirements Elicitation Page 7 of 15

Figure 3-7 An example of a use case, ReportEmergency. Under ReportEmergency, the left column denotes actor
actions, and the right column denotes system responses.
Generalizing scenarios and identifying the high-level use cases that the system must support enables
developers to define the scope of the system. Initially, developers name use cases, attach them to the initiating
actors, and provide a high-level description of the use case as in Figure 3-7. The name of a use case should be
a verb phrase denoting what the actor is trying to accomplish. The verb phrase “Report Emergency” indicates
that an actor is attempting to report an emergency to the system (and hence, to the Dispatcher actor). This
use case is not called “Record Emergency” because the name should reflect the perspective of the actor, not the
system. It is also not called “Attempt to Report an Emergency” because the name should reflect the goal of the
use case, not the actual activity.
Attaching use cases to initiating actors enables developers to clarify the roles of the different users.
Often, by focusing on who initiates each use case, developers identify new actors that have been previously
overlooked.
Describing a use case entails specifying four fields. Describing the entry and exit conditions of a use case
enables developers to understand the conditions under which a use case is invoked and the impact of the use
case on the state of the environment and of the system. Describing the flow of events of a use case enables
developers and clients to discuss the interaction between actors and system. This results in many decisions
about the boundary of the system, that is, about deciding which actions are accomplished by the actor and which
actions are accomplished by the system. Finally, describing the quality requirements associated with a use case
enables developers to elicit nonfunctional requirements in the context of a specific functionality.
Writing use cases is a craft. An analyst learns to write better use cases with experience. Consequently,
different analysts tend to develop different styles, which can make it difficult to produce a consistent
requirements specification. To address the issue of learning how to write use cases and how to ensure
consistency among the use cases of a requirements specification, analysts adopt a use case writing guide.
Figure 3-8 is a simple writing guide adapted from [Cockburn, 2001] that can be used for novice use case
writers. Figure 3-9 provides an example of a poor use case that violates the writing guideline in several ways.

SE, Ch - 3, Requirements Elicitation Page 8 of 15

Simple Use Case Writing Guide
• Use cases should be named with verb phrases. The name of the use case should indicate what the user is trying to
accomplish (e.g., ReportEmergency, OpenIncident).
• Actors should be named with noun phrases (e.g., FieldOfficer, Dispatcher, Victim).
• The boundary of the system should be clear. Steps accomplished by the actor and steps accomplished by the system
should be distinguished (e.g., in Figure 3-7, system actions are indented to the right).
• Use case steps in the flow of events should be phrased in the active voice. This makes it explicit who accomplished
the step.
• The causal relationship between successive steps should be clear.
• A use case should describe a complete user transaction (e.g., the ReportEmergency use case describes all the steps
between initiating the emergency reporting and receiving an acknowledgment).
• Exceptions should be described separately.
• A use case should not describe the user interface of the system. This takes away the focus from the actual steps
accomplished by the user and is better addressed with visual mock-ups (e.g., the ReportEmergency only refers to the
“Report Emergency” function, not the menu, the button, nor the actual command that corresponds to this function).
• A use case should not exceed two or three pages in length. Otherwise, use include and extend relationships to
decompose it in smaller use cases.
Figure 3-8 Use case writing guide.

Figure 3-9 An example of a poor use case. Violations of the writing guide are indicated in italics in the right column.
The ReportEmergency use case in Figure 3-7 may be illustrative enough to describe how FRIEND supports
reporting emergencies and to obtain general feedback from the user, but it does not provide sufficient detail for
a requirements specification. Next, we discuss how use cases are refined and detailed.
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 and implementation of the
system starts, the cost of changing the requirements 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 many changes and much validation during requirements
elicitation. Note that many use cases are rewritten several times, others substantially refined, and yet others
completely dropped. To save time, much of the exploration work can be done using scenarios and user
interface mock-ups.
3.4.5 Identifying Relationships among Actors and Use Cases
Even medium-sized systems have many 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

SE, Ch - 3, Requirements Elicitation Page 9 of 15

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.
Communication relationships between actors and use cases
Communication relationships between actors and use cases represent the flow of information during
the use case. The actor who initiates the use case should be distinguished from the other actors with whom
the use case communicates. By specifying which actor can invoke a specific use case, we also implicitly
specify which actors cannot invoke the use case. Similarly, by specifying which actors communicate with a
specific use case, we specify which actors can access specific information and which cannot. Thus, by
documenting initiation and communication relationships among actors and use cases, we specify access
control for the system at a coarse level.
The relationships between actors and use cases are identified when use cases are identified. Figure 3-11
depicts an example of communication relationships in the case of the FRIEND system. The «initiate»
stereotype denotes the initiation of the use case by an actor, and the «participate» stereotype denotes that an
actor (who did not initiate the use case) communicates with the use case.

Figure 3-11 Example of communication relationships among actors and use cases in FRIEND (UML use case diagram).
The FieldOfficer initiates the ReportEmergency use case, and the Dispatcher initiates the OpenIncident and
AllocateResources use cases. FieldOfficers cannot directly open an incident or allocate resources on their own.

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 flows 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 robustness).
Both the extended use case and the extensions are complete use cases of their own. They each must have entry
and end conditions and be understandable by the user as an independent whole.

Figure 3-12 Example of use of extend relationship (UML use case diagram). ConnectionDown extends the
ReportEmergency use case. The ReportEmergency use case becomes shorter and solely focused on emergency reporting.

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., to assess which areas are at
risk during a fire) and when allocating resources (e.g., to find which resources are closest 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 (Figure 3-13).

SE, Ch - 3, Requirements Elicitation Page 10 of 15

Figure 3-13 Example of include relationships among use cases. ViewMap describes the flow of events for viewing a city
map (e.g., scrolling, zooming, query by street name) and is used by both OpenIncident and AllocateResources use cases.
In summary, the following heuristics can be used for selecting an extend or an include relationship.
Heuristics for extend and include relationships
• Use extend relationships for exceptional, optional, or seldom-occurring behavior. An example of seldom-occurring
behavior is the breakdown of a resource (e.g., a fire truck). An example of optional behavior is the notification of
nearby resources responding to an unrelated incident.
• Use include relationships for behavior that is shared across two or more use cases.
• However, use discretion when applying the above two heuristics and do not overstructure the use case model. A
few longer use cases (e.g., two pages long) are easier to understand and review than many short ones (e.g., ten lines
long).

3.4.6 Identifying Initial Analysis Objects

One of the first obstacles developers and users encounter when they start collaborating with each other is differing
terminology. Although developers eventually learn the users’ terminology, this problem is likely to be
encountered again when new developers are added to the project. Misunderstandings result from the same
terms being used in different contexts and with different meanings.
To establish a clear terminology, developers identify the participating objects for each use case.
Developers should identify, name, and describe them unambiguously and collate them into a glossary.3
Building this glossary constitutes the first step toward analysis, which we discuss in the next chapter.
The glossary is included in the requirements specification and, later, in the user manuals. Developers keep
the glossary up to date as the requirements specification evolves. The benefits of the glossary are manyfold:
new developers are exposed to a consistent set of definitions, a single term is used for each concept (instead
of a developer term and a user term), and each term has a precise and clear official meaning.
The identification of participating objects results in the initial analysis object model. The identification of
participating objects during requirements elicitation only constitutes a first step toward the complete analysis
object model. The complete analysis model is usually not used as a means of communication between users
and developers, as users are often unfamiliar with object-oriented concepts. However, the description of the
objects (i.e., the definitions of the terms in the glossary) and their attributes are visible to the users and
reviewed. We describe in detail the further refinement of the analysis model in Chapter 5, Analysis.
3. The glossary is also called a “data dictionary” [Rumbaugh et al., 1991].

Many heuristics have been proposed in the literature for identifying objects. Here are a selected few:

Heuristics for identifying initial analysis objects

• Terms that developers or users must clarify to understand the use case
• Recurring nouns in the use cases (e.g., Incident)
• Real-world entities that the system must track (e.g., FieldOfficer, Resource)
• Real-world processes that the system must track (e.g., EmergencyOperationsPlan)
• Use cases (e.g., ReportEmergency)
• Data sources or sinks (e.g., Printer)
• Artifacts with which the user interacts (e.g., Station)
• Always use application domain terms.

SE, Ch - 3, Requirements Elicitation Page 11 of 15

 During requirements elicitation, participating objects are generated for each use case. 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. For example, Table 3-
2 depicts the initial participating objects we identified for the ReportEmergency use case.
Dispatcher Police officer who manages Incidents. A Dispatcher opens, documents, and closes incidents in
response to EmergencyReports and other communication with FieldOfficers. Dispatchers are
identified by badge numbers.

EmergencyReport Initial report about an Incident from a FieldOfficer to a Dispatcher. An EmergencyReport

usually triggers the creation of an Incident by the Dispatcher. An EmergencyReport is
composed of an emergency level, a type (fire, road accident, other), a location, and a description.

FieldOfficer Police or fire officer on duty. A FieldOfficer can be allocated to at most one Incident at a
time. FieldOfficers are identified by badge numbers.

Incident Situation requiring attention from a FieldOfficer. An Incident may be reported in the system
by a FieldOfficer or anybody else external to the system. An Incident is composed of a
description, a response, a status (open, closed, documented), a location, and a number of
FieldOfficers.

Table 3-2 Participating objects for the ReportEmergency use case.

Once participating objects are identified and consolidated, the developers can use them as a checklist for
ensuring that the set of identified use cases is complete.
3.4.7 Identifying Nonfunctional Requirements
Nonfunctional requirements describe aspects of the system that are not directly related to its functional
behavior. 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 because they have as much impact on the development and cost of the system.
For example, consider a mosaic display that an air traffic controller uses to track planes. A mosaic display
system compiles data from a series of radars and databases (hence the term “mosaic”) into a summary
display indicating all aircraft in a certain area, including their identification, speed, and altitude. The number
of aircraft such a system can display constrains the performance of the air traffic controller and the cost of the
system. If the system can only handle a few aircraft simultaneously, the system cannot be used at busy airports.
On the other hand, a system able to handle a large number of aircraft is more costly and more complex to
build and to test.
To accurately elicit all the essential nonfunctional requirements, both client and developer must
collaborate so that they identify (minimally) which attributes of the system that are difficult to realize are
critical for the work of the user. In the mosaic display example above, the number of aircraft that a single mosaic
display must be able to handle has implications on the size of the icons used for displaying aircraft, the features
for identifying aircraft and their properties, the refresh rate of the data, and so on.
Table 3-3 Example questions for eliciting nonfunctional requirements.
Category Example questions
Usability • What is the level of expertise of the user?
• What user interface standards are familiar to the user?
• What documentation shouldbe provided to the user?
Reliability • How reliable, available, and robust should the system be?
(including robustness, • Is restarting the system acceptable in the event of a failure?
safety, and security) • How much data can the system loose?
• How should the system handle exceptions?

SE, Ch - 3, Requirements Elicitation Page 12 of 15

 • Are there safety requirements of the system?
• Are there security requirements of the system?
Performance • How responsive should the system be?
• Are any user tasks time critical?
• How many concurrent users should it support?
• How large is a typical data store for comparable systems?
• What is the worse latency that is acceptable to users?
Supportability • What are the foreseen extensions to the system?
(including maintainability • Who maintains the system?
and portability) • Are there plans to port the system to different software or hardware
environments?
Implementation • Are there constraints on the hardware platform?
• Are constraints imposed by the maintenance team?
• Are constraints imposed by the testing team?
Interface • Should the system interact with any existing systems?
• How are data exported/imported into the system?
• What standards in use by the client should be supported by the system?
Operation Who manages the running system?
Packaging • Who installs the system?
• How many installations are foreseen?
• Are there time constraints on the installation?
Legal • How should the system be licensed?
• Are any liability issues associated with system failures?
• Are any royalties or licensing fees incurred by using specific algorithms or
components?

There are unfortunately few systematic methods for eliciting nonfunctional requirements. In practice,
analysts use a taxonomy of nonfunctional requirements (e.g., the FURPS+ scheme described previously) to
generate check lists of questions to help the client and the developers focus on the nonfunctional aspects of the
system.

3.5 Managing Requirements Elicitation

In the previous section, we described the technical issues of modeling a system in terms of use cases. 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 come to an agreement with the
client.
3.5.1 Negotiating Specifications with Clients: Joint Application Design
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 viewpoints, listen to other viewpoints, negotiate, and come to a mutually acceptable solution. The
outcome of the workshop, the final JAD document, is a complete requirements specification document that
includes definitions of data elements, work flows, and interface screens. Because the final document is jointly
developed by the stakeholders (that is, the participants who not only have an interest in the success of the
project, but also can make substantial decisions), the final JAD document represents an agreement among
users, clients, and developers, and thus minimizes requirements changes later in the development process.
JAD leverages group dynamics to improve communication among participants and to accelerate consensus.
At the end of a JAD session, developers are more knowledgeable of user needs, and users are more

SE, Ch - 3, Requirements Elicitation Page 13 of 15

knowledgeable of development trade-offs. Additional gains result from a reduction of redesign activities
downstream. Because of its reliance on social dynamics, the success of a JAD session often depends on the
qualifications of the JAD facilitator as a meeting facilitator.
3.5.2 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 (i.e., the developers who participate in the requirements), and the system designers (i.e., the
developers who participate in the system design). The first part of the document, including use cases and
nonfunctional requirements, is written during requirements elicitation. The formalization of the specification in
terms of object models is written during analysis. Figure 3-16 is an example template for a RAD used in this
book.
The first section of the RAD is an Introduction. Its purpose is to provide a brief overview of the function
of the system and the reasons for its development, its scope, and references to the development context (e.g.,
reference to the problem statement written by the client, references to existing systems, feasibility studies). The
introduction also includes the objectives and success criteria of the project.
The second section, Current system, describes the current state of affairs. If the new system will replace
an existing system, this section describes the functionality and the problems of the current system. Otherwise,
this section describes how the tasks supported by the new system are accomplished now. For example, in the
case of SatWatch, the user currently resets her watch whenever she travels across a time zone. Because of
the manual nature of this operation, the user occasionally sets the wrong time and occasionally neglects
to reset. In contrast, the SatWatch will continually ensure accurate time within its lifetime. In the case of
FRIEND, the current system is paper based: dispatchers keep track of resource assignments by filling out forms.
Communication between dispatchers and field officers is by radio. The current system requires a high
documentation and management cost that FRIEND aims to reduce.
Requirements Analysis Document
1. Introduction
1.1 Purpose of the system
1.2 Scope of the system
1.3 Objectives and success criteria of the project
1.4 Definitions, acronyms, and abbreviations
1.5 References
1.6 Overview
2. Current system
3. Proposed system
3.1 Overview
3.2 Functional requirements
3.3 Nonfunctional requirements
3.3.1 Usability
3.3.2 Reliability
3.3.3 Performance
3.3.4 Supportability
3.3.5 Implementation
3.3.6 Interface
3.3.7 Packaging
3.3.8 Legal
3.4 System models

SE, Ch - 3, Requirements Elicitation Page 14 of 15

 3.4.1 Scenarios
3.4.2 Use case model
3.4.3 Object model
3.4.4 Dynamic model
3.4.5 User interface—navigational paths and screen mock-ups
4. Glossary
Figure 3-16 Outline of the Requirements Analysis Document (RAD). Sections in italics are completed during analysis
(see next chapter).
The third section, Proposed system, documents the requirements elicitation and the analysis model of the new
system. It is divided into four subsections:
• Overview presents a functional overview of the system.
• Functional requirements describes the high-level functionality of the system.
• Nonfunctional requirements describes user-level requirements that are not directly related to functionality.
This includes usability, reliability, performance, supportability, implementation, interface, operational,
packaging, and legal requirements.
• System models describes the scenarios, use cases, object model, and dynamic models for the system. This
section contains the complete functional specification, including mock-ups illustrating the user interface
of the system and navigational paths representing the sequence of screens. The subsections Object
model and Dynamic model are written during the Analysis activity, described in the next chapter.
The RAD should be written after the use case model is stable, that is, when the number of modifications
to the requirements is minimal. The requirements, however, are updated throughout the development process
when specification problems are discovered or when the scope of the system is changed. The RAD, once
published, is baselined and put under configuration management. The revision history section of the RAD
will provide a history of changes include the author responsible for each change, the date of the change,
and a brief description of the change.

SE, Ch - 3, Requirements Elicitation Page 15 of 15