需求管理詳解

需求和需求管理

為什么需要管理需求？

簡單地說,系統開發團隊之所以管理需求,是因為他們想讓項目獲得成功.滿足項目需求即為成功打下了基礎.若無法管理需求,達到目標的幾率就會降低. 以下最近收集的證據很有說服力: Standish Group 從 1994 年到 2001 年的 CHAOS Reports 證實,導致項目失敗的最重要的原因與需求有關. 2001年,Standish Group 的CHAOS Reports報導了該公司的一項研究,該公司對多個項目作調查后發現,百分之七十四的項目是失敗的,既這些項目不能按時按預算完成.其中提到最多的導致項目失敗的原因就是"變更用戶需求". 

為什么要管理需求？

避免失敗就是一個很充分的理由.提高項目的成功率和需求管理所帶來的其他好處同樣也是理由.Standish Group 的 CHAOS 報告進一步證實了與成功項目關系最大的因素是良好的需求管理. 

什么是需求？

理解需求管理的第一步就是對什么是需求管理達成共識.Rational 把需求定義為"(正在構建的)系統必須符合的條件或具備的功能".電氣和電子工程師學會使用的定義與此類似. 著名的需求工程設計師 Merlin Dorfman 和 Richard H. Thayer 提出了一個包容且更為精練的定義,它特指軟件方面 - 但不僅僅限于軟件: 

"軟件需求可定義為: 用戶解決某一問題或達到某一目標所需的軟件功能. 系統或系統構件為了滿足合同,規約,標準或其他正式實行的文檔而必須滿足或具備的軟件功能." 

什么是需求管理

由于需求是正在構建的系統必須符合的事務,而且符合某些需求決定了項目的成功或失敗,因此找出需求是什么,將它們記下來,進行組織,并在發生變化時對它們進行追蹤,這些活動都是有意義的. 換句話說,需求管理就是：一種獲取,組織并記錄系統需求的系統化方案,以及一個使客戶與項目團隊對不斷變更的系統需求達成并保持一致的過程. 

這個定義與 Dorfman 與 Thayer 以及 IEEE 的"軟件需求工程"的定義相似.需求工程包括獲取,分析,規定,驗證和管理軟件需求,而"軟件需求管理"則是對所有相關活動的規劃和控制.這里介紹的以及 IBM Rational提出的需求管理定義包括了所有這些活動.它們的區別主要在于這里選用了"管理"這個詞,而不是"工程".管理這個詞更合適用來描述所有涉及到的活動,并且它準確地強調了追蹤變更以保持涉眾與項目團隊之間共識的重要性. 

對那些不熟悉"引出"這個詞的人來說,它可定義為團隊用來獲取或發現涉眾請求,確定請求后隱藏的真正需要,以及為滿足這些需要對系統提出的一組適當需求. 

需求管理問題 一個目的在于確保系統符合人們對其期望的流程面臨著哪些困難呢 當它真正在實際項目實施時,困難就暴露出來了.圖 1 顯示了年對開發人員,經理和質量保證人員所做的一次調查結果.該圖顯示了經歷過最常提到的需求相關難題的受訪者比例. 

下面列出了更多與需求有關的問題: 

需求不總是顯而易見的,而且它可來自各個方面. 需求并不總是容易用文字明白無誤地表達. 存在不同種類的需求,其詳細程度各不相同. 如果不加以控制,需求的數量將難以管理. 需求相互之間以及與流程的其他可交付工件之間以多種方式相關聯. 需求有唯一的特征或特征值.例如,它們既非同等重要,處理的難度也不同. 需求涉及眾多相關利益責任方,這意味著需求要由跨職能的各組人員來管理. 需求發生變更. 需求可能對時間敏感. 當這些問題與需求管理和處理技能不足以及缺乏易用工具等情況一同出現時,許多團隊都對管理好需求不抱希望了.IBM Rational 已經開發出指導團隊提高需求管理技能和流程的專業技術,并使用相應的工具使得上述的流程和專業技術得以實現. 

需求捕獲 

從上述的分析可以看出,需求的捕獲是需求管理的基礎和前提.在這里,將介紹一

種為業界所廣泛采用并經驗證的需求捕獲方法,即用例模型. 用例模型是系統既定功能及系統環境的模型,并作為客戶和開發人員之間的契約.

用例模型用作分析,設計和測試活動的基本輸入.用例是貫穿整個系統開發的一條主線.同一個用例模型即為需求工作流程的結果,可當作分析設計工作流程以及測試工作流程的輸入使用.參與者(Actor)和用例(UseCase)是用例模型中的主要元素. 下圖顯示了自動取款機系統用例模型的一部分: 

客戶

查詢

提款

轉帳

客戶身份驗證系統時鐘

數據庫服務器

(from )系統維護

信函打印機

打印對帳單

用例圖用于顯示包含參與者和用例的用例模型示例.系統建模有許多種方法,每種建模方法可以滿足不同的目的.然而,用例模型最重要的作用是將系統行為傳達給客戶或最終用戶.可能與該系統交互的用戶和任何其他系統都是參與者.由于參與者代表了系統用戶,它們協助界定系統并提供十分明確的系統用途說明.編寫用例依據參與者的需求來進行.這樣就確保該系統成為用戶期望得到的系統. 

參與者和用例都是通過將客戶需求及潛在用戶當作重要的信息查找到的.找到這些用例和參與者后,應對它們作簡要說明.在詳細說明這些用例之前,客戶應復審該用例模型以核實所有的用例和參與者都已經找到,并且它們可以提供客戶所需要的東西. 在迭代開發環境中,您可以選擇用例的子集以便在每個迭代中詳細描述.參與者和用例找到后,需要詳細說明每個用例的事件流.這些說明指出系統與參與者交互的方式以及在各個獨立用例中系統執行的有關操作. 

最后,對已完成的用例模型(包括用例說明)進行復審,開發人員和客戶使用該模型對系統應執行的操作達成一致意見. 

需求管理模型

在需求管理的流程中,需求的捕獲手段固然重要,但在需求的捕獲和需求最終成型的過程中,我們會面臨各種和需求相關的信息和資料(也可以把這些信息籠統地稱做"需求"),如何發現這些信息之間的關系并有效組織,更為關鍵. 需求類型 在RUP中,我們采用一種金字塔方式的管理辦法,來組織和管理我們獲取的信息乃至最終的需求. 

為了建立一個真正滿足客戶需求的系統,項目團隊首先必須確定系統要解決的問題.然后,團隊必須確定涉眾,從中獲得業務和用戶需要,對其進行描述,并區分它們的優先級.從這一組高層期望或需求出發,對產品或系統特性集達成一致意見.而后,由產品特性來抽取軟件需求,在我們的模型中,軟件需求是以用例模型的方式來描述.從測試的角度來看,測試項一定來自于軟件需求,即軟件需求中確定了哪些需求項,測試就要根據這些需求項來制定和實現. 

系統越大越復雜,出現的需求類型就越多.一個需求類型不過是指需求的一個類.通過確定需求類型,團隊可以把大量需求組織成意義明確且更容易管理的組.在一個項目中建立不同類型的需求有助于團隊成員對變更請求進行分類,并使相互之間的溝通更為清楚明確.從上述的分析中我們可以看到,通常,一類需求可以細分即分解成其他類型的需求.這里,我們就把需求分解為幾種類型,并在他們之間建立相應的關聯.業務規則和前景聲明包括高層次的需求,團隊可以從中導出用戶需要,特性和產品需求類型.用例和其他建模形式驅動設計需求,該需求可分解為軟件需求,并可以用分析設計模型來說明.測試需求源于軟件需求,它被分解為具體的測試過程.如果既定項目中有成百上千個,甚至上萬個需求實例時,對需求進行分類可以使項目更容易管理.上述的這些需求類型同時保存在對應的RUP文檔和數據庫中. 

應用需求類型

通過定義需求類型,以及他們之間的關系,我們就建立了一個需求管理模型的框架.當然,我們建立這樣的一個模型,是為了方便我們使用需求,為了達到這一目的,我們還需要在此基礎上添加相應的內容. 需要對各種需求類型添加它們的屬性,以便于對需求進行查詢等管理手段.比如,可以針對用戶需要,確定該需要的必要性,優先級,確定性等屬性.在實際的項目中,就可以確定這些屬性的值,而后根據這些實際屬性值來安排項目的進度表等.或是在項目進度緊急時,確定哪些需求是可以延期完成,而哪些是必須完成的,等等. 

需求的追蹤性 其次,可以根據不同需求的導出情況,在不同的需求之間建立追蹤關系.譬如,用戶需要決定了要構建產品的特性,產品的特性又決定了產品的軟件需求,等.在這些不同類型的需求之間建立關聯,一旦其中的某些需求發生變化,就可以確定它可能帶來的影響,從而制定相應的策略. 

需求管理的工作流程 

工作流明細簡介 

問題分析 

問題分析可以通過了解問題及涉眾的最初需要,并提出高層解決方案來實現.它是為找出"隱藏在問題之后的問題"而進行的推理和分析.問題分析期間,將對"什么是面臨實際問題"和"誰是涉眾"等問題達成一致.而且,您還要從業務角度界定解決方案,以及制約該解決方案的因素.您應該已經對項目進行過商業理由分析,這將便于您更好地預計能從構建中的項目中得到多少投資回報. 

理解涉眾需要 

需求來自各個方面,比如來自客戶,合作伙伴,最終用戶或是某領域的專家.您需要掌握如何準確判斷需求應來源于哪方面,如何接近這些來源并從中獲取信息.提供這些信息主要出處的個人在本項目中稱為涉眾.如果您正在開發一個在您公司內部使用的信息系統,那么在開發團隊中應包括具有最終用戶經驗和業務領域專業知識的人員.通常討論將在業務模型這一級上展開,而不是在系統這一級上展開.如果正在開發一個要在市場上出售的產品,那么您可以充分調動營銷人員,以便更好地了解該市場中用戶的需要. 獲取需要的活動可使用這樣一些技巧:訪談,集體討論,概念原型設計,問卷調查和競爭性分析等.獲取結果可能是一份圖文并茂的請求或需要列表,并按相互之間的優先級列出. 

定義系統 

定義系統指的是解釋涉眾需求,并整理為對要構建系統的意義明確的說明.在系統定義的初期要確定以下內容:需求構成,文檔格式,語言形式,需求的具體程度(需求量及詳細程度),需求的優先級和預計工作量(不同人在不同的實踐中通常對這兩項內容的看法大不相同),技術和管理風險以及最初規模.系統定義活動還可包括與最關鍵的涉眾請求直接聯系的初期原型和設計模型.系統定義的結果是用自然語言和圖解方式表達的系統說明. 

管理項目規模 

為使項目高效運作,應仔細根據所有涉眾的需求確定優先級,并對項目規模進行管理.有的開發人員僅僅重視所謂的"復活節彩蛋"(即開發人員感興趣或覺得有挑戰性的特性),而不是及早將精力投入降低項目風險或提高應用程序構架穩定性方面,這已使太多的項目蒙受損失.為確保盡早解決或降低項目中的風險,應以遞增的方式開發系統.要慎重選擇需求,以確保每次增加都能緩解項目中的已知風險.要達到目的,您需要和項目的涉眾協商每次迭代的范圍.通常,這要求具備管理項目各個階段的期望結果的良好技能.

除了控制開發過程本身,您還需控制需求的來源,并控制項目可交付工件的外觀. 改進系統定義 系統的詳細定義應能讓涉眾理解,同意并認可.它不僅需要具備所有功能,而且應符合法律或法規上的要求,符合可用性,可靠性,性能,可支持性和可維護性.感覺構建過程復雜的系統就應該有復雜的定義,這是一種常見的錯誤看法.這會給解釋項目和系統的目的造成困難.人們可能印象深刻,但他們會因不甚理解而無法給出建議.應該致力于

了解您制作的系統說明文檔的讀者.您可能常會發現需要為不同的讀者準備不同的說明文檔. 

我們認為用例方法是傳達系統目的和定義系統細節的一種行之有效的方法,它常與簡單的可視化原型結合使用.用例有助于為需求提供一個環境,利用它可生動地說明系統使用的方式. 

系統詳細定義的另一個構件是說明系統采用的測試方式.測試計劃及要執行測試的定義將會說明要核實哪些系統功能. 

管理需求變更

定義需求時無論怎樣謹慎小心,也總會有可變因素.變更的需求之所以變得難以管理,不僅是因為一個變更了的需求意味著要花費或多或少的時間來實現某一個新特性,而且也因為對某個需求的變更很可能影響到其他需求.應確保賦予需求一個有彈性的結構,使它能適應變更,并且確保使用可追蹤性鏈接可以表達需求與開發生命周期的其他工件之間的依賴關系.管理變更包括建立基線,確定需要追蹤的重要依賴關系,建立相關項之間的可追蹤性,以及變更控制等活動.