仕様の作成についていくつか質問があります。
ソフトウェア仕様を作成するとき、トピック「ユーザー要件定義」の下で、「機能」と「制約」のみを指定する必要がありますか？
「ユーザーインターフェイス」は「機能」または「制約」に分類されますか？
ソフトウェアを分割できる主な主要領域（要件）は何ですか（UIなど）。
回答:
すべての要件を事前に詳細に収集することは大したファンではありませんが（些細なプロジェクトの過程で大幅に変更される可能性があるため）、要件ドキュメントを作成している場合は、Volere要件仕様テンプレートが優れたガイドです。
一部のプロジェクトにとってはやり過ぎかもしれませんが、この要件に必要のない項目をメンタル的にチェックオフするだけの場合でも、考慮すべき素晴らしいチェックリストを提供します。
テンプレートに関する詳細情報へのリンクは次のとおりです。
http://www.volere.co.uk/template.htm
テンプレート自体（および要件プロセスのマスター -実際にはテンプレートよりも少し安く、完全なテンプレートテキストが含まれている本）には、各セクションで何をすべきかに関する多くの情報、例、アドバイスが含まれています。
そのセクションの概要は次のとおりです（上記のリンクから引用）。
プロジェクトの目的
利害関係者
必須の制約
命名規則と定義
関連する事実と仮定
仕事の範囲
ビジネスデータモデルとデータディクショナリ
製品の範囲
機能およびデータ要件
ルックアンドフィールの要件
使いやすさと人間性の要件
性能要件
運用および環境要件
保守性とサポートの要件
セキュリティ要件
文化的および政治的要件
法的要件
未解決の問題
既製のソリューション
新しい問題
タスク
新製品への移行
リスク
費用
ユーザードキュメントとトレーニング
待合室
ソリューションのアイデア
ソフトウェアでJoelを読むことをお勧めします。それがあなたの特定の質問に答えるかどうかはわかりませんが、彼は機能仕様を書くことの意味の優れた概要ます：
仕様の最も重要な機能は 、プログラム設計することです。すべて自分でコードに取り組んでいて、自分の利益のためだけに仕様を書いたとしても、仕様を書く行為-プログラムがどのように機能するかを詳細に記述する-は、実際に設計することを強いられますにプログラムをする ...
...人間の言語で製品を設計する場合、設計のいくつかの可能性について考え、修正し、改善するのに数分しかかかりません。ワープロで段落を削除しても、誰も気分が悪くなることはありません。しかし、プログラミング言語で製品を設計する場合、時間がかかります反復設計を行う数週間ます。さらに悪いことに、コードを書くのに2週間しか費やしていないプログラマーは、それがどんなに間違っていても、そのコードに非常に執着するでしょう...
...仕様を書くときは、プログラムがどのように機能するかを伝えるだけです。 1回。チームの全員が仕様を読むことができます。QAの人々はそれを読んで、プログラムがどのように機能するか、何をテストすべきかを知っています。マーケティング担当者は、これを使用して漠然としたベーパーウェアホワイトペーパーを作成し、まだ作成されていない製品についてWebサイトに掲載します。事業開発の人々は、この製品が脱毛やいぼなどを治す方法についての奇妙な空想を紡ぐためにそれを誤解していますが、投資家を獲得します。開発者はそれを読んで、どのコードを書くべきかを理解します。顧客はそれを読み、開発者が彼らが支払いたい製品を構築していることを確認します。テクニカルライターはそれを読み、素敵なマニュアルを書きます...
仕様がない場合でも、この通信はすべて発生します。なぜなら、必要なのはアドホックですからです。QAの人々は、プログラムを気ままに欺き、何かがおかしくなったら、プログラマーにもう一度割り込んで尋ねます別の事が仕事になっている方法についての愚かな質問を...
詳細な仕様がなければ、スケジュールを立てることは不可能です...多くのプログラミング組織では、デザインの議論が行われるたびに、通常は政治的な理由で誰も決定を下すことができません。そのため、プログラマーは議論の余地のないものだけに取り組んでいます。時間が経つにつれて、すべての厳しい決定が終わりに追いやられます...仕様を書くことは、仕様がなければ覆い隠される大小さまざまな刺激的な設計上の決定をすべて特定する素晴らしい方法です。 ..
ソフトウェア仕様を作成するとき、トピック「ユーザー要件定義」の下で、「機能」と「制約」のみを指定する必要がありますか？
要件は2つのことの組み合わせです...
「ユーザーインターフェイス」は「機能」または「制約」に分類されますか？
最後の質問で特定したように、「ユーザーインターフェイス」は要件のカテゴリになります。
ソフトウェアを分割できる主な主要領域（要件）は何ですか（UIなど）。
ソフトウェアに依存します。システムの一部に基づいて要件をグループ化することも、ユースケースや機能が果たすビジネス要件に基づいて要件をグループ化することもできます。
もちろん、これはすべて、ソフトウェアシステムの明確で明確な、テスト可能な説明を決定するという実際の目標に続くものです。
要件の主な要件は、テスト可能であることです。要件をテストする方法がわからない場合は、ライターが意図したとおりに実装されない可能性があります。
機能と制約のみに限定された要件ドキュメントを見たことはありませんが、このような構造を持つことには価値があることがわかります。ソフトウェアに従う必要があります。」
ユーザーインターフェイスには両方のカテゴリの要件があると思います
制約：
関数：
Startキーが押されると、ソフトウェアはWOPRへのTCP / IP接続を確立します」