歴史的に、要件収集のアプローチは直線的であると考えられてきました：アナリストはさまざまなステークホルダーとコミュニケーションを取り、希望のリストを作成し、それを仕様書にまとめました。しかし、プロジェクトが大規模になるほど、さまざまな利害関係者群の要件間の重複、重なり、直接的に反対の作業を特定し追跡することは困難になります。
大規模なシステムでは、しばしば以下のような事例が発生します：
分析段階での誤りは、実装時の対立、納期の延長、機能しないメカニズム、またはモジュールの統合の不可能性を引き起こす可能性があります。
プロフェッショナルなシステムアナリストは、以下の技術を使用せざるを得ません：
主な特徴：
要件の優先順位付けは矛盾の解決の方法ですか？
いいえ、優先順位付けは実装の順序の設定です。矛盾はバックログに置かれる前に、合意や妥協、要件の再検討によって解決されるべきです。
自動ツールだけで全ての関連性を特定できますか？
いいえ、自動化（例：トレーサビリティツール）は役立ちますが、埋め込まれたビジネスの意味、プロセスのニュアンス、隠れた対立は実際のステークホルダーとの議論を通じてのみ特定されます。
要件の重なりがある場合、それは必ず1つの要件が余分であることを意味しますか？
いいえ、要件は文言によって重なることがありますが、最終的な目標は異なる場合があります。意味を確認し、それらの集約や開示の機会を探す必要があります。
ネガティブケース：銀行のCRMで2つの部門が独立して"顧客の迅速な検索"を導入するよう依頼しました。要件が個別に実装され、重複が特定されなかったため、2つの異なる検索と混乱したシナリオが発生しました。
利点：
欠点：
ポジティブケース：アナリストは、主要な要件の断片とのワークショップを組織し、依存関係のマトリックスを作成し、シナリオを顧客や実行者と反復的に合意しました。
利点：
欠点：