Part8では，プロジェクトという視点を加えて利害関係者を考えます。利害関係者の目的とその構造を明確にして業務要求を定義します。要求の優先度は，重要度とリスクを加味した難易度で決定します。
Part8は，演習編の6回目です。Part7までは，業務システムの動的な振る舞いであるプロセスや，業務の静的な構造に着目する演習を解説しました。対象とする業務を様々な視点から分析してきたわけです。
Part8では，対象とする業務そのものだけではなく，業務を改善するためのプロジェクトという視点も考えます。業務は，理想と現実というギャップを抱えています。そして，そのギャップを解消するのがプロジェクトです。すなわち，業務を“問題領域”とすれば，プロジェクトは“解決領域”になります。
Part8の演習の目的は，プロジェクトの利害関係者を漏れなく洗い出し，利害関係者の目的とその構造を明確にした上で，業務レベルの要求項目を定義することです。具体的には「プロジェクトコンテキスト図」と「目的構造図」を作成します（図1）。
そのようにすることで，プロジェクトが問題領域に立ち向かうための地図を手に入れられます。すなわち，プロジェクトで間違った判断を行って，目的を達成する道を大きく踏み外すような恐れが少なくなるわけです。
利害関係者の洗い出しが重要
Part8の1つ目の演習は，プロジェクトの利害関係者をプロジェクトコンテキスト図で可視化することです。表記法は，業務コンテキスト図と同じで，UMLの「ユースケース図」をベースにした独自表記法です。サンプルを図2に示します。
プロジェクトでは，利害関係者を漏れなく洗い出すことが重要です。利害関係者に漏れがあると，要求の発生源に漏れがあるということですから，重要な要求を漏らしてしまうことになりかねません。
業務コンテキスト図に登場する関係者は，すべてプロジェクトコンテキスト図の利害関係者になります。図2では「業務関係者」としてまとめて表現しています。
このほかに，業務関係者ではない利害関係者も存在します。例えば，図2における「経営者」や「調達部門」，「ベンダー」などが該当します。業務のことだけを考えていると，そのような利害関係者を漏らしてしまいがちですから注意しましょう。
プロジェクト範囲の明確化
プロジェクトの目的は「○○を××する」という一言で表現します。この表現方法は業務コンテキスト図と同じです。このように表現することで，プロジェクトの最終成果物（出力）は「××された○○」という形で明確になります。出力が明確になることで，プロジェクトの範囲が明確になるわけです。
図2では，プロジェクトの目的が「RFPを発行する」ですから，プロジェクトの最終成果物は「発行されたRFP」になります。したがって「発行されたRFP」を使用するような活動は，このプロジェクトの範囲外になることが分かります。例えば，実際にシステムを構築する活動は，別プロジェクトということです。
「中古車販売業務システム化プロジェクト」というプロジェクト名は，プロジェクトの範囲を明確にする前に決めたので，目的と対応していません。ありがちなことですから，常にプロジェクト範囲は明確にしましょう。
