仕事で私は頻繁に仕様書を書く責任があり、そもそも仕様書を入手することを主張した人でもあります。問題は、仕様がどのように見えるべきか、そしてそれらに何が含まれるべきかがわからないことです。私の上司が仕様を書いているとき（私たちは両方ともそれに不慣れです）、彼らはテーブル名と私がそこに属しているとは思わないものを入れました。では、良いスペックを書くことを学ぶ良い方法は何ですか？
編集：機能仕様には、Webアプリケーション、入力タイプ（テキストボックス、ドロップダウンリストなど）を指定していると仮定するようなものを含める必要がありますか？
私の意見では、開発ドキュメントの最も重要な部分は、正しい人にそれを行わせることです。
シニア開発者/アーキテクト以外の誰かにテーブル構造/インターフェイスなどを定義させることは無駄の練習です-より経験豊富な開発者は一般的にそれのほとんどを捨てるでしょう。
ウィキペディアは実際には機能仕様の良いスタートです。これはあなたの仕様に似ているようです-http://en.wikipedia.org/wiki/Functional_specification。
SteveMcConnellのCodeCompleteには、仕様書とその内容を網羅したすばらしい章があります。
どちらも経験したことのない会社でアーキテクチャおよびビジネス分析チームを構築する任務を負ったとき、私はMcConnellの仕様の章を使用して、技術仕様ドキュメントの概要を作成しました。時間の経過とともに進化しましたが、このフレームワークから始めることで、何も見逃さないようにし、驚くほど使いやすいことがわかりました。
仕様を書くとき、私が従う経験則は、技術文書が常に一般的なものから始まり、特定のものに移るようにすることです-技術的な解決策が開発されているビジネス上の問題または目標を常に言い直してください解決するので、仕様を読んでいる人は、他のドキュメントにアクセスして、それをあらゆる種類のコンテキストに置く必要がありません。
Joel Spolsky による無痛機能仕様を参照してください。
彼がすべての仕様に持つべきだと言っていることのいくつか:
重要なのは、フォーマットを気にするのではなく、何かを書き留めておくことです。
書籍の購入：Ian Sommerville＆PeteSawyerによる要件エンジニアリングISBN0-471-97444-7またはKarlWiegersによるソフトウェア要件ISBN0-7356-0631-5