37signalsによって書かれたGetting Realからの短いエッセイ。 オリジナルはここで読むことができます 。仕様は抽象的なドキュメントであり、ほとんどの場合、完成したソフトウェア製品とは関係ありません。 なんで？ 説明させていただきます。
1.仕様はフィクションです彼女は現実とは何の関係もありません。 開発者がコードを記述し、デザイナーがインターフェイスを描画し、人々が完成した製品を使い始めると、アプリケーションが現実のものになります。 この仕様は、プロジェクトを何らかの形で完成させるものではありません。結局のところ、これらは紙の上の言葉に過ぎません。
2.仕様のタスクは、みんなを喜ばせることです仕様はすべてを一度に約束し、すべての人を幸せにしようとします。 これは称賛に値するが、まったく役に立たないアプローチです。 仕様では、複雑な妥協点を見つけて最適なオプションを選択することについては一切言及しておらず、アプリケーションを開発する際にこれなしではできません。
3.仕様は単なる合意の幻想です仕様の複数のページの下にある多くの保証署名は、合意ではありません。 あなたのチームは同じテキストを読みましたが、ほとんどの人はそれを独自の方法で理解していました。 そして、これは確かに将来の仕事で出てくるでしょう。 「待って、私はまったくそれを意味しませんでした！」、「やめなさい、私はそれを完全に異なって理解しました！」、「いいえ、いいえ、それはまさにそれであり、あなたはすべてそれにサインアップしました。」 あなたはこれがどのように起こるか非常によく知っています。
4.仕様では、プロジェクトについてほとんど知らないときに最も重要な決定を行うように強制します。何よりも、プロジェクトの最初の段階でプロジェクトについて知られています。 プロジェクトの期間が長くなるほど、プロジェクトについて学ぶことが多くなります。 それで、なぜあなたは始めさえせずに最も重要な決定をするべきですか？
5.仕様の使用は、不要な機能のファウリングにつながります仕様を書いている時点では、想像力以外には何も制限されません。 テキストの段落を追加したり、リストに別のアイテムを追加したりするよりも簡単なことはありません。 他の人のアイデアをプロジェクトに追加する必要はありません。作成者にとって楽しいものにするためです。 最後に何がありますか？ プロジェクトを開始するのは常識ではなく、テキストの段落と番号付きリストです。 これが、ナビゲーションバーに30個の水平タブがあるWebサイトの誕生です。
6.この仕様では、移動した経路を開発、変更、評価することはできません仕様項目は、一連の署名によって3回議論および修正されます。 開発プロセス中に、機能の1つが役に立たないことに気付いたとしても、戻る方法はありません。 固定仕様の存在自体が、アプリケーション開発中に要件が変更される可能性があるという事実と矛盾しています。
仕様の代わりに何が必要ですか？ まず、実際のプロトタイプアプリケーションにより近いシンプルなドキュメントから始めます。 製品の機能に関する短いテキストを作成します。 パターンにとらわれることなく、自由な形で考えを表現してください。 1ページに制限し、このタスクに1日以上費やさないでください。
その後、ユーザーインターフェイスの構築を開始します。 代替仕様として機能するのはインターフェイスです。 紙に書かれた簡単なスケッチから始めて、静的HTMLでインターフェースを設計します
（Getting Realは主にWebアプリケーションについて説明します-およそTransl）。見たり触れたりできるインターフェースは説明なしで理解でき、誤解を排除します。
アプリケーションのメインコードの記述を開始する前に、表示、クリック、およびディスカッションが可能なプロトタイプインターフェイスを作成します。 エンドユーザーの目を通して、できるだけ早く製品を見てください。
固定仕様については忘れてください。 プロジェクトの初期段階で最も重大な決定を下します。 古典的な意味で仕様を省くようにしてください。そうすれば、要件を変更して柔軟性を維持することがはるかに簡単になります。
最後に-Linus Torvaldsからの小さな
引用 ：
「...彼らは実質的に役に立たない。 仕様が現実と完全に一致していて、同時に開発者を本当に助けた単一の主要なプロジェクトを見たことはありません。
しかし、盲目的に仕様に依存している多くの失敗したプロジェクトを見ました。 私を信じて：仕様の開発は、現実に関係なく理論的にのみプロジェクトが行われることを意味するため、アプリケーションを作成する最悪の方法です。