ソフトウェア要求とは、システムが満たさなければならない条件、または備えていなければならない能力の仕様のことです。
そのほかの関係:  拡張者:
役割:  ユース・ケース定義者  
オプション度 / 使用時期:  使用時期はさまざまであり、通常はそのコンテナである成果物に包含されます。システムが満たさなければならない能力または条件がある場合には常に使用することが推奨されます。
テンプレートとレポート: 
 
例:   
UML の表現:  «use case» や «business rule» などの各種ステレオタイプを使用可能
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

ソフトウェア要求は、以下のものを仕様化する試みの中で文書化されます。

  • ユーザーが問題を解決して目標を達成するために必要なソフトウェアの機能
  • 契約、標準、仕様、その他の明文化された規定を満たすために、システムまたはシステム コンポーネントが備えていなければならないソフトウェアの機能
    参考資料 [THA97]

これはソフトウェア開発に不可欠の成果物ですが、要求の一部を完全に文書化しないままにしておくことが一般的な状況は多くあります。RUP では、反復的な方式でソフトウェア開発を管理し、重要な要求を時間をかけて見つけ出せるようにすることでこの懸念事項に対処しています。

概要 ページの先頭

ソフトウェア要求の成果物の作成にあたっては、以下に示すような、成果物のさまざまな側面を考慮するようにします。

  • 要求を提起する可能性があるさまざまな集団または利害関係者
  • 考慮する必要があるさまざまな要求の種類 (カテゴリ、特徴)

プロパティ ページの先頭へ

プロパティ名  概要 
Identifier  このソフトウェア要求を識別するために使用される一意な名前 
Short Description  できるだけ短く簡明な、要求についての説明 
Rationale  この要求が必要である理由と、この要求の実現によってもたらされる利益または価値についての説明 
UML Representation  «use case» や «business rule» などの各種のステレオタイプ
Detailed Description  要求の詳細な説明 
Restoration and Recovery Procedures  テスト環境構成の復元または回復を行うために必要な手順 

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

ソフトウェア要求は、方向づけフェーズの初期に、チームが利害関係者の要請に応じてシステムの開発範囲と構想の定義を開始するのと並行して、その要求を何らかの形式で概略化したものによって識別されます。ほとんどの要求については、推敲フェーズと作成フェーズの間に詳細を記述します。一部の要求については、移行フェーズで定義し、対処します。

責務 ページの先頭へ

この成果物に責任を持つのは主に、ユース・ケース定義者 の役割にある人物です。

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

この成果物は通常、ソフトウェア要求仕様書ユース ケース、またはその他の要求仕様成果物に含まれる形をとります。



Rational Unified Process   2003.06.15