This is one of the best papers I've ever read for making the case for Agile Methodologies. It's long, but well worth it. So fight through (that means you, Scott).

Here's an excellent excerpt about the problem with doing up-front requirements sign-off (i.e. taking the Waterfall approach):

Here's the problem. Suppose you say to customers, "Okay, we're going to give you a system to solve XYZ problem. We're going to gather all of the requirements, analyze them, and write them down in a big book for you to review. Your job is to make sure we have gotten everything right, because once we start coding, you can't make any changes. So we're going to ask you to sign-off on the requirements, and then if you want any changes, we'll estimate the cost and you'll have to approve the change.

Now let's assume that the customers don't really know what they need to solve XYZ problem (that's why they asked you to solve it). Thus, they are worried that they might forget to tell you something as you gather requirements, so they try to be very thorough. The process does not ask them to be sure that they need something when they put it on the requirements list; the process encourages them to put everything on the list unless they are certain they will not use it.

Is it any wonder that a system developed under these rules will have many features that end up in the rarely-if-ever used category? In our standard approach to defining scope, we build in tremendous incentives for excessive scope. Freezing scope usually has exactly the opposite effect that we desire. It does not prevent scope creep; it causes scope bloat.

FYI, I ran across this via another excellent post by Darrell Norton with a response to concerns about agile approaches. If you are interested in this subject, you should read that as well.