模板
教程
環境
性能
功能
管理
基于用例的需求管理
過程時代的軟件和系統開發
對大多數軟件和系統開發團隊來說，與過去自由的日子相比，20 世紀 90 年代是一個強調流程的時代。評測和驗證有效的軟件開發流程的標準得到推廣和普及。許多論述軟件開發流程的書籍和文獻以及關于業務建模和重建的的相關材料紛紛出版。不斷涌現出的軟件工具已經幫助人們制定和應用有效的軟件開發流程。在這十年內，全球經濟對軟件的依賴程度加深，它推動著開發流程的發展，提高了系統質量。
既然如此，那么今天頻頻發生的軟件項目失敗的事件又如何解釋呢？即使不是大多數，但為什么仍有那么多的項目受到延期、預算超支和質量問題的困擾呢？隨著我們的業務、國家經濟和日?；顒釉絹碓揭蕾囉谙到y，如何才能提高系統的質量？
像往常一樣，答案就在于該行業的人員、工具和流程。需求管理通常在軟件開發出現問題時作為解決方案提出來，但對于這門學科的改進則較少關注。
本文介紹有效需求管理流程的元素，特別強調成功實施需求管理所面臨的障礙。
需求管理除了應用于純軟件項目以外，同樣也應用于軟件只占最終結果的一部分或根本不包括在內的項目。為方便起見，本文以后將使用“系統”這個詞來指代任何或所有這些項目。然而，正是軟件開發的抽象本質本身，或者和硬件一起，使需求管理復雜化了，因此本文的重點在于軟件開發。
為什么要進行需求管理？
簡單地說，系統開發團隊之所怨言。
以下最近收集的證據很有說服力： Standish Group 從 1994 年到 1997 年的 CHAOS Reports 證實，導致項目失敗的最重要的原因與需求有關。[1] 1997 年 12 月，Computer Industry Daily 報導了 Sequent Computer Systems 公司的一項研究，該公司對美國和英國 500 名 IT 經理作調查后發現，百分之七十六的受訪者在他們的事業中經歷過完全的項目失敗。其中提到最多的導致項目失敗的原因就是“變更用戶需求”。[2] 為什么要管理需求？避免失敗就是一個很充分的理由。提高項目的成功率和需求管理所帶來的其他好處同樣也是理由。Standish Group 的 CHAOS 報告進一步證實了與成功項目關系最大的因素是良好的需求管理。
什么是需求？
理解需求管理的第一步就是對什么是需求管理達成共識。Rational 把需求定義為“（正在構建的）系統必須符合的條件或具備的功能”。電氣和電子工程師學會 (IEEE) 使用的定義與此類似。
著名的需求工程設計師 Merlin Dorfman 和 Richard H. Thayer 提出了一個包容且更為精練的定義，它特指軟件方面 - 但不僅僅限于軟件。
“軟件需求可以定義為：
用戶解決某一問題或達到某一目標所需的軟件功能。
系統或系統構件為了滿足合同、規約、標準或其他正式實行的文檔而必須滿足或具備的軟件功能?！盵3]
什么是需求管理
由于需求是正在構建的系統必須符合的事務，而且符合某些需求決定了項目的成功或失敗，因此找出需求是什么，將它們記下來，進行組織，并在發生變化時對它們進行追蹤，這些活動都是有意義的。
換句話說，需求管理就是： 一種獲取、組織并記錄系統需求的系統化方案。 以及一個使客戶與項目團隊對不斷變更的系統需求達成并保持一致的過程。 這個定義與 Dorfman 與 Thayer 以及 IEEE 的“軟件需求工程”的定義相似。需求工程包括獲取、分析、規定、驗證和管理軟件需求，而“軟件需求管理”則是對所有相關活動的規劃和控制[4]。這里介紹的以及 Rational Software 提出的需求管理定義包括了所有這些活動。它們的區別主要在于這里選用了“管理”這個詞，而不是“工程”。管理這個詞更合適用來描述所有涉及到的活動，并且它準確地強調了追蹤變更以保持涉眾與項目團隊之間共識的重要性。
對那些不熟悉“引出”這個詞的人來說，它可定義為團隊用來獲取或發現涉眾請求，確定請求后隱藏的真正需要，以及為滿足這些需要對系統提出的一組適當需求。
需求管理問題
一個目的在于確保系統符合人們對其期望的流程面臨著哪些困難呢？當它真正在實際項目實施時，困難就暴露出來了。圖 1 顯示了 1996 年對開發人員、經理和質量保證人員所做的一次調查結果。該圖顯示了經歷過最常提到的需求相關難題的受訪者比例。
圖 1：常見的需求問題
下面列出了更多與需求有關的問題：
需求不總是顯而易見的，而且它可來自各個方面。
需求并不總是容易用文字明白無誤地表達。
存在不同種類的需求，其詳細程度各不相同。
如果不加以控制，需求的數量將難以管理。
需求相互之間以及與流程的其他可交付工件之間以多種方式相關聯。
需求有唯一的特征或特征值。例如，它們既非同等重要，處理的難度也不同。
需求涉及眾多相關利益責任方，這意味著需求要由跨職能的各組人員來管理。
需求發生變更。
需求可能對時間敏感。
當這些問題與需求管理和處理技能不足以及缺乏易用工具等情況一同出現時，許多團隊都對管理好需求不抱希望了。Rational Software
已經開發出指導團隊提高需求管理技能和流程的專業技術。此外，Rational Requisite?Pro 是一個可獲得的、有效進行自動化管理需求的工具。
需求管理技巧
為了解決上述問題，Rational 鼓勵對關鍵技巧的開發。下面將要介紹的這些技巧是按順序給出的，但在有效的需求管理流程中，它們以不同的順序連續應用。在此，它們將以新項目在第一次迭代時可能使用的順序出現。
圖 2：問題分析步驟
關鍵技巧 1：分析問題
進行問題分析是為了理解業務問題，確定涉眾的最初需要，并提出高層解決方案。這些推理和分析行為找出“隱藏在問題背后的問題”。
在問題分析過程中，將對實際問題的說明取得一致，并確定有關的涉眾。初始解決方案的界限和約束從技術和業務兩個方面來定義。在適當的時候，項目的商業理由還分析期望從系統獲得的投資回報。
關鍵技巧 2：理解涉眾需要
需求有許多來源。它們可能來自于對項目結果感興趣的任何人?？蛻?、合作伙伴、最終用戶以及領域專家都是某些需求的來源。而管理人員、項目團隊成員、業務策略和管理機構是另外一些需求源。
因此，掌握如何確定哪些人員應該是需求源、如何獲得這些需求源以及如何從中獲取信息是很重要的。作為提供這些信息主要來源的個人在本項目中稱為“涉眾”。
如果您正在開發一個在您公司內部使用的信息系統，那么在開發團隊中應包括具有最終用戶經驗和業務領域專業知識的人員。討論一般從業務模型一級開始，而不從系統一級開始。如果正在開發一個要在市場上出售的產品，那么您可以充分調動營銷人員，以便更好地了解該市場中用戶的需要。
獲取需求的手段包括訪談、集體討論、概念原型設計、問卷調查和競爭性分析等。需求獲取的結果可能是一份圖文并茂的請求或需要列表，并按相互之間的優先級列出。
關鍵技巧 3：定義系統
定義系統指的是解釋涉眾需求，并整理為對要構建系統的意義明確的說明。在系統定義初期，需要決定需求的構成、文檔格式、語言規范、需求等級、請求優先級和預計工作量、技術和管理風險以及系統規模等。系統定義活動還可包括與最關鍵的涉眾請求直接聯系的初期原型和設計模型。
我們使用了“說明”這個詞而沒有用“文檔”，是為了避免在后者常見的使用中發現的固有缺陷。說明可以是書面文檔、電子文件、圖像或用于表達除系統本身以外的系統需求的任何表示方式。
系統定義的結果是用自然語言和圖解方式表達的系統說明。后面幾節將介紹推薦使用的一些說明格式。
關鍵技巧 4：管理系統規模
項目規模由分配給它的需求集定義。管理項目規模，使之適合可用資源（時間、人力和資金），是成功管理項目的關鍵。管理規模是一個持續不斷的活動，需要迭代式和遞增式開發，這就將項目細分為更易于管理的若干個小部分。
使用需求屬性（如優先級、工作量和風險）作為協商應包含需求的基礎，對管理規模而言是相當有用的技巧。側重于屬性，而不是需求自身，將減少通常對敏感問題的爭論。
這也有助于培養小組負責人的談判技巧，還有助于在項目中為組織培養推介人，對于客戶而言也是如此。產品/項目推介人應能夠代表組織拒絕那些超出可用資源的規模變更，也應有相應能力擴展資源以適應擴大的規模。
關鍵技巧 5：改進系統定義
對高層系統定義達成一致并充分理解了系統初始規模后，投入資源改進系統定義不僅有可能，而且也是經濟的。改進系統定義包括兩個重要的考慮事項：制定更詳細的高層系統說明和驗證系統是否符合涉眾需要，是否按說明運行。
說明通常是項目團隊的重要參考材料。在制定說明時一定要考慮受眾。人們常會犯一個錯誤，那就是用復雜定義表示構建起來很復雜的東西，尤其是在受眾無法或不愿意耗費精力去思考某些重要的需要取得一致認識時候。這就難以向項目團隊內外的人員解釋系統目的。相反，你可能會發現需要為不同的受眾編制不同類型的說明。本文介紹了詳細自然語言、正式文字和圖解說明推薦使用的格式。確定說明格式后，改進將持續貫穿整個項目生命周期。
關鍵技巧 6：管理變更的需求
不管您多么認真地定義需求，需求終將改變。實際上，一些變更是非常值得的！這意味著您的團隊需要與涉眾保持密切聯系。能否適應變更需求是評測團隊的涉眾敏感度和運作靈活性的一個尺度 - 敏感度和靈活性都是對項目成功有貢獻的團隊特征。變更不是敵人，而沒有管理的變更才是真正的敵人。
圖 3： 變更管理流程
需求變更表明多少需要耗費一些時間來實施某個特定的功能，而且對一個需求的變更對其他需求可能有影響。管理需求變更包括這樣一些活動：設立基線、追蹤每個需求的歷史、確定哪些依賴關系值得追蹤、在相關項之間建立可追蹤關系以及維護版本控制等。如圖 3 所示，建立變更控制或批準流程也很重要，它要求由指定的團隊成員來復審所有提議的變更。有時候這一單一的變更控制渠道稱為變更控制委員會 (CCB)。
重要的需求概念
為了在項目中運用需求管理技巧，參與項目的每個人理解某些基本的需求管理概念是很有裨益的。這些功能包括： 需求類型 功能交叉的團隊 可追蹤性 多維屬性 變更歷史 需求類型系統越大越復雜，出現的需求類型就越多。一個需求類型不過是指需求的一個類。通過確定需求類型，團隊可以把大量需求組織成意義明確且更容易管理的組。在一個項目中建立不同類型的需求有助于團隊成員對變更請求進行分類，并使相互之間的溝通更為清楚明確。
通常，一類需求可以細分即分解成其他類型的需求。業務規則和前景聲明包括高層次的需求，團隊可以從中導出用戶需要、特性和產品需求類型。用例和其他建模形式驅動設計需求，該需求可分解為軟件需求，并可以用分析設計模型來說明。測試需求源于軟件需求，它被分解為具體的測試過程。如果既定項目中有成百上千個，甚至上萬個需求實例時，對需求進行分類可以使項目更容易管理。
功能交叉的團隊
與諸如測試或應用程序建模等流程不同（這些流程可在單個業務組中進行管理），需求管理涉及了每一個能夠為開發流程提供專門技術的個人。其中應包括那些代表客戶和業務預期的人。開發經理、產品經理、分析員、系統工程師甚至客戶都應該參與進來。需求團隊還應包括創建系統解決方案的人 - 工程師、構架設計師、設計員、程序員、技術文檔編寫員以及其他提供技術支持的個人。測試員和其他質量保證人員應當作重要的團隊成員。
圖 4: 功能交叉的需求團隊
通常，創造和維護需求類型的職責可按照功能范圍來分配，從而進一步優化大型項目的管理。需求管理的功能交叉性質是這門學科非常具有挑戰性的一個方面。
可追蹤性
如需求類型說明所述，沒有一個需求表述是孤立存在的。涉眾請求與提議用于滿足這些請求的產品特性有關。產品特性與指定特性的功能性和非功能性行為的各個需求相關。測試案例與它們檢驗和驗證的需求相關。有一些需求可能依賴于其他需求，也可能相互排斥。團隊為了確定變更帶來的影響，保證系統符合預期，就必須理解、記錄并維護這些可追蹤性關系。盡管可追蹤性是需求管理中最難實施的概念之一，但它是適應變更所必不可少的。建立明確的需求類型，吸收功能交叉人員的參與，可使可追蹤性更容易實施和維護。要了解需求可追蹤性策略的更多信息，請參見白皮書“通過用例進行需求管理的可追蹤性策略” [5]。
圖 5：需求可追蹤性
多維屬性
每一個需求類型都有屬性，每一個獨立需求都有不同的屬性值。例如，可為需求分配優先級，確定其來源和原理，委派給某個職能范圍內的特定子團隊進行管理，指定一定的難度，或者與系統的某個迭代關聯關系起來。圖 6 對此作了說明，該圖顯示了 Rational RequisitePro 需求管理工具中 Learning Project 的一個特性需求類型的屬性。正如屏幕的標題所暗示，需求類型和每種類型的屬性是為整個項目定義的，由此確保了團隊上下使用的一致性。
圖 6： 定義特性的需求屬性
圖 7 顯示了 RequisitePro 中某個項目的特性需求實例。注意，即使未完整地顯示每個需求，但我們從屬性值即可了解每個需求的很多內容。在這個例子中，需求的優先級和難度 - 毫無疑問是由團隊的不同成員指定的 - 有助于團隊兼顧考慮涉眾優先級，以及對難度屬性值所反映工作量的大致估計，把項目規模限制在可用資源和時間的合理范圍內。在更詳細的需求類型中，優先級工作量屬性可能有更多的具體值（如預計時間、代碼行等），從而進一步改進規模。需求的多維性以及不同類型的需求（每種類型都有自己的屬性）對于組織大量需求和管理項目的整體規模來說是不可或缺的。
圖 7：設置各個需求的屬性值
變更歷史
單個需求和需求集合都有歷史記錄，并且內容隨著時間的推移而更具有含義。變更在所難免，而且變更有助于與環境變化和技術發展保持同步。記錄項目需求版本有助于團隊領導人找出變更項目的原因，如新的系統發布等。需求集合可能與某一個軟件版本相關，理解這一點有助于人們擴大對變更的管理，降低風險，提高實現重大里程碑的幾率。隨著單個需求發展，理解它們的變更歷史是很重要的：變更內容、起因、時間和誰授權變更等。
實施需求管理工作
需求管理采用上面介紹的關鍵技巧和概念成功地識別并解決問題。
為了建立一個真正滿足客戶需求的系統，項目團隊首先必須確定系統要解決的問題。然后，團隊必須確定涉眾，從中獲得業務和用戶需要，對其進行描述，并區分它們的優先級。從這一組高層期望或需求出發，對產品或系統特性集達成一致意見。
詳細的軟件需求應該以客戶和開發團隊都能理解的形式寫下來。我們發現，使用客戶的語言來描述這些軟件需求在取得理解和共識的過程中是最有效的。這些詳細的軟件需求隨后用作系統設計規約的輸入，或者作為實施和驗證所需的測試計劃及過程的輸入。軟件需求還應該促進初始用戶文檔規劃及設計。
圖 8： 需求管理結構概述
需求管理：工作流程明細
根據領域的不同，需求管理可遵循的方案有無限多種。下面的方案給出了六個詳細的工作流程，它們適用于每一個關鍵的需求管理技巧，但也可以應用到任何領域。
下面的工作流程圖摘自 Rational Unified Process [6]，需求工作流程明細。這些工作流程用角色、活動和工件（輸入或輸出）表示，圖 9 的活動圖對它們進行了概括。旁邊的文字簡單描述了每個工作流程，希望藉此增進讀者對改進需求管理流程的理解和興趣。關于 Rational Unified Process 的更多信息，可參考 http://www-900.ibm.com/cn/software/rational/products/unified_process/index.shtml.
圖 9： Rational Unified Process 中的需求工作流程
工作流程明細：分析問題
在問題分析中，主要的活動是制定項目前景。此活動的結果是產生了一個前景文檔，它確定了待建系統的高級用戶或客戶視圖。前景文檔將初始需求作為關鍵特性表述，這些特性是系統為了解決重大問題并滿足關鍵涉眾需要而必須具備的。系統分析員在此工作流程中扮演主要角色。系統分析員應該具有問題分析領域的專業知識，對問題有一定的理解，還應該能描述其認為可以解決問題的流程。此階段要求各個項目涉眾積極參與，還應該考慮所有相關的涉眾請求。
要開始管理依賴關系活動，應該為職責分配屬性，如基本原理、相對值或優先級以及請求的來源等。隨著前景的發展，分析員確定可能用例的用戶和系統（主角）。主角是用例模型的首要要素，它們將定義系統的功能性和非功能性技術需求。
圖 10： 分析問題
工作流程明細：分析問題
啟動：一個或多個認識到問題存在的涉眾啟動工作流程。
開發團隊中的系統分析員可以和這幾個最初的涉眾展開會話，幫助他們描述需要解決的問題。對所認識問題的簡要說明達成一致意見是很重要的。下表列出了問題說明的關鍵元素：
問題原文轉自：http://www.anti-gravitydesign.com
