Page 315 -

286 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING

in the wait state until (1) an internal clock indicates that some time interval
has passed, (2) an external event (e.g., a mouse movement) causes an inter-
rupt, or (3) an external system signals the software to act in some manner. A
behavioral model creates a representation of the states of the software and
the events that cause a software to change state.
Models created during requirements analysis serve a number of important
roles:

• The model aids the analyst in understanding the information, function, and
? How do we behavior of a system, thereby making the requirements analysis task easier
use the
models we create and more systematic.
during
requirements • The model becomes the focal point for review and, therefore, the key to a
analysis? determination of completeness, consistency, and accuracy of the specifica-
tions.
• The model becomes the foundation for design, providing the designer with
an essential representation of software that can be "mapped" into an imple-
mentation context.
The analysis methods that are discussed in Chapters 12 and 21 are actually mod-
eling methods. Although the modeling method that is used is often a matter of per-
sonal (or organizational) preference, the modeling activity is fundamental to good
analysis work.

11.3.3 Partitioning

Problems are often too large and complex to be understood as a whole. For this rea-
son, we tend to partition (divide) such problems into parts that can be easily under-
stood and establish interfaces between the parts so that overall function can be
Partitioning is a accomplished. The fourth operational analysis principle suggests that the informa-
process that results in
the elaboration of tion, functional, and behavioral domains of software can be partitioned.
data, function, or In essence, partitioning decomposes a problem into its constituent parts. Concep-
behavior. It may be tually, we establish a hierarchical representation of function or information and then
performed horizontally partition the uppermost element by (1) exposing increasing detail by moving verti-
or vertically.
cally in the hierarchy or (2) functionally decomposing the problem by moving hori-
zontally in the hierarchy. To illustrate these partitioning approaches, let us reconsider
the SafeHome security system described in Section 11.2.2. The software allocation
for SafeHome (derived as a consequence of system engineering and FAST activities)
can be stated in the following paragraphs:
SafeHome software enables the homeowner to configure the security system when it is
installed, monitors all sensors connected to the security system, and interacts with the
homeowner through a keypad and function keys contained in the SafeHome control panel
shown in Figure 11.2.