Not collecting at least 75% of the coarse-grained requirements (by showing mock-ups, pictures, arrows, whatever) is like telling the techie people “we dont really know what we want or what you have to build, but we will surely tell you after you build it and we can see it”. Ability to be fully iterative, ability to “throw away prototypes” from the business guys who are spending dollars, I have yet to see.
The designers (not coders) of a project need an overall idea of the core requirements of the business problem. Else expect a patchy design and noodle code.
Either you are a good technical-business interface and know both sides, or you dont. In the latter case, collecting requirements to communicate them to techies is probably not what you should be doing.
The biggest problem I am increasingly facing is business experts or subject matter experts who have read up too much technology on the web. This tribe is growing exponentially, and what they often express is “i want an SOA”, they don’t often say “i want my sales staff to be able to communicate with the warehouses” – things like that.
