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

1、.For personal use only in study and research;not for commercial use需求評審流程規(guī)范1. 評審的作用、目的和概念在團隊開發(fā)中， 充分的溝通是非常有必要的，溝通的方式之一就是通過文檔。不論評審的效果如何， 發(fā)現(xiàn)多少問題都可以讓相關(guān)人員了解需求與設(shè)計。而通過相互之間的討論，澄清一些模糊的認(rèn)識，進一步理解文檔的含義。評審不但是軟件開發(fā)活動中一個重要的質(zhì)量控制機制， 而且也是一個重要而有效的溝通方式。通過評審可以利用企業(yè)內(nèi)部各種優(yōu)秀成員的智慧，為軟件開發(fā)尋找最佳的解決方案。評審的作用和目的主要是盡早發(fā)現(xiàn)潛在的問題，盡早糾正缺陷， 控制糾

2、正成本的滾雪球效應(yīng)。 本階段造成的錯誤如果能夠及時地發(fā)現(xiàn)，或者在后面越早的階段發(fā)現(xiàn)，就能夠及早發(fā)現(xiàn)潛在的風(fēng)險，及時做好防范的對策，做到未雨綢繆。評審的過程不僅是為了發(fā)現(xiàn)問題，而且為了便于跟蹤及改正，還應(yīng)當(dāng)對問題進行記錄。特別是需要對問題的真實性進行確認(rèn)，剔除可能是誤解、 似是而非或不必采納的建議性問題。2. 評審角色構(gòu)成因素評審人員的選擇是評審效果的關(guān)鍵，需要考慮以下因素：? 項目重要性 ：項目重要性是決定角色構(gòu)成的最重要的因素， 評審角色的構(gòu)成因素首先要根據(jù)項目的重要性而定。 這與需要投入的成本有關(guān)， 對于重要的項目一般會更多地投入資源，提高評審級別。?項目復(fù)雜度： 項目的復(fù)雜度也是決定角色

3、構(gòu)成的因素之一，根據(jù)溫伯格的公式，項目管理的復(fù)雜度相當(dāng)于功能規(guī)模的平方數(shù)。筆者認(rèn)為還應(yīng)該考慮技術(shù)復(fù)雜度、技術(shù)新鮮度和文檔復(fù)雜度等因素。?項目組成員的能力成分和水平：評審角色構(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é)? 評審組長 ：制定評審計劃、 確定或制定各項評審準(zhǔn)則、 必要時組織評

4、審人員進行培訓(xùn)、組織必要的資源、進行評審分工、確保正式評審準(zhǔn)備充分、分發(fā)待評審文檔、必要時召開并主持評審會議、 向有關(guān)領(lǐng)導(dǎo)報告評審結(jié)果， 并且跟蹤評審錯誤的改正。? 評審人員 ：必要時參加與評審有關(guān)的培訓(xùn)、 按評審計劃閱讀待評審材料、 保證對待評審材料的理解、與待評審材料作者討論，并且指出和記錄問題。?文檔作者： 按評審計劃準(zhǔn)備并按時提交待評審材料、必要時對材料進行解釋、必要時參加評審會議，并且在確定需要改進時按時完成修改。? 記錄人員： 評審會議中記錄評審人員提出的問題及相關(guān)討論。?項目經(jīng)理： 制定保證評審和改正的項目進度計劃，還要確保評審準(zhǔn)備時間、評審會議時間及錯誤的改正時間。而且評審安排

5、及結(jié)果與所有項目成員溝通，必要時參加評審會議、閱讀評審報告、分析缺陷原因，并且改進項目質(zhì)量。4. 文檔評審的層次?過程規(guī)范 ：是否符合過程規(guī)范、是否按照計劃提交、是否按時經(jīng)過評審、是否準(zhǔn)時發(fā)布（注意提交時間與發(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ù)標(biāo)準(zhǔn)，這里所說的語法包括自然語言的語法和建模語言的語法。適合的評審人員要求：精通軟件工程、

6、分析與設(shè)計方法、建模工具和相關(guān)標(biāo)準(zhǔn)。? 文檔語義： 文檔成果表達(dá)清晰、無歧義，可以反映系統(tǒng)目標(biāo)。所有質(zhì)量合格的文檔（包括模型）都代表它期望代表的語義，而且應(yīng)該在代表這些語義時具有一致性。文字與圖表應(yīng)當(dāng)互相補充說明， 以更加清晰。 讓別人看得懂， 看完后知道下一步該怎么做 。適合的評審人員：行業(yè)業(yè)務(wù)專家、高級程序員和測試工程師。? 文檔邏輯： 主要體現(xiàn)需求與設(shè)計正確性、一致性，無遺漏、多余或錯誤。前后左右考慮周全，不同文檔之間、 文檔與行業(yè)標(biāo)準(zhǔn)之間、 同一文檔各成分之間不互相矛盾，清晰說明相關(guān)部分之間的關(guān)系，特別是要符合相關(guān)行業(yè)的業(yè)務(wù)標(biāo)準(zhǔn)規(guī)范。適合的評審人員：行業(yè)業(yè)務(wù)專家、產(chǎn)品經(jīng)理和測試工程師。

7、? ?文檔美學(xué)： 文檔成果能否表述得更好一些，文字、圖表是否能更加均衡和完整。需要追求平衡的美， 每個組成部分應(yīng)該大小適中， 可解讀并可變更。 平衡有多個方面，如排版次序更加合理、文字、圖形更加精煉并更易理解等。適合的評審人員：系統(tǒng)分析與設(shè)計專家，以及建模工具專家。? 結(jié)果優(yōu)化： 通過檢查判斷文檔成果 （如項目計劃、 需求規(guī)格及設(shè)計方案） 是否還有改進的空間，以便更加方便地進行項目管理、降低成本、 加快進度、提高質(zhì)量并減少風(fēng)險，盡可能達(dá)到最佳方案。任何一項設(shè)計都可以有許多不同的方案，通過“方案優(yōu)化 ”選定一種最好的方案。適合的評審人員：系統(tǒng)分析與設(shè)計專家、項目經(jīng)理和產(chǎn)品經(jīng)理。'.5.

8、文檔評審流程5.1 評審流程概覽 確定評審組長。 制定并發(fā)布評審計劃。 準(zhǔn)備評審。 舉行評審會議。 改正、跟蹤和回歸評審。 分析、總結(jié)和報告。 歸檔。5.2 確定評審組長由品質(zhì)保證人員與項目經(jīng)理、部門經(jīng)理論協(xié)商，確定項目的評審級別及評審人員角色構(gòu)成要求，初步確定評審組長人選。品質(zhì)保證人員與評審組長溝通，最終確定評審組長。評審組長充分了解項目相關(guān)情況，為制定評審計劃做好準(zhǔn)備。5.3 評審計劃 評審組長制定評審計劃（根據(jù)項目計劃和質(zhì)量計劃）。 評審組長確定評審對象和評審時間。 評審組長確定評審級別和策略（形式的組合）。 評審組長確定評審流程裁減和提交物。 評審組長確定入口條件并通過準(zhǔn)則。 評審組長

9、確定回歸評審準(zhǔn)則。 評審組長制定評審檢查表（CheckList）。 評審組長確定評審角色構(gòu)成。 評審組長根據(jù)評審角色構(gòu)成確定評審人員并成立評審小組。 相關(guān)人員（評審人員和項目團隊雙方）確認(rèn)評審計劃。評審組長發(fā)布評審計劃。5.4 評審準(zhǔn)備 正式評審前準(zhǔn)備：文檔作者向相關(guān)人員發(fā)布文檔。 評審人員閱讀了解文檔，爭取發(fā)現(xiàn)大部分問題。 文檔作者解決大部分發(fā)現(xiàn)的問題。'. 評審組長確定會議地點、環(huán)境、設(shè)備和所有材料。 評審組長確定人員職責(zé)和會議議程。 評審組長確定評審開始條件成熟。 評審組長通知相關(guān)人員到會。5.5 評審會議 主持人（評審組長）宣布會議議程、人員職責(zé)和會場紀(jì)律。 文檔作者介紹工作成

10、果，對評審人員的疑問進行必要的解釋。 評審人員對不解之處提出疑問，指出問題或缺陷并說明根據(jù)。 文檔作者與評審人員討論缺陷的真實性，分清缺陷性問題和建議性問題，討論確定是否需要按照評審人員的要求進行改進。 一般不涉及為節(jié)省時間改進方案或錯誤的糾正方案。5.6 評審記錄 正式評審應(yīng)當(dāng)記錄有共識的問題或缺陷，也要記錄有爭議待解決的問題。使評審工作文檔化，便于跟蹤最終解決。 總體記錄：包括項目名稱、系統(tǒng)名稱版本號、日期時間、主文檔名稱、附文檔名稱、文檔版本號、作者、評審類型（首次、回歸、部分和階段）、評審人員和評審結(jié)論。 缺陷記錄：包括缺陷編號、提出者、章節(jié)頁碼、缺陷描述、缺陷類型（嚴(yán)重、一般和建議）

11、和承諾改正時間。 驗證記錄：全部打勾的 CheckList，說明 CheckList 所列的工作都已經(jīng)做完，所列的內(nèi)容都已經(jīng)評審?fù)?，確保工作的完整性。5.7 評審結(jié)論評審結(jié)論包括如下內(nèi)容。 是否需要修改？這是就成果的整體而言，結(jié)論可以是無需、少量、較大或是一個量化的數(shù)字。 項目組確定是否接受修改要求？這是針對具體的一條意見或建議。 有些問題可能是誤會，消除了就不是問題；有些建議性的問題，項目組考慮進度可不接受修改要求。 如不接受修改要求，項目組給出不修改的理由。 如何處理？是否需要進行回歸評審？ 總體結(jié)論：合格或不合格。 確定的修改責(zé)任人和跟蹤責(zé)任人。 確定的回歸評審時間。 是否都認(rèn)同評審結(jié)論

12、？如果需要做得更正式一些，可以要求相關(guān)人員簽字表示同意評審結(jié)論，簽字'.5.8 跟蹤與總結(jié)評審中發(fā)現(xiàn)的問題的后續(xù)跟蹤是改正錯誤并消除缺陷的有效措施，應(yīng)當(dāng)有專門的責(zé)任人進行后續(xù)跟蹤確認(rèn)錯誤都已改正，根據(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)批準(zhǔn)發(fā)布通過的文檔。5.9 材料歸檔評審材料歸檔是項目配置管理工作的

13、一部分。新建項目， 記載配置管理工具中為此項目建立一個目錄，并建立下列子目錄。待評閱態(tài)： 文件放入此目錄后會自動通過郵件通知需要評閱的人員，全體評閱人員評閱完畢，也會自動通過郵件把意見通知文檔作者并實現(xiàn)到期自動提醒功能。待評審態(tài)： 文件放入此目錄后會自動通過郵件通知需要評審的人員，全體評閱人員評審?fù)戤叄?也會自動通過郵件把批準(zhǔn)或拒絕的意見通知文檔作者并實現(xiàn)到期自動提醒功能。受控態(tài)：評審批準(zhǔn)后自動轉(zhuǎn)入受控態(tài)并發(fā)布自動郵件。 簽出態(tài)：為了修改而版本升級，當(dāng)文件簽出時放入簽出態(tài)。修改后的文檔可能簽入到待評閱態(tài)、待評審態(tài)或直接到受控態(tài)，但文檔版本已經(jīng)升級。產(chǎn)品態(tài)：項目結(jié)束后受控態(tài)的文檔自動歸到產(chǎn)品態(tài)。'.僅供個人用于學(xué)習(xí)、研究；不得用于商業(yè)用途。For personal use only in study and research; not for commercial use.Nur f ü r den p