Some how we have to get to a meeting of minds. I know what I consider documentation and I have consistently said that if I am called up at 3am in a decaffeinated state after nursing a sick toddler the documentation has to be sufficient to resolve a production issue.

That said, if the requirements are not written in sufficient detail then how can developers write suitable tests for test/business driven development?

Are developers the right people to write documentation? Should there be a job role that sits somewhere between development and business analysts that produced the documentation?

There is a principle of "if it hurts, do it more often". You'd think that the development community would have applied their brains to this.

I think the problem lies in that business users actually use the end product of software and the idea that continuous integration increases quality and (possibly) speed of delivery is something they can buy into.

Technical documentation is something they will never read or see so if the development community whinge about doing it the business is not going to crack the whip to get it done.

There is nothing like a healthy dose of outsourcing to shine a glaring light on the inability to write decent requirements. Every change costs money, the costs can't be lost in internal bureaucracy.