需求評審流程規(guī)范

1、需求評審流程規(guī)范1. 評審的作用、目的和概念在團隊開發(fā)中，充分的溝通是非常有必要的，溝通的方式之一就是通過文檔。不論評審的效果如何，發(fā)現(xiàn)多少問題都可以讓相關(guān)人員了解需求與設(shè)計。而通過相互之間的討論，澄清一些模糊的認識，進一步理解文檔的含義。評審不但是軟件開發(fā)活動中一個重要的質(zhì)量控制機制，而且也是一個重要而有效的溝通方式。通過評審可以利用企業(yè)內(nèi)部各種優(yōu)秀成員的智慧，為軟件開發(fā)尋找最佳的解決方案。評審的作用和目的主要是盡早發(fā)現(xiàn)潛在的問題，盡早糾正缺陷，控制糾正成本的滾雪球效應(yīng)。本階段造成的錯誤如果能夠及時地發(fā)現(xiàn)，或者在后面越早的階段發(fā)現(xiàn)，就能夠及早發(fā)現(xiàn)潛在的風(fēng)險，及時做好防范的對策，做到未雨綢繆。

2、評審的過程不僅是為了發(fā)現(xiàn)問題，而且為了便于跟蹤及改正，還應(yīng)當(dāng)對問題進行記錄。特別是需要對問題的真實性進行確認，剔除可能是誤解、似是而非或不必采納的建議性問題。2. 評審角色構(gòu)成因素評審人員的選擇是評審效果的關(guān)鍵，需要考慮以下因素： 項目重要性：項目重要性是決定角色構(gòu)成的最重要的因素，評審角色的構(gòu)成因素首先要根據(jù)項目的重要性而定。這與需要投入的成本有關(guān)，對于重要的項目一般會更多地投入資源，提高評審級別。 項目復(fù)雜度：項目的復(fù)雜度也是決定角色構(gòu)成的因素之一，根據(jù)溫伯格的公式，項目管理的復(fù)雜度相當(dāng)于功能規(guī)模的平方數(shù)。筆者認為還應(yīng)該考慮技術(shù)復(fù)雜度、技術(shù)新鮮度和文檔復(fù)雜度等因素。 項目組成員的能力成分和

3、水平：評審角色構(gòu)成還應(yīng)當(dāng)根據(jù)項目團隊成員本身的各項技術(shù)水平，特別是分析和設(shè)計的技術(shù)水平如何，行業(yè)領(lǐng)域知識是否豐富來進行搭配。除了團隊內(nèi)部自己進行評審之外，評審團隊最好是一些獨立于項目團隊之外的成員構(gòu)成。應(yīng)當(dāng)注意的原則是人數(shù)要少而精，一個人可以兼多個角色，但要覆蓋各項人員需求。需要說明的是，不具備評審能力的不應(yīng)參加，可以通過旁聽來提高水平。3. 基本角色職責(zé) 評審組長：制定評審計劃、確定或制定各項評審準則、必要時組織評審人員進行培訓(xùn)、組織必要的資源、進行評審分工、確保正式評審準備充分、分發(fā)待評審文檔、必要時召開并主持評審會議、向有關(guān)領(lǐng)導(dǎo)報告評審結(jié)果，并且跟蹤評審錯誤的改正。 評審人員：必要時參加

4、與評審有關(guān)的培訓(xùn)、按評審計劃閱讀待評審材料、保證對待評審材料的理解、與待評審材料作者討論，并且指出和記錄問題。 文檔作者：按評審計劃準備并按時提交待評審材料、必要時對材料進行解釋、必要時參加評審會議，并且在確定需要改進時按時完成修改。 記錄人員：評審會議中記錄評審人員提出的問題及相關(guān)討論。 項目經(jīng)理：制定保證評審和改正的項目進度計劃，還要確保評審準備時間、評審會議時間及錯誤的改正時間。而且評審安排及結(jié)果與所有項目成員溝通，必要時參加評審會議、閱讀評審報告、分析缺陷原因，并且改進項目質(zhì)量。4. 文檔評審的層次 過程規(guī)范：是否符合過程規(guī)范、是否按照計劃提交、是否按時經(jīng)過評審、是否準時發(fā)布（注意提交

5、時間與發(fā)布時間的區(qū)別），以及評審的流程是否規(guī)范。適合的評審人員：QA。 文檔規(guī)范：文檔成果符合企業(yè)或業(yè)界已經(jīng)制定的文檔模板規(guī)范。企業(yè)，甚至行業(yè)應(yīng)當(dāng)制定統(tǒng)一的文檔規(guī)范，形成一個文檔約定和規(guī)則，以統(tǒng)一文檔內(nèi)容與風(fēng)格。適合的評審人員：QA。 文檔語法：文檔成果正確使用通用的方法與術(shù)語并符合軟件工程相關(guān)的技術(shù)標準，這里所說的語法包括自然語言的語法和建模語言的語法。適合的評審人員要求：精通軟件工程、分析與設(shè)計方法、建模工具和相關(guān)標準。 文檔語義：文檔成果表達清晰、無歧義，可以反映系統(tǒng)目標。所有質(zhì)量合格的文檔（包括模型）都代表它期望代表的語義，而且應(yīng)該在代表這些語義時具有一致性。文字與圖表應(yīng)當(dāng)互相補充說明

6、，以更加清晰。讓別人看得懂，看完后知道下一步該怎么做。適合的評審人員：行業(yè)業(yè)務(wù)專家、高級程序員和測試工程師。 文檔邏輯：主要體現(xiàn)需求與設(shè)計正確性、一致性，無遺漏、多余或錯誤。前后左右考慮周全，不同文檔之間、文檔與行業(yè)標準之間、同一文檔各成分之間不互相矛盾，清晰說明相關(guān)部分之間的關(guān)系，特別是要符合相關(guān)行業(yè)的業(yè)務(wù)標準規(guī)范。適合的評審人員：行業(yè)業(yè)務(wù)專家、產(chǎn)品經(jīng)理和測試工程師。 文檔美學(xué)：文檔成果能否表述得更好一些，文字、圖表是否能更加均衡和完整。需要追求平衡的美，每個組成部分應(yīng)該大小適中，可解讀并可變更。平衡有多個方面，如排版次序更加合理、文字、圖形更加精煉并更易理解等。適合的評審人員：系統(tǒng)分析與設(shè)

7、計專家，以及建模工具專家。 結(jié)果優(yōu)化：通過檢查判斷文檔成果（如項目計劃、需求規(guī)格及設(shè)計方案）是否還有改進的空間，以便更加方便地進行項目管理、降低成本、加快進度、提高質(zhì)量并減少風(fēng)險，盡可能達到最佳方案。任何一項設(shè)計都可以有許多不同的方案，通過“方案優(yōu)化”選定一種最好的方案。適合的評審人員：系統(tǒng)分析與設(shè)計專家、項目經(jīng)理和產(chǎn)品經(jīng)理。5. 文檔評審流程5.1評審流程概覽 確定評審組長。 制定并發(fā)布評審計劃。 準備評審。 舉行評審會議。 改正、跟蹤和回歸評審。 分析、總結(jié)和報告。 歸檔。5.2確定評審組長由品質(zhì)保證人員與項目經(jīng)理、部門經(jīng)理論協(xié)商，確定項目的評審級別及評審人員角色構(gòu)成要求，初步確定評審組長

8、人選。品質(zhì)保證人員與評審組長溝通，最終確定評審組長。評審組長充分了解項目相關(guān)情況，為制定評審計劃做好準備。5.3評審計劃 評審組長制定評審計劃（根據(jù)項目計劃和質(zhì)量計劃）。 評審組長確定評審對象和評審時間。 評審組長確定評審級別和策略（形式的組合）。 評審組長確定評審流程裁減和提交物。 評審組長確定入口條件并通過準則。 評審組長確定回歸評審準則。 評審組長制定評審檢查表（CheckList）。 評審組長確定評審角色構(gòu)成。 評審組長根據(jù)評審角色構(gòu)成確定評審人員并成立評審小組。 相關(guān)人員（評審人員和項目團隊雙方）確認評審計劃。評審組長發(fā)布評審計劃。5.4評審準備 正式評審前準備：文檔作者向相關(guān)人員發(fā)

9、布文檔。 評審人員閱讀了解文檔，爭取發(fā)現(xiàn)大部分問題。 文檔作者解決大部分發(fā)現(xiàn)的問題。 評審組長確定會議地點、環(huán)境、設(shè)備和所有材料。 評審組長確定人員職責(zé)和會議議程。 評審組長確定評審開始條件成熟。 評審組長通知相關(guān)人員到會。5.5評審會議 主持人（評審組長）宣布會議議程、人員職責(zé)和會場紀律。 文檔作者介紹工作成果，對評審人員的疑問進行必要的解釋。 評審人員對不解之處提出疑問，指出問題或缺陷并說明根據(jù)。 文檔作者與評審人員討論缺陷的真實性，分清缺陷性問題和建議性問題，討論確定是否需要按照評審人員的要求進行改進。一般不涉及為節(jié)省時間改進方案或錯誤的糾正方案。5.6評審記錄 正式評審應(yīng)當(dāng)記錄有共識的

10、問題或缺陷，也要記錄有爭議待解決的問題。使評審工作文檔化，便于跟蹤最終解決。 總體記錄：包括項目名稱、系統(tǒng)名稱版本號、日期時間、主文檔名稱、附文檔名稱、文檔版本號、作者、評審類型（首次、回歸、部分和階段）、評審人員和評審結(jié)論。 缺陷記錄：包括缺陷編號、提出者、章節(jié)頁碼、缺陷描述、缺陷類型（嚴重、一般和建議）和承諾改正時間。 驗證記錄：全部打勾的CheckList，說明CheckList所列的工作都已經(jīng)做完，所列的內(nèi)容都已經(jīng)評審?fù)?，確保工作的完整性。5.7評審結(jié)論評審結(jié)論包括如下內(nèi)容。 是否需要修改？這是就成果的整體而言，結(jié)論可以是無需、少量、較大或是一個量化的數(shù)字。 項目組確定是否接受修改要求

11、？這是針對具體的一條意見或建議。有些問題可能是誤會，消除了就不是問題；有些建議性的問題，項目組考慮進度可不接受修改要求。 如不接受修改要求，項目組給出不修改的理由。 如何處理？是否需要進行回歸評審？ 總體結(jié)論：合格或不合格。 確定的修改責(zé)任人和跟蹤責(zé)任人。 確定的回歸評審時間。 是否都認同評審結(jié)論？如果需要做得更正式一些，可以要求相關(guān)人員簽字表示同意評審結(jié)論，簽字5.8跟蹤與總結(jié)評審中發(fā)現(xiàn)的問題的后續(xù)跟蹤是改正錯誤并消除缺陷的有效措施，應(yīng)當(dāng)有專門的責(zé)任人進行后續(xù)跟蹤確認錯誤都已改正，根據(jù)結(jié)論必要時回歸評審。 評審組長分析評審數(shù)據(jù)并總結(jié)經(jīng)驗。 評審組長發(fā)布評審記錄與數(shù)據(jù)分析報告。 管理人員應(yīng)當(dāng)防止評審數(shù)據(jù)被不恰當(dāng)?shù)厥褂?，如果使用評審數(shù)據(jù)來對個人進行績效評價，將會給以后的評審工作造成障礙，使評審各方不能放開進行評審。 評審組長進行工作總結(jié)，工作總結(jié)很有必要，有利于對項目或過程的改進。 評審組長提交各類評審報告，有關(guān)領(lǐng)導(dǎo)批準發(fā)布通過的文檔。5.9材料歸檔評審材料歸檔是項目配置管理工作的一部分。新建項目，記載配置管理工具中為此項目建立一個目錄，并建立下列子目錄。 待評閱態(tài)：文件放入此目錄后會自動通過郵件通知需要評閱的人員，全體評閱人員評閱完畢，也會自動通過郵件把意見通知文檔作者并實現(xiàn)到期自動提醒功能。 待評審