Page 323 -

294 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING

In many cases the Software Requirements Specification may be accompanied by an
executable prototype (which in some cases may replace the specification), a paper
prototype or a Preliminary User's Manual. The Preliminary User's Manual presents the
software as a black box. That is, heavy emphasis is placed on user input and the
resultant output. The manual can serve as a valuable tool for uncovering problems
at the human/machine interface.

11.6 SPECIFICATION REVIEW

A review of the Software Requirements Specification (and/or prototype) is conducted
by both the software developer and the customer. Because the specification forms
the foundation of the development phase, extreme care should be taken in conduct-
ing the review.
The review is first conducted at a macroscopic level; that is, reviewers attempt to
ensure that the specification is complete, consistent, and accurate when the overall
information, functional, and behavioral domains are considered. However, to fully
explore each of these domains, the review becomes more detailed, examining not
only broad descriptions but the way in which requirements are worded. For exam-
ple, when specifications contain “vague terms” (e.g., some, sometimes, often, usually,
ordinarily, most, or mostly), the reviewer should flag the statements for further clari-
Software Requirements
Specification Review fication.
Once the review is complete, the Software Requirements Specification is "signed-
off" by both the customer and the developer. The specification becomes a "contract"
for software development. Requests for changes in requirements after the specifica-
tion is finalized will not be eliminated. But the customer should note that each after-
the-fact change is an extension of software scope and therefore can increase cost
and/or protract the schedule.
Even with the best review procedures in place, a number of common specification
problems persist. The specification is difficult to "test" in any meaningful way, and
therefore inconsistency or omissions may pass unnoticed. During the review, changes
to the specification may be recommended. It can be extremely difficult to assess the
global impact of a change; that is, how a change in one function affects requirements
for other functions. Modern software engineering environments (Chapter 31) incor-
porate CASE tools that have been developed to help solve these problems.

11.7 SUMMARY
Requirements analysis is the first technical step in the software process. It is at this
point that a general statement of software scope is refined into a concrete specifica-
tion that becomes the foundation for all software engineering activities that follow.
Analysis must focus on the information, functional, and behavioral domains of a
problem. To better understand what is required, models are created, the problem is