需求管理研究報(bào)

TOC\o"1-3"\h\z第8章需求管理 28.1介紹 28.2需求確認(rèn) 38.2.1目的 38.2.2角色與職責(zé) 38.2.3啟動(dòng)準(zhǔn)那么 38.2.4輸入 38.2.5主要步驟 4[Step1]非正式需求評(píng)審 4[Step2]正式需求評(píng)審 4[Step3]獲取需求承諾 48.2.6輸出 48.2.7結(jié)束準(zhǔn)那么 48.2.8度量 48.3需求跟蹤 58.3.1目的 53.3.2角色與職責(zé) 53.3.3啟動(dòng)準(zhǔn)那么 53.3.4輸入 53.3.5主要步驟 5[Step1]建立與維護(hù)需求跟蹤矩陣 5[Step2]查找不一致 6[Step3]消除不一致 68.3.6輸出 68.3.7結(jié)束準(zhǔn)那么 68.3.8度量 68.4需求變更控制 78.4.1目的 78.4.2角色與職責(zé) 78.4.3啟動(dòng)準(zhǔn)那么 78.4.4輸入 78.4.5主要步驟 7[Step1]需求變更申請(qǐng) 7[Step2]審批需求變更申請(qǐng) 7[Step3]更改需求文檔 7[Step4]重新進(jìn)行需求確認(rèn) 88.4.6輸出 88.4.7結(jié)束準(zhǔn)那么 88.4.8度量 88.5實(shí)施建議 8第8章需求管理需求管理〔RequirementManagement,RM〕的目的在客戶(hù)與開(kāi)發(fā)方之間建立對(duì)需求的共同理解，維護(hù)需求與其他工作成果的一致性，并控制需求的變更。需求管理過(guò)程域是SPP模型的重要組成局部。本標(biāo)準(zhǔn)闡述了需求管理過(guò)程域的三個(gè)主要規(guī)程：需求確認(rèn)[SPP-PROC-RM-VALIDATE]需求跟蹤[SPP-PROC-RM-TRACKING]需求變更控制[SPP-PROC-RM-CHANGE]上述每個(gè)規(guī)程的“目標(biāo)〞、“角色與職責(zé)〞、“啟動(dòng)準(zhǔn)那么〞、“輸入〞、“主要步驟〞、“輸出〞、“完成準(zhǔn)那么〞和“度量〞均已定義。本標(biāo)準(zhǔn)適用于國(guó)內(nèi)IT企業(yè)的軟件研發(fā)工程。建議用戶(hù)根據(jù)自身情況〔如商業(yè)目標(biāo)、研發(fā)實(shí)力等〕適當(dāng)?shù)匦薷谋緲?biāo)準(zhǔn)，然后推廣使用。8.1介紹我們把所有與需求相關(guān)的活動(dòng)通稱(chēng)為需求工程。需求工程中的活動(dòng)可分為兩大類(lèi)，一類(lèi)屬于需求開(kāi)發(fā)，另一類(lèi)屬于需求管理。圖8-1為需求工程的結(jié)構(gòu)圖〔流程見(jiàn)圖9-1〕。需求確認(rèn)需求管理需求分析需求定義需求調(diào)查需求開(kāi)發(fā)需求工程需求變更控制需求跟蹤需求確認(rèn)需求管理需求分析需求定義需求調(diào)查需求開(kāi)發(fā)需求工程需求變更控制需求跟蹤圖8-1需求工程結(jié)構(gòu)圖需求管理過(guò)程域主要有3個(gè)規(guī)程：需求確認(rèn)、需求跟蹤與需求變更控制。一、需求確認(rèn)需求確認(rèn)是指開(kāi)發(fā)方和客戶(hù)共同對(duì)需求文檔進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出書(shū)面承諾，使需求文檔具有商業(yè)合同效果。二、需求跟蹤需求跟蹤是指通過(guò)比較需求文檔與后續(xù)工作成果之間的對(duì)應(yīng)關(guān)系，建立與維護(hù)“需求跟蹤矩陣〞，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開(kāi)發(fā)。三、需求變更控制需求變更控制是指依據(jù)“變更申請(qǐng)－審批－更改－重新確認(rèn)〞的流程處理需求的變更，確保需求的變更不會(huì)失去控制而導(dǎo)致工程發(fā)生混亂。需求管理過(guò)程域產(chǎn)生的主要文檔有：?需求評(píng)審報(bào)告?，同技術(shù)評(píng)審報(bào)告的模板[SPP-TEMP-TR-REPORT]。?需求跟蹤報(bào)告?，模板見(jiàn)[SPP-TEMP-RM-TRACKING]。?需求變更控制報(bào)告?，模板見(jiàn)[SPP-TEMP-RM-CHANGE]。8.2需求確認(rèn)8.2.1目的開(kāi)發(fā)方和客戶(hù)對(duì)需求文檔如?用戶(hù)需求說(shuō)明書(shū)?和?產(chǎn)品需求規(guī)格說(shuō)明書(shū)?進(jìn)行評(píng)審，并作書(shū)面承諾。補(bǔ)充說(shuō)明：?用戶(hù)需求說(shuō)明書(shū)?和?產(chǎn)品需求規(guī)格說(shuō)明書(shū)?可以分開(kāi)也可以放在一起進(jìn)行需求確認(rèn)，視工程的具體情況而定。8.2.2角色與職責(zé)開(kāi)發(fā)方和客戶(hù)共同組織人員對(duì)需求文檔如?用戶(hù)需求說(shuō)明書(shū)?和?產(chǎn)品需求規(guī)格說(shuō)明書(shū)?進(jìn)行評(píng)審。開(kāi)發(fā)方負(fù)責(zé)人〔工程經(jīng)理〕和客戶(hù)對(duì)需求文檔作書(shū)面承諾，使之具有商業(yè)合同效果。8.2.3啟動(dòng)準(zhǔn)那么需求文檔如?用戶(hù)需求說(shuō)明書(shū)?和?產(chǎn)品需求規(guī)格說(shuō)明書(shū)?已經(jīng)完成。8.2.4輸入需求文檔如?用戶(hù)需求說(shuō)明書(shū)?和?產(chǎn)品需求規(guī)格說(shuō)明書(shū)?。8.2.5主要步驟[Step1]非正式需求評(píng)審工程經(jīng)理先在工程內(nèi)部組織人員進(jìn)行非正式的需求評(píng)審，以消除明顯的錯(cuò)誤和分歧。非正式的需求評(píng)審方式請(qǐng)參考技術(shù)評(píng)審過(guò)程域的對(duì)應(yīng)規(guī)程[SPP-PROC-TR-ITR]。[Step2]正式需求評(píng)審工程經(jīng)理邀請(qǐng)同行專(zhuān)家和用戶(hù)〔包括客戶(hù)和最終用戶(hù)〕一起評(píng)審需求文檔，盡最大努力使需求文檔能夠正確無(wú)誤地反映用戶(hù)的真實(shí)意愿。正式需求評(píng)審方式請(qǐng)參考技術(shù)評(píng)審過(guò)程域的對(duì)應(yīng)規(guī)程[SPP-PROC-TR-FTR]。[Step3]獲取需求承諾 當(dāng)需求文檔通過(guò)正式的評(píng)審之后，開(kāi)發(fā)方負(fù)責(zé)人〔工程經(jīng)理〕和客戶(hù)對(duì)需求文檔作書(shū)面承諾，使之具有商業(yè)合同效果。例如如下： 本需求文檔建立在雙方對(duì)需求的共同理解根底之上，我同意后續(xù)的開(kāi)發(fā)工作根據(jù)該需求文檔開(kāi)展。如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程〞執(zhí)行。我明白需求的變更將導(dǎo)致雙方重新協(xié)商本錢(qián)、資源和進(jìn)度等。 甲方負(fù)責(zé)人簽字乙方負(fù)責(zé)人簽字8.2.6輸出?需求評(píng)審報(bào)告?書(shū)面的需求承諾8.2.7結(jié)束準(zhǔn)那么需求文檔通過(guò)了正式評(píng)審，并且獲得開(kāi)發(fā)方和客戶(hù)的書(shū)面承諾。8.2.8度量工程經(jīng)理統(tǒng)計(jì)工作量和上述文檔的規(guī)模8.3需求跟蹤8.3.1目的將系統(tǒng)設(shè)計(jì)、編程、測(cè)試等階段的工作成果與需求文檔進(jìn)行比較，建立與維護(hù)“需求文檔－設(shè)計(jì)文檔－代碼－測(cè)試用例〞之間的一致性，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開(kāi)發(fā)。3.3.2角色與職責(zé)工程經(jīng)理跟蹤需求。3.3.3啟動(dòng)準(zhǔn)那么需求文檔已經(jīng)通過(guò)正式評(píng)審并獲得了承諾。系統(tǒng)設(shè)計(jì)、編程、測(cè)試等階段的工作成果如設(shè)計(jì)文檔、代碼、測(cè)試用例已經(jīng)產(chǎn)生。3.3.4輸入需求文檔設(shè)計(jì)文檔、代碼、測(cè)試用例等3.3.5主要步驟[Step1]建立與維護(hù)需求跟蹤矩陣正向跟蹤。檢查需求文檔中的每個(gè)需求是否都能在后續(xù)工作成果中找到對(duì)應(yīng)點(diǎn)。逆向跟蹤。檢查設(shè)計(jì)文檔、代碼、測(cè)試用例等工作成果是否都能在需求文檔中找到出處。正向跟蹤和逆向跟蹤合稱(chēng)為“雙向跟蹤〞。不管采用何種跟蹤方式，都要建立與維護(hù)需求跟蹤矩陣〔即表格〕。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對(duì)應(yīng)關(guān)系。矩陣單元之間的可能存在“一對(duì)一〞、“一對(duì)多〞或“多對(duì)多〞的關(guān)系。由于對(duì)應(yīng)關(guān)系比較復(fù)雜，最好在表格中加必要的文字解釋。表8-1為簡(jiǎn)單的需求跟蹤矩陣格式。當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時(shí)，要及時(shí)更新需求跟蹤矩陣。＃需求文檔〔版本，日期〕設(shè)計(jì)文檔〔版本，日期〕代碼〔版本，日期〕測(cè)試用例〔版本，日期〕1標(biāo)題或標(biāo)識(shí)符，說(shuō)明標(biāo)題或標(biāo)識(shí)符，說(shuō)明代碼名稱(chēng)，說(shuō)明測(cè)試用例名稱(chēng)，說(shuō)明2…………表8-1簡(jiǎn)單的需求跟蹤矩陣格式[Step2]查找不一致使用需求跟蹤矩陣的優(yōu)點(diǎn)是很容易發(fā)現(xiàn)需求文檔與后續(xù)工作成果之間的不一致之處，例如：后續(xù)工作成果沒(méi)有實(shí)現(xiàn)需求文檔中的某些需求；后續(xù)工作成果實(shí)現(xiàn)了需求文檔中的不存在的需求；后續(xù)工作成果沒(méi)有正確實(shí)現(xiàn)需求文檔中的的需求；工程經(jīng)理將發(fā)現(xiàn)的“不一致性〞記錄在?需求跟蹤報(bào)告?之中，并通報(bào)給相關(guān)責(zé)任人〔工作成果的開(kāi)發(fā)者〕。[Step3]消除不一致相關(guān)責(zé)任人給出消除“不一致〞的措施和方案，工程經(jīng)理將該措施和方案記錄到?需求跟蹤報(bào)告?之中。相關(guān)責(zé)任人消除“不一致性〞之后，工程經(jīng)理更新“需求跟蹤矩陣〞。8.3.6輸出?需求跟蹤報(bào)告?8.3.7結(jié)束準(zhǔn)那么每個(gè)開(kāi)發(fā)階段的“需求跟蹤矩陣〞都已經(jīng)建立。已經(jīng)消除了需求文檔與后續(xù)工作成果之間的不一致性。8.3.8度量工程經(jīng)理統(tǒng)計(jì)工作量和上述文檔的規(guī)模。8.4需求變更控制8.4.1目的修改“原需求文檔〞中不正確的內(nèi)容，產(chǎn)生新的需求文檔?？刂菩枨笪臋n的變更，防止發(fā)生混亂。補(bǔ)充說(shuō)明：本規(guī)程中的“原需求文檔〞是指已經(jīng)通過(guò)了評(píng)審并獲得書(shū)面承諾的需求文檔。8.4.2角色與職責(zé)開(kāi)發(fā)方負(fù)責(zé)人〔工程經(jīng)理〕和客戶(hù)共同控制需求變更。8.4.3啟動(dòng)準(zhǔn)那么某人〔來(lái)自開(kāi)發(fā)方或客戶(hù)方〕提出變更“原需求文檔〞的申請(qǐng)。8.4.4輸入“原需求文檔〞8.4.5主要步驟[Step1]需求變更申請(qǐng)需求變更申請(qǐng)人撰寫(xiě)“需求變更申請(qǐng)書(shū)〞，遞交給工程經(jīng)理或客戶(hù)方負(fù)責(zé)人?！靶枨笞兏暾?qǐng)書(shū)〞必須闡述：〔1〕變更原因；〔2〕變更的內(nèi)容；〔3〕此變更對(duì)工程造成的影響。[Step2]審批需求變更申請(qǐng) 開(kāi)發(fā)方負(fù)責(zé)人〔工程經(jīng)理〕和客戶(hù)共同審批“需求變更申請(qǐng)書(shū)〞：如果任何一方不同意變更，那么退回變更請(qǐng)求，工程按照“原需求文檔〞執(zhí)行。如果雙方都同意變更，轉(zhuǎn)向[Step3]。[Step3]更改需求文檔需求分析員根據(jù)[Step1]和[Step2]更改“原需求文檔〞，產(chǎn)生新的需求文檔。[Step4]重新進(jìn)行需求確認(rèn)重新進(jìn)行需求評(píng)審，參見(jiàn)需求