要求管理ワークフロー

次の図は、Rational Unified Process によって提唱されている要求管理ワークフローを示しています。図に示されているように、プロセスは反復的で動的であり、プロセス全体を通して変更管理が行われます。プロセスのフェーズは、チーム メンバーがプロジェクト要求を取り込む特定のドキュメントに関連付けられています。これらのフェーズとドキュメントは、このチュートリアル全般で頻繁に参照されます。

(Rational Unified Process 提供、2001)

問題の定義と利害関係者のニーズの理解

実際の問題を定義することは、プロジェクトをデザインするための重要な第 1 ステップです。ここでは、問題を、顧客が主張するニーズと実際に求めているニーズとのギャップとして定義します。実際の問題を定義することは想像するよりも困難です。問題だと思っていることでも、それが実際の問題ではない場合があるからです。これに対処するには、顧客から問題の定義を聞き、問題の陰にある問題を見つけるまで突き詰めてください。問題の原因が識別できたら、問題に最も影響を与えている要素に焦点を絞ることができます。

複雑な問題を効果的に解決するには、さまざまな利害関係者のグループ (問題に対する解決法の実施によって実質的に影響を受ける人) から意見を集めることが必要です。システムを使用する人 (スタッフや顧客) は、欠点を知る重要な情報源です。そのほか、システムを承認する人、システムを維持する人の意見も聞く必要があります。これらの人々も要求に関する重要な情報源です。

たとえば、多様な家庭用品を製造販売しているメールオーダー カタログ会社が、2 期に渡って利益がなかったと想定します。この原因を突き止めようと、役員と主要スタッフ メンバーが、失敗や無駄などすべてのコストとその他の過剰コストについて調べたところ、再作業、スクラップ、顧客の不満足、従業員の再編成などがこのコストになっているようです。そこで、不良品のコストを見積もってみると、生産の無駄またはスクラップがその多くを占めていることがわかりました。

次に、原因、または問題の陰にある問題を見つけます。問題の原因となる要素とは何でしょうか。スタッフは、返品、出荷損傷品、不正確な販売オーダー、製造不良品など多くの要因を確認することができました。引き続き、これらの各要因が問題に与える影響を判別してみます。記録を調べたところ、問題に最も影響しているのは不正確な販売オーダーによる顧客からの返品のようです。これに関連する情報が販売オーダー入力係、販売オーダー スーパーバイザ、請求係などから得られました。管理者は、この問題に対処することによって無駄を省くことができると判断し、入力時における販売オーダーの正確性を高めること、管理に販売データをレポートすることが重要であると、定義づけました。

システムの定義

システムを定義するときは、利害関係者のニーズを把握し、構築するシステムの記述にそのニーズを変換して編成します。構築する製品を定義し、システムの外部動作を説明するドキュメントを、要求仕様と言います。これは、システムの機能的動作を識別するようデザインされたユース ケース ドキュメントと、システムの機能を特定の用語で定義する補足要求仕様ドキュメントで構成されます。

(この項は、"Managing Software Requirements: A Unified Approach" Dean Leffingwell/Don Widrig 著 Boston: Addison-Wesley, 2000 (邦訳: 『ソフトウェア要求管理:新世代の統一アプローチ』、日本ラショナルソフトウェア株式会社、石塚 圭樹、荒川 三枝子 監訳) を参考にしています。)

メイン チュートリアルに戻る