概念: 要求管理
トピック
要求管理は、システムの要求の変更の発見、文書化、組織化、追跡を行うための体系的アプローチです。
ここでは要求を以下のように定義します。
システムが満たすべき条件や機能。
またここでは要求管理を、以下のような項目に対する体系的アプローチであると正式に定義します。
- システムの要求の導出、組織化、文書化
- システムの要求の変更について、顧客とプロジェクト チームの間に合意を確立し、維持する
効果的な要求管理の鍵は、各要求のタイプに関係する 属性と他の要求や他のプロジェクト成果物に対する追跡可能性と共に、要求の明確な説明を維持することにあります。
要求の収集は、容易な作業であるように思われがちです。しかし実際のプロジェクトでは、以下のような理由から収集作業は困難になります。
- 要求は常に明確になっているとは限らず、その源は多岐に渡る
- 要求は、言葉による説明が難しいことがある
- 要求には各種のタイプがあり、レベルも細かく分かれる
- 要求は数が多いため、管理を怠ると管理不能に陥りかねない
- 要求は要求同士で、またソフトウェア開発プロセスの納品可能物と互いに関係している
- 要求は固有のプロパティ、プロパティ値を持つ。たとえば、重要度や達成の難しさの面から見た場合、1 つとして同じ要求は存在しない。
- 利害関係者が多く関係している。このため要求を部門間で管理しなければならない。
- 要求は変化する
では、これらの困難を克服するために組織はどのようなスキルを備えるべきでしょうか。これまでの経験から、以下のようなスキルの習得が重要であることが分かっています。
問題の分析は、問題と初期の利害関係者のニーズを理解し、高レベルなソリューションを提案するために行います。問題の分析は、「問題の背後にある問題」を明らかにするための推測と分析の作業です。問題の分析時には、実際の問題について、また利害関係者の特定について共通理解を得ます。またビジネスの見地から、ソリューションの境界線、ソリューションに対するビジネス上の制約を定義します。さらに、構築中のシステムへの投資から期待できるメリットについて十分に理解するため、プロジェクトのビジネス ケースについても分析してもよいでしょう。
ワークフローの詳細: 問題の分析も参照してください。
要求の源は、顧客、パートナー、エンド ユーザー、ドメインの専門家など多岐に渡ります。そこで、これらのすべてを網羅して要求の源を特定し、そこから最大の情報を導出する方法を身につけていることが必要となります。主要な情報源である個人は、プロジェクトの利害関係者と呼びます。自社内で使用するシステムを開発している場合には、開発チーム内でエンド ユーザーやビジネス ドメインについて経験を持つユーザーがこれに相当します。また、ディスカッションは、システム レベルではなく、ビジネス モデル レベルで開始されることが非常に多く見られます。市場で販売するシステムを開発している場合には、市場の顧客のニーズを十分に把握するため、自社のマーケティング要員を幅広く活用することになります。
情報の導出には、インタビュー、ブレインストーミング、概念のプロトタイプ作成、アンケート、競争分析などの方法を用いることができます。情報の導出の結果は、文章や図によって提示され、それぞれ優先順位のついた要望、ニーズの一覧にします。
ワークフローの詳細: 利害関係者のニーズの理解も参照してください。
システムの定義を行うことは、利害関係者のニーズの理解を基に、構築するシステムに関する有意な説明を作成することです。システム定義の初期には、要求、文書形式、言語様式、要求仕様の程度 (数と詳細度) 要求の優先順位と予想される作業量 (通常、異なる方法を取る者同士では価値判断もまったく異なる)、技術と管理リスク、初期の範囲を構成するものについて判断を行います。この作業には、最も重要な利害関係者の要望に直接関係する初期のプロトタイプ モデル、設計モデルの作成が含まれます。システム定義の結果、文章と図でシステムを説明したものを作成することができます。
ワークフローの詳細: システムの定義も参照してください。
プロジェクトを効果的に進めるには、すべての利害関係者からの情報に基づき、要求の優先順位付けを慎重に行い、その範囲を管理することが必要になります。開発者がプロジェクトのリスクを低減するタスクや、アプリケーションのアーキテクチャを安定させるためのタスクよりも、いわゆる「イースター エッグ」 (開発者が興味をそそられ挑戦意欲にかかれるような機能) に注力するために困難が生じているプロジェクトが多々あります。可能な限りプロジェクトのリスクを排除、低減するためには、システムを段階的に開発し、段階ごとに要求を慎重に選択してプロジェクトの既知のリスクを低減していくことが必要です。そのためには、各反復の範囲についてプロジェクトの利害関係者と協議しなければなりません。通常この作業には、プロジェクトの各フェーズに期待される成果物を管理する十分なスキルが求められます。また要求の源、プロジェクトの提供可能物の状態、さらに開発プロセスそのものを管理することが必要です。
ワークフローの詳細: システムの範囲の管理も参照してください。
システムの詳細な定義は、利害関係者が理解、合意し、了承できるような形で表現しなければなりません。そのためには、機能だけでなく、法律、規制要求への適合、使いやすさ、信頼性、性能、サポートのしやすさ、保守容易性を網羅する必要があります。犯しがちな過ちは、作成に手間がかかると感じたものは複雑な定義を作成しなければならないと思ってしまうことです。このようなことをすると、プロジェクトやシステムの説明が難しくなってしまいます。そういった定義は、印象に残りやすいものの、理解できないために有効な情報を与えてはくれないでしょう。システムの説明をする文章を作成する際には、それを読む人を理解するために十分な努力が必要です。読む人が異なれば、文章の種類も変える必要があります。
これまで、シンプルで視覚的なプロトタイプと組み合わせられることの多いユース ケースの方法論について見てきました。ユース ケースは、システムの目的とシステムの詳細の定義を伝達するのに非常に有効な方法です。ユース ケースは、要求をコンテキストに組み入れるのに役立ち、システムの使用方法を示してくれます。
他にシステムの詳細な定義を構成するコンポーネントには、システムのテスト方法の説明があります。どのテストを実施するかを記述しているテスト計画と定義を見れば、どのシステム機能を検証するかが分かります。
ワークフローの詳細: システム定義の見直しも参照してください。
どんなに慎重に要求の定義を行っても、後に変更が生じることはしばしばあります。要求の変更の管理が複雑になる理由は、それにより特定の機能の実装に一定の時間がかかるという点だけでなく、それが他の要求に影響をおよぼす可能性があるという点にもあります。そこで、要求に変更に耐えられる構造を与え、要求と開発ライフサイクル中の他の成果物との依存関係が分かる追跡リンクを備えておくことが必要になります。変更管理には、ベースラインの確立、追跡すべき依存関係の特定、関連する項目間の追跡可能性の確立、変更管理などの作業が含まれます。
ワークフローの詳細: 変更依頼の管理も参照してください。
このトピックの詳細については、以下を参照してください。
概念: 要求 概念: 要求のタイプ 概念: 追跡可能性 ホワイト ペーパー: ユース ケースを使用した要求管理の適用
|