Requirements: Covering Your Rear End

If you've ever done a serious software project, you should understand that requirements-gathering is crucial to success. If you don't know what your customer wants, it's hard to deliver it. Short of developing psychic skills, your best bet is a solid functional requirements document (FRD) up front.

Of course, requirements-gathering is like anything else in software development. It's possible to become so bogged down trying to capture every nuance of the site that you never actually get around to coding it.

The analogy I use is this: Imagine that you're trying to get a rocket ship to Mars. I offer you two choices:

• Make one extremely well-calculated rocket burn at the launch pad, designed to deliver the ship into Mars orbit

• Make a reasonably accurate initial burn, and then do a series of mid-course corrections in flight

Now, the first approach is probably a little more fuel-efficient, but it requires an inhuman degree of precision in the original calculations. The second approach gets the ship off the pad much faster, but at the cost of a little more fuel (in the case of software, possible refactoring during development).

The punch line, of course, is that the first approach won't work at all if the customer suddenly moves Mars somewhere else. And moving Mars, or in this case changing requirements during development, is a fact of life.

So, with that in mind, the requirements-gathering shown here is a middle road between the search for total truth and jumping right in without understanding anything.