作業:
|
目的
|
|
ステップ | |
入力とする成果物: | 結果となる成果物: |
役割: システム分析者 | |
ツール メンター: | |
More Information: |
ワークフローの詳細: |
目的 | 「拡張プロジェクト チーム」で利害関係者の役割を果たす人物を識別する 要求のソースを見極め、優先順位を付ける |
既存のシステムでは、過去に延期した拡張依頼をこの作業で最初に考慮します。これらの要求は、製品のライフサイクルを通じて、正式な変更依頼管理のプロセスの一部として収集されます。これが、データの収集や、利害関係者の要望をさらに見直すための出発点になります。
この初期の情報収集が終了したら、利害関係者を代表することのできる、パートナー、ユーザー、顧客、ドメインの専門家、業界の分析者を探します。知識、コミュニケーション スキル、プロジェクトにどの程度参加できるか、「重要性」を考慮して、誰から情報を収集するかを決定します。これらの人々は、プロジェクトの利害関係者の役割を果たします。このため、実質的な「拡張プロジェクト チーム」となります。一般的に、プロジェクトの期間中に継続して協力できる小さなグループ (2 ~ 5 人) が理想的です。また、拡張チームのメンバーが増えるほど、メンバーの管理や、メンバーの時間を有効に使えることを確認するために、時間がかかるようになります。これらの人々は、プロジェクトに常時参加するわけではありません。一般的に、方向づけフェーズや推敲フェーズと、後のレビュー セッションで、要求検討会議に 1 回または数回参加します。
自分が行おうとしていることを、ほかの人々の実践方法から学ぶようにします。ソフトウェア製品を開発する場合、これは競合企業の情報を集めることを意味します。社内の情報システムの新しいバージョンを作成する場合は、現在のバージョンがどのように使用されているか、およびどのように改良できるかを調査するために、実践の現場を訪問します。
重要なソースとして、システムを使用する組織に関する既存の記述があります。ビジネス モデリングの作業分野の説明に従って作成したビジネス モデルや、その他のビジネス定義です。
目的 | 対応が必要な疑問点を系統的に記述する 情報を収集し、文書化する |
最も有用な情報収集の手段として、主要な利害関係者から選択したグループにインタビューを行う方法があります。質問や技法の例は、「ガイドライン: インタビュー」を参照してください。効果的なインタビューを行うためのサンプルのスクリプトは、「成果物: 利害関係者の要望」を参照してください。
これは広く使用されている技術です。いくつかのインタビューを行うと、同じ情報が何度も取り上げられることに気づく場合があります。このような情報を典型的な答えの選択肢と共に 1 つのアンケートにまとめ、より大きな利害関係者のグループに送ることができます。この方法では、アンケートに含めた特定の質問に対して与えられた答えに関し、正式な統計を取ることができます。ただし、利害関係者が実際のところ何を欲しているかについて統計で現実的な結果を得られるように質問を作成することが重要になります。
利害関係者は、答えを記入したアンケートを、インターネットを通じて返信できます。これにより、直接インタビューを行うよりも幅広い人々にアプローチできますが、結果に対するコントロールの程度は低くなります。問題点や誤解を明らかにするために、回答者と直接対話ができるわけではありません。このため、アンケートは非常にパワフルなツールとなり得ますが、直接のインタビューと置き換えられるものではありません。また、関連する質問をあらかじめ決定できること、およびこれらの質問を読み手が誤解しないように文章にできることを前提とします。
目的 | プロジェクト チームとプロジェクトの利害関係者が直接顔合わせを行う プロジェクトの利害関係者から、包括的な「希望リスト」をまとめる 要求検討会議に参加した利害関係者から収集した要求に優先順位を付ける |
ガイドライン: |
目的 | さまざまな要求検討会議からの結果を比較する 適切な情報が収集できたことを確認する |
特に複数の要求検討会議を行った場合、プロジェクト チームが結果を再検討し、次のことを行うことをお勧めします。
要求検討会議の結果は、レビューまたはフォローアップのセッションで、選択した顧客やユーザーのグループに提示します。このセッションでは、明らかにしなければならない問題 (つまり、完了しなければならないタスク) を明確にし、これらのタスクをメンバーに割り当てます。
Rational Unified Process
|