... The task is not to complete the entire product perfectly, but to complete your software's functionality perfectly.

Good points -- but it actually looks to me like the thrust here should be how to write specifications that are appropriate, adequate, bullet-proof and idiot-proof, and also make sure that these specs are readily translatable into the chosen programming language, complete with all necessary testing protocols -- i.e. given that the spec says "input comes from X, consisting of N bytes, etc" the test has to say "here's what is supposed to happen when input comes from anything other than X, and/or does not consist of N bytes, and/or etc."

Most of the perl core documentation (and much of the extra module documentation) that I've seen has a lot of the properties that one would want for proper/robust software specifications -- the reader is told what inputs are needed or allowable for a given function/method, what it returns when used properly, and what happens when not used properly. And this is typically done using clear, simple language, not overburdened with nonce acronyms, jargon or "technical legalese", and yet not at all vague, either. I would hope that critical-impact projects would model the development of specs on such examples.

Admittedly, the theory (or practice) of robust software design in critical-impact apps is not an area where I should try to assert any sort of personal expertise. I'll shut up now.