需求管理 (項目)

需求管理的內容

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等都是目前比較流行的需求管理工具,可以幫助開發團隊有效地管理軟體需求。

相關詞條

熱門詞條

聯絡我們