Page 133 -

This is a difficult situation for any project manager. It’s never a good idea to try to force the
team to accept requirements (or any tool, technique, or practice). But when software
requirements are the solution to the team’s most pressing problems, it’s up to the project
manager to convince the team to adopt good requirements practices. Chapter 9 gives
many examples of the kinds of problems a project manager may face, and suggests strate-
gies to deal with those problems. With requirements, however, there are a few additional
points that may make it easier for a project manager to convince the team to adopt good
practices.

Sell the Designers and Programmers First
Software architects, designers, and programmers who are used to working with software
requirements tend to find them so important that it’s difficult to imagine working without
them. But if they have never used requirements before, they instead tend to be resistant to
working with them. To the uninitiated, working with requirements may sound restrictive
and stifling. In organizations where this is the case, the problem is often compounded by
senior managers who do not have as solid a grasp on how their software is developed as
they should, and who will be very responsive to any complaints from their technical peo-
ple. A few negative comments from key programmers can be enough to pull the plug on
an entire requirements effort. Even worse, when an organization has not really embraced
the idea of software requirements, there is a real danger that the programmers will simply
say “yes” to any SRS that comes across their desks, only to ignore or change any require-
ments that they dislike when they actually build the software.
The key to using software requirements effectively is to help everyone in the organization
understand how those requirements will help them build better software. A project man-
ager who is looking to implement requirements should work to bring the designers and
developers on board. If a designer feels threatened by the changes, the project manager
should show him how the requirements define only the behavior of the software, and not
the design. A programmer may object that her creativity is being stifled; maybe she can be
shown that the requirements will help prevent the kinds of last-minute changes that cost
her weeks of work and made a mess of her code on her last project.

It’s not hard to communicate the benefits of change control to the engineering team,

because the change control process addresses some of the team’s most common com-
plaints. Most software engineers who are working in an organization that does not have
good requirements practices are always shooting at moving targets. Changing require-
ments are a daily fact of life, and even small projects feel like they rapidly spiral out of
control because of uncontrolled changes. A project manager can offer to control these
changes, so that the team can concentrate on building a good product once rather than
rebuilding a poor one over and over again. Once the programmers have been convinced of
that, it’s not hard to show them how software requirements are clearly a means toward
that end.
However, it is important that the project manager does not gloss over the fact that when a
designer or programmer is working to a set of requirements, it creates a more restrictive

SOFTWARE REQUIREMENTS 125