Page 321 -

292 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING

real (or envisioned) situation that is normally quite complex. Hence, it will be
incomplete and will exist at many levels of detail.

7. Establish the content and structure of a specification in a way that will enable
it to be amenable to change.

This list of basic specification principles provides a basis for representing software
requirements. However, principles must be translated into realization. In the next
section we examine a set of guidelines for creating a specification of requirements.

11.5.2 Representation
We have already seen that software requirements may be specified in a variety of
ways. However, if requirements are committed to paper or an electronic presenta-
tion medium (and they almost always should be!) a simple set of guidelines is well
worth following:

Representation format and content should be relevant to the prob-
? What are a lem. A general outline for the contents of a Software Requirements Specifica-
few basic
guidelines for tion can be developed. However, the representation forms contained within
representing the specification are likely to vary with the application area. For example, a
requirements?
specification for a manufacturing automation system might use different
symbology, diagrams and language than the specification for a programming
language compiler.
Information contained within the specification should be nested. Rep-
resentations should reveal layers of information so that a reader can move to
the level of detail required. Paragraph and diagram numbering schemes
should indicate the level of detail that is being presented. It is sometimes
worthwhile to present the same information at different levels of abstraction
to aid in understanding.
Diagrams and other notational forms should be restricted in number
and consistent in use. Confusing or inconsistent notation, whether graphi-
cal or symbolic, degrades understanding and fosters errors.
Representations should be revisable. The content of a specification will
change. Ideally, CASE tools should be available to update all representations
that are affected by each change.

Investigators have conducted numerous studies (e.g., [HOL95], [CUR85]) on human
factors associated with specification. There appears to be little doubt that symbology
and arrangement affect understanding. However, software engineers appear to have
individual preferences for specific symbolic and diagrammatic forms. Familiarity often
lies at the root of a person's preference, but other more tangible factors such as spa-
tial arrangement, easily recognizable patterns, and degree of formality often dictate
an individual's choice.