作業:
|
目的
|
|
ステップ | |
入力とする成果物: | 結果となる成果物: |
頻度: | |
役割: ユース・ケース定義者 | |
ツール メンター: | |
詳細情報: |
ワークフローの詳細: |
設計者、テスト担当者、文書作成者に手渡すために必要な詳細レベルにまで、すべての要求が指定されるようにします。ユース ケースに含まれないソフトウェア要求を把握するために、さらに詳細な情報が必要かどうかを調べるには、「チェックポイント: 補足仕様書」を見直してください。
正式なソフトウェア要求仕様 (SRS) を作成する場合は、「チェックポイント: ソフトウェア要求仕様」を見直してください。
要求が追跡または正式に管理されている場合は、各要求が明確に識別され、ラベル付けされていることを確認します。
要求は多くの場合、1 つ以上のツールを使用して保存、管理されます。たとえば、以下の用途のツールがあります。
このステップでは、これらのツールから文書を生成し、情報を簡単にレビューできるようにします。この作業に関連して実行できる該当するレポートについて詳しくは、この作業の「詳細情報」の項を参照してください。
要求を把握するために特別なツールを使用しない場合、このステップは該当しません (すべてのソフトウェア要求は文書に直接記述される)。
それほど形式的ではないプロジェクトの場合、このステップは関連するレポートと手作業で生成した文書を組み合わせる作業で構成されます。十分なサポート資料も提供して、要求を効率的にレビューできるようにします。
より形式的なプロジェクトの場合は、1 つ以上のソフトウェア要求仕様 (SRS) を使用して、プロジェクトを取り囲むすべての要求を収集、整理します。たとえば、製品の特定のリリースに含まれる特性ごとの完全なソフトウェア要求を記述するために、別々の SRS を使用する場合があります。これには、システムのユース ケース モデルから取り込んだいくつかのユース ケースが含まれる場合もあり、補足仕様書の詳細要求の関連セットと併せて、この特性の機能要求を記述します。
ソフトウェア要求仕様は、UML の「パッケージ」構成要素によって表現される、正式な IEEE 830 様式の文書です。これには 2 つのサンプル SRS テンプレートが用意されています。1 つはユース ケース モデリングと *共に* 使用するためのもので (rup_srsuc.dot)、もう 1 つはユース ケース モデリング *なしで* 使用するためのもの (rup_srs.dot) です。第 1 のテンプレート (rup_srsuc.dot) は、ユース ケース モデルの成果物 (ユース ケース モデル概要、ユース ケース レポート、補足仕様書) を参照、つまり包含します。このテンプレートを使用すると、これらの 3 つの成果物で情報を複製することなく、正規の IEEE 準拠の SRS を作成できます。
第 2 のテンプレート (rup_srs.dot) は、*すべての* ソフトウェア要求を直接含む、独立した文書です。ユース ケース成果物の要求が使用される場合、この文書では、ユース ケース成果物の追跡可能性を使用する必要があります。正確には、これらのテンプレートには同じ情報が含まれますが、ユース ケース モデルの情報は、第 1 のテンプレートでは参照の形式で包含され (複製ではない)、第 2 のテンプレートでは完全に複製されます (ユース ケースを使用している場合)。第 2 のテンプレートは、追跡可能性の関係を維持するのに、より多くの作業が必要になります。
このサブシステムや特性についてのソフトウェア要求の完全な定義を得るために、ソフトウェア要求仕様テンプレートを使用して、SRS パッケージの断片を組み立てて、残りの情報を提供します。
Rational Unified Process
|