製品要件の検証（validation）は、実装されたソリューションと元のビジネス要件との体系的な比較を含みます。ビジネスアナリストは重要な役割を果たし、要件の適切な形式化を保証し、受け入れ基準（acceptance criteria）を作成し、受け入れテストに直接参加します。不一致が見つかった場合、アナリストは欠陥を記録し、その原因（誤った実装、理解されていない要件、変更されたビジネスプロセス）を明らかにし、修正または変更の追加調整のための適切な手順を決定するのを助けます。
主な特徴:
ビジネスアナリストは、要件検証のタスクをテスターやQAチームに完全に委任できますか？
いいえ、QAはシステムをテストしますが、アナリストは製品がビジネス要件に適合していることに責任があります。彼はビジネスコンテキストにおける専門知識を持っています。
すべての機能要件が実装されているが、非機能要件が考慮されていない場合でも製品をリリースすることは許可されますか？
いいえ、非機能要件（パフォーマンス、安全性、使いやすさ）の不履行は、運用停止やユーザーの不満につながります。
要件が形式化されておらず、口頭の合意のみに存在する場合、その要件を検証済みと見なすことは可能ですか？
いいえ、要件は明確に記録され、形式化される必要があります。口頭の合意はしばしば誤解や間違いを引き起こします。
ネガティブケース: 開発者からのデモに基づいて結果を受け入れること、事前に受け入れ基準の形式化と合意がないこと。 プラス: 受け入れ段階が迅速に完了しました マイナス: 後で多くの考慮されていないニュアンスが明らかになり、顧客との間で対立が発生しました。
ポジティブケース: 要件を形式化し、顧客と要件文書を署名し、チェックリストを作成し、顧客との受け入れテストを実施しました。すべての指摘が記録され、修正されました。 プラス: 誤解が最小限に抑えられ、両者にとって透明なプロセス、争いのリスクが減少しました。 マイナス: 合意とテストのプロセスが予想以上に長くなりました。