My favorite project I did started off with the specification of "Make the knowledge base browse-able." Thats it. One sentence. I worked with the knowledge manager (who was responsible for the data and structure of the knowledge base), and a user interface guy. And we did it. Turned out to be a very successful project in part because the goal downer (same as gold owner in this case) didn't have any preconceptions of how the final thing worked - just that it worked and trusted us enough to let us make it.
On the other hand, there have been projects with many integration points between different teams where there were dozens of xsds floating around that specified every detail of the interface. The business came to us with mock ups of what they wanted and all the rules for how each field behaved and what was sent to the other systems. This worked too - and it was necessary. If any one team went off and did their own thing, it would have fallen like a house of cards once we tried to put it together. There were reams of paper that represented various versions of the specification.
Recently, one of the companies that subcontracts work to my current employer commented that they are very happy with us because they give us not much in the way of specifications and we do what they were thinking (our project managers must be telepathic).
There is no right answer, it depends completely on what the expectations of the client (be it another business uint in the company you work for, or an external client). The more they expect things and the less they trust you do to the right thing and accept what you give them, the more the work will need to specified.
One set of the approaches that was taken up to try to address this are the iterative methodologies. The idea with these is you build something in a short time period and then ask "is this what you were thinking?" Each iteration you add functionality or change it as the client asks. The most well known of these approaches is agile (which itself encompasses a range of methodologies).
As to books? There are dozens of them. Seriously, dozens. Maybe dozens of dozens if not more (there's no one book that we can tell you will solve that problem - just go into the project management section of a library or bookstore and start thumbing through them).