Page 311 -
P. 311
282 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
additional input. If the password is correct, the control panel awaits further
action.
3. The homeowner selects and keys in stay or away (see Figure 11.2) to activate
the system. Stay activates only perimeter sensors (inside motion detecting
sensors are deactivated). Away activates all sensors.
4. When activation occurs, a red alarm light can be observed by the homeowner.
Use-cases for other homeowner interactions would be developed in a similar man-
ner. It is important to note that each use-case must be reviewed with care. If some
element of the interaction is ambiguous, it is likely that a review of the use-case will
indicate a problem.
Each use-case provides an unambiguous scenario of interaction between an actor
and the software. It can also be used to specify timing requirements or other con-
straints for the scenario. For example, in the use-case just noted, requirements indi-
cate that activation occurs 30 seconds after the stay or away key is hit. This information
can be appended to the use-case.
Use-cases describe scenarios that will be perceived differently by different actors.
Wyder [WYD96] suggests that quality function deployment can be used to develop a
weighted priority value for each use-case. To accomplish this, use-cases are evalu-
ated from the point of view of all actors defined for the system. A priority value is
5
assigned to each use-case (e.g., a value from 1 to 10) by each of the actors. An aver-
age priority is then computed, indicating the perceived importance of each of the use-
cases. When an iterative process model is used for software engineering, the priorities
can influence which system functionality is delivered first.
11.3 ANALYSIS PRINCIPLES
Over the past two decades, a large number of analysis modeling methods have been
developed. Investigators have identified analysis problems and their causes and have
developed a variety of modeling notations and corresponding sets of heuristics to
overcome them. Each analysis method has a unique point of view. However, all analy-
sis methods are related by a set of operational principles:
1. The information domain of a problem must be represented and understood.
? What are the 2. The functions that the software is to perform must be defined.
underlying
principles that 3. The behavior of the software (as a consequence of external events) must be
guide analysis represented.
work? 4. The models that depict information, function, and behavior must be parti-
tioned in a manner that uncovers detail in a layered (or hierarchical) fashion.
5 Ideally, this evaluation should be performed by individuals from the organization or business
function represented by an actor.