在軟體產品發展生命週期中，做完軟體系統需求分析，產生了「軟體需求規格書(SRS)」，通常我們需要對這份文件做「評估」及「審查」，請問這個審查作業該定位成「驗證(Verification)」、「確認(Validation)」，或者「驗證與確認(V & V)」，為什麼 ？ 哪些人要參加 ？可採用什麼審查技術呢 ？ 以及該注意哪些事項 ？

請大家動動腦。說說您的看法~~~

@ 有興趣者可以參閱 [ 軟品協會電子報第 0007 期 ] ：

- 在「每個發展階段結束時」所實施的是「驗證」，而在「發展過程結束，交付給客戶前」所實施的是「確認」？ 這樣的認知其實是人云亦云，也顯示其對於工程過程產品的認知不夠充分 ......

- 許多資訊軟體從業人員的固有想法認為「軟體產品」或者「工作產品」不就是那個「在電腦上執行的程式」嗎 ？ 會有這樣的認知，其實是長久以來，國內的資訊軟體業者未重視軟體工程方法所造成的。所謂的工作產品、軟體產品，除了程式碼之外還包括軟體的需求文件、設計文件、測試文件等等 ......

----------------
引文:

請問林秘書長：

1. 在軟體發展過程中，何時需要實施驗證與確認(V&V) ?
2. 應該由誰來執行驗證與確認 ? 哪些人需要參加呢 ?

拜讀 [ 軟品協會電子報第 0007 期 ] 您的文章後，好像並沒有談到上述問題，能否賜教呢 ?

Orz

簡單地回覆一下：

首先，所謂驗證與確認，簡言之：「驗證」目的在看產品對於需求的符合性；「確認」目的在看產品是否符合使用目的。驗證確認的工作包括：測試、審查、分析、模擬等等，視產品特性及專案需求選擇(進一步且完整的說明，可以參閱相關的文件，例如CNS、ISO及IEEE的標準，或者參加本會所舉辦的「驗證與確認」推廣課程)。以這兩目的為基礎，來回答這兩個問題：

1. 在軟體發展過程中，何時需要實施驗證與確認(V&V) ?
驗證與確認是軟體全生命週期的活動，所謂軟體的全生命週期涵蓋了：獲取、供應、發展、運作及維護等五大過程，也就是軟體從概念發想起，一直到軟體產品從運作環境中汰除為止的所有活動。驗證的工作可以在生命週期中任何活動的期間來進行，驗證與確認的目標對象是「工作產品」。例如在需求分析階段中，對工作產品--「軟體需求規格書」分段實施驗證，一次審查數頁或十數頁(採用inspection方式)，確認則是在生命期中任何活動的最後，產品在交付給客戶前，對成為「產品」之「工作產品」所實施的檢驗工作，並常以確認工作的完成作為階段的結束。例如，在需求分析階段結束前，對將成為交付「產品」的「工作產品」--「軟體需求規格書」實施的檢驗，以確認後續的工作人員--例如軟體設計師、測試工程師、品保工程師能否運用這項產品進行其工作，客戶是否能以其作為付款的依據。有時候，這兩者可以就不同的目的，合併在一起實施。交付驗證與確認的項目，可以視需要涵蓋軟體生命週期中的所有工作產品與產品。

2. 應該由誰來執行驗證與確認 ? 哪些人需要參加呢 ?
驗證與確認的執行權責，可以由合約甲乙雙方議訂，因為從CNS 14837來看，獲取者(亦即甲方)可以對乙方實施(例如管理審查、驗收測試等)，而乙方可以實施並邀請甲方代表參加(此即聯合審查，工作里程碑上的審查會、聯合技術審查)，乙方也可以在內部對工作團隊的成果與產出實施。

驗證與確認活動有許多個層次，會就不同的產品/工作產品、不同的目的，而邀請不同的人員參與，這些人員涵蓋合約的甲乙雙方各個不同層次、工作領域的人員，例如：業主代表、業主專案經理、使用者本身、使用者代表、合約商的專案經理、計畫主持人、開發團隊成員(例如，SA、SD、PG等等)、測試人員、品保人員、監審商代表(若有監審商)、以及其他相關利害關係人等等。驗證與確認活動的層次可區分為「管理層次」及「技術(工作)層次」，執行的方式，在審查上可以有檢視、導覽、傳閱等；在測試上則是可以區分為單元測試、整合測試、系統測試及驗收測試等。

以上說明，請參考。

----------------
引文:

多謝林秘書長的賜教，我會報名參加您在5/16開的「軟體驗證與確認」課程。

我認為台灣軟體業者仿效硬體產業的兩岸分工獲利模式，應該是有機會的，也就是：「由台灣接單並做好系統需求分析與訂定規格 --> 委託大陸做系統設計與測試 --> 交回台灣做檢視與審查、驗證與確認 --> 交付產品給客戶」。

台灣軟體業者若要以「接單及委外生產者」的角色維續生存與競爭力，就應加強「系統需求分析與訂定規格」及「系統測試、檢視與審查、驗證與確認」的知識與能力，否則就只好大幅降低薪資，與大陸人拼程式設計了 !

我們公司最近承包了一個金融機構的資訊系統委外案，客戶要求在系統開發建置之前，除了必須提送專案管理計畫以外，還需要提交「驗證與確認計畫」，審核通過以後才能進行下一步的軟體需求分析及提報需求規格書，請問這個「驗證與確認計畫」應該要包含哪些內容呢 ?

期盼先進不吝賜教 (十萬火急) !

IEEE-STD-12207 + IEEE-STD-1012應足以提供你撰寫SVVP內容所需參考資訊。

資訊新兵

「驗證與確認計畫」的參考內容大綱如下：

1.目的
2.參考文件
3.用語釋義
4.驗證與確認
- 組織
- 主要時程
- 軟體健全度等級架構
- 資源
- 職責
- 工具/技術/方法
5.驗證與確認的流程
6.驗證與確認的報告需求
7.驗證與確認的行政管理需求
8.驗證與確認的文件需求

以上內容是摘自林泰龍老師的講義，建議您也可以去報名 3/30 林泰龍老師的課 ( 如果您時間來的及的話 )。

同意tyrone的說明。

我一邊引述tyrone的說明一邊說一下我們公司實際執行上的作法：

驗證的工作可以在生命週期中任何活動的期間來進行...
確認則是在生命週期中任何活動的最後...
驗證與確認活動有許多個層次，會就不同的產品/工作產品、不同的目的，而邀請不同的人員參與，這些人員涵蓋合約的甲乙雙方各個不同層次、工作領域的人員...

我們公司會接類似甲方監工的案子，通常會依照產品的特性，將產品切割成數個小單元分批進行驗證與確認。
由下一個階段的「接收者」「驗證」目前階段的「工作產品」對於需求的符合性；
由上一個階段的「產出者」「確認」目前階段的「工作產品」是否符合使用目的；
同一階段的Peer，則以平行的觀點，定位（確認）雙方角色目前的「位置」是否有偏差。
上/下一個階段的人員，則不限甲/乙雙方的角色，只要能達到目的的角色，我們就會邀請他參加，這樣，我們可以在一次的會議、討論中，推進一個小單元的「生命週期」。

不過，因為我們則是子公司，我們是將母公司的專案外包，所以，我們能夠這麼作，換作是其他公司，可能就沒有辦法這樣作了。

不知道我們這麼作，是不是能符合tyrone的說明？

　　下一個階段的接收者一起來做的是「確認」的工作，看看該工作產品是否能夠滿足下一個階段的使用目的，例如，能否用於設計工作、或用來安排測試的工作。
　　至於上一個階段的「產出者」可以一起來「驗證」目前階段的「工作產品」是否滿足前一個階段所提出的需求。例如前一個階段所分配給本階段工作產品的資訊安全需求、可用性需求、可維護性的需求.....是否在這個階段的工作產品中納入，並且做有效的展開了。當然這也可以不需要上一個階段「產出者」的參與，只要你做好需求的追溯工作。

----------------
引文: