3.5 要求アナリシス
要求アナリシス（BABOKガイドの第6章)は、ビジネスアナリストがどのように優先順位を付けてステークホルダー要求とソリューション要求を段階的に仕上げていくかを説明します。そしてプロジェクト・チームがスポンサー組織とステークホルダーのニーズを満たすソリューションをインプリメントすることを可能にします。そのためには、ステークホルダーが満足するようなソリューションを定義するためにステークホルダーニーズを分析し、改善を識別し推奨するためにビジネスの現状を評価し、そして結果の要求の検証と妥当性確認をします。
3.5.1 要求に優先順位を付ける（6.1）
アジャイルなプロジェクトにおいては、要求は徐々に仕上げられます。言いかえれば、引き出しタスク全体にわたって引き出した結果は、徐々にまたは継続的にブレークダウンされて仕上げられていきます。これは継続的改善の概念に似ていて、ビジネスアナリストは求められる詳細さで要求を絶えず詳しく記述し、意図したプロジェクト結果に基づいて優先順位付けされる新しい要求を識別します。各仕上げのポイントでは、ビジネス価値への貢献およびリスクの度合い応じて、構成要素が評価され優先順位付けされる必要があります。これは、アジャイルでは、プロジェクトの初期に一回だけ行う活動ではありません。これは、製品に関して学習することから始まり、すべての未了作業および新しい仕事に関するプロジェクトのライフサイクル全体にわたって行われます。
.1 アジャイルテクニック
・バックログマネジメント:
バックログマネジメントは多くの機敏なアプローチ中の必要条件を優先的にする標準方法です。ビジネス・ニーズが変わったり、ビジネスをより深く理解できた場合は、常に、バックログは再度、優先順位付けがされます。
・狩野アナリシス:
狩野アナリシスは、ユーザ・グループにフィーチャーの相対的重要度に対する洞察力を提供することができます。
・計画ワークショップ:
優先順位付け作業は、通常計画ワークショップ中に行われます。
注: MoSCoW優先順位付けの拡張も参照してください。
3.5.2 要求を体系化する（6.2）
ジャストインタイムで、連続的に行う要求の引き出し活動とドキュメンテーション活動により、要求がアジャイルなプロジェクトのためにどのように体系化されるだろうかを考えることは重要です。例えば、ユーザストーリーは、それをもっぱら記述する多数のドキュメントの中にしばしば現われます。その結果、適切な要求を探すことが厄介な活動にもなります。アジャイルなプロジェクトのドキュメントは手軽であるべきですが、要求マネジメント計画と、プロジェクト・チーム・メンバーおよび他のステイクホルダーによって使用できる要求を体系化する方法を持っていることはまだ重要です。
アジャイルの中で、フィーチャーセット間の依存性を最小化するために、要求を体系化することは価値があるでしょう。これは複雑さとリスクを最小化するので、ビジネス・レベルの価値で、テスト可能性が改善できます。技術的実装に相反するものとして、ビジネス価値にまつわる要求と、次第に仕上がる要求を体系化することは、ビジネス上の見地から設計されるソリューションに帰着します。例外はコンポーネントチームのようなプロジェクトに存在し、ビジネス価値は実現技術を提供することから生じます。そのときでさえ、リスク評価とビジネス価値への貢献に基づいて、これらの要求の優先順位付けと選択を行う必要があります。エピック内のストーリーマップは、要求を体系化する方法として使用することができます。
.1 アジャイルテクニック
・ストーリー分割：
エピックおよび(または)フィーチャーが体系化の方法として使用される場合、個々のストーリーはエピックかフィーチャーのまわりで体系化されるでしょう。
・ストーリーマッピング:
ストーリーマッピングは、さらに個々のストーリーがどのように関係があるか、あるいは、互いに支援するか示します。
これは、関連するストーリーを決定し、それらの関係に基づいたストーリーおよび関連する要求を体系化する方法として使用されるでしょう。
3.5.3 要求の仕様化とモデリング（6.3）
要求を仕様化しモデル化するためには、異なるレベルの仕上げと、異なるやり方があります。このアプローチは段階的詳細化（仕上がり）を支援するべきであり、変化に適応可能で、学習に基づき、そして、チームにソリューションをあまり早期には選択させないようにするべきです。さらに、意図および意図したビジネス価値が仕上げを通じて一貫してコミュニケーションされることを確実にするべきです。アジャイルなチームは、分割の最低のレベルでストーリーとタスクを使用する傾向があります。これらのストーリーとタスクは詳しいドキュメンテーションとユースケースに支援されます。受け入れテストが、要求の仕様化とモデリングの一部として作成されることが、ますます一般的になってきます。
.1 アジャイルテクニック
・ビヘイビア駆動開発(BDD):
機能性の具体的な例は、ステークホルダーが自分たちのニーズの仕様化と理解を助けてくれるかもしれませんし、あるいはより大きな価値のある特定のシナリオを扱うことを支援してくれるかもしれません
・ストーリーボーディング：
ユーザ・インターフェース(UI)機能性と振る舞いについて記述するために使用されます。
3.5.4 前提条件と制約条件を定義する
前提条件と制約条件の定義は、アジャイルなプロジェクトではリスク管理アプローチによって扱われます。例えば、それらが関係するフィーチャーかエピックで追跡できるように、いくつかのアジャイルなチームはテーマ内のストーリーとしてリスクを扱います。その後、リスク緩和アクティビティは優先順位が付けられ、鎮静するでしょう、また、その後、ストーリーとしての再優先順位付けが行なわれます。これは、典型的にチーム全員の支援に加えて、ビジネスアナリストおよびプロジェクト・マネージャーの役割を担う個人によって作成されます。その後、優先順位付けはプロダクトオーナーあるいは類似の役割の誰かによって行なわれるでしょう。
.1アジャイルテクニック
・手軽なドキュメント：
前提条件と制約条件は、プロジェクトの進歩とともに、プロジェクト・チームによって作成される手軽なドキュメンテーションの中で文書化することができます。
・ペルソナ:
ペルソナは、プロダクトチームが開発の間に知るべき、特別のユーザ・グループかステークホルダー・タイプに関連したリスクを追跡する一つの方法として使用することができます。ペルソナはスキャンし、ステイクホルダー分析の間にステイクホルダー・タイプに関して作られた任意の前提条件に関する情報を含めるために任意に修正されます。
・ユーザーストーリー：
ユーザストーリーはストーリーと関係する前提条件あるいは制約条件(特に後者)を追跡するために修正することができます。チームは、さらにこれらが開発のために計画されたストーリーと離れていることはチームとステイクホルダーに明らかである必要がありますが、顕著な作業項目としてチームが取り組むリスクを集める方法としてユーザーストーリーフォーマットを使用することができます。
3.5.5 要求を検証する（6.5）
検証は、何かが明確に設計されており品質規格を厳守していることを確実にします。例えば、ユーザストーリーあるいは他の要求ドキュメントが適切に構造化されていることを検証することは、適切なフィールドを含んでおり、適正レベルな詳細さを含んでいます。要求はプロジェクトのコースの至る所でのチームによって確認されます。振り返りおよびオペレーションレビューによって、チームは、要求の詳細レベルあるいはチームのパフォーマンスを改善するために要求を仕様化しモデル化する方法を修正することを決定するかもしれません。振り返り中のチーム、毎日のチームミーティングあるいは他のミーティングからの直接のフィードバックあるいはワークショップを誘発して、ソフトウェアが開発されているとともに、要求の検証は、通常チームのステイクホルダーとの直接の相互作用によって行われます。
.1 アジャイルテクニック
・振り返り：
振り返りは、構築されたものが要望されたビジネス結果にマッチするだろうということを確認するために、構築されたものの上に迅速なフィードバックを行ないます。
・ストーリーマッピング:
ストーリーマッピングは選択されたユーザーストーリーが要望されたビジネス結果を実際にデリバリーされるだろうということを確認するための技術です。
3.5.6 要求を妥当性確認する（6.6）
妥当性確認は、引き渡せるかプロダクトがその意図した目的を実際に満足することを確実にします。例えば、ユーザーストーリーは、それが記述するように意図されるビジネスプロセスか活動について十分に記述することの妥当性確認をします。要求はソリューションの開発およびデリバリーの全体にわたって、顧客、また可能なら、プロダクトオーナーか類似の役割の人との連続的な関与によって妥当性確認されます。これは開発の間において、リリース計画、イテレーション計画など、プロジェクト中の多くのポイントで起こります。プロトタイプは、さらにユーザにプロトタイプの発展上のユーザからフィードバックを得るプロダクトレビューミーティングを備えた開発で、初期にテストし試みることを与えることにより、その意図した目的に関する機能性のユーティリティを妥当性確認する、有効な方法になりえます。
.1 アジャイルテクニック
・ビヘイビア駆動開発：
ビヘイビア駆動またはテスト駆動開発では、例は設計された要求のための手段として、またソリューションを設計するための受け入れ基準を設立するために使用されます。これらの実世界の例を満たす能力は、ソリューション要求を妥当性確認する手段として役に立ちます。
・振り返り:
ソリューションが予定通りに開発されているかどうか、あるいは成功裡にニーズを満たしているかどうかを妥当性確認するために、顧客は振り返りのセッションによってソリューションを評価することができます。