成果物:
|
![]() |
開発構想では、開発対象の製品を利害関係者の視点で定義します。これは、利害関係者の主要なニーズと特色という観点から仕様化されます。開発構想には中心となる要求を具体的に示す概要が含まれており、より詳細な技術的要求に関する契約上の基盤となります。 |
役割: | システム分析者 |
---|---|
オプション度 / 使用時期: | 方向づけフェーズの早期に作成されます。ライフサイクルの前半部分を通して発展していきます。 |
テンプレートとレポート: |
|
例: | |
UML の表現: | なし |
詳細情報: | |
成果物を入力とする作業: | 成果物を出力とする作業: |
開発構想は、より詳細な技術上の要件を定義するための、全体的で時として概念的な基礎を提供します。開発構想は、認識されたソリューションの「エッセンス」を全体レベルの要求と設計上の制約の形で把握し、開発対象のシステムの概要を、振る舞いに関する要求の観点から読者に提示します。また、プロジェクトの承認プロセスの情報源となり、性質的に開発企画書と密接に関連します。開発構想は、プロジェクトについての基本的な「なぜ」と「何」を伝達し、将来下される決定に関して、それが正当なものかどうかを判断するための尺度となります。
この成果物の別名は、製品要求説明書です。
開発構想は、方向づけフェーズの早期に作成されます。ライフサイクルの前半を通して着実に発展させていき、作成フェーズの段階では変更を少なくしていくことが推奨されます。開発構想は、開発企画書および (初回ドラフトの) リスク リストとともに発展し、要求、アーキテクチャ、計画、技術についての理解が深まっていくにつれて見直しが進められることが想定されます。(「成果物: 開発企画書」と「成果物: リスク リスト」を参照)
開発構想はユース ケース モデリングのための情報源として機能し、プロジェクト全体を通して独立した成果物として更新、保守されます。
システム分析者 は、次のことを徹底することにより、開発構想の整合性に責任を持ちます。
初期の開発構想を作成するのは誰でもかまいませんが、方向づけフェーズでプロジェクトが確立される段階で、この成果物はシステム分析者 の責務になります。
一般に、開発構想の対象読者は、予算承認者、管理者、ユース ケース モデリング担当者、テスト担当者、開発チームなどの利害関係者です。
プロジェクトのニーズに合わせて必要なカスタマイズを行います。通常は、できるだけ早く利害関係者に公開できるように、また利害関係者によるレビューと理解を容易にするために、開発構想は簡潔に保つのがよい方法です。これは、利害関係者の要求や特徴のうち最も重要なものだけを扱い、詳細な要求は扱わないことによって実現されます。詳細はほかの要求成果物で、または付録の形で把握できます。
開発構想がユース ケースによってどのように実現されるかを見通せるように、開発構想は、そのユース ケースと主要なシナリオが作成される過程でそれらの観点から表現することが重要です。ユース ケースは、テスト ケース スイートを発展させるための有効な基礎にもなります。
機能属性をここで文書化するか、それとも要求管理計画書で文書化するかを決定します。どの情報 (属性) を開発構想に含めるか、またどの情報を要求管理ツールで管理するかを決定します。
Rational Unified Process
|