Requirements: The More the Better?

Abstract

Nothing ever, ever, becomes a requirement until two things happen: (1) there is a solid understanding and acceptance of the requirement's cost and schedule implications; and (2) knowledgeable technical people are so confident that the program can meet the requirement within the cost and schedule that they are willing to bet their jobs on it. Yikes!! Does this mean that we never undertake high-risk projects? No. what it does mean is that when you undertake high-risk activities, you agree on an expectation or requirement that includes failure, or falling short, as a real possibility, and your cost and schedule reflect the risk. The other thing that it means is that you may have to start a project with some requirements open until after the work progresses to a point where the requirement meets the two criteria above. The process is also flawed because there are usually too many requirements. Something about the engineering or designer mentality seems to demand hosts of requirements as an input to the technical process.