需求管理是以一種有系統的方式,來尋找、記錄、組織及追蹤系統的變更需求。
我們將需求定義為「系統必須符合的條件或能力」。
我們在形式上將需求管理定義為用來進行以下作業的系統化方法:
-
引出、組織及記錄系統的需求
-
建立及維護客戶和專案小組對系統變更需求的協議
有效率的需求管理關鍵包括保存一份清楚的需求陳述,以及其他需求及其他專案構件 的適當屬性和可追蹤性。
收集需求看似一件簡單的作業。但事實上專案會因為下列原因,而陷入困境:
-
需求總是難以捉摸,且可能有多個來源。
-
需求未能清楚明白地以文字表達。
-
需求種類繁多,且詳細程度不一。
-
若不加以控制,需求的數目會變得無法管理。
-
需求之間以及和軟體工程流程的其他可交付項目之間會互相關聯。
-
需求有獨特的內容和或內容值。例如,它們既不是同樣重要,也不是同樣容易滿足。
-
利害關係人眾多,意謂著必須由跨領域的人群來共同管理需求。
-
需求變更。
不論您如何審慎定義需求,總是會有一些東西要變更。讓需求變更複雜到難以管理的原因,不只是需求變更表示要花時間來實作特定的新增特性,同時也表示變更某項需求時,可能會影響到其他需求。管理變更包括建立基準線、決定有哪些重要的相依關係需要追蹤、建立相關項目之間的可追蹤性,
以及實施變更管制等活動。
我們建議您用使用案例來組織您的功能需求。拼除列出需求清單的方式,改為將需求組織成可以描述某個人會如何使用系統的方式。這不但可以提供更高層次的完整性和一致性,也可以更充分瞭解需求對使用者的重要性。
從傳統的物件導向系統模式來看,通常很難看出系統應該做的事情。這個問題是起源於系統在執行某些作業時,缺少一條「紅線」。在 Rational Unified Process (RUP)
中,使用案例就是那條紅線,因為使用案例會定義系統執行的行為。使用案例並不是傳統物件導向的一部分,但是它的重要性已愈來愈明顯。這一點也可以從「統一建模語言」涵蓋使用案例進一步看出。
RUP 採用「使用案例驅動方法」,這表示針對系統定義的使用案例就是整個開發流程的基礎。
使用案例在許多規範中都有它的功用存在。
-
使用案例的概念可以用來代表商業流程。我們將此使用案例變式稱為「商業使用案例」。這是「商業模型」規範的一部分。
-
「需求」規範會說明以使用案例作為軟體需求。使用案例會構成系統的客戶、開發人員以及測試人員都必須接受的重要基礎概念。
-
在「專案管理」規範中,是將使用案例作為規劃反覆式開發的基準。
-
使用案例在設計模型中,會實現作為「分析與設計」規範的一部分。使用案例實現化會以設計模型內的物件互動關係,來說明設計如何支援使用案例。
-
使用案例最終會變成被實作和可測試的情境,並且也是「實作」與「測試」規範的重要焦點。這些會用來產生測試案件和測試 Script;系統的功能是透過執行測試情境(執行每一個使用案例)方式來驗證。
-
在「部署」規範中,使用案例會形成使用手冊中的內容基礎。使用案例也可以用來定義產品的訂購單位。例如,客戶可以取得配置為特定使用案例組合的系統。
|