http://wiki.c2.com/?CoverYourAssets
総花(そうばな)主義は別の言い方をすると、八方美人です。自分では何の考えも持たず、たんに誰からも恨まれなければいいと、重要度を無視して網羅的なふるまいをすることを批判する言葉です。英語では少しニュアンスが違い、Cover Your Assets (財産奪い合いカードゲーム) という名前になっていますが、その根本問題は同じです。
すべての仕様が書かれていれば間違いではない、つまり、自分は悪くないから他の誰かが引責ペナルティを喰らうだろうという心理から思考停止して、あらゆることを均一に網羅した文書を作ると、じっさいは他の誰の役にも立ちません。意味を失っているため読みにくく、そのうえ量が多すぎてたいへんです。とくに、他のシステムの担当者が副次的な関連資料として見を通すには、あまりにも不向きです。ソースコードが仕様書ですと渡されたほうがまだ、IDE でコードリーディングできるぶん、いくらかましです。
また、文書には機械的に正しさを保証してくれる道具を使えません。じっさいの動きを知る人が、目で見て間違っていないことをチェックしないといけないため、量が多いと指数関数的に間違いが増えます。(単純に量に比例するのに加え、目を通せる回数が減り、関連する情報の距離が遠くなるからです)
ドキュメントが先行する開発プロセスでは、仕様書のミスが後の工程への責任問題になるので、概要のわかりやすさよりも総花的なやり方での保身を優先する心理に陥りやすくなります。話の合わないライバル (曖昧な視点
のために利害が競合した要求側と設計者など) に仕様ミスを追求されて失脚したくないというのは、プロダクトにとっては無駄な努力であるだけでなく、理解しやすい状態を維持するうえではむしろ迷惑です。
要求と設計と実装とテストを繰り返す開発プロセスの中で、メンバーが同じ価値観を共有しながら、文書も徐々に正しさの精度を高めていくのが健全です。じっさいに繰り返し使われた文書は、開発の中でフィードバックを受けた推敲結果が残るので、後で見る人も安心できます。
「仕様書の厚みがあると安心する」と言うのは、趣味の悪い冗談か、そうでなければ、自分の愚かさをアピールしていることになりますね。