ソフトウェア開発プロセスの要件段階の作成は、 ソフトウェア要件仕様 (SRS) (とも呼ばれます) 要件文書 ）。このレポートはソフトウェア エンジニアリング活動の基礎を築き、要件全体を引き出して分析する際に構築されます。 SRS は正式なレポートであり、顧客がソフトウェア (SRS) が要件を満たしているかどうかを確認できるようにするソフトウェアの表現として機能します。また、システムに対するユーザー要件と、システム要件の詳細な仕様も含まれます。
SRS は、特定の環境で特定の機能を実行する特定のソフトウェア製品、プログラム、またはアプリケーションのセットの仕様です。誰が書いたかに応じて、いくつかの目的を果たします。まず、SRS はシステムのクライアントによって作成される可能性があります。第 2 に、SRS はシステムの開発者によって作成される可能性があります。 2 つの方法はまったくさまざまな状況を作成し、文書に対してまったく異なる目的を確立します。最初のケースである SRS は、ユーザーのニーズと期待を定義するために使用されます。 2 番目のケースである SRS は、さまざまな目的で作成され、顧客と開発者間の契約文書として機能します。
優れたSRSの特徴
優れた SRS ドキュメントの特徴は次のとおりです。
1. 正確さ: ユーザーレビューは、SRS に記載されている要件の正確性を提供するために使用されます。 SRS は、システムに真に期待されるすべてのニーズをカバーできれば完璧であると言われています。
2. 完全性: SRS は、次の要素が含まれる場合にのみ完成します。
(1)。 機能、パフォーマンス、設計、制約、属性、または外部インターフェイスに関連するかどうかに関係なく、すべての必須要件。
私のモニターのサイズ
(2)。 利用可能なすべてのカテゴリの状況における、実現可能なすべてのクラスの入力データに対するソフトウェアの応答の定義。
注: 有効な値と無効な値の両方に対する応答を指定することが重要です。
(3)。 SRS 内のすべての図、表、図への完全なラベルと参照、およびすべての用語と測定単位の定義。
3. 一貫性: SRS は、矛盾の中に個別の要件のサブセットが記述されていない場合に限り、一貫性があります。 SRS では次の 3 種類の競合が考えられます。
(1)。 現実世界のオブジェクトの指定された特性は矛盾する可能性があります。例えば、
(a) 出力レポートの形式は、ある要件では表形式として記述されますが、別の要件ではテキストとして記述される場合があります。
(b) ある条件では、すべてのライトは緑色でなければならないと規定され、別の条件ではすべてのライトは青色でなければならないと規定されている場合があります。
(2)。 指定された 2 つのアクションの間に、合理的または一時的な矛盾が存在する可能性があります。例えば、
(a) 1 つの要件では、プログラムが 2 つの入力を加算することが決定され、別の要件では、プログラムが 2 つの入力を乗算することが決定される場合があります。
(b) 1 つの条件では、'A' が常に 'B' の後に続く必要があると述べられ、もう 1 つの条件では、'A と B' が同時に発生することが要求されます。
(3)。 2 つ以上の要件で同じ現実世界のオブジェクトを定義しても、そのオブジェクトに対して異なる用語が使用される場合があります。たとえば、ユーザー入力に対するプログラムの要求は、ある要件では「プロンプト」と呼ばれ、別の要件では「キュー」と呼ばれる場合があります。標準の用語と説明を使用することで、一貫性が高まります。
4. 明確さ: すべての固定要件の解釈が 1 つだけである場合、SRS は明確になります。これは、各要素が独自に解釈されることを示唆しています。複数の定義で使用されるメソッドがある場合、要件レポートは SRS での影響を明確にして理解しやすいように決定する必要があります。
5. 重要性と安定性のランキング: SRS 内の各要件に、その特定の要件の重要性または安定性のいずれかを示す識別子がある場合、SRS は重要性と安定性に関してランク付けされます。
通常、すべての要件が同じように重要というわけではありません。一部の前提条件は、特に生命に関わるアプリケーションでは必須である場合もありますが、その他の前提条件は望ましい場合もあります。これらの違いを明確かつ明確にするために、各要素を特定する必要があります。要件をランク付けするもう 1 つの方法は、項目のクラスを必須、条件付き、オプションとして区別することです。
6. 変更可能性: SRS は可能な限り変更可能にする必要があり、システムへの変更をある程度まで迅速に取得できる必要があります。変更には完全にインデックスを付け、相互参照する必要があります。
7. 検証可能性: 指定された要件が費用対効果の高いシステムで検証され、最終的なソフトウェアがそれらの要件を満たしているかどうかを確認できる場合、SRS は正しいです。要件はレビューの助けを借りて検証されます。
8. トレーサビリティ: SRS は、各要件の起源が明確であり、将来の開発または機能強化の文書で各条件を参照するのが容易な場合に追跡可能です。
トレーサビリティには 2 つのタイプがあります。
私のモニターはどのくらいの大きさですか
1.後方追跡可能性: これは、以前のドキュメントでソースを明示的に参照している各要件に依存します。
2. フォワードトレーサビリティ: これは、SRS 内の各要素が一意の名前または参照番号を持つかどうかによって異なります。
SRS のフォワードトレーサビリティは、ソフトウェア製品が運用および保守フェーズに入るときに特に重要です。コードや設計ドキュメントが変更されると、それらの変更に関係する可能性のある要件の完全なセットを確認できる必要があります。
9. 設計の独立性: 最終的なシステムには複数の設計選択肢から選択するオプションが必要です。より具体的には、SRS には実装の詳細を含めるべきではありません。
10. テスト容易性: SRS は、レポートからテスト ケースとテスト計画を簡単に生成できるような方法で作成する必要があります。
11. 顧客が理解できること: エンド ユーザーは、自分の明示的な領域の専門家であっても、コンピューター サイエンスの訓練を受けていない可能性があります。したがって、形式的な表記や記号の目的はできる限り避けるべきです。言葉はシンプルかつ明確に保つ必要があります。
12. 適切な抽象化レベル: SRS が要件段階で作成される場合は、詳細を明示的に説明する必要があります。一方、実現可能性調査の場合、使用できる分析は少なくなります。したがって、抽象化のレベルは、SRS の目的に応じて変更されます。
優れた SRS ドキュメントのプロパティ
優れた SRS ドキュメントの重要な特性は次のとおりです。
Java 8の機能
簡潔： SRS レポートは簡潔であると同時に、明確で一貫性があり、完全である必要があります。冗長で無関係な説明は可読性を低下させ、エラーの可能性も高くなります。
構造化: しっかりと構造化されている必要があります。適切に構造化されたドキュメントは、理解しやすく、修正しやすいものです。実際には、SRS ドキュメントはユーザーの要件に対応するために何度か改訂されます。多くの場合、ユーザーの要件は時間の経過とともに変化します。したがって、SRS ドキュメントの変更を容易にするためには、レポートを適切に構造化することが重要です。
ブラックボックスビュー: システムが何を行うべきかを定義するだけであり、それをどのように行うかについては言及しないでください。これは、SRS ドキュメントではシステムの外部動作を定義する必要があり、実装の問題については議論しないことを意味します。 SRS レポートは、開発されるシステムをブラック ボックスとして捉え、外部から見えるシステムの動作を定義する必要があります。このため、SRS レポートはシステムのブラックボックス仕様とも呼ばれます。
概念的な整合性: 読者が単に理解できるように、概念的な整合性を示す必要があります。望ましくないイベントに対する応答: 望ましくないイベントに対する許容可能な応答を特徴付ける必要があります。これらは、例外条件に対するシステム応答と呼ばれます。
検証可能: SRS ドキュメントに記載されているシステムのすべての要件が正しい必要があります。これは、実装において要件が満たされているかどうかを判断できる必要があることを意味します。