機能仕様

機能仕様には多くの目的があります。チームプロジェクトにおける主な目的の一つは、ソースコードやテストケースの作成、そしてデバッグといった時間のかかる作業に取りかかる前に、プログラムが達成すべき目標についてチーム内で合意を形成することです。通常、このような合意は、ソフトウェアが満たすべき要件を費用対効果の高い方法で実現するための交渉を経て、当該プロジェクトの関係者による1回以上のレビューを経て達成されます。

1. 開発者に何を作るべきかを伝えるため。
2. テスターに​​実行すべきテストを知らせるため。
3. 関係者に、彼らが何を得られるのかを知らせるため。

産業用ソフトウェア開発の体系的なライフサイクル（ウォーターフォールモデル）では、機能仕様書は実装すべき内容を記述します。次に、システムアーキテクチャ文書は、選択したソフトウェア環境を用いて機能がどのように実現されるかを記述します。非産業的なプロトタイプ開発においては、機能仕様書は通常、要件分析の後、または要件分析の一部として作成されます。

チームが機能仕様に関する合意に達したと判断すると、通常、機能仕様は「完了」または「承認済み」と宣言されます。その後、ソフトウェア開発チームとテストチームは、機能仕様を参考にソースコードとテストケースを作成します。テストの実施中は、プログラムの動作が機能仕様で定義された期待される動作と比較されます。

機能仕様書を作成する一般的な方法の一つは、シンプルなワイヤーフレームまたは正確なグラフィックデザインのUIスクリーンショットを描画またはレンダリングすることです。これが完了し、画面例がすべての関係者によって承認されたら、グラフィック要素に番号を付け、画面例の各番号に対応する説明文を追加できます。例えば、ログイン画面では、ユーザー名フィールドに「1」、パスワードフィールドに「2」というラベルを付け、各番号を文書で宣言することで、ソフトウェアエンジニアが使用したり、後でベータテストで機能が意図どおりであることを確認したりすることができます。この方法の利点は、画面例に無数の詳細情報を追加できることです。