活動: 管理變更需求
本活動管理需求的變更並評估整體影響。
說明工作分解結構團隊配置工作成果用法
目的
本活動的用途是評估所要求的變更對於需求所產生的影響,並對於已核准執行的變更,管理後續產生的影響。
關係
母項活動
說明

本活動致力於:

需求的變更很自然會影響下游的構件(例如,分析與設計工作成果、測試工作成果、部署構件等)。在 管理相依關係期間發現和記錄的 可追蹤性關係,明確定義需求與其他工作成果之間的關係。在瞭解需求變更的影響時,這些關係是關鍵。

內容
事件驅動Yes
多次出現的項目
持續進行中
選用
規劃
可重複的
人員配置

引進延伸團隊(關係人:客戶代表、領域專家及其他人物)。對於工作受到變更所影響的任何人,納入為軟體專案團隊的技術審查人員。請小心確實管理您的審查資源。除非確定對專案有益,否則請勿納入整個延伸團隊。

延伸團隊應該融合問題領域的專長、專案的技術難度,以及需求管理和使用案例模型的技巧。

用法
用法指引

每當修正需求時,就應該進行這項活動。

每當需求更新時,就應該定期審查並更新需求屬性和相依關係。

對於「初始」和「詳述」階段的每一個反覆,建議您召開一次使用案例模型的審查會議,審查正在進行的工作;在仔細開發任何使用案例之前,使用者要先完成並簽署這項審查,可視為非常重要的里程碑,以免浪費資源來開發不正確的使用案例。 此外,在「詳述」階段結束時,您應該召開使用案例模型的詳細審查會議。 切記,在「詳述」階段結束時,您應該會建立一個完成 80% 的使用案例模型,也許是代表名詞解釋的領域模型。 在「建構」和「轉換」階段的每一個反覆中,當使用案例模型修正時,您也應該召開一次使用案例模型的審查會議。 此次審查應該以反覆中所開發的使用案例模型為重點。

主要考量

核心開發團隊應該進行多次內部審查:在由延伸團隊正式視察和審查工作之前,經由演練來排除不必要的矛盾之處。

您應該分割資料,不要讓團隊一次審查每件事。審查會議不要超過一天。例如,您可能舉行兩次會議來分開審查使用者介面和行為情境,或審查特定子系統相關的所有需求構件。

另一項重要的考量是追蹤需求歷程。只要掌握需求變更的本質與理由,審查人員可以獲得必要的資訊來適當地回應變更。