Page 309 -

280 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING

QFD uses customer interviews and observation, surveys, and examination of his-
torical data (e.g., problem reports) as raw data for the requirements gathering activ-
ity. These data are then translated into a table of requirements—called the customer
voice table—that is reviewed with the customer. A variety of diagrams, matrices, and
evaluation methods are then used to extract expected requirements and to attempt
to derive exciting requirements [BOS91].

11.2.4 Use-Cases
As requirements are gathered as part of informal meetings, FAST, or QFD, the soft-
ware engineer (analyst) can create a set of scenarios that identify a thread of usage
for the system to be constructed. The scenarios, often called use-cases [JAC92], pro-
vide a description of how the system will be used.
A use-case is a To create a use-case, the analyst must first identify the different types of people
scenario that describes (or devices) that use the system or product. These actors actually represent roles that
how software is to be
used in a given people (or devices) play as the system operates. Defined somewhat more formally,
situation. an actor is anything that communicates with the system or product and that is exter-
nal to the system itself.
It is important to note that an actor and a user are not the same thing. A typical
user may play a number of different roles when using a system, whereas an actor
represents a class of external entities (often, but not always, people) that play just
one role. As an example, consider a machine operator (a user) who interacts with
the control computer for a manufacturing cell that contains a number of robots and
numerically controlled machines. After careful review of requirements, the software
for the control computer requires four different modes (roles) for interaction: pro-
Use-Cases gramming mode, test mode, monitoring mode, and troubleshooting mode. There-
fore, four actors can be defined: programmer, tester, monitor, and troubleshooter. In
some cases, the machine operator can play all of these roles. In others, different peo-
ple may play the role of each actor.
Because requirements elicitation is an evolutionary activity, not all actors are iden-
tified during the first iteration. It is possible to identify primary actors [JAC92] during
the first iteration and secondary actors as more is learned about the system. Primary
Use-cases are defined actors interact to achieve required system function and derive the intended benefit
from an actor’s point from the system. They work directly and frequently with the software. Secondary
of view. An actor is a
role that people actors support the system so that primary actors can do their work.
(users) or devices play Once actors have been identified, use-cases can be developed. The use-case
as they interact with describes the manner in which an actor interacts with the system. Jacobson [JAC92]
the software. suggests a number of questions that should be answered by the use-case:

• What main tasks or functions are performed by the actor?
• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about changes in the external envi-
ronment?