RUP：通過用例應用需求管理

領測軟件測試網

RUP：通過用例應用需求管理

作者：Roger Oberg、Leslee Probasco 和 Maria Ericsson 
©2000 Rational Software Corporation技術論文 TP505 （版本 1.4）

 
如果您對需求管理一無所知或者一知半解，但有志于改進需求過程，那么本文將為您提供一個框架，您可以利用它開發自己的方案。

用例和軟件需求規約 (SRS) 為了讓讀者更好地理解需求管理工作流程，作者從 Rational Software 的 Unified Process 以及工業標準統一建模語言特地挑選了一些文檔類型和需求管理工件予以說明。Unified Process 和統一建模語言都推薦使用一種用例驅動的軟件工程流程。 因此，本文描述了一種用于指定軟件需求的用例驅動方案。這些工作流程還可代替用例模型和用例，或作為它們的補充，與更傳統的軟件需求規約（如 IEEE 標準）一起使用。

流程時代的軟件和系統開發
對大多數軟件和系統開發團隊來說，與過去自由的日子相比，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 把需求定義為“（正在構建的）系統必須符合的條件或具備的功能”。電氣和電子工程師學會使用的定義與此類似。

著名的需求工程設計師 Merlin Dorfman 和 Richard H. Thayer 提出了一個包容且更為精練的定義，它特指軟件方面 - 但不僅僅限于軟件：

“軟件需求可定義為： 

用戶解決某一問題或達到某一目標所需的軟件功能。 
系統或系統構件為了滿足合同、規約、標準或其他正式實行的文檔而必須滿足或具備的軟件功能�！盵3] 

什么是需求管理？
由于需求是正在構建的系統必須符合的事務，而且符合某些需求決定了項目的成功或失敗，因此找出需求是什么，將它們記下來，進行組織，并在發生變化時對它們進行追蹤，這些活動都是有意義的。

換句話說，需求管理就是： 

一種獲取、組織并記錄系統需求的系統化方案，以及一個使客戶與項目團隊對不斷變更的系統需求達成并保持一致的過程。 
這個定義與 Dorfman 與 Thayer 以及 IEEE 的“軟件需求工程”的定義相似。需求工程包括獲取、分析、規定、驗證和管理軟件需求，而“軟件需求管理”則是對所有相關活動的規劃和控制[4]。這里介紹的以及 Rational Software 提出的需求管理定義包括了所有這些活動。它們的區別主要在于這里選用了“管理”這個詞，而不是“工程”。管理這個詞更合適用來描述所有涉及到的活動，并且它準確地強調了追蹤變更以保持涉眾與項目團隊之間共識的重要性。

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

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

圖 1 - 常見的需求問題

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

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

需求管理技巧
為了解決上述問題，Rational 鼓勵對關鍵技巧的開發。下面將要介紹的這些技巧是按順序給出的，但在有效的需求管理流程中，它們以不同的順序連續應用。在此，它們將以新項目在第一次迭代時可能使用的順序出現。

圖 2 - 問題分析步驟

關鍵技巧 1：分析問題
進行問題分析是為了理解業務問題，確定涉眾的最初需要，并提出高層解決方案。這些推理和分析行為找出“隱藏在問題背后的問題”。

在問題分析過程中，將對實際問題的說明取得一致，并確定有關的涉眾。初始解決方案的界限和約束從技術和業務兩個方面來定義。在適當的時候，項目的商業理由還分析期望從系統獲得的投資回報。

關鍵技巧 2：理解涉眾需要
需求有許多來源。它們可能來自于對項目結果感興趣的任何人�？蛻�、合作伙伴、最終用戶以及領域專家都是某些需求的來源。而管理人員、項目團隊成員、業務策略和管理機構是另外一些需求源。

因此，掌握如何確定哪些人員應該是需求源、如何獲得這些需求源以及如何從中獲取信息是很重要的。作為提供這些信息主要來源的個人在本項目中稱為“涉眾”。

如果您正在開發一個在您公司內部使用的信息系統，那么在開發團隊中應包括具有最終用戶經驗和業務領域專業知識的人員。討論一般從業務模型一級開始，而不從系統一級開始。如果正在開發一個要在市場上出售的產品，那么您可以充分調動營銷人員，以便更好地了解該市場中用戶的需要。

獲取需求的手段包括訪談、集體討論、概念原型設計、問卷調查和競爭性分析等。需求獲取的結果可能是一份圖文并茂的請求或需要列表，并按相互之間的優先級列出。

關鍵技巧 3：定義系統
定義系統指的是解釋涉眾需求，并整理為對要構建系統的意義明確的說明。在系統定義初期，需要決定需求的構成、文檔格式、語言規范、需求等級、請求優先級和預計工作量、技術和管理風險以及系統規模等。系統定義活動還可包括與最關鍵的涉眾請求直接聯系的初期原型和設計模型。

我們使用了“說明”這個詞而沒有用“文檔”，是為了避免在后者常見的使用中發現的固有缺陷。說明可以是書面文檔、電子文件、圖像或用于表達除系統本身以外的系統需求的任何表示方式。

系統定義的結果是用自然語言和圖解方式表達的系統說明。后面幾節將介紹推薦使用的一些說明格式。

原則 55：在編寫比較正式的模型前，先使用自然語言進行編寫 在第一次編寫正式模型時，往往要用自然語言描述模型，而不是直接得到解決方案系統。請考慮以下示例： 要打長途電話時，用戶應該拿起電話。系統將回應撥號音。用戶撥打號碼“9”，系統回應一種特殊的撥號音... 系統有四種狀態：空閑、撥號音、特殊撥號音和連接狀態。要使系統從空閑狀態轉向撥號音狀態，請拿起電話。要從撥號音狀態轉到特殊撥號音狀態，請撥號碼“9”。 注意在后一個例子中，文字未起任何幫助讀者理解的作用。 - Alan M. Davis, 201 Principles of Software Development, 1995

關鍵技巧 4：管理系統規模
項目規模由分配給它的需求集定義。管理項目規模，使之適合可用資源（時間、人力和資金），是成功管理項目的關鍵。管理規模是一個持續不斷的活動，需要迭代式和遞增式開發，這就將項目細分為更易于管理的若干個小部分。

使用需求屬性（如優先級、工作量和風險）作為協商應包含需求的基礎，對管理規模而言是相當有用的技巧。側重于屬性，而不是需求自身，將減少通常對敏感問題的爭論。

這也有助于培養小組負責人的談判技巧，還有助于在項目中為組織培養推介人，對于客戶而言也是如此。產品/項目推介人應能夠代表組織拒絕那些超出可用資源的規模變更，也應有相應能力擴展資源以適應擴大的規模。

關鍵技巧 5：改進系統定義
對高層系統定義達成一致并充分理解了系統初始規模后，投入資源改進系統定義不僅有可能，而且也是經濟的。改進系統定義包括兩個重要的考慮事項：制定更詳細的高層系統說明和驗證系統是否符合涉眾需要，是否按說明運行。

說明通常是項目團隊的重要參考材料。在制定說明時一定要考慮受眾。人們常會犯一個錯誤，那就是用復雜定義表示構建起來很復雜的東西，尤其是在受眾無法或不愿意耗費精力去思考某些重要的需要取得一致認識時候。這就難以向項目團隊內外的人員解釋系統目的。相反，你可能會發現需要為不同的受眾編制不同類型的說明。本文介紹了詳細自然語言、正式文字和圖解說明推薦使用的格式。確定說明格式后，改進將持續貫穿整個項目生命周期。

關鍵技巧 6：管理變更的需求
不管您多么認真地定義需求，需求終將改變。實際上，一些變更是非常值得的！這意味著您的團隊需要與涉眾保持密切聯系。能否適應變更需求是評測團隊的涉眾敏感度和運作靈活性的一個尺度 - 敏感度和靈活性都是對項目成功有貢獻的團隊特征。變更不是敵人，而沒有管理的變更才是真正的敵人。

圖 3 - 變更管理流程

需求變更表明多少需要耗費一些時間來實施某個特定的功能，而且對一個需求的變更對其他需求可能有影響。管理需求變更包括這樣一些活動：設立基線、追蹤每個需求的歷史、確定哪些依賴關系值得追蹤、在相關項之間建立可追蹤關系以及維護版本控制等。如圖 3 所示，建立變更控制或批準流程也很重要，它要求由指定的團隊成員來復審所有提議的變更。有時候這一單一的變更控制渠道稱為變更控制委員會 (CCB)。

重要的需求概念

為了在項目中運用需求管理技巧，參與項目的每個人理解某些基本的需求管理概念是很有裨益的。這些功能包括： 

* 需求類型 
* 功能交叉的團隊 
* 可追蹤性 
* 多維屬性 
* 變更歷史 
* 需求類型

系統越大越復雜，出現的需求類型就越多。一個需求類型不過是指需求的一個類。通過確定需求類型，團隊可以把大量需求組織成意義明確且更容易管理的組。在一個項目中建立不同類型的需求有助于團隊成員對變更請求進行分類，并使相互之間的溝通更為清楚明確。

通常，一類需求可以細分即分解成其他類型的需求。業務規則和前景聲明包括高層次的需求，團隊可以從中導出用戶需要、特性和產品需求類型。用例和其他建模形式驅動設計需求，該需求可分解為軟件需求，并可以用分析設計模型來說明。測試需求源于軟件需求，它被分解為具體的測試過程。如果既定項目中有成百上千個，甚至上萬個需求實例時，對需求進行分類可以使項目更容易管理。

功能交叉的團隊
與諸如測試或應用程序建模等流程不同（這些流程可在單個業務組中進行管理），需求管理涉及了每一個能夠為開發流程提供專門技術的個人。其中應包括那些代表客戶和業務預期的人。開發經理、產品經理、分析員、系統工程師甚至客戶都應該參與進來。需求團隊還應包括創建系統解決方案的人 - 工程師、構架設計師、設計員、程序員、技術文檔編寫員以及其他提供技術支持的個人。測試員和其他質量保證人員應當作重要的團隊成員。

圖 4 - 功能交叉的需求團隊

通常，創造和維護需求類型的職責可按照功能范圍來分配，從而進一步優化大型項目的管理。需求管理的功能交叉性質是這門學科非常具有挑戰性的一個方面。

可追蹤性
如需求類型說明所述，沒有一個需求表述是孤立存在的。涉眾請求與提議用于滿足這些請求的產品特性有關。產品特性與指定特性的功能性和非功能性行為的各個需求相關。測試案例與它們檢驗和驗證的需求相關。有一些需求可能依賴于其他需求，也可能相互排斥。團隊為了確定變更帶來的影響，保證系統符合預期，就必須理解、記錄并維護這些可追蹤性關系。盡管可追蹤性是需求管理中最難實施的概念之一，但它是適應變更所必不可少的。建立明確的需求類型，吸收功能交叉人員的參與，可使可追蹤性更容易實施和維護。要了解需求可追蹤性策略的更多信息，請參見白皮書“通過用例進行需求管理的可追蹤性策略” [5]。

圖 5 - 需求可追蹤性

多維屬性
每一個需求類型都有屬性，每一個獨立需求都有不同的屬性值。例如，可為需求分配優先級，確定其來源和原理，委派給某個職能范圍內的特定子團隊進行管理，指定一定的難度，或者與系統的某個迭代關聯關系起來。圖 6 對此作了說明，該圖顯示了 Rational RequisitePro 需求管理工具中 Learning Project 的一個特性需求類型的屬性。正如屏幕的標題所暗示，需求類型和每種類型的屬性是為整個項目定義的，由此確保了團隊上下使用的一致性。

圖 6 - 定義特性的需求屬性

圖 7 顯示了 RequisitePro 中某個項目的特性需求實例。注意，即使未完整地顯示每個需求，但我們從屬性值即可了解每個需求的很多內容。在這個例子中，需求的優先級和難度 - 毫無疑問是由團隊的不同成員指定的 - 有助于團隊兼顧考慮涉眾優先級，以及對難度屬性值所反映工作量的大致估計，把項目規模限制在可用資源和時間的合理范圍內。在更詳細的需求類型中，優先級工作量屬性可能有更多的具體值（如預計時間、代碼行等），從而進一步改進規模。需求的多維性以及不同類型的需求（每種類型都有自己的屬性）對于組織大量需求和管理項目的整體規模來說是不可或缺的。

圖 7 - 設置各個需求的屬性值

變更歷史
單個需求和需求集合都有歷史記錄，并且內容隨著時間的推移而更具有含義。變更在所難免，而且變更有助于與環境變化和技術發展保持同步。記錄項目需求版本有助于團隊領導人找出變更項目的原因，如新的系統發布等。需求集合可能與某一個軟件版本相關，理解這一點有助于人們擴大對變更的管理，降低風險，提高實現重大里程碑的幾率。隨著單個需求發展，理解它們的變更歷史是很重要的：變更內容、起因、時間和誰授權變更等。

將需求管理付諸實踐
需求管理采用上面介紹的關鍵技巧和概念成功地識別并解決問題。

為了建立一個真正滿足客戶需求的系統，項目團隊首先必須確定系統要解決的問題。然后，團隊必須確定涉眾，從中獲得業務和用戶需要，對其進行描述，并區分它們的優先級。從這一組高層期望或需求出發，對產品或系統特性集達成一致意見。

詳細的軟件需求應該以客戶和開發團隊都能理解的形式寫下來。我們發現，使用客戶的語言來描述這些軟件需求在取得理解和共識的過程中是最有效的。這些詳細的軟件需求隨后用作系統設計規約的輸入，或者作為實施和驗證所需的測試計劃及過程的輸入。軟件需求還應該促進初始用戶文檔規劃及設計。

圖 8 - 需求管理結構概述

為了推動需求管理，項目團隊應該： 

對項目的常用詞匯表取得一致。 
制定系統前景，描述系統將要解決的問題以及系統的主要特性。 
至少獲得五個重要領域的涉眾需要：功能、可用性、可靠性、性能和可支持性。 
決定使用哪些需求類型。 
為每一個需求類型選擇屬性及屬性值。 
選擇需求的說明格式。 
確定創造一種或多種需求類型的團隊成員，以及那些對此有貢獻或僅僅進行查看的團隊成員。 
決定所需的可追蹤性。 
制定變更需求需遵守的提議、復審、決議程序。 
開發一個追蹤需求歷史的機制。 
為團隊成員和管理人員創建進度和狀態報告。 
這些必要的需求管理活動與行業、開發方法和需求工具無關。它們同時也很靈活，能夠在最嚴格、變化速度最快的應用軟件開發環境下執行有效的需求管理。

文檔簡介 用文檔來描述需求的決定值得認真考慮。一方面，書面記錄是人們廣泛接受的一種交流形式，對大部分人來說，這是自然不過的了。另一方面，項目的目標在于產生系統，而不是文檔。 常識和經驗告訴我們，問題不在于是不是要記錄需求，而是怎么記錄。文檔模板為需求管理提供了一種統一的格式。Rational RequisitePro 不僅提供這些模板，還提供其他特性，將文檔內的需求鏈接到一個包含所有項目需求的數據庫。這種獨一無二的特性不僅允許需求自然地記錄下來，同時還能存放在關系型數據庫里，便于訪問和管理。

需求管理：工作流程明細
根據領域的不同，需求管理可遵循的方案有無限多種。下面的方案給出了六個詳細的工作流程，它們適用于每一個關鍵的需求管理技巧，但也可以應用到任何領域。

下面的工作流程圖摘自 Rational Unified Process [6]，需求工作流程明細。這些工作流程用角色、活動和工件（輸入或輸出）表示，圖 9 的活動圖對它們進行了概括。旁邊的文字簡單描述了每個工作流程，希望藉此增進讀者對改進需求管理流程的理解和興趣。關于 Rational Unified Process 的更多信息，可參考 www.rational.com。

　

圖 9 - Rational Unified Process 中的需求工作流程

工作流程明細：分析問題
在問題分析中，主要的活動是制定項目前景。此活動的結果是產生了一個前景文檔，它確定了待建系統的高級用戶或客戶視圖。前景文檔將初始需求作為關鍵特性表述，這些特性是系統為了解決重大問題并滿足關鍵涉眾需要而必須具備的。系統分析員在此工作流程中扮演主要角色。系統分析員應該具有問題分析領域的專業知識，對問題有一定的理解，還應該能描述其認為可以解決問題的流程。此階段要求各個項目涉眾積極參與，還應該考慮所有相關的涉眾請求。

要開始管理依賴關系活動，應該為職責分配屬性，如基本原理、相對值或優先級以及請求的來源等。隨著前景的發展，分析員確定可能用例的用戶和系統（主角）。主角是用例模型的首要要素，它們將定義系統的功能性和非功能性技術需求。

圖 10 - 分析問題

工作流程明細：分析問題
啟動：一個或多個認識到問題存在的涉眾啟動工作流程。

開發團隊中的系統分析員可以和這幾個最初的涉眾展開會話，幫助他們描述需要解決的問題。對所認識問題的簡要說明達成一致意見是很重要的。下表列出了問題說明的關鍵元素：

問題           確定問題 
對涉眾影響     列出受問題影響的涉眾 
問題的影響     描述問題的影響 
成功的解決方案 列出成功解決方案的一些主要優點 

問題說明簡明扼要解釋了項目的目的。問題分析員深入調查所有涉眾請求和初始商業理由，包括顯著優點以及大致估計的成本等。在定義問題說明的同時，團隊還應該編寫詞匯表，記錄常用術語并統一其定義。

用例模型簡介 用例模型包括主角、用例以及它們之間的關系。主角代表了必須與系統交換信息的所有事物，包括通常所謂的用戶。當主角使用系統的時候，系統執行一個用例。好的用例是一個事務序列，該序列為主角提供一個可評測的價值結果。用例集合是系統的完整功能。 Jacobson I., Christerson M., Jonsson P., Overgaard G., Object-Oriented Software Engineering - A Use Case Driven Approach, Addison Wesley - ACM Press, 1992

問題分析員還確定系統的主要主角。主角是系統的用戶或者將與之交換信息的其他任何系統。在這一階段，問題分析員應該簡單確定主角與系統交互的一些顯而易見的方式。說明應面向業務流程而非系統行為。例如，預算程序可能會允許一個類型的主角“制定部門預算”，而其他類型的主角可以“合并部門預算”。系統分析員以后可以將它們用到其他用例中，這些用例與特定系統行為結合起來更有意義。例如，“制定部門預算”可以產生像“導入電子表格信息”以及“創建預算視圖”等系統用例。

上述問題分析會話通常進行不止一次，會話對象可能是不同的涉眾，并且中間還夾帶開發團隊的內部會話。與涉眾打交道的系統分析員將主持一次與開發團隊成員的會話，展望問題的技術解決方案，從初始涉眾輸入中導出特性，并起草前景說明，即待建系統的第一個定義。為了方便初始涉眾理解提議的解決方案，系統分析員可以利用建模工具或手工繪圖技術來完善前景說明。

要從多方面向初始涉眾咨詢，以幫助改進問題說明，限制可能解決方案的個數和規模。涉眾和系統分析員就關鍵特性的優先級進行談判，對資源及開發資源所需的工作量取得一般性的理解，藉此來管理該工作流程中的依賴關系。盡管優先級和工作量/資源的估計不可避免會發生變化，但提早管理依賴關系可建立起一個在整個開發生命周期中一直延續使用的重要模式。這是規模管理的本質所在，是一個項目成功的早期預報器。

在經過幾次草案更新后，前景文檔進入團隊必須決定是否對額外需求獲取進行投資的階段。同時，商業理由的批準過程也分別開始啟動了。本文不打算深入探討商業理由，只對其進行簡單說明。商業理由描述： 

1 環境（產品領域、市場和規模）， 
2 技術方案， 
3 管理方案（時間安排、風險、對成功的客觀評測方法）， 
4 以及財政預測。 

工作流程明細：理解涉眾需要
如果初始問題分析證明增加投資是合理的，則鄭重開始理解涉眾需要工作流程。這一階段的關鍵活動是獲取涉眾請求。主要結果是收集確定優先級的涉眾需要和特性，利用此結果可改進前景文檔，加深對需求屬性的理解。另外，在這個工作流程中，您可以根據用例和主角對系統展開討論。另一個重要輸出結果是經過更新的詞匯表，它使團隊成員對常用詞匯有一致的理解。

工作流程明細：理解涉眾需要
系統分析員和關鍵涉眾通過訪談、專題討論會、示意板、業務流程用例和其他手段，確定更多的涉眾，獲取他們的請求，確定關鍵需要和特性。這些會話由一個或多個系統分析員主持進行。需求專題討論會是最有用的需求獲取手段。該流程包括用戶、幫助臺人員、企業主、測試員以及其他對提議項目的結果有利害關系的個人。涉眾請求通常是不明確、重疊甚至是離譜的。除正式的獲得結果外，涉眾請求還可以用格式設計很好的文檔、數據庫的缺陷和擴展請求或者電子郵件和群件線程等形式表達。系統分析員記錄已確定的關鍵涉眾需要，對其進行分類和區分優先次序。

理解涉眾需要：“取悅客戶”從何處開始 涉眾請求要盡可能在請求涉眾使用的語言和格式中獲取。與后繼的需求類型（通常由具有豐富流程知識和技術的項目團隊成員創造）不同，涉眾請求通常很難表達清楚。涉眾請求經常交叉或重復。而且涉眾請求的表達形式多種多樣，從紙條到擴展請求數據庫等等都有。 分析員（或代表分析員角色的團隊）必須復審所有需求，對其進行解釋、分類，甚至還要重新錄入（不重寫），在前景文檔中將其翻譯成關鍵涉眾需要及系統特性。根據開發的嚴格程度以及工具的可用性，可應用一部分或所有涉眾請求、需要與特性之間的可追蹤性，幫助涉眾理解在決定系統需求時如何解釋清楚他們的請求和需要。 通過應用理解涉眾需要工作流程，說明獲取請求和滿足涉眾需要的非常重要事項，對建立涉眾對開發團隊能力的信心而言具有重大意義。

對涉眾需要有了更好的理解之后，開發團隊里的系統分析員改進前景文檔，將主要精力放在制定“產品定位說明”上。該說明用簡潔的兩三句話確立項目的顯著價值。說明應包括預期用戶、項目解決的問題、所帶來的利益，以及它所取代的競爭者。所有的團隊成員都應該理解該項目的主題。系統分析員還更新詞匯表，促進團隊對術語的共同理解。

從多方面向關鍵涉眾咨詢，以便對從理解涉眾需要得到的新特性的優先級進行協商，獲得對當前開發新特性所需資源和工作量的理解。利用問題分析，在該工作流程中管理依賴關系有助于管理項目的規模。它還建立起涉眾請求、需要與系統特性之間的可追蹤性，讓涉眾相信他們的建議確實得到考慮。

工作流程明細：定義系統
最初的兩個需求工作流程明細（分析問題和理解涉眾需要）創建了關鍵系統定義的早期迭代（包括前景文檔指定的特性）、用例模型的第一個大綱，以及初始需求屬性。下一個工作流程明細即定義系統，通過改進特性定義，添加新主角、用例和補充規約，完善了高級系統需求說明。

圖 12 - 定義系統

工作流程明細：定義系統
更新詞匯表是為了反映當前對術語的理解，這些術語用于描述在用例模型及補充規約中捕獲的特性和需求。

系統分析員使用在改進的前景文檔中定義的特性集來派生用例并以說明，這些用例詳細闡述用戶對系統預期行為的觀點。用例模型作為客戶、用戶和系統開發人員之間的合同，規定了所選特性如何在系統中發揮作用。它有助于系統開發人員設置符合現實的期望和目標，幫助客戶和用戶驗證系統是否達到了這些期望。

一些系統需求沒有很好地符合用例。系統分析員就在補充規約里說明這些需求。許多非功能性需求，如可用性、可靠性、性能、可支持性等，都放在補充規約中。應該注意，這些類型的許多非功能性需求專門針對單個用例。用例闡釋者最好將這些需求放在用例規約本身（請參見改進系統工作流程），在補充規約里描述系統范圍的非功能性需求。

在該工作流程明細中，系統分析員創建和設置了補充需求的屬性（如優先級和相關用例）。除此之外，系統分析員還為初始用例和新用例添加并更新屬性值。

最后，系統分析員通過追蹤重要用戶需要和關鍵特性到相關用例以及補充規約說明的需求，以此來管理依賴關系。

工作流程明細：管理系統規模
在確定特性級別的需求，描述大多數主角、用例以及補充規約所指定的其他需求后，系統分析員應該收集需求屬性（如優先級、工作量、成本和風險等），并盡可能精確地為其指定屬性值。這使得人們對如何確定系統發布的初始規模有了更好的理解，也讓構架設計師能夠從結構上確定具有重要意義的用例。

由項目和開發管理人員一起制定的迭代計劃，首次出現在該工作流程明細：管理系統規模中。迭代計劃也是一個開發計劃，它定義為發布版計劃的迭代次數和頻率。早期的迭代應計劃規模內風險最高的元素。

管理規模工作流程的其他重要輸出包括軟件構架文檔的初始迭代和一個修訂過的前景文檔，前景文檔反映分析員和關鍵涉眾對系統功能和項目資源的加深理解。

與前面提到的商業理由一樣，迭代計劃的第一個問題是，軟件構架文檔不是需求管理工作流程的一個工件，盡管它與該工作流程有關而且是 Rational Unified Process 的一部分。這部分內容不在本文的討論范圍內。


經驗告訴我們，成功管理規模的關鍵在于，仔細考慮分配給涉眾需要、特性、用例和補充規約所指定的其他需求的屬性值，與代表性涉眾定期進行開放而誠懇的交流。

圖 13 - 管理系統規模

工作流程明細：管理系統規模
構架設計師為用例的風險范圍、構架重要性和構架覆蓋范圍確定優先順序。盡管定義系統時用到了許多用例和補充規約需求，但通常只有用例的一個子集才是好的系統構架的關鍵。確定用例的優先級后，構架設計師改進迭代或開發計劃，利用 Rational Rose 這類工具建立系統構架的用例視圖模型。

系統分析員通過改進前景中特性的需求屬性來管理依賴關系。他們還對用例和補充規約里的需求進行改進。系統分析員確保涉眾需要、特性、用例需求和補充規約需求存在適當的可追蹤性。這里特意使用了“適當的可追蹤性”。請參見本文中插入的關于可追蹤性的說明文字。

在整個項目中，該步驟是最為重要的步驟之一。第一次，我們對所提議的系統了解如此之深，使得我們能對需求、項目資源和交付日期作出重大承諾。同時也必須理解，這些需求將會隨著了解程度的加深而變更。如果在前三個工作流程對依賴關系進行管理，則執行這一步驟就會容易得多，將來進行變更也更容易。

貫穿項目的整個生命周期，隨著形勢和環境的變化，由于系統分析員必須就修改后的項目規模和前景與關鍵涉眾進行協商，因此將會多次重新檢查該工作流程明細。涉眾和開發團隊成員只有把該步驟看作一個自然前進過程 - 既不要讓用戶措手不及，也不要企圖向組織索要更多時間和金錢 - 才能成功管理項目規模，使之與可用資源相符合。該工作流程在項目的主要里程碑處需重復多次，以便評估對系統及系統問題的新認識是否要求變更規模。盡管已承諾的需求、預算和期限很難更改，但隨著對確定優先級的用例、補充規約和早期系統迭代的深入理解，不可避免會導致人們重新考慮系統規模。

需要重申，在到達改進階段之前，以及在貫穿項目生命周期內發生變化前，項目團隊應維持日常的規模管理，這一點很關鍵。涉眾代表必須理解并相信，在難度不斷增加的規模協商中，他們的優先考慮和利益始終得到認真的對待。在改進系統需求之前，只有重要的需求才有待于協商或修改。除非建立有效的規模管理制度，否則項目注定會變成一次“死亡之旅” - 規模過大的項目將殘酷地走向延期和成本超支的絕路。

工作流程明細：改進系統定義
進入改進系統定義后，該工作流程明細假設已經概述了系統級別的用例并至少簡要描述了主角。通過項目規模管理，前景中的特性再次確定了優先順序，現在可以相信，這些特性在比較嚴格的預算和期限下是可以實現的。該工作流程的輸出是對系統功能更深入的理解，這些系統功能在詳細用例、已修訂的補充規約以及系統本身的初期迭代中進行說明。

顯然，不是所有的系統都有用戶界面，不是所有的初期迭代都包括 GUI 元素。這里我們僅僅將它們作為初期迭代的示例。其他例子包括原型、模型和示意板。

圖 14 - 改進系統定義

工作流程明細：改進系統定義
用例闡釋者詳述每個用例的事件流定義、前置和后置條件以及其他文本屬性。為最大限度地減少工作量并提高可讀性，建議使用標準文檔格式或用例規約模板來記錄每個用例的文字信息。創建考慮周全的用例規約對系統質量至關重要。制定規約要求對涉眾需要以及與用例相關的特性有透徹的理解。讓項目團隊的若干成員（如軟件工程師）參與用例創建是再好不過了。

同時，用例闡釋者使用并非用例特有的附加需求對補充規約進行修訂。

用戶界面設計員模擬系統的用戶界面并進行原型設計。這項工作與用例的演進密切相關。

對每個需求有更深入的理解后，用例闡釋者和系統分析員對其工作量、成本、風險以及其他屬性值進行修正。

系統定義改進流程的結果提交給另一輪管理規模工作流程明細。對系統有更多的了解后，可能需要改變優先級。毫無疑問，如果必要，系統發布的規模將需要復審和改進。

工作流程明細：管理需求變更
當變更發生時 -- 變更是不可避免會發生的 -- 管理需求變更工作流程明細需持續應用于項目生命的全過程，這與管理系統規模工作流程明細一樣。該工作流程的輸出可能導致對每個工件的修改，這又要求在所有的項目團隊成員和涉眾之間進行有效的交流。

在這個工作流程中，我們引入了受需求工作流程影響的其他工件。需求的變更必然影響在分析設計工作流程中表示的系統模型。需求變更還影響用于驗證需求是否正確實施的測試。在前面的例子中，這些工件是 Rational Unified Process 的組成部分，但不是本文論述的主題。在管理依賴關系流程中確定的可追蹤性關系是理解這些影響的關鍵。

可追蹤性
在需求領域，與可追蹤性有關的事務有很多。許多事務都具有追蹤單個客戶需求到每個相關規約、測試、模型元素以及最終源碼文件的特點。的確，一些可追蹤性是成功的需求變更管理的關鍵。

然而，這里事先警告，在項目的整個生命周期中，建立和維護各種形式的可追蹤性都需要投資。像所有的投資一樣，可追蹤性的投資回報點逐漸減少，這取決于具體情況。本文強調在不同需求類型之間進行追蹤的價值。這是一個很好的起點，而且可以用 Rational RequisitePro、Rose、SoDA 和 TeamTest 這樣的工具使之自動化。我們相信，你終將發現某個級別的需求可追蹤性是好的投資對象。 

要了解需求可追蹤性策略的更多信息，請參見白皮書“通過用例進行需求管理的可追蹤性策略” [6]。


管理需求變更工作流程的另一個重要概念是需求歷史追蹤。通過把握需求變更的性質和基本原理，復審員（工作受變更影響的任何軟件項目團隊成員）將收到對變更作出正確響應所需的信息。

圖 15 - 管理需求變更

工作流程明細：管理需求變更
出于各種原因，任何涉眾或項目團隊成員都有可能提出變更需求的請求。所有變更請求 (Cr)，包括對需求或擴展請求甚至缺陷的變更，都應該通過同一個變更請求管理 (CRM) 流程進行疏導。至少，這應包括在一個集中數據庫系統中記錄并追蹤請求，并由中央復審委員會執行復審。CRM 流程的詳情見 Rational Unified Process 的其他小節。

系統分析員應該協調最好由變更控制委員會 (CCB) 執行的復審活動，收集并檢查所有的變更請求，并將它們分類為： 

實施中不影響需求的缺陷， 對現有的某類型需求的修改，或者 擴展修改。 
分類后，按在其他需求工作流程中描述的方法為所提出的需求變更指定屬性和值。

在復審變更請求的時候，系統分析員向一個由涉眾代表和項目團隊成員組成的 CCB 陳述確定優先順序的需求變更。超過資源限制的規模修改請求被拒絕，或者將其上交給涉眾代表，涉眾代表有權批準對日期以及預算事項的必需變更。

CCB 批準或拒絕需求變更。

系統分析員把需求變更傳達給需求闡釋者，或直接修改前景、用例、補充規約文檔或其他需求工件中的需求。

需求復審員（開發人員、測試員、經理及其他團隊成員）通過審查需求歷史，對需求變更對他們的工作造成的影響進行評估。最后，他們實施變更，對他們有權修改的相關需求作適當改動。

總結
管理需求的需要并不新鮮。那么，究竟是什么值得我們去思考呢？ 

首先，如果項目常常不能滿足客戶、錯過最后期限和預算超支，就有理由重新考慮開發方案了。在設計方案時，如果您確信與需求相關的問題正在消耗你的開發工作，就有理由考慮改進需求管理了。

其次，本文總結的需求管理方案體現了幾千個案例的集體經驗和智慧，而且代表了許多個人深思熟慮的觀點，他們在需求管理領域與客戶合作已有數年時間。我們認為，他們的貢獻 - 以及 Rational Unified Process 對這些貢獻所作的透徹陳述 - 總結起來代表了需求管理的“最佳方案”。你將發現這些需求建議是最可靠的。

作者向 Dr. Ivar Jacobson 對本文的直接和間接貢獻，以及 Dean Leffingwell、Dr. Alan Davis、Ed Yourdon 和 Elemer Magaziner等人的幫助表示感謝。尤其，我們要感謝 Rational Software 的客戶，他們在數以百計開發項目中應用和改進了這些方案。

最后，在過去的兩年內，生產有效軟件開發解決方案的領先公司 Rational Software 接受需求管理的挑戰，生產了多種工具來使執行這一艱巨任務實現自動化。長期、普遍存在的需求管理問題得到了解決。也許這最終才是今天在需求管理領域開始追求卓越的最佳原因。

關于上述概念的完整論述，請參考 Dean Leffingwell 的關于軟件需求管理的優秀著作[7]。 

參考資料
[1] CHAOS, The Standish Group International, Inc., Dennis, MA, 1994, 1997.

[2] Computer Industry Daily, December 12, 1997.

[3] Dorfman, M. and R. Thayer, Software Engineering, IEEE Computer Society Press,
Los Alamitos, CA, 1997 pp.79.

[4] Dorfman, M. and R. Thayer, Software Engineering, IEEE Computer Society Press,
Los Alamitos, CA, 1997 pp.80.

[5] Spence, Ian and Leslee Probasco, “通過用例進行需求管理的可追蹤性策略”, 白皮書, Rational Software Corporation, 1998.

[6] Rational Unified Process™, Rational Software Corporation, Cupertino, CA, 1999.

[7] Leffingwell, Dean and Don Widrig, Managing Software Requirements - A Unified Approach, Addison-Wesley, 2000.

文章來源于領測軟件測試網 http://www.kjueaiud.com/