Applied Software Project Management

Introduce Software Requirements Carefully

There are plenty of books that tell us that poor requirements are the most common cause of software quality problems. Yet many project managers have had difficulty bootstrapping efforts within their own teams to implement better software requirements practices. Software requirements should make intuitive sense: before a team can build software, they need to know what to build. In practice, however, many project managers have found that it is difficult to convince their teams to adopt good software requirements engineering practices. This is especially true for certain kinds of projects:

• Small projects in which the programmer is confident that he understands all of the requirements already

• Projects in which "everybody" knows what the software is supposed to do

• Projects without a user interface (like batch processes or back-end calculation software)

• Any project considered "technical"— one in which one or more of the stakeholders is a programmer

In all these projects, there is an expectation that a programmer can make all of the decisions about the behavior of the software. It seems intuitive (but incorrect) that since the programmer can already decide on the details of the implementation, he should also have a grasp on what is being implemented. The programmer is often the most confident person in the organization about his own ability to do this, which the rest of the team and the stakeholders always find reassuring.

This is a difficult situation ...