決定要使用什麼工作成果及如何使用。除了指出要使用什麼工作成果之外,也必須調整要使用的每一個工作成果,以符合專案的需求。
下表指出建議哪些「需求」工作成果及哪些可視為選用(亦即,只在特定的情況下使用)。 至於其他調整注意事項,請參閱工作成果說明頁的調整章節。
工作成果
|
目的
|
調整(選用、建議)
|
工作成果:使用案例模型(工作成果:參與者、工作成果:使用案例、工作成果:使用案例套件)
|
使用案例用來定義功能需求。
|
建議大部分專案採用。
使用案例是建議用來擷取功能需求的方法。
|
工作成果:分鏡腳本
|
專案若含有尚未真正瞭解的行為需求,應該考慮利用分鏡腳本作業來引出需求。
|
選用
可以使用其他需求引出技術。
|
工作成果:名詞解釋
|
確保專案的每個相關人員都使用共同的詞彙。
|
建議大部分專案採用。
|
工作成果:需求屬性
|
需求屬性資料庫有助於確保需求設定了適當的優先順序,也適當進行追蹤。
|
選用
不過,在需求相對較少的專案上,需求屬性資料庫並不嚴格需要。
|
工作成果:需求管理計劃
|
說明要收集的資訊及用來測量、報告和控制產品需求變更的控制機制。如果需求管理複雜度或客戶可見度保證提供個別文件,便需要個別文件。
|
選用
需求較少的專案可以採取可由軟體開發計劃直接說明的輕型需求管理方式。
其他專案可以選取和遵循較嚴格的方式,但只產生少量說明,或不產生正式說明。例如,要收集的一組需求屬性,可以由工具的配置來隱含地說明。
|
工作成果:軟體需求規格
|
用來收集所有需求,以正式文件提供給客戶。
|
選用
在較不正式的專案上,可能不需要正式文件。
|
工作成果:關係人需求
|
擷取對於專案的所有要求,以及如何處理過這些要求。
|
建議大部分專案採用。
為了建置符合關係人需求的系統,務必徵求和檢視關係人的要求,這一點很重要。
許多專案都只是將「關係人需求」當作「變更要求」的種類來管理。其他專案則可能只是非正式地擷取「關係人需求」。
|
工作成果:增補規格
|
用來擷取非功能需求。
|
建議大部分專案採用。
|
工作成果:願景
|
擷取非常高階的需求和設計限制,使讀者瞭解將開發的系統。
|
建議大部分專案採用。
|
使用哪些報告的決策,取決於專案所能使用的報告工具。如果能夠得到產生報告的工具,我們建議您針對模型導向或資料庫導向的工作成果來產生報告,如「使用案例」和「參與者」。您可以從工作成果說明頁面中取得 RUP
配置現有的報告,在目錄樹瀏覽器中,它們分組在相關工作成果之下。
只有在正式合約、標準或規格文件將需求強加於需求管理工作時,本節才適用。它稱為「輸入需求規格」。
在需求工作期間,您將需求擷取在這些文件中:工作成果:願景、工作成果:關係人需求、工作成果:使用案例模型、工作成果:增補規格。
請決定是否要維護輸入需求規格。當您發現不當、錯誤或有缺點的需求時,是否要返回更新輸入需求規格? 您也必須決定如何維護輸入需求規格和工作成果:使用案例之間的 追蹤或參照。
請選擇下列策略之一或策略組合:
-
不更新輸入需求規格。由使用案例和增補規格指定系統將執行什麼動作。
-
請勿更新輸入需求規格,應該維護從使用案例追溯回來的
可追蹤性。
-
更新輸入需求規格,所有工作和成本都包括在內。
-
使輸入需求規格發展成包含需求的增補規格。功能輸入需求會簡單轉送至使用案例。
大部分專案都會發現不當、錯誤或有缺點的需求很多,維護原始輸入需求規格並沒有意義。以使用案例模型期間所顯現的新資訊來更新輸入需求規格的工作,只有極少數專案的客戶願意支付它。
請勿太早強調這個主題。在專案開始時,人們往往會相信起始需求規格,不過,在以使用案例來處理問題領域之後,大部分人對於起始需求規格的看法會完全改變。
請決定如何核准使用案例。限制客戶必須正式審查的使用案例數目可以節省許多時間。客戶也許會接受只正式檢視所有使用案例的一部分。
請選擇下列中的一或多個策略:
-
所有使用案例都必須通過專案之外的代表所進行的外部檢視。
-
部分次要使用案例可以在非正式的檢視或內部正式檢視中,用簡單的方式來核准。
次要使用案例是對系統很重要,但對主要使用者的作業不重要的使用案例;比方說,與系統的管理和維護相關的使用案例,例如,增加系統使用者、變更使用者權限,以及建立備份。沒有這些使用案例,系統將無法運作,不過,重要使用者的主要興趣並不在這裡。
您使用的策略會隨著您與客戶的關係而不同。他們相信您能夠正確執行支援的使用案例,而不需要正式的核准流程嗎? 雖然這可以節省可觀的時間,但您能夠達到使用案例模型的正確品質嗎?
附註:如果要解決這個問題,客戶可能必須涉入需求工作中。客戶代表涉入之後,他們也許能核准,也許能向其他客戶提供建議;客戶涉入之後,專案會具有可信度。
如需審查層次的相關資訊,請參閱準則:審查層次。
|