V&V #2

以前書いたVerification & Validationの記事は、ちょっと拙かったので改めて再考してみた。

まず「正しく取り込まれているか」と「正しく構築されているか」という表現をしたが、どうもしっくりこない。「正しく反映されているか」と「正しく実現されているか」と置き換えたい。取り込むだけでなく、なんらかの反映があるし、構築＝実装という表現は、中間的な作業成果物には不適当と判断した。

Verification & Validationの定義

検証(Verification)は、対象(システムやシステムの構成要素)が、対象に与えられた要求・要件・仕様どおりに正しく実現されているかどうかを確認することだ。妥当性確認(Validation)は、顧客・利害関係者の所期のニーズや要求が対象に正しく反映されているかどうかを確認すること、つまりビジネス上の狙いや価値を反映したものや顧客の意図していたものになっているかどうかを確認することだ。（※この部分の表現を変更した）

Verification & Validationのように、検証して妥当性確認を行うという順で明示されることが多いことは、前回述べた。これは、Verificationは開発側で内部的(インターナル)に行えるのに対し、Validationは顧客や関係者を巻き込む場合が通常なので、まずはインターナルなVerificationを行って問題なければValidationに臨みなさいという示唆である。また、階層化される構成要素に対応して作業が細分されている場合、そのタスクの担当者は顧客要件(所期のニーズや要求)を十分に把握できていないという状況も想定される。

Verification & Validationの詳細

活動には、入力の作業成果物があり、活動の内部でなんらかの変換作業が実施され、新たな作業成果物が出力される。たとえば、要求の仕様化では、システム要求が入力でシステム要件が出力である。システムアーキテクチャ設計では、システム要件が入力でシステム設計が出力である。各構成要素の設計では、構成要素の仕様が入力で各設計が出力となる、などだ。

検証(Verification)は、活動の出力と入力を照合して、出力が入力で与えられた要求・要件・仕様どおりに正しく実現されているかを確認することだ。これは活動の事後条件を満たしているかどうかをチェックすることに相当する。

妥当性確認(Validation)は、活動の出力と顧客要件を照合して、出力が顧客の所期のニーズや要求を正しく反映しているか、言い換えると正しいものを実現できているかを確認することだ。これは、検証(Verification)を前提とするならば、活動の事前条件をチェックすることに相当する。開発はプロセスの連鎖で進められるので、その過程で所期のニーズや要求から乖離することがありえる。それをチェックする訳だ。

通常、活動の最初に入力となる要求・要件・仕様は担当者の理解のためにもレビューされる。その際に顧客要件と照合した確認作業も行われるかもしれない。しかし、この段階では妥当性を十分に確認できない場合がある。活動を経て出力された作業成果物から、初めて視覚的に確認できるものがある。たとえば、システム要件に含まれる画面をイメージするとわかりやすい。要求の仕様化では、自然言語(ユースケース記述など)で表現された要求を入力として、画面イメージを含む画面要件を定義する。顧客や利害関係者は、その画面イメージを実際にながめてみることにより、本来の自分たちの意図に合致しているかをより具体的に認識できるのだ。（※この部分の解釈を追加した）

予防的なVerification & Validation

中間的な作業成果物に対して、早期に予防的にV&Vを適用することが推奨されている。検証(Verification)の手段としては、レビューやプロトタイプでの検証が挙げられる。妥当性確認(Validation)についても、顧客・利害関係者を巻き込んだレビューやプロトタイプ(モックアップ)での確認、また受け入れテストのテストケース作成などがある。受け入れテストのテストケース(テスト仕様)を記述することは、妥当性確認の１つの技法として取り上げられている。これはテストケースが十分に記述できるということは、要求に曖昧さがなく定量的であることを意味している。