納品されたシステムの検収は、
こちらでも、要求内容をもとにテストシナリオを作成し、
それが通れば、納品完了にしています。

また、仕様書については、開発元で作成したものを提出してもらいますが
要件定義・基本設計・テストを重視し、
詳細設計については、ソースにコメントがあればOKとしています。
ほしい情報が記載されていれば、見た目は気にしないです。
仕様書がない場合は、ソース等から起こす作業をこちらですることもあります。
メンテナンスではどうしても必要になるので。

ブラウザを使うシステム（Web系システムと仮定します）は
安価＋短納期での案件が多いので、きちんとした仕様書をお願いする場合は、
納期の延期（または別案件扱い）＋費用追加が発生する場合があります。
仕様内容もフォーマット化されていない場合が多く、
プロトタイプ等が仕様書と同じ役割を果たすこともありますし、
メモ帳や秀丸に箇条書きされたものが、仕様書代わりで使われるケースもあります。

プログラムを書くよりも、仕様書をきれいに書くほうが時間がかかるし、
開発手法が多様化してきているので、開発側と相談して納品物を決めるようにしています。
開発側でユーザ側にとって仕様書のもつ意味を理解しているところは、
仕様書もきちんとしたものが提出されてきます。