1. 概述
一次正式的會議。在會議上向使用者、客戶或其他相關各方介紹乙個或一組工作產品，以徵求對方的意見和批准。評審的最終目的是得到評審員的批准。
2. 流程圖
2.1 主流程
評審會
準備評審－－－－》發現缺陷－－－》作出決定－－－》會議結束
2.2 準備評審
小組負責人：計畫評審、發評審通知
協調員： 分發評審資料
評審員： 構思問題
2.3 發現缺陷
協調員：主持會議
評審員：提出問題、討論問題、確定缺陷
記錄員：記錄缺陷
2.4 作出決定
評審員：作出評審決定、確定跟蹤人或下次評審時間
記錄員：記錄評審決定
3. 詳細說明
3.1 計畫
作者要確定評審的重點和範圍，編制待評審工作產品的檢查點。針對專案所處的不同階段，所關注的重點和範圍可能不一樣，檢查點也就不同。
確定了評審範圍之後，便可以確定評審者及擔任的角色、議程和進行評審所需的資訊。選擇評審者時，應該在軟體構架專業知識和領域專業知識之間建立平衡。一般情況下，評審者主要是本專案/本部門人員，評審者中要有該工作產品的使用者，如果有必要，請求其他專案/部門的人員做評審者。評審者必須是對待評審工作產品是否通過評審具有批准權的人員。
評審者的角色分：
協調員:協調員確保評審按議程進行，並以當前的主題為重點。協調員應該確保對枝節問題的討論不會使評審脫離正軌，而且所有評審員都以平等的身份參加討論。
評審員:評審員提出問題。一定要側重於提出問題，而不要耗費大量精力討論如何解決問題。注重結果，而不是方法。
讀者:閱讀待評審工作產品，這個角色通常可由作者承擔。
記錄員:記錄所討論的內容和要採取的行動。
評審者的數目應該控制在三~七個人。如果評審員的數量太多，實際上會因為會議時間過長、參與更困難，以及在評審過程中增加了枝節問題和討論，而降低評審的質量。如果評審者少於三個，則會因為減少了問題的多樣性而增加片面性的風險。所有評審者都充當評審員角色。
評審員應該在要評審的領域擁有豐富經驗；對於用例，評審員應該理解問題領域；對於軟體構架，評審員還需要具備軟體設計技術的知識。缺乏經驗的評審員可以通過參與評審了解有關構架的內容，但他們對評審的幫助很小，同時他們的參與還可能會分散評審力量。
選擇符合以下條件的評審員：
具有相當的背景來理解所介紹的材料。
所評審產品或工作產品的質量與之有利害關係。
協調者與作者確定評審會議的時間並通知評審者。在資料分發和評審會議之間應該有足夠的時間讓評審者做準備工作。
3.2 準備
評審之前，作者應該收集要評審的工作產品、檢查點和所有背景材料，並分發給評審者。預先分發足夠的評審材料，讓評審者有時間準備評審，可以顯著提高評審結果的質量。準備評審還會大大提高評審的效率和有效性。
評審者應該在評審之前研究文件、構思問題、確定要討論的問題，並記錄到《缺陷記錄》。在評審員正常工作量的情況下，幾個工作日通常是準備評審所需的最少時間。
評審者如果對檢查點有疑義，應在評審前與作者溝通並解決。若作者修改了檢查點，則要及時把修改後的檢查點分發給評審者。
3.3 評審
3.3.1 理解評審流程
一般來說，評審流程是乙個重複進行的迴圈過程：
評審員提出問題
討論問題，同時對問題進行了確認
確定缺陷（確定需要解決的地方）
記錄員記錄問題
直到沒有確定的問題時再繼續下一步
為了使這個過程有效進行，每個人都必須理解評審的目標是提高評審工作產品的質量。應該以發現問題的挑剔眼光來評審工作產品。這種做法可能很困難，所以所有評審員都必須經常提醒自己將重點放在確定問題上。我們都強烈地感覺到工作是屬於自己的；通常，我們很難接受批評，甚至是建設性的批評。因為這樣，我們必須更加努力地工作，以便將注意力集中在評審目標上：使工作產品的質量更好。
3.3.2 使評審保持簡短
簡短而側重於明確目標的評審是最有效的。因為很難長期保持重點，而且評審員還有其他的工作要做，應該將評審時間限制在兩小時之內。如果要進行時間較長的評審，可以將其拆分為幾個規模較小、更有重點的評審。如果評審員能保持重點，就會獲得更好的結果。
這種作法的關鍵是制定非常確定的議程和清楚明確的目標。分發評審材料後，應該向大家傳達這些目標，而且評審會議開始時，協調員應該強調這些目標。之後，在會議進行期間，協調員還必須經常地（有時是強迫性的）強調這些目標。
3.3.3 確定問題，而不要解決問題
評審會議無法實現預期結果的乙個主要原因是，會議很容易變成關於應該如何解決問題的討論。解決問題通常需要調查和仔細思考；評審的形式對於這種討論來說不是乙個有效的方法。確定了問題之後，確定該缺陷是否必須得到解決，之後將調查和解決的任務分配給某個人。評審會議應該只注重確定問題。
如果問題需要一組人作進一步的討論，就另外召開一次單獨的會議重點討論該主題。通常，這種會議需要一些調查和準備工作，而且需要一些具備適當工作技能的人員參加。評審應該將重點放在確定其他問題上。協調員經常需要施加相當大的影響，來確保評審會議側重於這個方向。
3.3.4 作出決定
評審者討論決定是否通過評審，決定有：通過，有條件通過，部分通過，不通過。對於有條件通過，要註明條件及跟蹤人；對於部分通過，要說明通過的部分，決定未通過部分的下次評審時間；對於不通過，要決定下次評審時間。
3.4 對評審結果採取行動
如果不對評審結果採取行動，那麼評審就沒有什麼價值。評審結束時：
確定問題列表的優先順序。
建立缺陷，以追蹤問題及其解決辦法。
如果需要進行其他調查，將調查問題（而不是解決問題）的任務分配給乙個小團隊。
對於可以在當前迭代中解決的問題，指派乙個人或乙個團隊解決該問題。
將未解決問題的列表留給未來的迭代計畫工作。
架構設計 概要設計評審
1.1整理需求用例 新平台或多系統需求 要求描述 完整性概要設計應該覆蓋詳細需求設計 識別系統干係人 找到產品需求功能的使用者，可能是人 軟體 識別需求的關係 需求之間的泛化 包含 擴充套件，以便於模組的劃分 用例圖示例 用例圖教程 1.2模組劃分 要求描述 覆蓋當前所有需求 詳細需求設計上的任一需...
QA如何高效參與設計評審
qa如何高效參與設計評審 目標與方法 帶著如果按這個做出來後，真的能實現我們的需求與功能嗎？用各類使用者場景去構想他的設計與實現是否可行，是否存在遺漏。即提前去把所需功能按設計的思路，我們在腦海裡來執行一下 對關鍵的設計決定進行驗證，並幫助關鍵專案從設計階段轉化為最後的實現 從下面幾個方面去評審這份...
軟體設計評審檢查單
軟體設計評審檢查單 很多企業在做cmmi 3級，都要求了專案組要寫設計文件，做設計評審。按watts s.humphrey的建議，設計評審的工作量要大於設計工作量的1 2。很多企業也做了設計評審，但是很少發現實質性的問題。經過我的分析，發現缺少設計評審的檢查單是其中乙個很重要的原因，設計評審時專家使...