4.WORKING FROM IGNORANCE: Recognize That Requirements Change

While developers disagree vehemently about the optimum granularity of software requirements documentation, they are in complete agreement about another aspect of the process: The requirements will change. According to developers, however, managers and CIOs apparently prefer to imagine that the software will adhere to the requirements document even when it's wrong or misleading. The clueful CIO will understand this key fact, as well as the importance of building a change management process into the development lifecycle so that changes can be controlled and dealt with.

The first issue in changing requirements is the notion of estimating project effort. Brian Marick, an independent consultant on agile methods, points out that every project starts from ignorance; you have the least amount of data available with which to make sane decisions. "If you knew now what you'll know tomorrow, the decision would be better," Marick points out. This isn't an excuse for procrastination, per se, but a philosophy of waiting where appropriate. That often means removing detail, such as deciding only on the broad product direction, and specifying details one piece at a time. However, he cautions, "This approach requires careful attention to feedback from the real world, so that you in fact take into account tomorrow's information when making tomorrow's decision, and constantly improving your ability to react to change and recover from mistakes. It does no good to know what the right decision is tomorrow when you do not have the resources to implement it."

Scott Ambler, practice leader Agile Development within the IBM Methods group, agrees that getting a "solid" estimate up front is a naive desire. "That one decision motivates a whole bunch of really bad practices, such as big requirements up front (BRUF), big design up front (BDUF), and judging the project team on whether they meet the budget instead of whether they achieved great ROI."

Poor or underspecified requirements aren't necessarily a sign of incompetence. An experienced software architect and lead developer at a CMMI Level 5 company suggests that requirements are inadequate for conveying everything necessary up front. "It's partly because the users are not always able to express all their actual needs; partly because requirements do not describe current work practices, but rather describe expectations for the future system; and partly because requirements have to address many business-related aspects, such as vendor selection, cost estimation and contractual obligations," he says.

But whether it's a contractual requirement to dot all I's and cross all T's, or simply the way you learned to scope out every project, your programming staff wants you to recognize that change is the norm rather than the exception. "We need to turn away from the traditional approach of trying to nail down all the detailed requirements up front, and then imposing so-called 'change control' processes designed not to control change, but to discourage it. Instead, CIOs should actively and firmly support methods that embrace change and deal with it gracefully, as agile and lean methods are meant to do," agile developer Dave Nicolette says.

Since requirements change over time, Hazen points out, the process needs to be managed appropriately. There will be reviews and sign-offs again. The project time line must be revisited to determine if deadlines remain realistic. At some point, you do have to freeze the changes and move forward. "Scope creep is a killer for projects, especially ones that are time constrained, which the vast majority are," says Hazen.