需求管理過程

xxxx有限公司 需求管理過程xxx有限公司需求管理過程需求管理過程文檔版本號：V1.0文檔編號：XXXX_RM_PROC_RM文檔密級：內部公開歸屬部門/項目：研發(fā)部編寫人：xxxx生效日期：xxxx-xx-xx版權信息本文件涉及之信息，屬xxxx有限公司所有。未經xxxx有限公司允許，文件中的任何部分都不能以任何形式向第三方散發(fā)。網址：/

文檔修訂記錄版本號修訂日期修訂人修訂說明修訂狀態(tài)審核日期審核人批準人V1.0xxxxxxx正式版Axxxxxxxxxxx修訂狀態(tài)：A--增加，M--修改，D--刪除日期格式：YYYY-MM-DD

目錄1. 目的/方針 12. 范圍 13. 術語 14. 角色與職責 15. 入口準則 16. 輸入 27. 流程圖 28. 主要活動 38.1. 需求確認 38.1.1. 需求評審 48.1.2. 需求承諾 58.2. 需求變更 58.2.1. 需求變更申請 58.2.2. 需求變更的實施 68.3. 需求跟蹤 68.3.1. 建立需求跟蹤矩陣 68.3.2. 需求跟蹤矩陣的維護與使用 69. 輸出 710. 出口準則 711. 引用文檔 712. 使用模板 7PAGE8/8目的/方針通過定義需求管理過程，規(guī)范公司軟件開發(fā)項目的需求管理活動，提高需求質量，從而提高軟件生產率，降低開發(fā)成本，改進軟件質量。需求管理應控制需求的變更，并確保項目工作產品與需求的一致性。范圍適用于公司所有產品研發(fā)類、實施類、合同開發(fā)類以及維護開發(fā)類項目。術語術語或縮略語解釋軟件需求在IEEE軟件工程標準詞匯表(1997年)中定義軟件需求為：（1）用戶解決問題或達到目標所需的條件或能力。（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。（3）一種反映上面(1)或(2)所描述的條件或權能的文檔說明。

通俗的講，“需求”就是用戶的需要，它包括用戶要解決的問題、達到的目標、以及實現(xiàn)這些目標所需要的條件，它是一個程序或系統(tǒng)開發(fā)工作的說明，表現(xiàn)形式一般為文檔形式。用例是在系統(tǒng)中執(zhí)行的一系列動作，這些動作將生成對特定參與者可見的價值結果，一個用例定義了一組用例實例需求分析是指在需求開發(fā)過程中，對所獲取的需求信息進行分析，及時排除錯誤和彌補不足，確保需求文檔正確地反映用戶的真實意圖。需求分析的關鍵就是對問題域的研究與理解。為了便于理解問題域，現(xiàn)代軟件工程方法所推薦的做法就是對問題域進行抽象，將其分解為若干基本元素，然后對元素之間的關系進行建模。角色與職責角色職責項目經理負責組織軟件開發(fā)項目的需求分析和管理工作需求分析師負責需求的獲取，分析以及定義、并對需求進行評審研發(fā)部評審委員會接受需求評審申請，組織進行需求的評審CCB參與需求的確認、需求變更的確認客戶參與需求的確認、需求變更的確認入口準則項目立項輸入項目立項公告流程圖圖1：需求管理過程（需求確認）流程圖圖2：需求管理過程（需求變更：詳見《變更管理規(guī)程》中基線變更流程）流程圖主要活動軟件需求工程包括了需求開發(fā)和需求管理兩個部分，需求管理的目的是在客戶與項目組之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。需求管理的主要活動包括：需求確認，需求變更和需求跟蹤控制。需求獲取前應該制定《需求開發(fā)計劃》。需求確認需求確認是指項目組和客戶（或客戶代表）共同對《用戶需求規(guī)格說明書》或《軟件需求規(guī)格說明書》進行評審，雙方對需求達成共識后做出承諾。需求確認包含兩個重要工作：“需求評審”和“需求承諾”。需求評審應對所形成的需求文檔進行評審，以便作為下一階段工作的基礎。需求評審的方式分為“技術評審會議”與“組內評審”兩種。項目組根據需求分析的進展情況，采用“組內評審”的方式分階段對需求分析的階段成果進行評審，分階段評審可以將原本需要進行的大規(guī)模評審拆分成各個小規(guī)模的評審，降低了需求返工的風險，提高了評審的質量。組內評審要求：評審組長：項目經理；評審組成員：研發(fā)部經理、需求分析師、系統(tǒng)分析師、測試工程師，適當邀請組外專家參與；輸入：《軟件需求規(guī)格說明書》，《用戶需求規(guī)格說明書》輸出：會議紀要檢查單：需求評審檢查單當需要召開技術評審會議時，由項目組向研發(fā)部提出需求技術評審申請，由研發(fā)部組織按“技術評審會議”的方式實施需求評審。技術評審會議要求如下：評審組織部門：研發(fā)部評審組成員：項目組代表測試組代表公司的技術專家與業(yè)務專家客戶服務部門代表客戶或客戶代表系統(tǒng)關聯(lián)組代表QA工程師輸入：《軟件需求規(guī)格說明書》，《用戶需求規(guī)格說明書》輸出：評審報告檢查單：需求評審檢查單關于“組內評審”、“技術評審會議”的要求詳見《評審過程》。需求承諾項目經理將評審通過的《軟件需求規(guī)格說明書》提交給客戶（或客戶代表）、系統(tǒng)關聯(lián)項目組進行確認，確認的方式可以是以下方式之一：直接簽字：由承諾方在評審報告上直接簽字或蓋章確認郵件方式：由項目經理將《軟件需求規(guī)格說明書》與評審報告通過郵件發(fā)送給接收方，并明確確認通過的準則（如：如果在一周內未予以回復則默認為確認通過）；發(fā)送會議紀要函：如果承諾方參加了評審會議并在會上達成了共識，則可以編制會議紀要在紀要中描述參加評審的人員、評審的結論等，并通過紀要函的方式發(fā)送給承諾方。項目的軟件需求規(guī)格說明書經過評審與確認后，應根據《配置管理過程》的要求建立需求基線。需求變更對一個軟件項目來說，無論最初的需求分析有多么明確，開發(fā)過程中的需求變化也還是不可避免的。這主要有以下幾種原因：軟件所應用的外部環(huán)境發(fā)生變化；隨著用戶對軟件的熟悉和應用，又提出新的需求；項目組進行需求分析時未能徹底分析用戶的需求，或分析錯誤；用戶在開始時不能很全面的知道所需軟件的功能。需求變更申請項目組外的需求變更由變更申請人通過填寫《需求變更申請單》向項目組提出進行，變更申請人一般是客戶代表，需要得到客戶項目負責人簽字確認，并蓋以單位公章，簽字蓋章后傳真回公司，提交到研發(fā)部評審，經過部門評審后反饋給客戶和項目負責人；項目組內部的需求變更通過《軟件變更申請單》提出。需求變更的實施項目組根據《變更管理規(guī)程》中的要求實施變更。在變更完成后，若需要發(fā)布新的需求基線，項目組應根據《配置管理過程》中“基線發(fā)布”的要求重新建立需求基線，并通知相關的人員。需求跟蹤對一個軟件項目來說，當需求確定下來以后，應該保證在軟件設計過程中每個需求都被實現(xiàn)，且項目的其它工作產品與需求保持一致。因此，一個比較好的方法就是建立一種需求雙向跟蹤機制。雙向跟蹤即：正向跟蹤：當發(fā)生需求變更時，通過從需求向后追溯到下游相關工作產品，可分析出這些關聯(lián)項是否需要變更，從而達到追溯的目的；逆向跟蹤。通過從下游工作產品回溯到需求，可分析需求是否得到滿足，從而達到回溯的目的。進行需求雙向跟蹤的一個簡單的方法是建立一個映射，從需求到設計，從設計到編碼，以及從編碼到測試用例，把每個需求都映射到對應的位置。這個映射可以用需求跟蹤矩陣來實現(xiàn)。建立需求跟蹤矩陣當《軟件需求規(guī)格說明書》通過評審之后，項目經理應組織根據確定的需求跟蹤的粒度編制《需求跟蹤矩陣》。項目經理指定人員對需求跟蹤矩陣進行個人復查，確保跟蹤粒度合理、跟蹤項適用。需求跟蹤矩陣的維護與使用隨著軟件設計、編碼、以及測試開發(fā)的不斷推進，項目經理應指定專人在項目的各個階段產品形成時，將相關的信息填入需求跟蹤矩陣，建立階段工作產品與需求的對應關系，并由項目經理指定人員對其完整、正確、一致性進行確認。對于已納入需求跟蹤矩陣的相關工作產品產生的變更，則由變更實施人員在每次變更完成后根據變更修改需求跟蹤矩陣的對應關系，在每個里程碑時由項目經理指定人員負責對跟蹤矩陣的完整、正確、一致性進行確認。在項目實施過程中，項目組可以利用需求跟蹤矩陣實施相關的控制，如：利用需求跟蹤矩陣，審核所有定義的需求是否已經在相關產品中得到實現(xiàn)；當發(fā)生需求變更時，可以利用需求跟蹤矩陣受需求變更影響的其它工作產品，確保不忽略每個受到影響的系統(tǒng)元素；當相關的工作產品產生變更時，可以向前追