請問
(1)Requirements Validation、Products Validation、Requirements Verification、Products Verification四者之差別為何?
(2)前述四項應如何配合生命週期之Phase規畫?
(3)應完成何種文件?

有關驗證(Verification)和確認(Validation)在本網站在已有一些討論，可能過去都沒說得很清楚，以致還有人提出這類的問題，這次就儘量把它說清楚些。

首先，我們要知道：我們之所以要開發某一產品(Product)，一定是想藉由該產品去解決某一問題。所以反過來說，新產品的開發必是由最初的一個構想(Concept)(這個構想就是代表要解決的問題)開始，再經由一連串的過程將它具體化，直到最終產品的完成，而此一過程就是開發產品的生命週期。產品的最初構想是高度抽象化的，而開發完成的產品是最具體化的。所以開發產品的過程，就是不斷將產品的構想降低其抽象程度，直到最後形成產品。

而此一過程牽涉到哪些人員，會因為產品的大小(規模)、複雜度、操作產品的人數、使用壽期、對產品的安全要求…等等因素而不同。這些不同的人員具有不同的背景(文化)、知識、技能、經驗…，這些人員如何在產品的生命週期中精準地溝通有關產品的資訊？就成為開發產品能否成功的最主要關鍵，通常這就有賴其中的工作人員，以不同文件來呈現最終產品不同的抽象程度，這些文件也就成為最終產品不同抽象程度的化身。為了確保產品資訊在這些不同的文件中傳遞與轉換，只是降低其抽象程度而沒有失真，就必須對這些文件進行驗證與確認。在開發產品的生命週期內，要對每一份代表產品不同抽象度的文件以及最終產品進行驗證與確認。如果，不是如此，譬如：只對需求文件與最終產品做驗證確認，那麼所做的驗證確認將大打折扣，達不到做驗證確認的完整目的。

產品開發的生命週期中要用哪些文件來呈現產品不同的抽象程度？這些文件於何時產生？…這些問題是受到選用的開發產品的生命週期模型(就是專案中人員分工的方式)所影響，選用生命週期模型時要考量產品、人員、技能、管理方法與客戶的要求…等因素。基本上生命週期中的每個階段(phase)至少會出一份文件，而每份文件都會透過一個流程(Process)來產生，通常開發產品的專案至少會有產生產品需求文件(如：SRS)、設計文件(如：SDD)、實作產品…等的過程。而製作每一份文件必有其輸入(也就是製作該文件的依據)，而且每份文件也都有其用途，意即有其預定的讀者(即使用該文件的人)。

對需求文件做的驗證與確認就是需求驗證(Requirements Verification)和需求確認(Requirements Validation)，對最終產品做的驗證與確認就是產品驗證(Products Verification)和產品確認(Products Validation)。需求驗證的依據是產生需求文件的輸入，包括：RFP、訪談紀錄與Change Request，它的主要目的在驗證每一項提出的需要已納入需求文件中沒有遺漏。需求確認的依據是使用需求文件的目的，主要包括三項：其一使用者要確認需求文件代表的產品，如果被實作(implement)出來後，可以解決其問題，意即符合其最初要開發產品的構想；其二設計者要確認在技術上可以實現該需求；其三測試者要確認當產品完成時該需求可以被客觀的決定是否被滿足。產品驗證的依據是產品設計說明(如SDD)，其目的是在驗證每一項設計都在最終產品上實作出來了。產品確認是以使用產品的目的為依據，其目的為確認產品以達到預期的使用目的(即前面所說的產品構想)。雖說產品驗證的依為產品設計說明，但是實務上不會於驗證時才拿它來用，而是先依據產品設計說明，設計出白箱測試的測試個案，在於實際進行產品驗證時執行這些白箱測試的測試個案。同樣的產品確認是先依據已確認過的需求文件，設計黑箱測試的測試個案，再於實際進行產品確認時執行這些黑箱測試的測試個案。實務上產品驗證與產品確認除了上述的測試方式外，當然還有其它的方式，不過在此不一一說明。

驗證與確認最主要的產出應是發現的異常報告，每一項異常應有一個報告，以紀錄驗證確認的對象、異常的現象、執行的人員…等，這些是追蹤與除錯時要用到的資訊。實務上驗證確認要完成什麼文件，就必須依據專案計畫而定。有的專案會將驗證確認的活動另外規劃在獨立的驗證確認計畫中，那麼就要有相對應的驗證確認報告。同樣的如果專案有獨立的測試計畫，就要依據它產生必要的測試報告。

希望以上的說明足夠清楚，而對您有所幫助。

周茂松 敬上