Page 348 -

CHAPTER 12 ANALYSIS MODELING 319

12.6 THE MECHANICS OF STRUCTURED ANALYSIS

In the previous section, we discussed basic and extended notation for structured
analysis. To be used effectively in software requirements analysis, this notation must
The analysis model be combined with a set of heuristics that enable a software engineer to derive a good
allows a reviewer to analysis model. To illustrate the use of these heuristics, an adapted version of the
examine software
requirements from Hatley and Pirbhai [HAT87] extensions to the basic structured analysis notation will
three different points be used throughout the remainder of this chapter.
of view. Therefore, be In the sections that follow, we examine each of the steps that should be applied
certain to use ERDs, to develop complete and accurate models using structured analysis. Through this dis-
DFDs, and STDs when
you build the model. cussion, the notation introduced in Section 12.4 will be used, and other notational
forms, alluded to earlier, will be presented in some detail.

12.6.1 Creating an Entity/Relationship Diagram
The entity/relationship diagram enables a software engineer to fully specify the data
objects that are input and output from a system, the attributes that define the prop-
erties of these objects, and their relationships. Like most elements of the analysis
model, the ERD is constructed in an iterative manner. The following approach is
taken:

? What steps 1. During requirements elicitation, customers are asked to list the “things” that
are required
the application or business process addresses. These “things” evolve into a
to build an ERD? list of input and output data objects as well as external entities that produce
or consume information.
2. Taking the objects one at a time, the analyst and customer define whether or
not a connection (unnamed at this stage) exists between the data object and
other objects.
3. Wherever a connection exists, the analyst and the customer create one or
more object/relationship pairs.
4. For each object/relationship pair, cardinality and modality are explored.
5. Steps 2 through 4 are continued iteratively until all object/relationships have
been defined. It is common to discover omissions as this process continues.
New objects and relationships will invariably be added as the number of iter-
ations grows.
6. The attributes of each entity are defined.
7. An entity relationship diagram is formalized and reviewed.
8. Steps 1 through 7 are repeated until data modeling is complete.

To illustrate the use of these basic guidelines, the SafeHome security system exam-
ple, discussed in Chapter 11, will be used. Referring back to the processing narrative