要件検証は、要件が開発のために定義されていることを確認するプロセスであり、顧客が本当に望んでいるシ 要件に関連する問題を確認するために、要件の検証を実行します。 開発プロセスの後半で検出されたときにエラーが過度のリワークを増加させる可能性があるため、通常、要件検証を使用して開発の初期段階でエラーをチェ

要件検証プロセスでは、我々は、ソフトウェア要件仕様（SRS）に記載されている要件をチェックするためのテストの異なるタイプを実行し、これらのチェ….. 問題のリストは、要件検証のプロセス中に検出された問題を示します。 合意された措置のリストには、検出された問題を修正するために取られるべき是正措置が記載されています。

個別に、またはシステムの全体または一部をチェックするためにチェックする他の技術と組み合わせて使用されるいくつかの技術があります。

1. テストケース生成:
   Srs文書に記載されている要件はテスト可能でなければならず、実施されたテストでは、要件に存在するエラーが明らかになります。 一般的に、テストが設計が困難または不可能である場合、これは通常、要件を実装することが困難であり、再考すべきであることを意味すると考えられ
2. プロトタイピング：
   この検証技術では、システムのプロトタイプは、エンドユーザーまたは顧客の前に提示され、彼らは提示されたモデルを実験し、そ このタイプのモデルは、一般的に、ユーザーの要件に関するフィードバックを収集するために使用されます。
3. 要件レビュー:
   このアプローチでは、srsは、請負業者組織とクライアント側の両方の人々を含む人々のグループによって慎重にレビューされ、レビュアーは体系的にエラーと曖昧さをチェックするために文書を分析します。
4. 自動整合性分析:
   このアプローチは、要件仕様の非決定性、欠落ケース、型エラー、循環定義などのエラーを自動的に検出するために使用されます。

   まず、要件は正式な表記で構造化され、ケースツールを使用してシステムの一貫性をチェックし、すべての矛盾の報告が特定され、是正措置が取られます。

5. ウォークスルー:
   ウォークスルーには正式に定義された手順がなく、差別化された役割の割り当てを必要としません。
   • アイデアが実現可能かどうかを早期に確認します。
   • 他の人の意見や提案を得る。
   • 他人の承認を確認し、合意に達する。