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