Overview

Requirements hell is that particular circle of the Inferno where Sisyphus is pushing the rock up a hill, only to see it roll down again. Often misinterpreted, this myth has roots in reality. Sisyphus has actually reached the top of the hill many times; it's just that he keeps asking whether he's done, with the unfortunate result of being made to start over.

Perhaps the answer to getting requirements right is not to ask. On the other hand, I suspect the answer is that you just have to keep going, rolling that requirements rock uphill. This chapter lays out the terrain so that at least you won't slip and roll back down.

The needs of the user are, or at least should be, the starting point for designing a database. Ambiguity and its resolution in clearly stated and validated requirements are the platform on which you proceed to design. Prioritizing the requirements lets you develop a meaningful project plan, deferring lower-priority items to later projects. Finally, understanding the scope of your requirements lets you understand what kind of database architecture you need. This chapter covers the basics of gathering data requirements as exemplified by the Holmes PLC commonplace book system.

Ambiguity and Persistence

Gathering requirements is a part of every software project, and the techniques apply whether your system is database-centric or uses no database at...