條目化需求管理帶來的瀑布式敏捷

?需求評審之? 版中，定義了5類評審審計（Audits）在CMM3/CMMI3中，同級評審（也 評審或者同級互?）是其要?傳統(tǒng)的基于文檔和文檔評審的方法在2001年起的敏捷動中被視 繁瑣、繁文縟需求評審的定觀察軟件運行與測試有部 ，但并不是測5大關(guān)鍵方面，分別是：1，組織2，時機；3，側(cè)重；4，評審者；5，評審對象。組織形式分

需求評審組織形說 說結(jié)對評審雙人在可全程實時口頭交流的情況下，包括面對面、語音或，進行需求評審潛在的人際。

會議形式，參會人數(shù)多于2人，評審者在會前預(yù)審，作者和評審者在會議流探討。優(yōu)點：業(yè)界已經(jīng)積累了許多評審流程[10]，會前會中會后都有相當成指導，各方交無預(yù)審的會議審

非即 評審的新情 非即 評審的例時時 說需求完稿后，關(guān)鍵各方參加評審，一旦通過，就進入下一階段工作。

高頻按需評按照需要，頻繁的開展，比如針對指定功能的桌查，每天或每幾天 需求評審的側(cè)重分側(cè) 說 需求評審的評審者分評審 說嚴格同級也稱，這樣的評審不直接影響作者和評審者，可以讓作者無作者上評審者中沒有作者的上級，評審者之間可能存在上下級， CMMIfor DEVV1.3中沒有采用嚴格同級來實施同級評審，只說明了由作者的同級或稱同級人員來實施同級評審[23]，而在實踐中不少的同級評審包括有作者的下級，含作者上評審者中包括作者的上級。評審表現(xiàn)可能被上級用于評價人員績效。下 需求評審的對對 說檔 各類需求文檔，比如需求規(guī)格說明書，用例分析，用戶故事等等，在CMMI，工產(chǎn)是適地現(xiàn)規(guī)的確“確做。優(yōu)點：能夠較早的開缺點：不夠直觀，尤其難以判斷交互 優(yōu)點：直觀展現(xiàn)實現(xiàn)的需求，可以更好的判斷需求，尤其是交互易用性缺點：得到可運行軟常見情組織常見情組織式評審嚴格同級、同級（評審者不含上級），常見需求評審情情況情況情況情況情況常見稱需求里程碑會需求分評需求結(jié)需求分段同級互需求管組織形有預(yù)審的會非即結(jié)對即非即有預(yù)審的會時里程完定分里程側(cè)技技技管評審含上同同同含上對需求文需求文需求文需求文需求文標準評

瀑布模型下需求評需求評審框架分析說 需求里程碑評 有預(yù)審的會議形式，里程碑，技術(shù)和管理方面，非同級需求文檔評 分段需求同級評 有預(yù)審的會議形式，分段，技術(shù)方面，同級需求文檔評CMMI給需求評審帶來的變新需求評審框架對傳統(tǒng)瀑布模型的啟 IEEE標準需求評標準評 需求評審框架分析說 技術(shù)評 有預(yù)審的會議形式，里程碑，技術(shù)方面，非同級需求文檔評有預(yù)審的會議形式，完稿，技術(shù)方面，同級需求文檔評走 有預(yù)審的雙人或者會議，定期或者高頻，技術(shù)方面，同級需求文檔評敏捷開發(fā)下常見需求評審相關(guān)實踐情 Scrum中產(chǎn)品待辦列表細無預(yù)審的會議，定期，技術(shù)方面，同級需求文檔評審Scrum中計劃會議第一部無預(yù)審的會議，定期的里程碑，管理方面，同級需求文檔評審Scrum每日站會和燃盡圖無預(yù)審的會議，每日高頻，管理方面，同級需求文檔評審 敏捷帶來的啟示敏捷帶來的啟示 需求條目化管理下的需求評有些工具中條目稱為工作項(workitem)1，狀態(tài)流轉(zhuǎn)實現(xiàn)工作流2，條目屬性字段可定全程的需 評需求條目的流程定需求條目流程關(guān)鍵點的評狀態(tài)流 關(guān)鍵點的評從草稿到已分析需求分析人員內(nèi)部評審（比如同級互查），通過后狀態(tài)流轉(zhuǎn)到“已分析”，顯從已分析到已評審由對產(chǎn)品需求負責的人員擔當，常見有產(chǎn)品經(jīng)理、項目經(jīng)理或者產(chǎn)品，如果工具有并行功能，可讓多人參與此，這相當于需求里程碑評審的從已評審到已設(shè)計由開發(fā)人員需求得到設(shè)計的覆蓋，這仍然是基于文檔的現(xiàn)由從已實現(xiàn)到已核 由需求分析人員來驗證實現(xiàn)是否符合當初的需求，這是基于軟件運行的評審從已核對到已測試由測試人員根據(jù)測試來校對需求是否得到正確實現(xiàn)，這也是基于軟件運行的評審，這里與測試有所，但這里是對需求本身的，與測試對于測試用例的執(zhí)行是不一樣的，當然可以根據(jù)需求對應(yīng)測試用例的執(zhí)行結(jié)果來需求。需求測試缺陷雙向追條目話管理下的需