従来、要求は概念: 要求で説明されるカテゴリの 1 つに当てはまるテキストの記述として考えられきました。要求は、「システムが満たすべき条件や機能」を記述します。

そこで、ここでは要求のタイプという概念を導入し、要求の抽象概念や目的をレベルごとに分けることにします。

../../artifact/ar_tstste.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません

また、利害関係者が持つあいまいな「希望」、正式の要求を追跡し、その対応方法を学ぶこともできます。開発構想書は、重要な「ユーザー ニーズ」やシステムの「機能」の追跡に役立ちます。またユース ケース モデルは、機能上の「ソフトウェア要求」の詳細を説明するのに有効であり、このため「システムが満たすべき条件や機能」を記載した要求やユース ケース プロパティ内の個々のコメントと同じく、ユース ケースを必要に応じて追跡、維持することも必要となります。補足仕様書には、他の「ソフトウェア要求」を記載することができます。たとえば、設計上の制約や法律、規制に関するシステム要件などです。ソフトウェア要求を完全に定義するため、ユース ケース補足仕様書を 1 つにまとめ、特定の「機能」やサブシステムのグループを対象とするソフトウェア要求仕様書 (SRS) を定義することもできます。

システムの規模が大きくなり複雑になるにつれ、説明や要求のタイプが増え、要求の数自体も増えています。プロジェクトの「ビジネス ルール」や「開発構想」は、「ユーザー ニーズ」、「機能」、その他の「製品要求」を反映したものです。ユース ケースなどのモデリング、その他の補足仕様書は、設計要求の追求に役立ちます。これにより設計要求を、分析と設計のモデルやダイアグラムの中で機能的、非機能的「ソフトウェア要求」にさらに細かく分類することができます。

詳細情報

このトピックの詳細については、以下を参照してください。

概念: 要求
../../../papers/apprmuc.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんホワイト ペーパー: ユース ケースを使用した要求管理の適用



Rational Unified Process   2003.06.15