Control Changes to Requirements
Of all of the effective requirements practices, this one is among the most critical, perhaps second only to the need to discover and emerge the real requirements. Capers Jones reports that creeping user requirements is endemic to the software industry and that its severity is directly proportional to the size of the application. He believes that the real problem is inadequate methods, tools, and approaches for dealing with creeping requirements in a way that minimizes damage to the structure of the software, schedule slippage, and other related problems. Whitten notes that one of the most common problems with projects is taking on too much work--attempting to exceed requirements rather than to meet minimum requirements. "Meeting minimum requirements" means providing the client what is needed. Don't provide unessential function. Whitten takes issue with the premise that meeting minimum requirements is unexciting and noncompetitive. He feels that deliberately practicing meeting minimum requirements helps an organization or company to be first-to-market, earn increasing credibility from clients, and strongly posture their enterprise for taking on new business opportunities.
The lack of an effective mechanism to deal with changes is a critical weakness in most system and software development efforts today. Without it, it's not possible to maintain control of the project.
Years ago, the conventional approach was to insist that the requirements be "frozen" before the development work proceeded. However, more recently, we've come to recognize that we can't hold requirements constant because the real world continues to change while we develop. We need other ways to deal with a changing world, or else the capabilities of our delivered systems will differ significantly from the real customer and user needs.