評審人員：必要時參加與評審有關的培訓、按評審計畫閱讀待評審材料、保證對待評審材料的理解、與待評審材料作者討論，並且指出和記錄問題。
文件作者：按評審計畫準備並按時提交待評審材料、必要時對材料進行解釋、必要時參加評審會議，並且在確定需要改進時按時完成修改。
記錄人員：評審會議中記錄評審人員提出的問題及相關討論。
專案經理：制定保證評審和改正的專案進度計畫，還要確保評審準備時間、評審會議時間及錯誤的改正時間。而且評審安排及結果與所有專案成員溝通，必要時參加評審會議、閱讀評審報告、分析缺陷原因，並且改進專案質量。
過程規範：是否符合過程規範、是否按照計畫提交、是否按時經過評審、是否準時發布（注意提交時間與發布時間的區別），以及評審的流程是否規範。
適合的評審人員：qa。
文件規範：文件成果符合企業或業界已經制定的文件模板規範。企業，甚至行業應當制定統一的文件規範，形成乙個文件約定和規則，以統一文件內容與風格。
適合的評審人員：qa。
文件語法：文件成果正確使用通用的方法與術語並符合軟體工程相關的技術標準，這裡所說的語法包括自然語言的語法和建模語言的語法。
適合的評審人員要求：精通軟體工程、分析與設計方法、建模工具和相關標準。
文件語義：文件成果表達清晰、無歧義，可以反映系統目標。所有質量合格的文件（包括模型）都代表它期望代表的語義，而且應該在代表這些語義時具有一致性。
文字與圖表應當互相補充說明，以更加清晰。讓別人看得懂，看完後知道下一步該怎麼做。
適合的評審人員：行業業務專家、高階程式設計師和測試工程師。
文件邏輯：主要體現需求與設計正確性、一致性，無遺漏、多餘或錯誤。前後左右考慮周全，不同文件之間、文件與行業標準之間、同一文件各成分之間不互相矛盾，清晰說明相關部分之間的關係，特別是要符合相關行業的業務標準規範。
適合的評審人員：行業業務專家、產品經理和測試工程師。
文件美學：文件成果能否表述得更好一些，文字、圖表是否能更加均衡和完整。需要追求平衡的美，每個組成部分應該大小適中，可解讀並可變更。
平衡有多個方面，如排版次序更加合理、文字、圖形更加精煉並更易理解等。
適合的評審人員：系統分析與設計專家，以及建模工具專家。
結果優化：通過檢查判斷文件成果（如專案計畫、需求規格及設計方案）是否還有改進的空間，以便更加方便地進行專案管理、降低成本、加快進度、提高質量並減少風險，盡可能達到最佳方案。任何一項設計都可以有許多不同的方案，通過「方案優化」選定一種最好的方案。
適合的評審人員：系統分析與設計專家、專案經理和產品經理。
① 確定評審組長。
② 制定並發布評審計畫。
③ 準備評審。
④ 舉行評審會議。
⑤ 改正、跟蹤和回歸評審。
⑥ 分析、總結和報告。
⑦ 歸檔。
由品質保證人員與專案經理、部門經理論協商，確定專案的評審級別及評審人員角色構成要求，初步確定評審組長人選。品質保證人員與評審組長溝通，最終確定評審組長。評審組長充分了解專案相關情況，為制定評審計畫做好準備。
① 評審組長制定評審計畫（根據專案計畫和質量計畫）。
② 評審組長確定評審物件和評審時間。
③ 評審組長確定評審級別和策略（形式的組合）。
④ 評審組長確定評審流程裁減和提交物。
⑤ 評審組長確定入口條件並通過準則。
⑥ 評審組長確定回歸評審準則。
⑦ 評審組長制定評審檢查表（checklist）。
⑧ 評審組長確定評審角色構成。
⑨ 評審組長根據評審角色構成確定評審人員並成立評審小組。
⑩ 相關人員（評審人員和專案團隊雙方）確認評審計畫。
評審組長發布評審計畫。
① 正式評審前準備：文件作者向相關人員發布文件。
② 評審人員閱讀了解文件，爭取發現大部分問題。
③ 文件作者解決大部分發現的問題。
④ 評審組長確定會議地點、環境、裝置和所有材料。
⑤ 評審組長確定人員職責和會議議程。
⑥ 評審組長確定評審開始條件成熟。
⑦ 評審組長通知相關人員到會。
① 主持人（評審組長）宣布會議議程、人員職責和會場紀律。
② 文件作者介紹工作成果，對評審人員的疑問進行必要的解釋。
③ 評審人員對不解之處提出疑問，指出問題或缺陷並說明根據。
④ 文件作者與評審人員討論缺陷的真實性，分清缺陷性問題和建議性問題，討論確定是否需要按照評審人員的要求進行改進。一般不涉及為節省時間改進方案或錯誤的糾正方案。
① 正式評審應當記錄有共識的問題或缺陷，也要記錄有爭議待解決的問題。使評審工作文件化，便於跟蹤最終解決。
② 總體記錄：包括專案名稱、系統名稱版本號、日期時間、主文件名稱、附文件名稱、文件版本號、作者、評審型別（首次、回歸、部分和階段）、評審人員和評審結論。
③ 缺陷記錄：包括缺陷編號、提出者、章節／頁碼、缺陷描述、缺陷型別（嚴重、一般和建議）和承諾改正時間。
④ 驗證記錄：全部打勾的checklist，說明checklist所列的工作都已經做完，所列的內容都已經評審完，確保工作的完整性。
評審結論包括如下內容。
① 是否需要修改？這是就成果的整體而言，結論可以是無需、少量、較大或是乙個量化的數字。
② 專案組確定是否接受修改要求？這是針對具體的一條意見或建議。有些問題可能是誤會，消除了就不是問題；有些建議性的問題，專案組考慮進度可不接受修改要求。
— 如不接受修改要求，專案組給出不修改的理由。
— 如何處理？是否需要進行回歸評審？
— 總體結論：合格或不合格。
— 確定的修改責任人和跟蹤責任人。
— 確定的回歸評審時間。
— 是否都認同評審結論？如果需要做得更正式一些，可以要求相關人員簽字表示同意評審結論，簽字
評審中發現的問題的後續跟蹤是改正錯誤並消除缺陷的有效措施，應當有專門的責任人進行後續跟蹤確認錯誤都已改正，根據結論必要時回歸評審。
① 評審組長分析評審資料並總結經驗。
② 評審組長發布評審記錄與資料分析報告。
③ 管理人員應當防止評審資料被不恰當地使用，如果使用評審資料來對個人進行績效評價，將會給以後的評審工作造成障礙，使評審各方不能放開進行評審。
④ 評審組長進行工作總結，工作總結很有必要，有利於對專案或過程的改進。
⑤ 評審組長提交各類評審報告，有關領導批准發布通過的文件。
評審材料歸檔是專案配置管理工作的一部分。新建專案，記載配置管理工具中為此專案建立乙個目錄，並建立下列子目錄。
① 待評閱態：檔案放入此目錄後會自動通過郵件通知需要評閱的人員，全體評閱人員評閱完畢，也會自動通過郵件把意見通知文件作者並實現到期自動提醒功能。
② 待評審態：檔案放入此目錄後會自動通過郵件通知需要評審的人員，全體評閱人員評審完畢，也會自動通過郵件把批准或拒絕的意見通知文件作者並實現到期自動提醒功能。
③ 受控態：評審批准後自動轉入受控態並發布自動郵件。
④ 簽出態：為了修改而版本公升級，當檔案簽出時放入簽出態。修改後的文件可能簽入到待評閱態、待評審態或直接到受控態，但文件版本已經公升級。
⑤ 產品態：專案結束後受控態的文件自動歸到產品態。
02需求評審流程
檢驗檢疫業務資訊化工作管理作業指導書 需求評審流程說明 為規範檢驗檢疫業務資訊化工作，根據有關法律法規及總局有關管理規定，結合資訊化工作實際，制定本流程說明。本流程適用於對已立項的檢驗檢疫業務資訊化專案，專案單位組織編寫的檢驗檢疫業務資訊化專案使用者需求已完成，組織進行需求評審工作。1 申請需求評審...
需求評審報告
編號 atkj rw tf 01 a 填表說明 1 本評審報告適用於所有的評審。2 評審工作量 評審時長 評審人數 評審總工作量 評審預讀總工作量 評審準備總工作量 評審工作量 評審後整理工作量 評審效率 評審差錯總數 評審總工作量 返工工作量 解決工作量 確認工作量。3 評審差錯分類分為 1 5級...
什麼是需求評審
開評審會議時經常會 跑題 導致評審效率很低。有時話匣子一開啟後關不上，大家越扯越遠，結果評審會議變成了聊天會議。主持人應當控制話題，避免大家討論與主題無關的東西。對於自主研發的產品，由於需求評審人員大部分是開發人員，大家會不知不覺地談論軟體 如何做 由於需求是否 可實現 可驗證 可測試 本來就屬於需...