Page 205 -

Requirements Haven’t Been Implemented
When a software team delivers a product that’s missing features, the users tend to notice.
It seems like this should never happen—aren’t there many reviews and checkpoints along
the way that ought to prevent it? In fact, the only time when the original requirements
are ever checked against the final software is during software testing. And if there is a
problem with testing, the most serious symptom is unimplemented requirements.

There are many reasons why requirements do not get implemented. Sometimes a designer
or programmer does not understand what’s written in the specification, or has a different
understanding than what was intended. But sometimes it’s simply an oversight. Good
review, requirements, and programming practices will help reduce this—instead of miss-
ing features, there might only be a few requirements that have rules that are not fully
implemented. But it is rare for the programmers to deliver software that completely meets
every single requirement.
Missing requirements are especially insidious because they’re difficult to spot. It’s not hard
to tell that something is there that shouldn’t be; it’s much harder to recognize when some-
thing important is not there at all. Often, a programmer will be completely taken by sur-
prise when a user comes back to her and asks where a certain feature is in the software.
It’s especially likely that the missing requirements are difficult to spot because even the
programmer missed them when looking over his own work. Programmers tend to be care-
ful and meticulous people; they would have caught the obvious ones.
What’s more, the programmers do not necessarily see which requirements are more
important to the users and stakeholders—they all have to be built, and it’s up to the users
and stakeholders, not the programmers, to prioritize what is developed. So by the time the
software is built and delivered to the users, the requirements that are missing are difficult
to spot, but are still just as important to the people who asked for them. It is not uncom-
mon for a programmer to be surprised that a user even noticed that a business rule in a
requirement was not implemented: the programmer didn’t know that it was important,
even though the user saw it as absolutely critical. When this happens, the programmer is
both embarrassed and upset that all of his good work is ignored because some tiny rule

was missing; the user, on the other hand, considers the software unusable, and has trou-
ble even evaluating the rest of the work that’s been done.
Obvious Bugs Slip Through
In many software organizations, there is a general feeling that the software testers are not
very good at their jobs. Things that were written down and reviewed don’t get tested.
Applications are released with huge, glaring bugs, even though the testers passed the build
and said it was fine to release. There are several common reasons this happens.

Sometimes bugs slip through because of ill-trained software testers. Organizations that are
just setting up a software engineering group for the first time often don’t have a software
testing group at all, and don’t realize that software testing—like programming, require-
ments engineering, or design—is its own engineering discipline, requiring both training

SOFTWARE TESTING 197