I worked on a project once where I got the 'report' requirements from the Business Analysts, and it simply said they wanted a report for EVERYTHING (literally, that is what it said).

There was no breakout or list, there were no examples, nothing, it just said a report for EVERYTHING. I very well could have applied my own interpretation to that and delivered a stack of reports (would have been about 50, rough estimate), but is that using project resources (time and money) wisely?

Intuitively, I looked at this and figured out that the Business Analyst either did not have the time or the knowledge (or just didn't feel like it) to properly research and assess the needs of the customer and provide requirements information that was realistic (at least give me a list and description of each report). I took it to my boss and showed him and he agreed with me, that we should go back to the Lead BA and get more clarification because this was going to be a big endeavor (on an already huge project), and at least get a sanity check, and if they truly do NEED EVERYTHING, then get a list of deliverables and some kind of requirements for each. I also told the lead BA that it looked like someone didn't feel like doing this (we were all spread thin) and that I can give him 50 reports (and that count was just a guess), but do the users NEED these, and will they use these, or will they just get printed out, then sit on someones desk until they get thrown in the trash (how many times have we seen this).

When the lead BA got back to me, the list was down to 5 reports (a far cry from the original 50) and I had requirements for each (which is how it should have been)

So by using a little intuition and questioning the requirements (it was obvious they were lacking) we were able to get more realistic requirements that ultimately saved a lot of time and money, both of which were in short supply. Personally, I believe the requirements should have never made it to me, they should have been caught in the approval process, but at least there is some notion of checks and balances in the entire process.

Had I gone ahead and given the users 50 reports with the vague requirements I had, the chances of me getting it right would have been pretty slim and it would have made us all (the project team) look stupid.

This is analogous to asking a home-builder to build you a house without providing any input. I'm sure he could build a very nice well built home, but will it suit your needs? I'm sure it would have been a successful project to him (he did what he was asked), but most likely, he would not have met all your needs simply by guessing. Realistically, no builder is going to do this...he is going to ask you what you need and then deliver that. And so it is the same in software development...we have to use our own judgement to assess requirements (or lack of) and designs and go back to our analysts and end users and find out what it is they WANT, and more importantly, what they NEED. At least then everyone is 'on the same page' as far as project expectations are concerned and you have a better chance of overall project success.