Page 134 -

environment than he is used to. This should be out in the open: otherwise, he will feel
that the project manager is trying to hide the obvious, which can lead to distrust and
reduced morale among the team members. Programmers can be convinced of the benefits
as well. It’s likely that interviewing users is the programmers’ least favorite part of the job,
and being handed an SRS that contains everything the users want, so that they do not
have to spend time talking to them, is often enough of a trade-off to make up for a small
reduction in freedom.

In the end, requirements are good for the designers and programmers, and it should not
be too difficult for a project manager to help them understand that. Once the engineering
team starts to see requirements engineering as a way for them to increase their quality,
reduce their rework, and make their projects go much more smoothly, it is much easier to
get the management of the organization on board.

Speak the Managers’ Language
Building software without requirements is similar to building a house without blueprints.
It’s possible to start hammering nails into wood, and the builders will probably come up
with some sort of structure that will stand on its own and provide shelter. But if those
builders start hammering nails before the blueprints are done, it’s almost impossible that
they will end up building a house that matches the blueprints. But this doesn’t stop man-
agers from trying to get the programming team to start building the software before the
requirements are complete.
Many managers do not understand why requirements engineering is important. All they
see is people sitting around and writing a bunch of documents instead of writing code. It’s
not immediately obvious to them why the team is “wasting” so much time on this. The
code has to be written, and they don’t see why the programmers have to wait until they
get these documents to begin writing it. It seems to them that the programmers can at
least get started on writing something. For a lot of managers, it’s very frustrating when pro-
grammers are not writing code—every day they see the team writing requirements is one
more day that the programmers didn’t get started building the software. When the design-
ers and programmers are not sold on the idea of requirements engineering, there is little
chance that anyone else in the organization will accept it.

Many managers don’t speak the language of software engineering. When this is the case,
any attempt to sell them on software requirements by giving a technical explanation
about software behavior and quality attributes will cause their eyes to glaze over. Some
managers are good at convincing engineers that they understand technical issues that are
really beyond them; a project manager might walk away from this conversation thinking
that no other person had agreed that the team should implement requirements engineer-
ing on a project. But this is probably the manager’s reaction to any technical change sug-
gested by a team member, and he will withdraw his “support” (or claim that he never
understood it in the first place and never really agreed) at the first sign of friction between
engineers.

126 CHAPTER SIX