三、管理需求中須注意的問題
Rational公司的兩位RUP的開發與管理者Per Kroll和Philippe Kruchten在《實踐者指南》一書中，曾提示了一些不能正確應用RUP的問題，這在管理需求工作中也有所體現。由于以用例驅動需求管理所獲得的明顯益處，容易使 團隊成員產生盲目樂觀情緒，從而減弱了把握正確應用的思維判斷能力，產生過猶不及或輕視麻痹的行為及不良效果，這是在管理需求實踐中必須加以注意和避免的。其主要問題有：
一是創建過多的用例。一個常見的現象是根據功能把用例劃分得太細，沒能做到“有所為有所不為”，這樣將產生下列的后果：用戶對粒度太小的用例很難了解及難以判斷是否滿足他們的需求；設計人員對于過細的功能無法全部實現，難以通過設計滿足實際用戶需求；開發人員對關系太緊密的用例很可能開發重復功能并妨礙其他人工作；測試人員要花很多額外精力合成測試用例，才能創建有意義的測試。要避免發生這種情況，應注重以下列的幾條標志來準確量度把握：無法衡量能否給用戶產生價值的用例，代表的是不完整的交互過程，應當重建；用例A總是與用例B或用例C相關，應當把它們整合為一個用例；兩個或多個用例有著幾乎相同的描述，就可以把它們合并在一起；對于用例模型中用例之間的關系，不要進行多于一層的抽象。
二是忽視需求定義的準確與共識。系統的用例模型是由多個系統分析員協同完成的，模型本身也是由多個工件所組成。如果忽略了不同工件之間是否存在矛盾或沖突的地方，就會在模型內部產生不一致性，這種不一致性將會直接影響到需求定義的準確性。同時用例模型最大的優點就在于它應該易于被不同涉眾所理解且無二義性，因此用例的粒度、個數以及模型元素之間的關系復雜程度都應該依此原則所決定，從而使準確的需求定義成為團隊成員和所有涉眾達成共識的基礎。
三是在初始階段過于細化需求。根據RUP對生命周期的階段、目的和里程碑的劃分，初始階段的目的是定義系統的邊界并理解最重要的用戶需求，這個階段最重要的任務是盡快建立可執行的架構，以化解重大 風險，因此不必在初始階段花費太多時間細化需求。這一階段只要得到一個合理并完整的參與者和用例的清單，廣泛而扼要地描述需求，細化基本的或關鍵的用例，就可結束任務，爾后盡早轉入到細化階段，從而為后續的細化需求工作留出充裕的時間。
四是不善于設置需求的優先級。由于 資源或技術條件的限制，不可能把所有需求都一次性完成，這樣就必須進行精心設置，按優先級排序，分批予以實現。為需求設置優先級時應當思考：某個用例是否必須在另一個用例之前實現？是否必須實現整個用例？哪些用例或用例的哪些部分是最重要的？哪一些提供了最多的價值？應把每個需求按對效益的貢獻打分，然后將優先級高的先實現，低的到下一個版本，對不斷進來的新需求也應照此辦理。還要注意的一點是，最合理的需求不一定是要最先考慮的，“經濟為本”應始終是指導優先排序的最高原則。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
