The customer who doesn't know what they want:

http://dilbert.com/strips/comic/2006-01-29/

I'm a "grey beard" and I've run my own shop several times. I've always insisted on detailed specifications, signed off by the customer, before development work begins (we don't count prototyping as development work). I had a sales geek grouse once about "how much time it was taking to design the thing, why can't we just do it?" When the next project came in, I let him run with it and "just do it." Afterwards -- after all the carnage, scopus creepus maximus, missed dates, gross budget overruns, etc. -- he came to me and said, "OK, point taken, we should always get specs signed off at the beginning." Experience has shown me that people who "just do it" are spending more time on a project than if the scope/requirements/sign-off steps are followed.

The Business Analyst should always be getting the scope, requirements, and high-level design done before handing it off to the development team. The developer should be responsible for the details*. In terms of SQL, I document what kind of data is to be captured and approximately how much of it is coming in, and the DBA and developer team up to determine the types and sizes...the details.

Hopefully everyone has seen the classic "what the customer wanted" drawings (they wanted a tire swing, got a barcalounger hung from steel girders) and it shows how important it is that everyone is on the same page, singing the same hymn, at the same stanza and note.

(* - Although one time I was a BA for a hospital system shop and we had a mainframe Y2K project outsourced to India, and they couldn't figure out what had to be done and insisted on a detailed specification document with the specific changes we wanted. I had to, for each of the 140+ CICS and batch COBOL programs, list the row number where the code to be changed was found and show the before and after changes. I pointed out to the VP of development that if I was going into each program anyway and document the changes, why not have me make the changes and be done with it? Turns out the CEO "had read a magazine" and wanted an outsourcing firm to do the "menial" tasks and no amount of logic could change his mind. Needless to say we spent a lot of time and money to get specifications for someone who should never have been allowed near the code in the first place.)