,需求的數(shù)量將難以管理. 需求相互之間以及與流程的其他可交付工件之間以多種方式相關聯(lián). 需求有唯一的特征或特征值.例如,它們既非同等重要,處理的難度也不同. 需求涉及眾多相關利益責任方,這意味著需求要由跨職能的各組人員來管理. 需求發(fā)生變更. 需求可能對時間敏感. 當這些問題與需求管理和處理技能不足以及缺乏易用工具等情況一同出現(xiàn)時,許多團隊都對管理好需求不抱希望了.IBM Rational 已經(jīng)開發(fā)出指導團隊提高需求管理技能和流程的專業(yè)技術,并使用相應的工具使得上述的流程和專業(yè)技術得以實現(xiàn). 
需求捕獲 
    從上述的分析可以看出,需求的捕獲是需求管理的基礎和前提.在這里,將介紹一種為業(yè)界所廣泛采用并經(jīng)驗證的需求捕獲方法,即用例模型. 用例模型是系統(tǒng)既定功能及系統(tǒng)環(huán)境的模型,并作為客戶和開發(fā)人員之間的契約.
    用例模型用作分析,設計和測試活動的基本輸入.用例是貫穿整個系統(tǒng)開發(fā)的一條主線.同一個用例模型即為需求工作流程的結果,可當作分析設計工作流程以及測試工作流程的輸入使用.參與者(Actor)和用例(UseCase)是用例模型中的主要元素. 下圖顯示了自動取款機系統(tǒng)用例模型的一部分: 
客戶
查詢
提款
轉帳
客戶身份驗證系統(tǒng)時鐘
數(shù)據(jù)庫服務器
(from )系統(tǒng)維護
信函打印機
打印對帳單
    用例圖用于顯示包含參與者和用例的用例模型示例.系統(tǒng)建模有許多種方法,每種建模方法可以滿足不同的目的.然而,用例模型最重要的作用是將系統(tǒng)行為傳達給客戶或最終用戶.可能與該系統(tǒng)交互的用戶和任何其他系統(tǒng)都是參與者.由于參與者代表了系統(tǒng)用戶,它們協(xié)助界定系統(tǒng)并提供十分明確的系統(tǒng)用途說明.編寫用例依據(jù)參與者的需求來進行.這樣就確保該系統(tǒng)成為用戶期望得到的系統(tǒng). 
    參與者和用例都是通過將客戶需求及潛在用戶當作重要的信息查找到的.找到這些用例和參與者后,應對它們作簡要說明.在詳細說明這些用例之前,客戶應復審該用例模型以核實所有的用例和參與者都已經(jīng)找到,并且它們可以提供客戶所需要的東西. 在迭代開發(fā)環(huán)境中,您可以選擇用例的子集以便在每個迭代中詳細描述.參與者和用例找到后,需要詳細說明每個用例的事件流.這些說明指出系統(tǒng)與參與者交互的方式以及在各個獨立用例中系統(tǒng)執(zhí)行的有關操作. 
    最后,對已完成的用例模型(包括用例說明)進行復審,開發(fā)人員和客戶使用該模型對系統(tǒng)應執(zhí)行的操作達成一致意見. 
四、需求管理模型
    在需求管理的流程中,需求的捕獲手段固然重要,但在需求的捕獲和需求最終成型的過程中,我們會面臨各種和需求相關的信息和資料(也可以把這些信息籠統(tǒng)地稱做"需求"),如何發(fā)現(xiàn)這些信息之間的關系并有效組織,更為關鍵. 需求類型 在RUP中,我們采用一種金字塔方式的管理辦法,來組織和管理我們獲取的信息乃至最終的需求. 
    為了建立一個真正滿足客戶需求的系統(tǒng),項目團隊首先必須確定系統(tǒng)要解決的問題.然后,團隊必須確定涉眾,從中獲得業(yè)務和用戶需要,對其進行描述,并區(qū)分它們的優(yōu)先級.從這一組高層期望或需求出發(fā),對產(chǎn)品或系統(tǒng)特性集達成一致意見.而后,由產(chǎn)品特性來抽取軟件需求,在我們的模型中,軟件需求是以用例模型的方式來描述.從測試的角度來看,測試項一定來自于軟件需求,即軟件需求中確定了哪些需求項,測試就要根據(jù)這些需求項來制定和實現(xiàn). 
    系統(tǒng)越大越復雜,出現(xiàn)的需求類型就越多.一個需求類型不過是指需求的一個類.通過確定需求類型,團隊可以把大量需求組織成意義明確且更容易管理的組.在一個項目中建立不同類型的需求有助于團隊成員對變更請求進行分類,并使相互之間的溝通更為清楚明確.從上述的分析中我們可以看到,通常,一類需求可以細分即分解成其他類型的需求.這里,

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html