需求管理研究分析報告

1、 TOC o 1-3 h z HYPERLINK l _Toc16317781 第8章 需求治理 PAGEREF _Toc16317781 h 2 HYPERLINK l _Toc16317782 8.1 介紹 PAGEREF _Toc16317782 h 2 HYPERLINK l _Toc16317783 8.2 需求確認(rèn) PAGEREF _Toc16317783 h 3 HYPERLINK l _Toc16317784 8.2.1 目的 PAGEREF _Toc16317784 h 3 HYPERLINK l _Toc16317785 8.2.2 角色與職責(zé) PAGEREF _Toc16

2、317785 h 3 HYPERLINK l _Toc16317786 8.2.3 啟動準(zhǔn)則 PAGEREF _Toc16317786 h 3 HYPERLINK l _Toc16317787 8.2.4 輸入 PAGEREF _Toc16317787 h 3 HYPERLINK l _Toc16317788 8.2.5 要緊步驟 PAGEREF _Toc16317788 h 4 HYPERLINK l _Toc16317789 Step1 非正式需求評審 PAGEREF _Toc16317789 h 4 HYPERLINK l _Toc16317790 Step2 正式需求評審 PAGERE

3、F _Toc16317790 h 4 HYPERLINK l _Toc16317791 Step3 獵取需求承諾 PAGEREF _Toc16317791 h 4 HYPERLINK l _Toc16317792 8.2.6 輸出 PAGEREF _Toc16317792 h 4 HYPERLINK l _Toc16317793 8.2.7 結(jié)束準(zhǔn)則 PAGEREF _Toc16317793 h 4 HYPERLINK l _Toc16317794 8.2.8 度量 PAGEREF _Toc16317794 h 4 HYPERLINK l _Toc16317795 8.3 需求跟蹤 PAGER

4、EF _Toc16317795 h 5 HYPERLINK l _Toc16317796 8.3.1 目的 PAGEREF _Toc16317796 h 5 HYPERLINK l _Toc16317797 3.3.2 角色與職責(zé) PAGEREF _Toc16317797 h 5 HYPERLINK l _Toc16317798 3.3.3 啟動準(zhǔn)則 PAGEREF _Toc16317798 h 5 HYPERLINK l _Toc16317799 3.3.4 輸入 PAGEREF _Toc16317799 h 5 HYPERLINK l _Toc16317800 3.3.5 要緊步驟 PAG

5、EREF _Toc16317800 h 5 HYPERLINK l _Toc16317801 Step1 建立與維護(hù)需求跟蹤矩陣 PAGEREF _Toc16317801 h 5 HYPERLINK l _Toc16317802 Step2 查找不一致 PAGEREF _Toc16317802 h 6 HYPERLINK l _Toc16317803 Step3 消除不一致 PAGEREF _Toc16317803 h 6 HYPERLINK l _Toc16317804 8.3.6 輸出 PAGEREF _Toc16317804 h 6 HYPERLINK l _Toc16317805 8.

6、3.7 結(jié)束準(zhǔn)則 PAGEREF _Toc16317805 h 6 HYPERLINK l _Toc16317806 8.3.8 度量 PAGEREF _Toc16317806 h 6 HYPERLINK l _Toc16317807 8.4 需求變更操縱 PAGEREF _Toc16317807 h 7 HYPERLINK l _Toc16317808 8.4.1 目的 PAGEREF _Toc16317808 h 7 HYPERLINK l _Toc16317809 8.4.2 角色與職責(zé) PAGEREF _Toc16317809 h 7 HYPERLINK l _Toc16317810

7、8.4.3 啟動準(zhǔn)則 PAGEREF _Toc16317810 h 7 HYPERLINK l _Toc16317811 8.4.4 輸入 PAGEREF _Toc16317811 h 7 HYPERLINK l _Toc16317812 8.4.5 要緊步驟 PAGEREF _Toc16317812 h 7 HYPERLINK l _Toc16317813 Step1 需求變更申請 PAGEREF _Toc16317813 h 7 HYPERLINK l _Toc16317814 Step2 審批需求變更申請 PAGEREF _Toc16317814 h 7 HYPERLINK l _Toc

8、16317815 Step3 更改需求文檔 PAGEREF _Toc16317815 h 7 HYPERLINK l _Toc16317816 Step4 重新進(jìn)行需求確認(rèn) PAGEREF _Toc16317816 h 8 HYPERLINK l _Toc16317817 8.4.6 輸出 PAGEREF _Toc16317817 h 8 HYPERLINK l _Toc16317818 8.4.7 結(jié)束準(zhǔn)則 PAGEREF _Toc16317818 h 8 HYPERLINK l _Toc16317819 8.4.8 度量 PAGEREF _Toc16317819 h 8 HYPERLINK

9、 l _Toc16317820 8.5 實(shí)施建議 PAGEREF _Toc16317820 h 8第8章 需求治理需求治理（Requirement Management, RM）的目的在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求與其他工作成果的一致性，并操縱需求的變更。需求治理過程域是SPP模型的重要組成部分。本規(guī)范闡述了需求治理過程域的三個要緊規(guī)程：需求確認(rèn) SPP-PROC-RM-VALIDATE需求跟蹤 SPP-PROC-RM-TRACKING需求變更操縱 SPP-PROC-RM-CHANGE上述每個規(guī)程的“目標(biāo)”、“角色與職責(zé)”、“啟動準(zhǔn)則”、“輸入”、“要緊步驟”、“輸出”、“完

10、成準(zhǔn)則”和“度量”均已定義。本規(guī)范適用于國內(nèi)IT企業(yè)的軟件研發(fā)項(xiàng)目。建議用戶依照自身情況（如商業(yè)目標(biāo)、研發(fā)實(shí)力等）適當(dāng)?shù)匦薷谋疽?guī)范，然后推廣使用。8.1 介紹我們把所有與需求相關(guān)的活動通稱為需求工程。需求工程中的活動可分為兩大類，一類屬于需求開發(fā)，另一類屬于需求治理。圖8-1為需求工程的結(jié)構(gòu)圖（流程見圖9-1）。需求確認(rèn)需求治理需求分析需求定義需求調(diào)查需求開發(fā)需求工程需求變更操縱需求跟蹤圖8-1 需求工程結(jié)構(gòu)圖需求治理過程域要緊有3個規(guī)程：需求確認(rèn)、需求跟蹤與需求變更操縱。一、需求確認(rèn)需求確認(rèn)是指開發(fā)方和客戶共同對需求文檔進(jìn)行評審，雙方對需求達(dá)成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。

11、二、需求跟蹤需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護(hù)“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。三、需求變更操縱需求變更操縱是指依據(jù)“變更申請審批更改重新確認(rèn)”的流程處理需求的變更，確保需求的變更可不能失去操縱而導(dǎo)致項(xiàng)目發(fā)生混亂。需求治理過程域產(chǎn)生的要緊文檔有：需求評審報告，同技術(shù)評審報告的模板 SPP-TEMP-TR-REPORT。需求跟蹤報告，模板見 SPP-TEMP-RM-TRACKING。需求變更操縱報告，模板見 SPP-TEMP-RM-CHANGE。8.2 需求確認(rèn)8.2.1 目的開發(fā)方和客戶對需求文檔如用戶需求講明書和產(chǎn)品需求規(guī)格講明書進(jìn)行評審，并作

12、書面承諾。補(bǔ)充講明：用戶需求講明書和產(chǎn)品需求規(guī)格講明書能夠分開也能夠放在一起進(jìn)行需求確認(rèn)，視項(xiàng)目的具體情況而定。8.2.2 角色與職責(zé)開發(fā)方和客戶共同組織人員對需求文檔如用戶需求講明書和產(chǎn)品需求規(guī)格講明書進(jìn)行評審。開發(fā)方負(fù)責(zé)人（項(xiàng)目經(jīng)理）和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。8.2.3 啟動準(zhǔn)則需求文檔如用戶需求講明書和產(chǎn)品需求規(guī)格講明書差不多完成。8.2.4 輸入需求文檔如用戶需求講明書和產(chǎn)品需求規(guī)格講明書。8.2.5 要緊步驟Step1 非正式需求評審項(xiàng)目經(jīng)理先在項(xiàng)目內(nèi)部組織人員進(jìn)行非正式的需求評審，以消除明顯的錯誤和分歧。非正式的需求評審方式請參考技術(shù)評審過程域的對應(yīng)規(guī)程SP

13、P-PROC-TR-ITR。Step2 正式需求評審項(xiàng)目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實(shí)意愿。正式需求評審方式請參考技術(shù)評審過程域的對應(yīng)規(guī)程SPP-PROC-TR-FTR。Step3 獵取需求承諾當(dāng)需求文檔通過正式的評審之后，開發(fā)方負(fù)責(zé)人（項(xiàng)目經(jīng)理）和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。示例如下：本需求文檔建立在雙方對需求的共同理解基礎(chǔ)之上，我同意后續(xù)的開發(fā)工作依照該需求文檔開展。假如需求發(fā)生變化，我們將按照“需求變更操縱規(guī)程”執(zhí)行。我明白需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進(jìn)度等。甲方負(fù)責(zé)人簽字乙方

14、負(fù)責(zé)人簽字8.2.6 輸出需求評審報告書面的需求承諾8.2.7 結(jié)束準(zhǔn)則需求文檔通過了正式評審，同時獲得開發(fā)方和客戶的書面承諾。8.2.8 度量項(xiàng)目經(jīng)理統(tǒng)計(jì)工作量和上述文檔的規(guī)模8.3 需求跟蹤8.3.1 目的將系統(tǒng)設(shè)計(jì)、編程、測試等時期的工作成果與需求文檔進(jìn)行比較，建立與維護(hù)“需求文檔設(shè)計(jì)文檔代碼測試用例”之間的一致性，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。3.3.2 角色與職責(zé)項(xiàng)目經(jīng)理跟蹤需求。3.3.3 啟動準(zhǔn)則需求文檔差不多通過正式評審并獲得了承諾。系統(tǒng)設(shè)計(jì)、編程、測試等時期的工作成果如設(shè)計(jì)文檔、代碼、測試用例差不多產(chǎn)生。3.3.4 輸入需求文檔設(shè)計(jì)文檔、代碼、測試用例等3.3.5 要緊步驟S

15、tep1 建立與維護(hù)需求跟蹤矩陣正向跟蹤。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應(yīng)點(diǎn)。逆向跟蹤。檢查設(shè)計(jì)文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采納何種跟蹤方式，都要建立與維護(hù)需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應(yīng)關(guān)系。矩陣單元之間的可能存在“一對一”、“一對多”或“多對多”的關(guān)系。由于對應(yīng)關(guān)系比較復(fù)雜，最好在表格中加必要的文字解釋。表8-1為簡單的需求跟蹤矩陣格式。當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。需求文檔（版本，日期）設(shè)計(jì)文檔（版本，日期）代碼（版本，日期）測

16、試用例（版本，日期）1標(biāo)題或標(biāo)識符，講明標(biāo)題或標(biāo)識符，講明代碼名稱，講明測試用例名稱，講明2表8-1 簡單的需求跟蹤矩陣格式Step2 查找不一致使用需求跟蹤矩陣的優(yōu)點(diǎn)是專門容易發(fā)覺需求文檔與后續(xù)工作成果之間的不一致之處，例如：后續(xù)工作成果沒有實(shí)現(xiàn)需求文檔中的某些需求；后續(xù)工作成果實(shí)現(xiàn)了需求文檔中的不存在的需求；后續(xù)工作成果沒有正確實(shí)現(xiàn)需求文檔中的的需求； 項(xiàng)目經(jīng)理將發(fā)覺的“不一致性”記錄在需求跟蹤報告之中，并通報給相關(guān)責(zé)任人（工作成果的開發(fā)者）。Step3 消除不一致相關(guān)責(zé)任人給出消除“不一致”的措施和打算，項(xiàng)目經(jīng)理將該措施和打算記錄到需求跟蹤報告之中。相關(guān)責(zé)任人消除“不一致性”之后，項(xiàng)目經(jīng)

17、理更新“需求跟蹤矩陣”。8.3.6 輸出需求跟蹤報告8.3.7 結(jié)束準(zhǔn)則每個開發(fā)時期的“需求跟蹤矩陣”都差不多建立。差不多消除了需求文檔與后續(xù)工作成果之間的不一致性。8.3.8 度量項(xiàng)目經(jīng)理統(tǒng)計(jì)工作量和上述文檔的規(guī)模。8.4 需求變更操縱8.4.1 目的修改“原需求文檔”中不正確的內(nèi)容，產(chǎn)生新的需求文檔。操縱需求文檔的變更，防止發(fā)生混亂。補(bǔ)充講明：本規(guī)程中的“原需求文檔”是指差不多通過了評審并獲得書面承諾的需求文檔。8.4.2 角色與職責(zé)開發(fā)方負(fù)責(zé)人（項(xiàng)目經(jīng)理）和客戶共同操縱需求變更。8.4.3 啟動準(zhǔn)則某人（來自開發(fā)方或客戶方）提出變更“原需求文檔”的申請。8.4.4 輸入“原需求文檔”8.4.5 要緊步驟Step1 需求變更申請需求變更申請人撰寫“需求變更申請書”，遞交給項(xiàng)目經(jīng)理或客戶方負(fù)責(zé)人?！靶枨笞兏暾垥北仨氷U述：（1）變更緣故；（2）變更的內(nèi)容；（3）此變更對項(xiàng)目造成的阻礙。Step2 審批需求變更申請開發(fā)方負(fù)責(zé)人（項(xiàng)目經(jīng)理）和客戶共同審批“需求變更申請書”：假如任何一方不同意變更，則退回變更請求，項(xiàng)目按照“原需求文檔”執(zhí)行。假如雙方都同意變更