ソフトウェア要求仕様 (SRS) では、完成したシステム、またはそのシステムの一部を対象にソフトウェア要求を把握します。
役割:  ユース・ケース定義者  
オプション度 / 使用時期:  方向づけフェーズで最初に検討され、推敲フェーズと作成フェーズで洗練されます。
テンプレートとレポート: 
 
例:   
UML の表現:  なし
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

ソフトウェア要求仕様 (SRS) では、プロジェクトに関するすべての要求を収集し、組織化することに焦点を当てます。たとえば、製品の特定リリースの各機能に対する完全なソフトウェア要求を記述するには、独立した SRS を作成する方が望ましい場合があります。この仕様には、対象の機能の機能要求を記述する目的で、補足仕様書に詳述された関連する要求群と共に、システムのユース ケース モデル内のいくつかのユース ケースが取り込まれる場合があります。

ソフトウェア要求仕様は、プロジェクトのソフトウェア要求を収集し、UML の「パッケージ」構成要素で表現される IEEE 830 準拠の正式文書にまとめる目的で使用されます。サンプルの SRS テンプレートが 2 種類用意されています。1 つはユース ケース モデリングと共に使用することを想定したもの (rup_srsuc.dot)、もう 1 つはユース ケース モデリングなしで使用することを想定したもの (rup_srs.dot) です。

後者 (rup_srs.dot) は、すべてのソフトウェア要求を文書内に直接的に含める独立した文書です。ユース ケース成果物要求が使用される場合、この文書では、それらの要求への追跡可能性を使用する必要があります。技術的には、両方の文書に含まれる情報は同じですが、前者ではユース ケース モデル内の情報が複製されずに参照として取り込まれるのに対し、後者では情報が完全に複製されます (ユース ケースを使用している場合)。そのため、後者のほうが追跡可能性関係の保守により多くの作業が必要となります。

これらの要求を収集するためのツールは数多く存在するため、要求はいろいろな成果物からさまざまなツールを使用して収集できる、ということを認識するのが重要です。たとえば、機能外要求、設計上の制約などのテキスト形式の要求を、テキスト文書化ツールを使用して補足仕様書に収集することが適切な場合があります。一方で、ユース ケース内の機能要求の一部 (または全部) を収集することが有益な場合もあれば、ユース ケース モデルの定義作業のニーズに適したツールを使用すると便利な場合もあります。この理由から、SRS の要求は 1 つのパッケージに集めます。このパッケージは単独の文書であることもあれば、要求を記述するさまざまな成果物の集合体であることもあります (「ガイドライン: ソフトウェア要求仕様」を参照)。

SRS パッケージは、プロジェクトの開発フェーズ全体を通してシステムの発展を管理します。新しい機能が開発構想書に追加されたり、構想書が修正されたりすると、それらを反映した推敲が SRS パッケージの内部で行われます。ソフトウェア要求仕様を使用するのは次の人々です。

  • システム分析者は、開発構想書補足仕様書を作成し、保守します。開発構想書は SRS の情報源として機能し、システム分析者、顧客、その他の開発者の間のコミュニケーションを仲介します。
  • 要求定義者は、個別のユース ケースや、SRS パッケージのその他のコンポーネントを作成し、保守します。
  • 設計者は、クラスの責務、操作、属性を定義したり、実装環境に合わせてクラスを調整したりする際に参照物として SRS パッケージを使用します。
  • 実装担当者は、クラスを実装するときに情報源として SRS パッケージを参照します。
  • プロジェクト管理者は、反復を計画するときに情報源として SRS パッケージを参照します。
  • ../workers/wk_tstds.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト担当者は SRS パッケージを使用して、システムの適合性を検証します。

概要 ページの先頭へ

ソフトウェア要求仕様 (SRS) は、システムまたはその一部を対象とする完全なソフトウェア要求を把握します。

以下に示すのは、ユース ケース モデリングを使用するプロジェクトにおける SRS の概要の典型例です。この成果物は、ユース ケース モデルユース ケース、適用可能な補足仕様書、その他の補足情報を含むパッケージで構成されます。ユース ケース モデリングを使用しない場合の SRS のテンプレートでは、すべての要求を 1 つの文書で把握し、補足仕様書から必要なセクションを引用して挿入するので、補足仕様書は不要になります。具体例については、../../webtmpl/templates/req/rup_srs.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんユース ケースを使用しない SRS の HTML テンプレートを参照してください。

SRS に関してはさまざまな編成が可能です。これまでに述べた事項についてのより詳細な説明や、SRS の編成に関するその他の選択肢については、../referenc.htm#IEEE98 -- このハイパーリンクは、生成されたこの Web サイト内に存在しません参考資料 [../referenc.htm#IEEE98 -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんIEEE830-1998] を参照してください。

タイミング ページの先頭へ

ソフトウェア要求仕様:

  • ソフトウェア要求仕様は、当初は方向づけフェーズで、システムの開発範囲の定義を補足するものとして検討されます。
  • 推敲フェーズと作成フェーズでは、仕様を段階的に洗練していきます。

責務 ページの先頭へ

ユース・ケース定義者 は、ソフトウェア要求仕様の作成に責任を持ちます。ソフトウェア要求仕様は、ユース ケース モデルの重要な補足成果物です。SRS パッケージでは、必要な補足仕様書と、ユース ケースモデルユース ケースが収集され、システム、または定義されたサブシステムに対する要求の完全な集合が把握されます。

カスタマイズ ページの先頭へ

SRS に関してはさまざまな編成が可能です。これまでに述べた事項のより詳細な説明や、SRS の編成におけるその他の選択肢については、参考資料 [IEEE93] を参照してください。

この成果物は、論理的には以下のものを包含します。



Rational Unified Process   2003.06.15