Page 320 -

CHAPTER 11 ANALYSIS CONCEPTS AND PRINCIPLES 291

work only if a library system is developed so that components that do exist
can be cataloged and then retrieved. It should be noted that an existing soft-
ware product can be used as a prototype for a "new, improved" competitive
product. In a way, this is a form of reusability for software prototyping.
Formal specification and prototyping environments. Over the past two
decades, a number of formal specification languages and tools have been
developed as a replacement for natural language specification techniques.
Today, developers of these formal languages are in the process of developing
interactive environments that (1) enable an analyst to interactively create
language-based specifications of a system or software, (2) invoke automated
tools that translate the language-based specifications into executable code,
and (3) enable the customer to use the prototype executable code to refine
formal requirements.

11.5 SPECIFICATION

There is no doubt that the mode of specification has much to do with the quality of
solution. Software engineers who have been forced to work with incomplete, incon-
sistent, or misleading specifications have experienced the frustration and confusion
that invariably results. The quality, timeliness, and completeness of the software suf-
fers as a consequence.

11.5.1 Specification Principles
Specification, regardless of the mode through which we accomplish it, may be viewed
as a representation process. Requirements are represented in a manner that ulti-
mately leads to successful software implementation. A number of specification prin-
ciples, adapted from the work of Balzer and Goodman [BAL86], can be proposed:
1. Separate functionality from implementation.
In most cases, it is
unreasonable to 2. Develop a model of the desired behavior of a system that encompasses data
expect that the and the functional responses of a system to various stimuli from the environ-
specification will “cross ment.
every t and dot every
i.” It should, however, 3. Establish the context in which software operates by specifying the manner in
capture the essense of which other system components interact with software.
what the customer
requires. 4. Define the environment in which the system operates and indicate how “a
highly intertwined collection of agents react to stimuli in the environment
(changes to objects) produced by those agents” [BAL86].
5. Create a cognitive model rather than a design or implementation model. The
cognitive model describes a system as perceived by its user community.
6. Recognize that “the specifications must be tolerant of incompleteness and
augmentable.” A specification is always a model—an abstraction—of some