需求管理的內容
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所示的變更數據列表。
| 數據項名稱 | 定義 |
| 項目名稱和ID | 變更所在項目的名稱和ID |
| 變更階段 | 需求階段、設計階段、編碼、測試和驗收階段。不同階段的需求變更請求對整個項目開發的影響也不同 |
| 變更優先權 | 每個變更的相對重要性 |
| 變更標誌 | 變更的狀態 |
| 變更原因描述 | 簡單描述提出變更的原因 |
| 變更內容描述 | 對變更的內容進行簡單描述 |
| 相關的變更請求 | 是否有相關的變更請求，如果有，指定相關的變更請求 |
| 變更的狀態信息 | 包括變更請求人、變更批准人、當前負責人、變更關閉人、請求日期、審批日期、期望解決日期以及關閉日期 |
| 變更影響分析 | 基於受影響工作產品對變更的影響進行分析 |
| 變更處理信息 | 所影響的工作產品列表以及各工作產品對變更的處理狀態 |
需求管理工具
在軟體規模很小的時候，人們採用文檔檔案的方式來存儲軟體需求規格說明書和其他文檔。在一些小規模的軟體系統開發中，人們也還這樣做。但是，隨著各種計算機套用系統越來越複雜，軟體規模也越來越龐大。這時傳統的基於文檔檔案存儲需求的方式越來越顯露出它的局限性，主要體現在：
①手工維護大量文檔檔案十分困難。
②很難保持文檔與現實的一致。
③通知受變更影響的設計人員是手工過程。
④不太容易做到為每一個需求保存附加的信息。
⑤很難在功能需求與相應的用例、設計、代碼、測試和項目任務之間建立聯繫鏈。
⑥很難跟蹤每個需求的狀態。
⑦異地協作開發變得很困難。
隨著軟體工程技術的發展，需求管理的任務越來越繁重，迫切需要研製需求管理工具來自動化地管理需求，提高工作效率。IBM Rational RequisitePro、Telelogic DOORSreg和Borland CaliberRM等都是目前比較流行的需求管理工具，可以幫助開發團隊有效地管理軟體需求。
