需求評審流程

1、精選優(yōu)質(zhì)文檔-傾情為你奉上肈產(chǎn) 品 需 求 評 審膆(V1.0)1、2、 螂產(chǎn)品需求評審的目的、目標(biāo)、范圍薀1、目的袇產(chǎn)品需求是軟件開發(fā)最重要的一個輸入 ，需求的質(zhì)量很大程度上決定了項目質(zhì)量或產(chǎn)品質(zhì)量。并且需求風(fēng)險常常是軟件開發(fā)過程中最大的一個風(fēng)險 ，要降低需求階段帶來的風(fēng)險。而產(chǎn)品需求評審的目的，是在軟件項目初期發(fā)現(xiàn)那些潛在的缺陷或錯誤，避免這些錯誤和缺陷遺漏到項目的后續(xù)階段。芆膃2、目標(biāo)1)2) 節(jié)需求已經(jīng)文檔化并且完整地描述了產(chǎn)品需求期望； 3)4) 袀業(yè)務(wù)問題已經(jīng)解決了； 5)6) 蒞系統(tǒng)要求的性能價格比已經(jīng)經(jīng)過討論研究并證實是合理的； 7)8) 薄已經(jīng)明確了控制需求的方向（“控制”在

2、這里的意思是包括所有的機制、方法及應(yīng)用程序中用于保證其功能與期望相一致的過程。）； 9)10) 螀確定需求階段所有解決問題的方法和途徑是有效和正確的。蠆蒅3、范圍1)2) 羅對需求規(guī)格說明的正確性進行評審3)4) 蒂對需求規(guī)格說明的實踐性進行評審5)6) 蒈對需求規(guī)格說明的完整性進行評審7)8) 薅對需求方案的可行性和成本預(yù)算進行評審9)10) 膂對需求的質(zhì)量屬性進行評審11)12) 袀對需求的可實施性進行評審13)14) 膇對需求包含的用例文檔進行評審15)16) 薅需求評審會的過程和結(jié)束標(biāo)準薃3、4、 螞具體執(zhí)行操作流程芀5、6、 蚅具體角色及職責(zé)關(guān)系ll 羄準備階段（P）聿需求負責(zé)人：爭

3、取上層決策者的支持與諒解，在正式評審之前，將相關(guān)的需求記錄（文檔或其他形式）發(fā)布給每個參與評審的人員手中。收集相關(guān)評審人員的各項需求評審建議和意見，對存在爭議和疑惑的需求說明必須做好討論的安排。罿管理層：籌備相關(guān)的資源，包括人力、時間計劃，評審場地。螅開發(fā)負責(zé)人、測試負責(zé)人：做好評審前的相關(guān)質(zhì)疑與確認記錄。ll 莄實施階段（D）1)2) 螁與會人就某具體的問題進行討論，討論的優(yōu)先級如下所列 ØØ 螇最重要的業(yè)務(wù)內(nèi)容，一般是按流程、功能、細節(jié)來排定ØØ 裊爭議或疑問較多的地方ØØ 螅部分有爭議的地方ØØ 艿對于沒有提

4、出疑義的地方，可以快速流過3)4) 螀最后，要注意一定要回顧已提出問題和有結(jié)論的地方5)6) 羅由需求負責(zé)人整理會議的綱要，記錄各與會人員的相關(guān)意見，并在會后遞交紀要ll 袂檢查再實施階段（C）1)2) 羈需求負責(zé)人：對評審得出結(jié)論的問題進行再次確認和修正補充并確定下次評審的時間3)4) 蕿按照第一階段的流程再次進行組織，并確認結(jié)果ll 肄總結(jié)階段（A）1)2) 芃就以上內(nèi)容做最后的確認，需求定稿，各方簽字確認。3)4) 蚃今后的變更轉(zhuǎn)入需求變更流程，其后產(chǎn)生的評審為小范圍內(nèi)評審。5)6) 莈7、8、 膄具體檢查手段蚄 在評審會議過程中，通過評審表（附錄一）對需求說明書進行考核。膁9、10、

5、肇報告反饋機制膄注：評審會議結(jié)束后，將會議紀要及評審表在一個工作日內(nèi)交至上級審閱,閱后將會議紀要及評審表發(fā)放至各與會人員。肅袃膀芄附錄一：節(jié)編號芁項目實際案例或說明評審結(jié)果1與需求相關(guān)的數(shù)據(jù)定義數(shù)據(jù)流向，可以有數(shù)據(jù)流圖2功能需求是否覆蓋了所有的異常情況的處理對涉及到流程類的操作進行頭腦風(fēng)暴，畫出流程圖，找出所有的異常情況3是否標(biāo)識了將來可能變化的需求可擴展性的考慮或是可維護性。測試中需要注意和跟蹤的地方。4是否說明了系統(tǒng)輸入的來源輸入的數(shù)據(jù)是什么樣的5是否說明了系統(tǒng)輸入輸出的類型輸入輸出等價類的劃分6是否說明了系統(tǒng)輸入輸出的值域，單位，格式7是否說明了系統(tǒng)輸入，輸出的精度有效位數(shù)8是否說明了如

6、何進行系統(tǒng)輸入合法性的驗證輸入合法性的驗證。9時間因素時間精度，跨度，使用的時間控件的情況。10需求項的編號，需求唯一，并可標(biāo)識需求管理和跟蹤11與需求相關(guān)的維護性系統(tǒng)上線后是怎么被維護的？維護的工作量是怎樣的，由誰來維護，維護的頻度是多大的。12需求定義系統(tǒng)的外部接口與內(nèi)部接口劃定測試范圍，模塊集成測試的依據(jù)。從不同的入口準備數(shù)據(jù)。13需求之間是否有沖突和矛盾14是否對每個需求給出設(shè)計理由，理由是否充分。比如，按id倒序排序，為什么要按id，為什么要倒序排序，按別的是不是更好？15是否冗余同一個需求被定義多次16系統(tǒng)應(yīng)用的環(huán)境，如瀏覽器，應(yīng)用語言，分辨率等等。17需求形式化語言的運用對于數(shù)學(xué)公式的描述，或是復(fù)雜流程，盡量用形式化語言進行描述。18需求是否可以驗證需求的可測試性，是否需要開發(fā)打上logo。19對于異常數(shù)據(jù)產(chǎn)生的結(jié)果是否有描述垃圾數(shù)據(jù)的處理20所有頁面控件的默認狀態(tài)是否明確的標(biāo)明21是否有關(guān)于權(quán)限控制的說明22對于提示信息的文案說明是否有詳細的描述23Demo列表，demo是否加入了版本控制24是否對界面需求有所描述25需求中是否包含模糊性詞語舉例，如：依需要，順利完成，正確完成，可以，可能，等等26需求描述中應(yīng)有優(yōu)先級別和重要程度的描述27軟件需求文檔和用戶需求文檔是否有對應(yīng)的跟蹤關(guān)系全選和反選詳細說明，反選是取反還