Page 312 -

CHAPTER 11 ANALYSIS CONCEPTS AND PRINCIPLES 283

5. The analysis process should move from essential information toward imple-
mentation detail.

By applying these principles, the analyst approaches a problem systematically. The
information domain is examined so that function may be understood more com-
pletely. Models are used so that the characteristics of function and behavior can be
communicated in a compact fashion. Partitioning is applied to reduce complexity.
Essential and implementation views of the software are necessary to accommodate
the logical constraints imposed by processing requirements and the physical con-
straints imposed by other system elements.
In addition to these operational analysis principles, Davis [DAV95a] suggests a set 6
of guiding principles for requirements engineering:

• Understand the problem before you begin to create the analysis model. There is
a tendency to rush to a solution, even before the problem is understood. This
often leads to elegant software that solves the wrong problem!
• Develop prototypes that enable a user to understand how human/machine inter-
“A computer will do action will occur. Since the perception of the quality of software is often
what you tell it to based on the perception of the “friendliness” of the interface, prototyping
do, but that may be (and the iteration that results) are highly recommended.
much different from
what you had in • Record the origin of and the reason for every requirement. This is the first step
mind.” in establishing traceability back to the customer.
Joseph
Weizenbaum • Use multiple views of requirements. Building data, functional, and behavioral
models provide the software engineer with three different views. This
reduces the likelihood that something will be missed and increases the likeli-
hood that inconsistency will be recognized.
• Rank requirements. Tight deadlines may preclude the implementation of every
software requirement. If an incremental process model (Chapter 2) is applied,
those requirements to be delivered in the first increment must be identified.
• Work to eliminate ambiguity. Because most requirements are described in a
natural language, the opportunity for ambiguity abounds. The use of formal
technical reviews is one way to uncover and eliminate ambiguity.
A software engineer who takes these principles to heart is more likely to develop a
software specification that will provide an excellent foundation for design.

11.3.1 The Information Domain
All software applications can be collectively called data processing. Interestingly, this
term contains a key to our understanding of software requirements. Software is built

6 Only a small subset of Davis’s requirements engineering principles are noted here. For more
information, see [DAV95a].