Page 124 -

any planned software behavior a project team member, user, stakeholder, or decision-maker
does not agree with. This means that defects could be caused by any number of problems:

• Somebody does not believe that the planned behavior will satisfy the users’ or stake-
holders’ needs.
• Somebody believes that those needs may be better satisfied with different behavior.

• An inspector does not understand what’s written or feels that it is ambiguous or confusing.
• A project team member does not believe that the behavior can be implemented as written.
• Two or more requirements contradict each other—an implementation that satisfies one
cannot satisfy the others.

If there is a requirement in the SRS that has one of these problems, it must be identified
and fixed so that everyone agrees on everything in the document. There will almost cer-
tainly be defects that slip through—no inspection team is perfect—and each of these will
cost much more time to fix after it has been designed, coded, and tested than it would
have if it had been caught using the SRS development script. The goal is to find as many
defects as possible, in order to reduce the amount of time that the team must spend later
on in the project undoing the few that slipped past.
One of the most common mistakes in software engineering is to shortchange the SRS. A
good project manager knows that the fastest way to finish a project is to take the time up
front to get the requirements right. For many managers, however, cutting the require-
ments short sometimes seems tempting. They are impatient to have the programmers
begin working on something concrete that they can use, and do not necessarily see the
value of planning the behavior of the software before it is built. But skipping the software
requirements activities will always come back to damage the project later. Any defects in
the SRS will get magnified in later work products. If a defect is left in the SRS and not
caught until testing, that defect will be designed into the software. If the defect is still not
caught in the design phase, then code will be built to implement that design, and a test
plan will be created and executed that verifies that behavior is accurately reflected in the
final build. When that defect is eventually discovered by a user, fixing it will require an
enormous amount of effort from the entire project team. This is why it is worth spending
time doing extra iterations of reviews at the outset of the project—it’s much more efficient
to build the software right the first time than it is to go back and fix it later.
The best way to prevent defects is through iteration. This is why the SRS development
script calls for repeated reviews of the SRS. It may seem to the project team that they are
sitting through redundant deskchecks, walkthroughs, and inspections of a single SRS. It is
sometimes tempting to cut this process short and declare that the SRS is “good enough.”
The project manager needs to resist this urge. When the SRS goes through what some
people might perceive as “yet another iteration,” it’s because somebody found a defect in
it that needs to be fixed. If this defect is not fixed now, the effort required to fix it later will
dwarf the effort required to do another review of the SRS.

116 CHAPTER SIX