Page 125 -

There is a risk that when nontechnical people read the SRS draft, they will fail to under-
stand what is written in it and simply agree to whatever is written down. This often hap-
pens in an organization in which software requirements have never been used before. To
address this problem, the project manager should work to help everyone understand why
it is so important that they take the time to read and understand each SRS draft. This often
requires sitting down with each person to make sure he really read and understood the
document. Even if that seems time-consuming and patronizing, it’s better than losing an
enormous portion of the project’s effort because the team is busy fixing defects that could
have been caught in the first place.
If users and stakeholders are used to playing with intermediate builds and vetoing soft-
ware features that they don’t like, they may object to sitting through a walkthrough meet-
ing rather than waiting until the programmers produce something. However, that’s a very
costly way to build software. Words on a page are much easier to change than functions
and objects in source code. A defect that only takes a few minutes to fix in a draft of an
SRS can require days, weeks, or months of the most irritating sort of programming to
repair after it’s been coded. This is why it’s in the project team’s best interest to catch the
defects as early as possible.
Another problem is that some people may not read repeated drafts; after seeing the first
few drafts, they may start to ignore later revisions. One way to reduce the risk of this hap-
pening is to keep the initial iterations’ review teams very small, and only expand them
when the draft is close to completion. People who are not used to reading technical docu-
mentation are much more likely to read a single draft than they are to read a half-dozen of
them. But in the last iterations, it still may be difficult to get nontechnical people to work
their way through a technical document. This is where a walkthrough can be a useful tool
to ensure that everyone understands the document. (See Chapter 5 for more information
on walkthroughs.)

Requirements Differ from Design
Many people have trouble understanding the difference between scope (which demon-
strates the needs of the organization), the requirements (which describe the behavior of
the software to be implemented), and design (which shows how the behavior will be

implemented). It is hard for them to describe the behavior of a piece of software without
talking about windows, forms, buttons, checkboxes, clicking, dragging, etc. The difference
between scope, requirements, and design is a very important distinction that the entire
project team should be familiar with.
Table 6-13 shows several examples that illustrate the difference between the user needs
that might appear in a vision and scope document, the behavior that might appear in an
SRS, and the design that might appear in a design specification or code comments. As a
general rule, unless the requirements analyst specifically intends to constrain the design-
ers and programmers, design elements should be left out of the SRS.

SOFTWARE REQUIREMENTS 117