I just read this little, uninformative and rather opinionated post on why documentation is required: http://www.spoiledtechie.com/post/Why-do-I-document-Code.aspx.

I certainly believe there is a time and place for documentation, the rigors that Scott suggests in his post are completely over the top.

I don't think Scott necessarily has to believe in the same level of documentation as I do; however, I find this statement to be detrimental to software development as a whole:

Everyone knows that the customer always changes their mind, well if you use the SRD, they are held by a legally binding contract that specifically states what to develop.  You as a developer don't develop anything else except for what this document states.  Therefore if the customer changes their minds, well you can either point back to the SRD or decide to charge them more money

Anyone who believe that because you hold a SRD in your hand that entitles you to charge your customer more, or push back and refuse to do work, should not be in software development. You are providing a service to your customer. If you deliver something the customer doesn't want or need then you haven't provided a service. Is there a cost associated with change, of course. Take a quick look at any of the recent movements in software engineering: TDD, Agile, Lean, etc., and you can see that there are a lot of attempts at reducing that cost. Refusing to do the work doesn't help you as a software engineer; it hurts your customer. If you are a consulting company and your customer is an outside agency, then you need to consider the change, and the cost associated with it, and make sure your billing structure accounts for the unexpected. If your customer is the company you work for, then you are only hurting your company.