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.
   306   307   308   309   310   311   312   313   314   315   316