本活動致力於:
需求的變更很自然會影響下游的構件(例如,分析與設計工作成果、測試工作成果、部署構件等)。在管理相依關係期間發現和記錄的可追蹤性關係,明確定義需求與其他工作成果之間的關係。在瞭解需求變更的影響時,這些關係是關鍵。
引進延伸團隊(關係人:客戶代表、領域專家及其他人物)。對於工作受到變更所影響的任何人,納入為軟體專案團隊的技術審查人員。請小心確實管理您的審查資源。除非確定對專案有益,否則請勿納入整個延伸團隊。
延伸團隊應該融合問題領域的專長、專案的技術難度,以及需求管理和使用案例模型的技巧。
每當修正需求時,就應該進行這項活動。
每當需求更新時,就應該定期審查並更新需求屬性和相依關係。
對於「初始」和「詳述」階段的每一個反覆,建議您召開一次使用案例模型的審查會議,審查正在進行的工作;在仔細開發任何使用案例之前,使用者要先完成並簽署這項審查,可視為非常重要的里程碑,以免浪費資源來開發不正確的使用案例。 此外,在「詳述」階段結束時,您應該召開使用案例模型的詳細審查會議。 切記,在「詳述」階段結束時,您應該會建立一個完成 80% 的使用案例模型,也許是代表名詞解釋的領域模型。 在「建構」和「轉換」階段的每一個反覆中,當使用案例模型修正時,您也應該召開一次使用案例模型的審查會議。 此次審查應該以反覆中所開發的使用案例模型為重點。
核心開發團隊應該進行多次內部審查:在由延伸團隊正式視察和審查工作之前,經由演練來排除不必要的矛盾之處。
您應該分割資料,不要讓團隊一次審查每件事。審查會議不要超過一天。例如,您可能舉行兩次會議來分開審查使用者介面和行為情境,或審查特定子系統相關的所有需求構件。
另一項重要的考量是追蹤需求歷程。只要掌握需求變更的本質與理由,審查人員可以獲得必要的資訊來適當地回應變更。
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.