当たり前ですが、オフショア開発向けの仕様書っていうのは存在しません。
　ただ、オフショア受託側に好まれる仕様書というのは存在します。
　開発のエンドであるPGが好む普通の仕様書でいいんですけどね。
　オフショア開発の場合、仕様書が最大のコミュニケーションツールになるので、重要です。

　よく言われるようなUMLモデリングとかどうとかは、きっと便利ですが、必ずしも、そのようなテクニックが全てを解決するとは思えません。
　仕様書の判読性で開発の効率はぐっと変わってきます。
　結構、馬鹿にならない工程です。
　もし、仕様書に不明な点があったら、質問をなげるか、自力で調べる作業のどちらかが必要です。
　調べるものであれば、調べればいいだけですが、調べても分からないもの、一言あれば、調査の時間が短縮出来るものについては、記述があれば助かります。
　
　特に、オフショアの場合、クライアントから一次請けをするケースは非常に少ないでしょうから、仕様の質問に対する戻りはオンサイトよりも余計に時間を要します。
　戻りを待つ間、平行して別の画面を作るなどのパラレルな動きをしていく事で稼働率を上げる工夫は出来ますが、それでも、一度で読み取れる事が理想です。
　
　もちろん、仕様書を細かく書けば書くほど、時間が掛かり、上流工程のコストが増えます。
　それはそれでコスト増に繋がりますし、一般に、下流工程よりも上流工程のエンジニアの確保の方が難しいです。
　確かに、仕様書の品質向上と共に、PG側の読解力を向上させる必要もあるというのは最もです。
　しかし、オフショアでは、仕様書を書く人と仕様書を見てコードを書く人が距離的に分断されるという前提がある為、限界があり、互いにポイントを合わせた仕様書作りが必要です。
　この辺りは技術論ではなく、協力して作業を行った経験の蓄積かも知れません。

　顧客とノウハウを積み上げる事が最も重要だと、思っています。
　その為には、弊社はサイレントな下請けにならないようにしたいと思っています。　　　

　とは言え、発注元に仕様書改善要求を上げるのは、結構、勇気が要るんですけどね。　
　弊社の能力不足の指摘を受ける可能性もありますし、発注元（＝顧客）の怒りを買う結果になる事もあるので。
　しかし、怒りを買っても、最終的なところで迷惑を掛けるよりはいいと思っています。
　継続的な関係になっていく為には、顧客と弊社の両者がナレッジを溜め、次回以降、もしくは、現在の案件の改善に繋げていければ、恒久的な関係になれると考えています。