2010年7月20日

「要求の検証」とは耳慣れない用語です。この用語におなじみの読者はどのくらいいるでしょうか。

一方、「ソリューションの検証」とか「システムの検証」「ソフトウェアの検証」はかなりおなじみではないでしょうか。

まず、「検証（Verification）」とは、成果物が仕様どおりに作成されているか（Do things right.）を確認するプロセスです。一方「妥当性確認（Validation）」は、成果物が意図された正しいもの（役に立つもの）になっているか（Do right things）を確認するプロセスです。

「ソリューションの検証」はソリューションが仕様どおりに出来上がっているかをチェックするもので、通常「結合テスト」や「総合テスト」で行われます。作る側の視点ですから、プロジェクト内部の仕事です。

そして、「ソリューションの妥当性確認」は利用者側の視点ですから、通常受入れ検査（テスト）になります。

他の知識体系（CMMI、SWEBOK、共通フレーム2007）でも同様の定義です。

ソリューションの「検証」と「妥当性確認」は上記のように、広く普及している概念です。

ところが、「要求の検証」と「要求の妥当性確認」はまだあまり普及していません。他の知識体系では一部あるものと、そうでないものがあり、取り扱い（定義を含めて）が一定ではありません。

【インプット】

　－要求(*)[表明された要求を除く]

　（ビジネス要求、ステークホルダ要求、ソリューション要求、移行要求など）

「要求の検証」の定義：　要求が正しく定義されていて受け入れ可能な品質をもつこと。

そして、要求品質の特性として以下を定義しています。

　[凝集性]

　　要求は一つのことに関連している。1つの要求が複数の事柄をカバーすることはよくありません。

　[完全性]

　　要求に抜けや、漏れがないこと。

　　例えば、DFD（データフロー図）のデータフローには全てラベルや、矢印が付いているかをチェックします。各モデルにおいて間違いがあってはいけません。

　[一貫性]

　　要求間で矛盾がなく整合していること。

 [正確性]

　　要求に欠陥があってはいけません。間違った表現をしてはいけません。

[実現可能]

　　実装可能でなければならない。実装することができないものを要求に含めてはいけません。

　[修正可能]

　　必要に応じ、個々の要求に対する変更履歴を管理できるようになっていなくてはいけません。

　[あいまいでない]

　　要求は一通りの解釈ができるものである必要があります。複数の解釈ができるものは困ります。

　[テスト可能性]

　　要求が正しく実装されているか客観的に証明するためには、テストできなければいけません。

要求に品質という概念があることを理解していただけたでしょうか。

また、「ソリューションの検証」と「要求の検証」（BABOK(R)での定義）の違いもお分かりいただけましたでしょうか。「要求の検証」はBABOK(R)ならではのタスクと言えます。他の知識体系では明確に定義されていません。