Page 135 -

The way to sell the managers on requirements engineering is to speak their language.
Most senior managers who are in charge of making project decisions are most concerned
with getting the product out the door faster, and with getting fewer calls from users who
have found that the software does not do what they need it to do. The project manager
who is trying to put the software requirements tools in place should show the manager
how they can fix these very serious problems that have plagued past projects. The goal is
not to drive a wedge between the programmers and the stakeholders and users. Rather,
requirements help everyone reach the same goal.
A common complaint among stakeholders and users is that programmers have not taken
the time to listen to them before starting in on building the software. If this goes
unchecked in an organization for too long, people can start to see the programmers as
cocky. A project manager working on selling the idea of requirements can look for exam-
ples of this in the organization. There are probably instances in the past when a program-
mer has assured a stakeholder or user that he understands exactly what she needs, only to
go ahead and build something that only does half of what the stakeholder wanted, plus a
bunch of stuff that doesn’t make any sense at all. There may be a piece of software out in
the organization that has a bunch of confusing buttons or menu options; it’s possible that
the intended users don’t even know what they do. There may have been a rollout in the
past where the users had to alter the way they did their work in order to accommodate the
software. These are all advertisements for adding software requirements engineering
activities to the next project, and the project manager can use them as examples of the
kinds of problems that software requirements can fix.
Selling the idea of requirements to senior managers and decision-makers usually takes a
lot of effort. The project manager will have to repeat herself many times. In many organi-
zations, the managers do not really understand how the software gets built—they leave
those “technical details” to the engineers. Luckily, software requirements engineering
activities lend themselves to explanations in simple, layman’s language.
It should make intuitive sense to a senior manager that the programmers are not mind-
readers. It’s likely that they have neither the time nor the inclination to sit down and
interview everyone who may have something to add to the project. And the experts do

not have time to make themselves available to the programmers for the entire length of
the project. The solution is clearly to have someone sit down and talk to the people who
need the software built. That person should be a software engineer capable of eliciting
software requirements and building a feasible software requirements specification. Most
managers should understand this on a “gut” level.

Diagnosing Software Requirements Problems
Project teams that have problems specifying the software requirements often find that
their projects suffer from a few typical problems. Strangely, many programmers and
project managers do not realize that they are problems at all. There is a common and mis-
taken belief that they are just characteristics of how software is typically developed. But

SOFTWARE REQUIREMENTS 127