需求管理過程-模板1

1、XXX有限公司XXX有限公司需求管理過程編寫：編寫時間:審核：審核時間:發(fā)布日期:文檔版本：V1.0軟件研發(fā)部發(fā)布未經允許，文檔內容不可全部或部分發(fā)表、復制、使用于任何目的。1 前言1.1目的通過左義需求管理過程，使分配的需求受控，保證需求和訃劃、工作產品一致*1.2適用范E本文檔對需求管理過程的立義適用于各種領域、各種類型的軟件開發(fā)和軟件測試模式的需求管理 活動；本文檔的適用范甫為組織中的各開發(fā)項目。1.3讀者對象軟件開發(fā)和軟件測試過程中的相關人員，特別是需求開發(fā)與需求管理人員；包括有關髙層經理、 項目經理、需求分析人員、系統(tǒng)分析人員、QA人員等相關人員。2過程總體描述2.1過程概述需求管理

2、過程是維護需求，監(jiān)控需求的狀態(tài)，控制需求變更，進行需求的跟蹤等的過程。為項目 在需求方而建立和維護與客戶的共識：并將所建立的需求作為估算、策劃、實施和管理項目的基 礎；控制管理需求及北變更，使開發(fā)計劃、工作產品和活動與需求保持一致：進行需求的跟蹤， 可改善產品質呈:、降低維護成本、實現重用。需求管理的活動貫穿項目的整個生命周期。需求管理主要包括需求左義、需求變更、需求跟蹤、需求狀態(tài)跟蹤等幾個過程。構成參見下圖：需求開發(fā)2. 2角色和職責在需求管理相關的活動中，涉及的角色以及主要職責參見下表:角色職責能力要求備注客H/最終 用戶被邀請參與軟件需求規(guī)格說明書的評審： 參與并確認客戶需求的定義。項目

3、經理參與軟件需求規(guī)格說明書的評審： 建立并維護本項目的需求跟蹤矩陣,跟蹤需求 負責接收需求變更申請表，組織需求變更 活動的開展：左義需求狀態(tài)類型；分析需求跟蹤狀態(tài)結果：接受需求變更、需 求狀態(tài)類別確左的 培訓高級經理參與軟件需求規(guī)格說明書的評審 批準軟件需求規(guī)格說明書評審報告角色職責能力要求備注項目組成員協(xié)助項目經理泄義客戶原始需求或需求 協(xié)助項目經理編寫軟件需求規(guī)格說明書 負責不同階段的需求跟蹤矩陣內容（素材）的 更新、分析、再利用負責變更的需求的修改：測試人員參與軟件需求規(guī)格說明書的評審： 負責不同階段的跟蹤矩陣內容（素材）的更新、 分析、再利用配置管理 人員參與軟件需求規(guī)格說明書的評審；

4、 負責將需求基線納入配宜管理；并在需求基線 的變更過程中，記錄變更狀態(tài)：發(fā)布變更和基 線：更新需求基線；統(tǒng)訃需求變更總數；接受需求變更、需 求狀態(tài)表填寫、需 求狀態(tài)圖繪制的培 訓質疑保證人 員參與軟件需求規(guī)格說明書的評審：檢査需求跟蹤矩陣的填寫，協(xié)助項目經理 分析需求跟蹤狀態(tài)結果2. 3過程結構/流程描述需求管理活動相關流程圖如下：需求管理（REQM）輸入需求分析人員 項目經理 質量保證人員繚出用戶需求說明書 （或用戶原始需 求）分析細化用八需求編寫軟件窩求規(guī)輅說明書不通過評審軟件需求刼格 說明書軟件花求規(guī)格說明 書及其相關文檔需求跟參矩陣霜求跟蹤矩陣定義需求狀態(tài)定期維護維護后的能求跟蹤矩陣需

5、求變更請求未通過需求變更分析弼求迫蹤維護需求跟蹤矩陣合簽發(fā)布3過程3. 1需求定義活動3.1.1概述需求左義活動的目的是形成一個清晰準確的、完整的、一致的可驗收測試的用于產品的技術性軟 件需求規(guī)格說明書及其相關文檔。3.1.2主要步需求左義的主要步驟如下：1）細化并分析客戶需求 細化、分析客戶需求，用工程語言描述需求； 對需求進行分配，將需求和產品的總體架構、產品組件或產品模塊進行對照： 識別接口需求和一些衍生、潛在的需求： 識別、調整、協(xié)調干系人的需求。2）文檔編寫和評審 根據分析結果編寫軟件需求規(guī)格說明書。該文檔經過評審后入庫。軟件需求規(guī)格說明 書的表達形式根據產品刖目的實際情況不同，通常

6、是指由需求列表、軟件需求規(guī)格 說明書、需求式樣文檔、輔助性質的系統(tǒng)測試用例（關鍵用例）等共同組成的一組說明性 文檔。3.1.3輸入與輸出入口準則用戶原始需求或項目任務書已批準；評審準備已經完成；項目需求的支持工具:$0MiCrOSOftOffiCe 工具（PrOjeCtXWOrdXEXCeI>ACCeSSX SOUrCeSafe 等）活動參與人員得到能力與過程方而的培訓；了解需求開發(fā)的步驟、方法，具備開發(fā) 的系統(tǒng)的領域知識。輸入工作產品用戶原始需求或項目任務書或客戶提交的需求說明書； 組織的需求活動方針/規(guī)程：出口準則軟件需求規(guī)格說明書已經被評審、批準、正式入庫；輸出工作產品軟件需求規(guī)格

7、說明書 軟件需求規(guī)格說明書評審報告3. 2需求跟蹤活動3.2.1概述需求跟蹤的目的是建立與維護“需求一設汁一編程一測試”之間的一致性，確保所有的工作成果 符合需求。通過實施需求跟蹤將會使項目在審核、變更影響分析、維護、跟蹤、再設計、重用、 減小風險、測試等方而受益，具體活動包括填寫每項需求與規(guī)格龍義的功能項、軟件結構設計項、 詳細設計項、源代碼模塊、測試用例等之間的對應表。需求跟蹤有兩種方式： 正向跟蹤：檢査軟件需求規(guī)格說明書中的每個需求是否都能在后繼工作成果中找到對 應點 逆向跟蹤：檢查設訃文檔、代碼、測試用例等工作成果是否都能在軟件需求規(guī)格說明書中找到出處°不論采用何種跟蹤方式，

8、建議建立與維護需求跟蹤矩陣，具體格式參見相關模板。需求跟蹤 矩陣保存了需求與后繼工作成果的對應關系。矩陣單元之間可能存在“一對一”、“一對多”或 "多對多”的關系。由于對應關系比較復雜，最好在表格中加必要的文字解釋。3.2.2主要步驟需求跟蹤的主要步驟如下：D建立并維護需求跟蹤矩陣，跟蹤需求；跟蹤活動貫穿項目的整個生命周期，即在項目的各個階段均要進行客戶需求的跟蹤活動，具體活 動如下： .需求分析階段跟蹤矩陣的填寫由需求分析組人員負責將軟件需求規(guī)格說明書中功能或對象項對應填入跟蹤矩陣中。 設計階段跟蹤矩陣的填寫由系統(tǒng)設計組人員負責將概要設汁說明書和詳細設計說明書中設訃項對應填入跟 蹤

9、矩陣中。 .編碼階段跟蹤矩陣的填寫由編碼組人員負責將源代碼程序對應填入跟蹤矩陣中。 .測試階段跟蹤矩陣的填寫由測試用例編寫組負責將測試用例項對應填入跟蹤矩陣中。 .需求變更時跟蹤矩陣的填寫在項目的不同階段發(fā)生需求變更時，項目經理組織分析跟蹤矩陣并獲得需要變更的內容， 軟件工程組根據變更情況填寫變更意見，經項目經理審批后，CIVl人員按照軟件工程組填 寫的內容更新跟蹤矩陣，同時統(tǒng)計需求狀態(tài)情況。2）變更的跟蹤與反向跟蹤當發(fā)生變更時，通過需求跟蹤矩陣找到與變更項關聯的其他項，可分析是這些關聯項也要變更， 從而達到反向跟蹤的目的。該活動主要由各個階段變更負責人執(zhí)行；QA人員負責監(jiān)察執(zhí)行情況。3.2.

10、3輸入與輸出入口準則軟件需求規(guī)格說明書已經得到CCB批準并基線化輸入工作產品軟件需求規(guī)格說明書： 后續(xù)的軟件需求規(guī)格說明書、設計文檔、代碼、測試用例等。出口準則在生命周期的不同階段，將有相應的出口準則需求左義階段：已淸晰填寫客戶需求龍義階段產生的髙層需求、業(yè)務用例描述、細 化的需求等表項內容需求分析階段：已淸晰填寫規(guī)格定義的需求列設計階段：已淸晰填寫設計項列實現階段：已淸晰填寫源代碼模塊列測試階段：已淸晰填寫測試文檔（或測試用例）列輸出工作產品需求跟蹤矩陣3. 3需求狀態(tài)跟蹤活動3.3.1概述在項目的整個開發(fā)過程中，跟蹤每項需求的狀態(tài)是需求管理的一個重要的方而，通過周期性的報 告需求項的各狀態(tài)

11、類別在整個需求中所占的百分比將會改進項目的監(jiān)控工作。狀態(tài)的跟蹤包括狀 態(tài)的左義和狀態(tài)跟蹤圖的繪制，目的是了解項目是如何達到完全驗證所有已獲得批準的需求這個目標的。3.3.2主要步需求狀態(tài)跟蹤的主要步驟如下：D定義需求狀態(tài)類別由項目經理根據項目的具體情況在客戶需求定義之后選擇或左義需求狀態(tài)類別0需求狀態(tài)的改變 同時引起需求跟蹤矩陣的改變。定義的需求狀態(tài)類別包括： 已建議：該需求已被有權提岀需求的人（客戶或系統(tǒng)分析組成員）建議。 已批準：該需求已被分析，估計了其對項目與下一部分的影響，已用一個確定的產品版本號 或創(chuàng)建編號分配到相關的基線中，軟件開發(fā)組已承諾實現該項需求。 已實現：已實現需求項的代碼

12、的設計、編寫和單元測試。 已驗證：使用所選擇的方法已驗證了實現的需求，例如測試等。該需求現在被認為完成。 已刪除：計劃的需求已從基線中刪除，但必須是按變更要求進行的。2）由指左人員左期（每兩周或每月等，根搦項目的規(guī)模確左）填寫需求狀態(tài)跟蹤表對需求變更 的分布進行統(tǒng)計，并繪制出需求狀態(tài)跟蹤圖。3.3.3輸入與輸出入口準則軟件需求規(guī)格說明書及其相關文檔，已經得到CCB批準并基線化輸入工作產品軟件需求規(guī)格說明書出口準則需求跟蹤矩陣已完成輸出工作產品需求跟蹤矩陣、需求變更分布.需求狀態(tài)圖3. 4需求變更活動3.4.1概述D需求變更的來源變更原因分析：對大多數項目而言，需求發(fā)生若干次變更似乎是不可避免的

13、。需求發(fā)生變更的起 因主要有： 隨著項目的進展，開發(fā)方或客戶方對需求的了解越來越深入：原先的需求文檔可能存在這樣 那樣的錯誤或不足，因此要變更需求。 市場或業(yè)務發(fā)生了變化，原先的需求泄義內容可能跟不上當前的市場或業(yè)務需要，因此要變 更需求。提出需求變更的動機是好的，目的是希望產品更加符合用戶的需求2）需求變更控制需求變更控制的動機是： 如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已泄義的變更規(guī)程執(zhí)行，以 免變更失去控制。 如果需求變更帶來的壞處大于好處，那么拒絕變更。由于需求文檔是重要的配垃項，需求的變更應當遵循配置管理中的變更控制規(guī)程。3.4.2主要步驟需求變更的主要步驟如下：D

14、需求變更流程，參見下表：提出需求變更變更影響評估評審評估報告修訂項目汁劃> 實施變更變更結束 由變更申請人向項目經理提交需求變更申請表。 由CCB負責對變更進行評估。評估包括對變更的技術可行性.代價.業(yè)務需求和資源限制等 方面，可能需要系統(tǒng)組或項目組參與討論，填寫需求變更申請表中評估一欄。 由CCB負責對變更進行審核，得出是否批準的結論。填寫需求變更申請表中批準一欄。 變更被拒絕：由項目經理或配宜管理人員通知變更申請人。 變更被接受：取得用戶認可，修訂項目計劃，由具體責任人實施具體變更。并由CM通 知到受影響的相關組。 由項目經理組織變更結果驗證，得到驗證通過、修改變更或取消驗證的不同結

15、果。 由CCB批準，更新基線：配置管理人員升級需求基線并向相關組發(fā)布已更新的基線。2）需求變更影響到的其他活動 變更分布統(tǒng)計、需求狀態(tài)的跟蹤活動（參見第34 ,Y）: 制泄新的項目計劃（包含品保計劃和配置管理計劃）： 填寫項目周報中相關內容： 更新和維護需求跟蹤矩陣：3.4.3輸入與輸出入口準則需求變更申請表已提交輸入工作產品需求變更申請表原需求文檔（指已經通過了評審并獲得書而承諾的需求文檔）出口準則需求變更評審報告已被評審、批準并正式入庫 變更被拒絕，CCB批準簽字 變更被取消，CCB批準簽字基線更新，變更被執(zhí)行，CCB批準簽字，進行了驗證輸出工作產品需求變更申請需求變更評審報告 需求變更狀

16、態(tài)統(tǒng)計 需求跟蹤矩陣 相關項目計劃中受影響的部分4度量需求管理活動中可應收集、度量如下信息和數據，以支持將來組織過程資產的使用和改進1）軟件需求規(guī)格說明書升級、維護和評審的工時2）軟件需求規(guī)格說明書的質量度量： 正確性 完備性 一致性 無歧義性 可驗證性 可修改性 必要性 可跟蹤性 可實現性 可理解性 有優(yōu)先級別的3）跟蹤矩陣填寫相關人員填寫跟蹤矩陣所花的工時。4）項目經理審批跟蹤矩陣所花的工時。5）配宜管理人員管理跟蹤矩陣所花的工時。6）配置管理人員確認不同階段跟蹤矩陣的完整性所花的工時。7）項目經理需求狀態(tài)跟蹤所花的工時。8）配置管理人員需求狀態(tài)跟蹤所花的工時。9）配置管理人員需求狀態(tài)統(tǒng)計

17、。10）配置管理人員需求變更狀態(tài)統(tǒng)計。11）配置管理人員訃算客戶需求累計變更數。12）項目經理需求變更所花的工時。裁剪指南編 號活動相關配置項5重點歳剪原則一般I小型備注I1需求定義軟件需求規(guī)格說明書需求功能列表O需求評審報告2需求跟蹤需求跟蹤矩陣O4需求變更需求變更評審報告6附錄6.1引用文檔/參考資料6.1.1引用文檔 需求管理方針 需求活動指南6. 12參考資料 CMMI PrOdUCt DeVelOPment Team. CaPabiIity MatUrity Model®* IntegratiOn （CMMI- SE/SW/IPPD/SS, VI.1）, Staged RePreSentation, CMU/SEI-2002-TR-Ol2 基于軟件能力成熟度模型的軟件過程改進，鄭人杰等著，淸華大學出版社，2003年3月6. 2術語表 客戶（Customer）:泛指與開發(fā)組織簽訂開發(fā)合同的組織或人：可以是代