one of the tenants of the agile manifesto is that we have come to value "Working software" over "Comprehensive documentation".

One of the most challenging aspects of gathering requirements is that they are fluid, changing, and never fully 'captured' as we would like to imagine they are. Software is ever-emerging much like writing music.

If you're currently using requirements documents think about this for a moment... when the first draft of the requirements was shown to you as a developer you probably said "Seriously? Where's the rest?". A few versions down the road, it was starting to look like there was actually enough to begin writing. However, as you started writing some code you found more questions that you had to ask. Eventually, things, while not completely diverged from the requirements may just not have even been a part of the 'finished' requirements document.

I can't count how many times, even with very lavish requirements documents, that I ended up finding some little aspect that i had to 'figure out' (when i say that i mean i had to guess because no one knew the answer).

AND (tribute to mike vizdos)

This is ok.

And

Agile development takes this into consideration by urging you to write software that is "Incomplete" and then show it to your user to solicit feedback!

And

This is where many QA people get squeemish.

And they'll probably freak out because they think you're going to release code that isn't done yet!!! I mean how could you possibly release the ability to load documents without the ability to first save them!!! (In mike Cohn's book he talks about the product owner who wants to see how the loading of documents worked first because the product was going to revolve around that feature, and with user stories he was allowed to do that).

Vaibhav here puts up a good reason to follow this acronym of INVEST when making user stories. I can't explain it any better.

Once you implement the first user story you have working software and with working software, your customers can finally SEE what it is and begin making decisions about what to do next. Some people might say, well what if i already have my product and i'm just adding features to it? It works the same way, the stakeholders will get  a chance to see some fully implemented functionality (however small) from end to end and THIS is how they generate ideas and YOU get feedback that makes your product BETTER and more competitive.