需求管理 (項目)

出自 MBA智库百科(https://wiki.mbalib.com/)

需求管理(項目)(requirement mangement)

　　需求管理是一種用於查找、記錄、組織和跟蹤系統需求變更的系統化方法，可用於獲取、組織和記錄系統需求並使客戶和項目團隊在系統需求變更上保持一致。有效的需求管理在於維護清晰明確的需求闡述、每種需求類型所適用的屬性，以及與其他需求和其他項目工作之間的可追蹤性。

　　需求管理活動包括：

　　(1)定義需求基線。

　　(2)評審需求變更並評估每項需求變更對軟體產品的影響從而決定是否實施它。

　　(3)以一種可控制的方式將需求變更融人當前的軟體項目。

　　(4)讓當前的項目計劃和需求保持一致。

　　(5)估計變更所產生的影響併在此基礎上協商新的約定。

　　(6)實現通過需求可跟蹤對應的設計、源代碼和測試用例。

　　(7)在整個項目過程中跟蹤需求狀態及其變更情況。

　　1．需求管理的特定實踐

　　需求管理包含5個特定實踐，如圖1所示。現簡介如下。

　　圖1　　需求實踐示意圖

　　①獲得對需求的理解。在初步整理需求的基礎上，項目小組和用戶代表通過初步的分析討論，對當前項目的需求達成共識，併在需求列表中作相應記錄。

　　②獲取需求承諾。通過項目參與者的書面承諾，建立各方或各項工作的基準。

　　③管理需求變更。維護變更歷史，為調整與控制提供數據。

　　④在需求變更後維護對需求的雙向可追溯性。從軟體可維護性的角度提出管理要求。

　　⑤標識項目工作(包括計劃和產品)與需求的不一致性。若發現不一致性，即啟動糾正措施。

　　2．需求管理的管理流程

　　上述5個特定實踐，可歸結為以下3項活動，即需求確認、需求跟蹤和需求變更。

　　(1)需求確認包括圖1中第1、2兩個特定實踐。由開發方和客戶共同對主要需求文檔“軟體需求規格說明書”進行評審，雙方達成共識後作出書面承諾，使需求文檔具有商業合同效力。

　　由此可見，需求確認實際上包含了兩個重要工作：需求評審和需求承諾。其中需求承諾是雙方對通過正式評審後的“軟體需求規格說明書”作出的共同承諾。承諾書的格式如下：

　　本“軟體需求規格說明書”是建立在雙方對需求的共同理解基礎之上的，我們同意後續的開發工作根據該“軟體需求規格說明書”進行。如果需求發生變化，
我們將按照“需求變更流程”執行，即需求的變更將導致雙方重新協商成本、[[資源]]和進度等。

　　項目經理簽字　　　　[[客戶]]或客戶代表簽字

　　

　　該承諾書將附在“軟體需求規格說明書”後，一同存檔保存。

　　(2)需求跟蹤

　　包括圖1的第4、5兩個特定實踐，即維護對需求的雙向可追溯性和標識項目工作與需求的不一致性。

　　為了有效地檢驗最終軟體產品能否滿足所有需求，對項目的需求要進行跟蹤管理。跟蹤的目的，是建立與維護“需求一設計一編程一測試”之間的一致性，確保所有工作成果都符合用戶需求。為此可採用需求大綱中的需求跟蹤矩陣，對每個需求追蹤到實現該需求的設計、編碼以及測試案例，從而驗證該軟體產品是否實現了所有需求，是否對所有需求進行過測試。

　　需求變更要進行控制，嚴格防止因失控而導致項目混亂，出現重大的風險。

　　1．需求變更的利弊

　　隨著項目的進展，用戶和開發方對需求的瞭解越來越深入，原先的需求文檔很可能存在錯誤或不足。另一方面，市場會發生變化，原先的文檔也可能跟不上當前的市場需求。可見需求變更總是不可避免的，有些是為了修正缺陷，有些屬於增強功能。

　　對項目開發小組而言，變更需求通常意味著要調整資源、重新分配任務，並修改前期的工作成果，有時要付出較大的代價。如果動不動就變更需求，某些項目也許永遠不能按時完成。為此，需求變更必須遵守利大於弊的原則，並做到：

　　①為避免出現失控等風險，對納入基線以前的需求文檔，可通過正常的check—in和check—out進行更改。而納入基線以後的需求文檔，更需按照預定的變更控制規程，確保快速、順利和有序地進行變更。

　　②遵照如圖2所示的需求變更流程來處理。下文將具體介紹這一流程。

　　圖2 需求變更流程

　　2．需求變更的流程

　　需求變更通常按變更申請一審批一更改一重新確認的流程進行。

　　(1)變更申請

　　此時的狀態為“請求變更”。首先由申請人提交需求變更申請書，其內容應該包括：

　　①變更源類型。指引起變更的原因類型，可分為需求變更、設計變更、代碼優化、用戶文檔優化和計劃變更等。②變更優先順序。依據變更的重要性、緊迫性和對關鍵業務的影響程度，以及對系統安全性和穩定性的影響程度，可分為critical、high、middle和low等4級。

　　③變更標誌。分為新增、修改和刪除。

　　④變更影響分析。包括變更影響的工作產品和負責人，對工作量和進度的影響，發生風險的可能性與影響程度，以及需要回測的範圍。

　　⑤可能影響的工作產品。包括項目計劃、需求文檔、概要設計文檔、詳細設計文檔、源代碼和程式、測試計劃和測試案例以及用戶文檔。

　　上述申請書應由項目經理進行評估，其內容包括：

　　①該需求變更在技術上是否可行。

　　②對工期、成本、質量的影響。首先評估單個模塊工期的影響，即實現該需求變更需要的成本和工作量；然後評估實現該需求變更對整體工期工作量和成本的影響。

　　(2)變更審批

　　按照影響的大小由不同的負責人審批。

　　①對影響小的變更，由項目經理直接審批。

　　②對影響大的變更，提交軟體變更控制委員會(Sottware Change Control Board，SCCB)審批。

　　③項目SCCB仍無法決定的變更，再提交高層SCCB決定。

　　所謂影響大的變更一般包括下列情況：

　　①變更影響的模塊數超過10個或超過50％，或者可能影響軟體系統的框架。

　　②變更會影響對客戶的承諾。

　　③變更會帶來“高”或者“高中”程度的風險。

　　如果審批請求未通過，則該變更請求結束。

　　(3)變更修改

　　如果需求變更已審批通過，應指定相關的責任人對產品進行修改，並指定人員對更改後的產品進行審核。還應在產品列表中記錄具體修改的產品名稱、修改描述和是否完成修改的狀態。包括：

　　①應及時更新相應的需求大綱和需求分析說明。

　　②如果影響項目計劃的內容，修改項目計劃，以反映需求的變更。

　　③如果影響到概要設計文檔、詳細設計文檔、源代碼和程式、測試計劃和測試案例或者用戶文檔，它們也需要被及時更新。

　　④如果影響到測試，還需要進行回歸測試。

　　⑤如果對文檔進行修改，需在修改歷史表格中註明修改人、修改時間以及修改原因。

　　⑥如果對原文件修改過大，必要時項目經理可以重新組織工作產品的評審。

　　⑦如果對代碼進行修改，需要導出編譯申請表，通知編譯和測試。

　　(4)變更關閉

　　如果修改後不需要進行測試，則當所有產品全部修改完成時，由最後完成修改的人關閉該變更。如果變更修改後提交測試，則由測試人員負責該變更是否最後關閉：

　　①如果測試未通過，則返回修改者繼續修改。

　　②如果所有工作產品全部修改完成，並且測試通過，關閉該變更。

　　圖3為需求變更的狀態轉換圖，從中可看到各種需求變更狀態的轉換。

　　圖3　　需求變更狀態轉換圖

　　3．需求變更的數據項

　　為了確切記錄需求變化，還需登記如表1所示的變更數據列表。

　　在軟體規模很小的時候，人們採用文檔文件的方式來存儲軟體需求規格說明書和其他文檔。在一些小規模的軟體系統開發中，人們也還這樣做。但是，隨著各種電腦應用系統越來越複雜，軟體規模也越來越龐大。這時傳統的基於文檔文件存儲需求的方式越來越顯露出它的局限性，主要體現在：

　　①手工維護大量文檔文件十分困難。

　　②很難保持文檔與現實的一致。

　　③通知受變更影響的設計人員是手工過程。

　　④不太容易做到為每一個需求保存附加的信息。

　　⑤很難在功能需求與相應的用例、設計、代碼、測試和項目任務之間建立聯繫鏈。

　　⑥很難跟蹤每個需求的狀態。

　　⑦異地協作開發變得很困難。

　　隨著軟體工程技術的發展，需求管理的任務越來越繁重，迫切需要研製需求管理工具來自動化地管理需求，提高工作效率。IBM Rational RequisitePro、Telelogic DOORSreg和Borland CaliberRM等都是目前比較流行的需求管理工具，可以幫助開發團隊有效地管理軟體需求。

• 需求管理（供應鏈)