需求管理的內容
1.需求管理的特定實踐需求管理包含5個特定實踐,如圖1所示。現簡介如下。
需求變更控制
需求變更要進行控制,嚴格防止因失控而導致項目混亂,出現重大的風險。1.需求變更的利弊
隨著項目的進展,用戶和開發方對需求的了解越來越深入,原先的需求文檔很可能存在錯誤或不足。另一方面,市場會發生變化,原先的文檔也可能跟不上當前的市場需求。可見需求變更總是不可避免的,有些是為了修正缺陷,有些屬於增強功能。
對項目開發小組而言,變更需求通常意味著要調整資源、重新分配任務,並修改前期的工作成果,有時要付出較大的代價。如果動不動就變更需求,某些項目也許永遠不能按時完成。為此,需求變更必須遵守利大於弊的原則,並做到:
①為避免出現失控等風險,對納入基線以前的需求文檔,可通過正常的check—in和check—out進行更改。而納入基線以後的需求文檔,更需按照預定的變更控制規程,確保快速、順利和有序地進行變更。
②遵照如圖2所示的需求變更流程來處理。下文將具體介紹這一流程。
圖3需求變更狀態轉換圖
3.需求變更的數據項
為了確切記錄需求變化,還需登記如表1所示的變更數據列表。
數據項名稱 | 定義 |
項目名稱和ID | 變更所在項目的名稱和ID |
變更階段 | 需求階段、設計階段、編碼、測試和驗收階段。不同階段的需求變更請求對整個項目開發的影響也不同 |
變更優先權 | 每個變更的相對重要性 |
變更標誌 | 變更的狀態 |
變更原因描述 | 簡單描述提出變更的原因 |
變更內容描述 | 對變更的內容進行簡單描述 |
相關的變更請求 | 是否有相關的變更請求,如果有,指定相關的變更請求 |
變更的狀態信息 | 包括變更請求人、變更批准人、當前負責人、變更關閉人、請求日期、審批日期、期望解決日期以及關閉日期 |
變更影響分析 | 基於受影響工作產品對變更的影響進行分析 |
變更處理信息 | 所影響的工作產品列表以及各工作產品對變更的處理狀態 |
需求管理工具
在軟體規模很小的時候,人們採用文檔檔案的方式來存儲軟體需求規格說明書和其他文檔。在一些小規模的軟體系統開發中,人們也還這樣做。但是,隨著各種計算機套用系統越來越複雜,軟體規模也越來越龐大。這時傳統的基於文檔檔案存儲需求的方式越來越顯露出它的局限性,主要體現在:①手工維護大量文檔檔案十分困難。
②很難保持文檔與現實的一致。
③通知受變更影響的設計人員是手工過程。
④不太容易做到為每一個需求保存附加的信息。
⑤很難在功能需求與相應的用例、設計、代碼、測試和項目任務之間建立聯繫鏈。
⑥很難跟蹤每個需求的狀態。
⑦異地協作開發變得很困難。
隨著軟體工程技術的發展,需求管理的任務越來越繁重,迫切需要研製需求管理工具來自動化地管理需求,提高工作效率。IBM Rational RequisitePro、Telelogic DOORSreg和Borland CaliberRM等都是目前比較流行的需求管理工具,可以幫助開發團隊有效地管理軟體需求。