3.2 知識エリア：引き出し
引き出し（BABOK(R)ガイド第3章）は、ビジネスアナリストがどのように、ステークホルダーと連携し、ニーズや懸念を識別、理解し、そして彼らが働いている環境を理解する方法について説明します。効果的な引き出しは、ステークホルダーが口にする表面的な欲求よりも、むしろの実際の根本的ニーズを明確にすることを確実にします。引き出しは、従来のアプローチ（ウォーターフォール）では独立したフェーズ/活動だったのですが、アナリシスの活動と一緒に、プロジェクトの全期間で実行されます。引き出しは、(別個の活動またはフェーズとして引き出しを行っていた従来のアプローチと比較すると)プロジェクト全体にわたって進行し、アナリシス活動と共に行なわれます。
アジャイルなプロジェクトにおいては、最も多く共通するパターンが、ソリューションのハイ・レベルのニーズ、ゴール、スコープを見る最初の引き出し活動です。すべてのイテレーションの中で、バックログアイテムを構成するユーザストーリーのための引き出しでさらに詳細に引き出しが行われます。
3.2.1 タスク：引き出しを準備する（3.1）
プロジェクト存続中の全期間で引き出しが行われます。早い段階で、それはハイレベルの要求を定義するために支援材料とリソースのスケジュールを調整するためにビジネスアナリストによって行われます。プロジェクトのこのフェーズで引き出し活動は、より探検的セッションとして一般に組み立てられます。そして根本的なニーズを理解し、フィーチャーの最初の要求リストを組み立て、そして今後の作業にとって何が最も価値があるのか決めます。プロジェクトが進行するにつれて、作業がバックログの優先順位付けによって調整されます。そしてより頻繁に、ローレベルの特別のフィーチャーか要求の詳細を理解するためのより構造化された、直接的な引き出しセッションに帰着するでしょう。ステイクホルダーは、要求を仕上げるために開発者と直接仕事をしても構いません。その状況で、開発者は、プロジェクト用のビジネスアナリシス活動を行なっており、よいビジネスアナリシスプラクティスのトレーニングを受けるべきです。それが可能でなければ、ビジネスアナリストがその代理を務めるでしょう。このタスクは、リソースのスケジューリングとバックログの漸進的な精緻化に合わせて入力の調整が必要です。
引き出し活動に備えて、一緒に働くステークホルダーのニーズ、ウォンツおよび好みを理解するために、ビジネスアナリストが顧客調査およびステイクホルダー分析を行なうことが勧められます。引き出しの議論をステークホルダーに最適化することによって、ビジネスアナリストは、引き出しセッションの効率および価値を最大化することができます。
.1 アジャイルテクニック
ペルソナ：
ペルソナは、ステークホルダーの特定のニーズへの洞察を提供してくれ、ステークホルダーのニーズを理解する上で最も効果的なテクニックです。
ユーザストーリー：
ユーザストーリーはストーリーが明確にする価値を享受する人の役割を識別します。（したがって、その価値について詳しく説明できる利害関係者を識別します）
ストーリーマッピング：
ユーザおよび他のステークホルダーとユーザストーリーマップを開発することは、ソリューションにインプリメントされたストーリーが現実味のある製品になることを確実にするでしょう。
3.2.2 引き出しの活動を指揮する（3.2）
引き出しの活動はプロジェクト全体で頻繁に行われ、毎日のように実施されます。早い段階では引き出しは、高レベルの要求やプロダクトビジョンを定義するために実行されます。プロジェクトの進捗とともに、ステークホルダーは、イテレーション計画と開発の最中に、開発チームと直接対話をします。すべての引き出し活動の意図は、直接作業を正確に確実に行うのにちょうどよい詳細さの要求を生成することです。この引き出し活動は、プロダクトユーザー、および議論されているフィーチャーまたは要求に既得権益を持っている他のステイクホルダーとともに、しばしばワークショップで行われます。
アジャイルテクニック
ビヘイビア駆動開発：
ステークホルダーは、単に抽象的なモデルを使用するのではなく、サンプル（例）を提供することによって、彼らのニーズを明確にすることです。
協働ゲーム：
協働ゲームにおいて、引き出しの参加者は問題やソリューションの共同理解の構築に協力することが推奨されます。
注：上記のように、アナリシス活動は通常、引き出しセッション中に実行されます。このアジャイル拡張版に記載されるテックニックのほとんどは、多くのBABOK®ガイドのテクニックと同様に、この目的に適しています。
3.2.3 引き出しの結果を文書化する（3.3）
ドキュメントの主要な価値は、それが長期的な知識の維持のために使用できることです。アジャイルアプローチは、要求の開発とソフトウェアの実装との間の時間を最小限に抑えて、チームにそのドキュメント作成に費やす労力を減らすことを目指しています。引き出し活動の記録は、後日に重要な意思決定が理解できるようにするため、または規制やガバナンスの要求が満たされていることを確実にするためには必要です。要求および要求用コンテキストを表わす成果物は、単に文章によるドキュメンと限定する必要はありません。モデル、モックアップ、プロトタイプなどにより要求を視覚化することは、ソリューションに関する大規模な情報量を伝えるための迅速なメカニズムです。しかしながら、不必要にソリューションの選択肢を制限せずに要求を定義することが重要なように、ソリューションを模倣するビジュアル化を使用する場合はさらに注意するべきです。
アジャイルテクニック
手軽なドキュメント：
開発ドキュメントのガイドラインについては、このセクションを参照してください。ほとんどの場合、引き出しとアナリシス作業の別々のドキュメントが存在しません。
3.2.4 引き出しの結果を確認する（3.4）
これは、イテレーションの計画時、イテレーションの開発期間中、そして顧客の受け入れ時にチームによって実行されます。顧客は結果を見ると、特定のストーリーのいくつかの要素について心変わりすることがあります。このフィードバックは、引き出しの活動を主導するタスクへのインプットとなります。
.1 アジャイルテクニック
ビヘイビア駆動開発：
引き出しの結果は受け入れ基準の形で捕らえられ、頻繁にソフトウェアがステークホルダー・ニーズを満たすことを確認するためにチームによって使用されます。 ビヘイビア駆動開発またはテスト駆動開発では、例は引き出された要求を確認するために使用され、受け入れ基準を作成する根拠としてよく使用されます。
振り返り（リトロスペクティブ）:
振り返りのセッションにおいて引き出された情報は、顧客が運用中のプロダクトを見た時に感じた見解に基づき、確認もしくは反駁されるかもしれません。そしてソリューション要求の修正につながるかもしれません。