Software Engineering Institute Carnegie Mellon

ASP Main Page
About ASP
Areas of Work
News
CMMI Acquisition Module
CMMI-ACQ Model
Acquisition Patterns of Failure
Publications and Presentations by Topic
Presentations
Publications by Type and Date
Related Materials
Adventures of Ricky and Stick
Success Stories
Pilot Studies
Useful Sources & Links
Training
Conference on Acquisition of Software-Intensive Systems
Contact Us

Ricky & Stick - A Grab Bag of "Want-to-Haves" Is Not a Requirements Set

Ricky & Stick main page

The process of software system development often involves an ongoing process of refining requirements. And that refinement process is very susceptible to requirements creep, growth, and explosion. It's the same danger that Mom is always warning Ricky about: "Your eyes are too big for your stomach," she says, which he usually ignores.

Yet the rest of us are often deaf to that same warning. It all starts when a bunch of people start out with a good idea: "Let's get rid of these overlapping, obsolete, redundant systems!" So a project begins, and the early requirements are defined. Then everyone goes over to the Dark Side: "Now that we see what we've started, why don't we reengineer ALL of our seventy-three thousand processes into one central, unified, joint, all-purpose, galactic, do-it-all, never-have-to-worry-again INTEGRATED SYSTEM!."

What's happened is that the understandable desire to eliminate redundancy and incompatibility has transformed itself into a greedy desire for something that ignores practicality and precedent. We get giddy with possibilities, and imagine a cosmically large system whose humongous list of functional requirements makes any development effort prone to failure. And in those giddy moments, it's easy to forget that the pages of acquisition history are littered with tales of failed programs slain by impossible requirements. (And this same scenario also shows there are lots of things that are excellent when taken individually, but awful when put together willy-nilly. A different moral, perhaps, but one worth noting.)

The lesson is that, even taking into account the incredible flexibility of software, a coherent system needs some internal integrity and boundedness to it. More important (from the viewpoint of the poor soul who has to manage its development), a system's requirements should ideally reflect some comprehension of whether those requirements can be satisfied.


For More Information

Send comments or questions to asp-requests@sei.cmu.edu


return to top
Ricky & Stick main page
Acquisition Support main page