Page 329 -

300 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING

QUICK model is created and then vali- and control specifications are created as part of
LOOK dated by both software engineers the analysis modeling activity.
and customers/users. How do I ensure that I’ve done it right? Analysis mod-
What is the work product? Data object descriptions, eling work products must be reviewed for cor-
entity relationship diagrams, data flow diagrams, rectness, completeness, and consistency.
state transition diagrams, process specifications,

• The products of analysis must be highly maintainable. This applies particularly to the
Target Document [software requirements specifications].
• Problems of size must be dealt with using an effective method of partitioning. The Vic-
torian novel specification is out.
• Graphics have to be used whenever possible.
• We have to differentiate between logical [essential] and physical [implementation] con-
siderations . . .
At the very least, we need . . .
• Something to help us partition our requirements and document that partitioning before
specification . . .
• Some means of keeping track of and evaluating interfaces . . .
• New tools to describe logic and policy, something better than narrative text . . .
There is probably no other software engineering method that has generated as much
interest, been tried (and often rejected and then tried again) by as many people, pro-
voked as much criticism, and sparked as much controversy. But the method has pros-
pered and has gained a substantial following in the software engineering community.

12.1 A BRIEF HISTORY

Like many important contributions to software engineering, structured analysis was
not introduced with a single landmark paper or book. Early work in analysis model-
ing was begun in the late 1960s and early 1970s, but the first appearance of the struc-
“The problem is not tured analysis approach was as an adjunct to another important topic—"structured
that there are design." Researchers (e.g., [STE74], [YOU78]) needed a graphical notation for repre-
problems. The senting data and the processes that transformed it. These processes would ultimately
problem is expecting
otherwise and be mapped into a design architecture.
thinking that having The term structured analysis, originally coined by Douglas Ross, was popularized
problems is a by DeMarco [DEM79]. In his book on the subject, DeMarco introduced and named the
problem.”
key graphical symbols and the models that incorporated them. In the years that fol-
Theodore Rubin
lowed, variations of the structured analysis approach were suggested by Page-Jones
[PAG80], Gane and Sarson [GAN82], and many others. In every instance, the method
focused on information systems applications and did not provide an adequate nota-
tion to address the control and behavioral aspects of real-time engineering problems.