軟件需求管理部分完整版課件

需求開發(fā)面臨的特殊難題需求開發(fā)：是針對一個新軟件或系統(tǒng)開發(fā)項目的情況，這種項目有時也稱為零起點項目(green-fieldproject)。大多數(shù)組織的主要精力集中于維護現(xiàn)存的遺留系統(tǒng)，或者為已有的商業(yè)產(chǎn)品構(gòu)建新的版本；其他組織也很少是從零開始構(gòu)建一個新系統(tǒng)，而是對商用現(xiàn)貨產(chǎn)品進行集成、定制和擴充，以滿足自己的需要。1需求開發(fā)面臨的特殊難題需求開發(fā)：是針對一個新軟件或系統(tǒng)開發(fā)項開始捕獲信息缺少精確的需求文檔，那么維護人員就必須進行逆向工程，通過代碼來理解系統(tǒng)，將此看作是軟件考古學(softwarearchaeology)。構(gòu)建一個包含當前系統(tǒng)部分的需求表示可達到以下3個有用的目標：消除知識鴻溝，使將來的維護人員能更好地理解所做的變更。收集當前系統(tǒng)的一些信息——當前系統(tǒng)在以前缺乏良好的書面文檔。提供一個指標，表明當前的系統(tǒng)測試集對系統(tǒng)功能的覆蓋率。開始捕獲信息缺少精確的需求文檔，那么維護人員就必須進行逆向工2定義質(zhì)量需求軟件的質(zhì)量屬性和性能目標是選擇解決方案時所要考慮的用戶需求的另一個方面。我們至少要研究下面幾個屬性：性能易使用性靈活性互操作性完整性定義質(zhì)量需求軟件的質(zhì)量屬性和性能目標是選擇解決方案時所要考慮3盡早地而且要經(jīng)常地設定優(yōu)先級客戶和開發(fā)人員協(xié)同工作，共同選定功能實現(xiàn)的順序，這樣增量開發(fā)才會取得成功。開發(fā)團隊的目標是，將可用的功能和對質(zhì)量的改進有規(guī)律地交到用戶手中，因此，開發(fā)人員必須了解每次增量開發(fā)計劃實現(xiàn)哪些功能。盡早地而且要經(jīng)常地設定優(yōu)先級客戶和開發(fā)人員協(xié)同工作，共同選定4設定需求優(yōu)先級每一個受資源限制的軟件項目都必須對要求的產(chǎn)品功能定義相對優(yōu)先級。設定優(yōu)先級有助于項目經(jīng)理解決沖突、安排階段性交付，并且做出必要的取舍。討論設定需求優(yōu)先級的重要性，提出一個簡單的優(yōu)先級劃分方案，并介紹更嚴格的基于價值、成本和風險的優(yōu)先級分析方案。5設定需求優(yōu)先級每一個受資源限制的軟件項目都必須對要求的產(chǎn)品功需求和進度安排注意： 不要迫于壓力而許下自己明知道不可能做到的諾言，這是避免最后兩敗俱傷的秘訣。需求和進度安排注意： 6需求管理需求管理7需求管理的原則和實踐需求管理包括在項目開發(fā)過程中維護需求約定的完整性、準確性以及保持需求約定是最新約定的所有活動，如圖所示。8需求管理的原則和實踐8軟件需求管理部分完整版課件9軟件需求管理需求管理所要完成的任務需求管理模型管理變更需求風險管理需求跟蹤需求管理工具軟件需求管理需求管理所要完成的任務10需求管理所要完成的任務

需求管理的首要任務在于使開發(fā)人員和用戶雙方對于需求都有一個明確的認識。需求模型實際是最終產(chǎn)品的抽象化表現(xiàn)。用戶需求的滿足程度是衡量設計優(yōu)劣的標準。優(yōu)秀的需求分析應當非常精確細致地對用戶需求作出描述，同時也應該最大程度地給予方案設計者充分發(fā)揮的余地。對開發(fā)項目進行任務劃分，將整體開發(fā)任務細化為多個子模塊，從而使這些子模塊能夠平行開發(fā)而無需太多的干預。需求管理在開發(fā)周期中是自始至終存在的。需求管理必須始終保持更新。需求管理同項目管理是密不可分的。需求管理所要完成的任務需求管理的首要任務在于使開發(fā)人員和用11需求管理的任務明確需求并達成共識；建立關聯(lián)，根據(jù)不同需求設計相應解決辦法；進行系統(tǒng)優(yōu)化，提出設計方案；監(jiān)控和解決可能出現(xiàn)的問題以及需要做出的改變；控制不同開發(fā)任務的開展；對最終產(chǎn)品做出評測；監(jiān)控可能出現(xiàn)的重復開發(fā)；提出項目實施時間表；確定最終用戶界面。需求管理的任務明確需求并達成共識；12里程碑與項目管理一項需求的滿足就意味著一塊里程碑的確立。里程碑構(gòu)造機制的基本方法之一就是進程管理。需求管理在開發(fā)周期中是自始至終存在的。需求管理必須始終保持更新，它構(gòu)成了技術管理的基礎。需求管理同項目管理是密不可分的。里程碑與項目管理一項需求的滿足就意味著一塊里程碑的確立。13需求管理模型

不同的需求組合起來，構(gòu)成了一套完整的需求模型。需求管理的一項重要工作就是在整個項目的不同任務之間建立聯(lián)系。需求管理包括在工程進展過程中維持需求約定集成性和精確性的所有活動。需求管理的關鍵過程領域。需求管理的步驟。需求管理模型不同的需求組合起來，構(gòu)成了一套完整的需求模型。14需求管理的主要活動控制對需求基線的變動。保持項目計劃與需求一致?？刂茊蝹€需求和需求文檔的版本情況。管理需求和聯(lián)系鏈之間的聯(lián)系或管理單個需求和其它項目可交付品之間的依賴關系。跟蹤基線中需求的狀態(tài)。需求管理的主要活動控制對需求基線的變動。15需求開發(fā)與需求管理的分界中程在線信息產(chǎn)業(yè)培訓網(wǎng)需求開發(fā)與需求管理的分界中程在線信息產(chǎn)業(yè)培訓網(wǎng)16需求基線管理為何需要：頻繁的需求變更會破壞開發(fā)的節(jié)奏，使整個項目開發(fā)的進度陷入混亂和失控的狀態(tài)，而且會變成一個“救火隊”式的工作，整天都在處理突發(fā)事件.主要思想：將所有現(xiàn)在的、將來的需求進行優(yōu)先級評估，然后分解成為不同的組，每次迭代都選擇其中優(yōu)先級最高的部分進行開發(fā)，然后在迭代完成之前，開發(fā)工作不響應變更，這些劃入的需求項就是需求基線的組

成部分需求基線管理為何需要：頻繁的需求變更會破壞開發(fā)的節(jié)奏，使整個17需求基線管理--操作思路我們應該在分析的基礎上，將需求整合成為用例或功能項，然后對其進行優(yōu)先級、依賴性進行綜合性評估優(yōu)先級判斷：業(yè)務人員確定業(yè)務決定，技術人員確定技術決策；“滿意度/不滿意度”模型依賴性是指對于某些功能，在實現(xiàn)上有必須的依賴關系，即當某些功能沒有實現(xiàn)時，另

外的功能無法開始，這就需要對其

進行調(diào)整需求基線管理--操作思路我們應該在分析的基礎上，將需求整合成18需求變更管理需求變更是一定存在的，而需求變更管理并不是指逃避它，更不是說要避免它，它實際上是希望控制變更在基線內(nèi)的需求不響應變更，為開發(fā)人員提供一個安靜的工作時間狀態(tài)專門的需求變更管理來對所有的需求變更進行響應，了解需求變更的關鍵意圖、新產(chǎn)生的工作量，從而良好地進行重新計劃，以便能夠有效地解決其對整個開發(fā)帶來的麻煩需求變更管理需求變更是一定存在的，而需求變更管理并不是指逃避19對待軟件項目管理的組織必須確保做到以下幾點：在提交提議的需求變更之前要對其進行仔細的評估。請合適的人員就需求變更做出周全合理的業(yè)務決策。將已批準的變更傳達給受此影響的所有人員。項目以一致的方式將需求變更包含進來。采用一致的變更控制方法，就可以避免相關問題，避免開發(fā)工作的返工和浪費時間等情況的發(fā)生。對待軟件項目管理的組織必須確保做到以下幾點：20變更控制委員會變更控制委員會，有時也稱為配置控制委員會(configurationcontrolboard，CCB)，已被證實是軟件開發(fā)領域公認的最佳實踐(McConnell1996)。CCB是由人組成的團體，可以由一個小組擔任，也可以由多個不同的小組擔任，這些人共同決定將哪些已提議的需求變更和新提議的特性在產(chǎn)品中付諸實現(xiàn)。CCB也決定所報告的缺陷中哪些需要糾正，什么時候糾正。CCB可以評審和批準對項目中任何基線工作產(chǎn)品所做的變更，項目需求文檔只是其中的一個樣例。變更控制委員會變更控制委員會，有時也稱為配置控制委員會(co21CCB的組成CCB的成員應該能代表需要參與制定決策的所有小組，當然這些決策制定只能是在CCB的權(quán)力范圍之內(nèi)?？煽紤]從下面這些部門中選擇CCB代表：項目或程序管理部門產(chǎn)品管理或需求分析部門開發(fā)部門測試或質(zhì)量保證部門市場或客戶代表編寫用戶文檔的部門技術支持或幫助部門配置管理部門CCB的組成CCB的成員應該能代表需要參與制定決策的所有小組22CCB規(guī)章CCB規(guī)章描述了CCB的目的、權(quán)力范圍、成員構(gòu)成、運作規(guī)程和決策的制定過程等(Sorensen1999)。CCB的權(quán)力范圍規(guī)定了哪些決策由CCB決定，哪些決策則必須上報給高一級CCB或者由管理層來決定。1.制定決策決策制定過程的描述應該確定：CCB成員或主要角色的人數(shù)，這是制定決策的法定人數(shù)。所采用的決策規(guī)則是投票、少數(shù)服從多數(shù)、協(xié)商決定或其他方法。CCB規(guī)章CCB規(guī)章描述了CCB的目的、權(quán)力范圍、成員構(gòu)成、23CCB規(guī)章CCB主席是否可以否決CCB的集體決策。級別高的CCB或其他人是否必須認可CCB做出的決策。2.交流狀態(tài)CCB做出決策之后，應該指派專人對變更數(shù)據(jù)庫中的變更請求狀態(tài)進行更新。3.重新協(xié)商原先的約定在接受一個重大的需求變更之前，為了適應這一變更，需要同管理部門和客戶重新協(xié)商原先的約定(Humphrey1997)。協(xié)商的內(nèi)容可能包括，要求推遲產(chǎn)品交付時間，要求增派人手，或者要求推遲實現(xiàn)尚未實現(xiàn)的優(yōu)先級較低的需求等。CCB規(guī)章CCB主席是否可以否決CCB的集體決策。24變更需要付出代價：影響分析對軟件實施大的功能增強，則需要進行影響分析(impactanalysis)。但是，即使是小的變更請求，也可能潛伏著難以預料的復雜性。影響分析是需求管理的一個關鍵方面(Arnold和Bohner1996)。通過對影響進行分析，可以準確地理解提議的變更所涉及到的問題，有助于項目團隊就批準哪些提議做出周全合理的業(yè)務決策。影響分析:通過對所提議的變更進行檢查，確定可能必須創(chuàng)建、修改或廢棄哪些部分，并估計與實現(xiàn)這些變更相關的工作量。變更需要付出代價：影響分析對軟件實施大的功能增強，則需要進行25影響分析的過程影響分析有3個方面：1.理解進行變更可能涉及的問題。變更常常會產(chǎn)生大量的連鎖反應，產(chǎn)品包括的功能太多會降低其性能，甚至會到令人難以接受的地步。2.確定如果團隊將提議的變更包括到產(chǎn)品中，可能必須對哪些文件、模型和文檔進行修改。3.確定實現(xiàn)變更所需執(zhí)行的任務，并估計完成這些任務所需的工作量。注意: 跳過影響分析并不能改變?nèi)蝿盏囊?guī)模，只會使規(guī)模令人感到驚奇，而軟件方面令人驚奇卻很少是好消息。影響分析的過程影響分析有3個方面：注意: 26影響分析報告模板圖是一個推薦的報告模板，表示對每個需求變更造成的潛在影響的分析結(jié)果。如果采用標準模板，CCB成員就可以輕松地找到他們所需的信息，作出合理的決策。影響分析報告模板圖是一個推薦的報告模板，表示對每個需求變更造27需求的變化是永恒的。因而，對于需求變更應該正確對待，盡量將其負面影響降低。需求變更可能來自解決方案提供商、客戶或產(chǎn)品供應商等外部因素，也可能來源于項目組內(nèi)部。變更都是有代價的，應該評估一下變更的代價及其對項目的影響。在需求變更發(fā)生之前盡量減少需求變更，以將需求變更帶來的風險降低到最低。切忌在項目設計之前試圖消除需求變更。需求的變化是永恒的。因而，對于需求變更應該正確對待，盡量將其28需求變更的原因因競爭、成本等因素，工期已經(jīng)確定且極不合理.用戶在需求期提不出需求、或用戶的需求不明確.項目組對業(yè)務不熟悉、或者沒有與用戶密切結(jié)合、需求分析工作不細致.項目組沒有很好地實施需求管理.需求變更的原因因競爭、成本等因素，工期已經(jīng)確定且極不合理.29需求變更的惡性循環(huán)需求變更的惡性循環(huán)30需求變更的因素需求變更的因素31需求變更的代價需求變更的代價32減少需求變更減少需求變更33需求變更的過程管理認識到變更不可避免，為變更制訂計劃。確認需求基線。建立控制變更的唯一渠道。使用變更控制系統(tǒng)來捕獲變更。分層次地管理變更。需求變更的過程管理認識到變更不可避免，為變更制訂計劃。34基于配置管理的需求管理避免需求在未授權(quán)情況下變更，或在有潛在破壞性的情況下不受限制地隨意變更。保護隊需求文檔的修正。方便對文檔以前版本的檢索或重建。支持系統(tǒng)以增量的方式改進基線。避免對文檔的同時更新和沖突?；谂渲霉芾淼男枨蠊芾肀苊庑枨笤谖词跈?quán)情況下變更，或在有潛在35基線管理需求基線(requirementbaseline)是團隊成員已經(jīng)承諾將在某一特定產(chǎn)品版本中實現(xiàn)的功能性和非功能性需求的一組集合?；€：已經(jīng)通過正式評審和批準的某規(guī)約或產(chǎn)品，它可以作為進一步開發(fā)的基礎，并且只能通過正式的變化控制過程的改變。[IEEE]基線是一個軟件配置管理的概念。在軟件工程的范圍內(nèi)，基線是軟件開發(fā)中的里程碑，其標志是有一個或多個軟件配置項的交付，且已經(jīng)經(jīng)過正式技術評審而獲得認可。配置管理組或委員會（CCB）按照需求基線，對整個項目的進程進行控制和把握?；€管理需求基線(requirementbaseline36需求狀態(tài)的變化需求狀態(tài)的變化37需求管理過程注意 如果項目中無人負責執(zhí)行需求管理活動，那么就不要指望需求管理能夠運作。需求管理過程注意 38需求版本控制版本控制是管理需求規(guī)格說明和其他項目文檔必不可少的一個方面。需求文檔的每一個版本都必須惟一地標識出來。為了盡量減少混亂、沖突和誤傳，應該指派一個人專門負責更新需求，并確保只要需求有所變更就相應地改變其版本標識號。最簡單的版本控制機制是，根據(jù)標準約定，對每一個軟件需求規(guī)格說明版本進行手工標識。還有一種更復雜的技術，可以把需求文檔存儲在版本控制工具中。版本控制最有用的方法是將需求存儲在商業(yè)需求管理工具的數(shù)據(jù)庫中。需求版本控制版本控制是管理需求規(guī)格說明和其他項目文檔必不可少39需求屬性應該考慮為每個需求指定如下一些屬性：需求創(chuàng)建的日期。需求的當前版本號。創(chuàng)建需求的作者。負責確保該需求得到滿足的人員。需求的擁有者或一組涉眾列表。需求狀態(tài)。需求的最初來源。創(chuàng)建需求的理由。需求涉及的子系統(tǒng)。需求涉及的產(chǎn)品版本號。使用的驗證方法或驗收測試的標準。需求實現(xiàn)的優(yōu)先級。需求的穩(wěn)定性。

注意 如果選擇的需求屬性太多，那么開發(fā)團隊會望而生畏，結(jié)果是他們絕不可能提供所有需求的全部屬性值，也無法有效地使用這些屬性信息。需求屬性應該考慮為每個需求指定如下一些屬性：注意 40跟蹤需求狀態(tài)表列出了若干可能的需求狀態(tài)。有些跟蹤人員還添加了另外兩個狀態(tài)：“已設計(Designed)”和“已交付(Delivered)。狀態(tài)定義已提議(Proposed)

該需求已被有相應權(quán)限的人提出

已批準(Approved)

該需求已經(jīng)被分析，它對項目的影響已進行了估計，并且已經(jīng)被分配到某一特定版本的基線中。關鍵涉眾已同意包含這一需求，軟件開發(fā)團隊已承諾實現(xiàn)這一需求

已實現(xiàn)(Implemented)

實現(xiàn)這一需求的代碼已完成了設計、編碼和單元測試。這一需求已被跟蹤到相關的設計元素和編碼元素

已驗證(Verified)

已在集成產(chǎn)品中確認了這一需求的功能實現(xiàn)是正確的。這一需求已被跟蹤到相關的測試用例。這一需求目前可以被認為是已完成了

已刪除(Deleted)

已批準的需求又從需求基線中取消了。要解釋清楚為什么要刪除這一需求，以及是誰決定刪除的

已否決(Rejected)

需求已被提議，但并不計劃在下一版本中實現(xiàn)它。要解釋清楚為什么要否決這一需求，以及是誰決定否決的

跟蹤需求狀態(tài)表列出了若干可能的需求狀態(tài)。有些跟蹤人員還添加了41評估需求管理的工作量如果跟蹤在需求管理上投入了多少工作量，我們就可以評估工作量是太少，還是正合適，或者是太多，并且可以對當前過程和未來的計劃做出相應的調(diào)整。將下面這些活動中所投入的工作量加起來，就可以算出需求管理的工作量：提交需求變更和提議新的需求。評估已提議的變更，包括進行影響分析。變更控制委員會的活動。更新需求文檔或數(shù)據(jù)庫。向受影響的小組或個人傳達需求變更。跟蹤并報告需求狀態(tài)。收集需求的跟蹤信息。評估需求管理的工作量如果跟蹤在需求管理上投入了多少工作量，我42需求風險管理需求風險管理43所謂風險就是可能給項目的成功帶來某些損失或威脅的情況。由于需求在軟件項目中具有十分重要的地位，所以精明的項目管理者應盡早確定與需求相關的風險并積極主動地控制它們。典型的需求風險包括：誤解需求。用戶的參與不恰當。項目范圍和目標不確定或隨意進行變更。對需求不斷進行變更等。44所謂風險就是可能給項目的成功帶來某些損失或威脅的情況。44軟件風險管理基本原理對外部實體的依賴就是一種常見的風險來源。項目管理一直面臨各種風險的挑戰(zhàn)：評估不準確、管理人員拒絕開發(fā)人員的準確評估、對項目狀態(tài)不了解以及進行了人員調(diào)整等原因所引起的風險。技術風險威脅著高度復雜或很前沿的開發(fā)項目。知識的缺乏是風險的另一種來源，另外還有參與者對所用的技術或項目應用領域經(jīng)驗不足。經(jīng)常變更的或強制執(zhí)行的一些政府規(guī)定可能會使最好的項目規(guī)劃徹底作廢。軟件風險管理基本原理對外部實體的依賴就是一種常見的風險來源。45風險管理的要素風險管理(riskmanagement)就是使用某些工具和步驟把項目風險限制在一個可接受的范圍內(nèi)。風險管理提供了一種標準的方法，可以指出風險因素并將其編寫成文檔，評估這些風險的潛在威脅，并提出減少這些風險因素的戰(zhàn)略。風險管理的要素風險管理(riskmanagement)就是46風險管理包括圖所示的這些活動。風險評估(riskassessment)是一個對項目進行檢查以確定潛在風險領域的過程。風險避免(riskavoidance)是處理風險的一種方法，也就是盡量不要做冒險的事。風險管理包括圖所示的這些活動。47編寫項目風險文檔圖展示了一個模板，用于對單個風險編寫文檔。編寫項目風險文檔48制定風險管理計劃對于小型項目，可以把控制風險的計劃包括在軟件項目管理計劃內(nèi)。但對一個大型項目，則應該編寫一個單獨的風險管理計劃，詳細說明打算采用哪些方法來識別、評估、編檔和跟蹤風險。這一計劃還應該包括風險管理活動的角色和職責。要建立起周期性進行風險監(jiān)控的措施。

注意： 不要想當然地以為，在識別出了風險并采取了降低風險的相應活動之后，風險就會處于您的控制之下。接下來還要實行風險管理活動。制定風險管理計劃對于小型項目，可以把控制風險的計劃包括在軟件49與需求有關的風險無足夠用戶參與用戶需求的不斷增加模棱兩可的需求不必要的特性過于精簡的規(guī)格說明忽略了用戶分類不準確的計劃與需求有關的風險無足夠用戶參與50風險管理是我們的好幫手即使不能控制項目可能遇到的所有風險，風險管理也能幫助我們看清形勢，做出合理的決策。風險管理是我們的好幫手即使不能控制項目可能遇到的所有風險，風51風險管理的措施明確你當前項目面臨的一些與需求有關的風險，不要把當前的問題當作風險，一定要是那些還未發(fā)生的事情。將風險因素編寫成文檔，為每項風險推薦至少一種可能的降低風險的方法。風險管理的措施明確你當前項目面臨的一些與需求有關的風險，不要52風險管理的措施召集代表開發(fā)、市場、客戶和管理各方面的涉眾召開風險“集體研討”會議。風險管理的措施召集代表開發(fā)、市場、客戶和管理各方面的涉眾召開53需求跟蹤需求跟蹤提供了一個表明與合同或說明一致的方法。更進一步，需求跟蹤可以改善產(chǎn)品質(zhì)量，降低維護成本，而且很容易實現(xiàn)重用。需求跟蹤鏈使你能跟蹤一個需求使用期限的全過程。通用的跟蹤模型顯示了我們要在軟件開發(fā)的不同層面全面地跟蹤需求。需求跟蹤需求跟蹤提供了一個表明與合同或說明一致的方法。更進一54需求跟蹤的定義[IEEE，1994]

開發(fā)過程的兩個或多個產(chǎn)品之間能夠建立關系的程度，尤其是那些具有前后關系或主從關系的產(chǎn)品。例如，某個給定組件的需求和設計的匹配程度。軟件開發(fā)產(chǎn)品中每個元素能夠建立其存在理由的程度；例如，數(shù)據(jù)流圖中的每個元素定位它所滿足需求的程度。需求跟蹤的定義[IEEE，1994]開發(fā)過程的兩個或多個產(chǎn)55商業(yè)需求管理工具以數(shù)據(jù)庫為核心的產(chǎn)品以文檔為核心的方法商業(yè)需求管理工具以數(shù)據(jù)庫為核心的產(chǎn)品56使用需求管理工具的益處

項目需求的收集工作做得很好，也應該使用自動化工具幫助您在開發(fā)過程中管理這些需求。隨著時間的推移，團隊成員對需求細節(jié)的記憶會逐漸變得模糊，這時使用需求管理工具的益處就得到了最大程度的體現(xiàn)。下面介紹這種工具可以幫助我們完成哪些任務：管理版本和變更項目應該定義需求基線，基線就是某一版本的產(chǎn)品要實現(xiàn)的需求的集合。存儲需求屬性應該為每個需求記錄一些描述性屬性，要清楚地標出各種版本的產(chǎn)品要實現(xiàn)的需求基線。使用需求管理工具的益處

項目需求的收集工作做得很好，也應該57使用需求管理工具的益處進行影響分析通過確定某一提議的變更可能影響哪些其他系統(tǒng)元素，這些聯(lián)系鏈可以幫助分析這一變更對某一特定需求將產(chǎn)生的影響。跟蹤需求狀態(tài)將需求保存在數(shù)據(jù)庫中就可以知道產(chǎn)品指定了多少離散的需

求。訪問控制需求管理工具可以定義單個用戶或用戶組的訪問權(quán)限，并通過到數(shù)據(jù)庫的Web接口與地域上分散的團隊共享信息。與涉眾溝通有些需求管理工具允許團隊成員通過電子聯(lián)系方式來討論需求問題。重用需求將需求保存在數(shù)據(jù)庫中，就可以方便地在多個項目或子系統(tǒng)中重用這些需求。使用需求管理工具的益處58需求管理工具的功能大多數(shù)需求管理工具都與Word有某種程度的集成，一般情況下，是在Word菜單欄中添加了一個專門的工具菜單。這些工具的輸出能力包括以用戶指定的專門格式或表格格式報告生成需求文檔的能力。產(chǎn)品有一個共同的趨勢，就是盡量與應用程序開發(fā)所用的其他工具相集成，如圖所示。選購需求管理產(chǎn)品時，要考慮它是否能與所用的其他工具交換數(shù)據(jù)。需求管理工具的功能大多數(shù)需求管理工具都與Word有某種程度的59需求開發(fā)面臨的特殊難題需求開發(fā)：是針對一個新軟件或系統(tǒng)開發(fā)項目的情況，這種項目有時也稱為零起點項目(green-fieldproject)。大多數(shù)組織的主要精力集中于維護現(xiàn)存的遺留系統(tǒng)，或者為已有的商業(yè)產(chǎn)品構(gòu)建新的版本；其他組織也很少是從零開始構(gòu)建一個新系統(tǒng)，而是對商用現(xiàn)貨產(chǎn)品進行集成、定制和擴充，以滿足自己的需要。60需求開發(fā)面臨的特殊難題需求開發(fā)：是針對一個新軟件或系統(tǒng)開發(fā)項開始捕獲信息缺少精確的需求文檔，那么維護人員就必須進行逆向工程，通過代碼來理解系統(tǒng)，將此看作是軟件考古學(softwarearchaeology)。構(gòu)建一個包含當前系統(tǒng)部分的需求表示可達到以下3個有用的目標：消除知識鴻溝，使將來的維護人員能更好地理解所做的變更。收集當前系統(tǒng)的一些信息——當前系統(tǒng)在以前缺乏良好的書面文檔。提供一個指標，表明當前的系統(tǒng)測試集對系統(tǒng)功能的覆蓋率。開始捕獲信息缺少精確的需求文檔，那么維護人員就必須進行逆向工61定義質(zhì)量需求軟件的質(zhì)量屬性和性能目標是選擇解決方案時所要考慮的用戶需求的另一個方面。我們至少要研究下面幾個屬性：性能易使用性靈活性互操作性完整性定義質(zhì)量需求軟件的質(zhì)量屬性和性能目標是選擇解決方案時所要考慮62盡早地而且要經(jīng)常地設定優(yōu)先級客戶和開發(fā)人員協(xié)同工作，共同選定功能實現(xiàn)的順序，這樣增量開發(fā)才會取得成功。開發(fā)團隊的目標是，將可用的功能和對質(zhì)量的改進有規(guī)律地交到用戶手中，因此，開發(fā)人員必須了解每次增量開發(fā)計劃實現(xiàn)哪些功能。盡早地而且要經(jīng)常地設定優(yōu)先級客戶和開發(fā)人員協(xié)同工作，共同選定63設定需求優(yōu)先級每一個受資源限制的軟件項目都必須對要求的產(chǎn)品功能定義相對優(yōu)先級。設定優(yōu)先級有助于項目經(jīng)理解決沖突、安排階段性交付，并且做出必要的取舍。討論設定需求優(yōu)先級的重要性，提出一個簡單的優(yōu)先級劃分方案，并介紹更嚴格的基于價值、成本和風險的優(yōu)先級分析方案。64設定需求優(yōu)先級每一個受資源限制的軟件項目都必須對要求的產(chǎn)品功需求和進度安排注意： 不要迫于壓力而許下自己明知道不可能做到的諾言，這是避免最后兩敗俱傷的秘訣。需求和進度安排注意： 65需求管理需求管理66需求管理的原則和實踐需求管理包括在項目開發(fā)過程中維護需求約定的完整性、準確性以及保持需求約定是最新約定的所有活動，如圖所示。67需求管理的原則和實踐8軟件需求管理部分完整版課件68軟件需求管理需求管理所要完成的任務需求管理模型管理變更需求風險管理需求跟蹤需求管理工具軟件需求管理需求管理所要完成的任務69需求管理所要完成的任務

需求管理的首要任務在于使開發(fā)人員和用戶雙方對于需求都有一個明確的認識。需求模型實際是最終產(chǎn)品的抽象化表現(xiàn)。用戶需求的滿足程度是衡量設計優(yōu)劣的標準。優(yōu)秀的需求分析應當非常精確細致地對用戶需求作出描述，同時也應該最大程度地給予方案設計者充分發(fā)揮的余地。對開發(fā)項目進行任務劃分，將整體開發(fā)任務細化為多個子模塊，從而使這些子模塊能夠平行開發(fā)而無需太多的干預。需求管理在開發(fā)周期中是自始至終存在的。需求管理必須始終保持更新。需求管理同項目管理是密不可分的。需求管理所要完成的任務需求管理的首要任務在于使開發(fā)人員和用70需求管理的任務明確需求并達成共識；建立關聯(lián)，根據(jù)不同需求設計相應解決辦法；進行系統(tǒng)優(yōu)化，提出設計方案；監(jiān)控和解決可能出現(xiàn)的問題以及需要做出的改變；控制不同開發(fā)任務的開展；對最終產(chǎn)品做出評測；監(jiān)控可能出現(xiàn)的重復開發(fā)；提出項目實施時間表；確定最終用戶界面。需求管理的任務明確需求并達成共識；71里程碑與項目管理一項需求的滿足就意味著一塊里程碑的確立。里程碑構(gòu)造機制的基本方法之一就是進程管理。需求管理在開發(fā)周期中是自始至終存在的。需求管理必須始終保持更新，它構(gòu)成了技術管理的基礎。需求管理同項目管理是密不可分的。里程碑與項目管理一項需求的滿足就意味著一塊里程碑的確立。72需求管理模型

不同的需求組合起來，構(gòu)成了一套完整的需求模型。需求管理的一項重要工作就是在整個項目的不同任務之間建立聯(lián)系。需求管理包括在工程進展過程中維持需求約定集成性和精確性的所有活動。需求管理的關鍵過程領域。需求管理的步驟。需求管理模型不同的需求組合起來，構(gòu)成了一套完整的需求模型。73需求管理的主要活動控制對需求基線的變動。保持項目計劃與需求一致?？刂茊蝹€需求和需求文檔的版本情況。管理需求和聯(lián)系鏈之間的聯(lián)系或管理單個需求和其它項目可交付品之間的依賴關系。跟蹤基線中需求的狀態(tài)。需求管理的主要活動控制對需求基線的變動。74需求開發(fā)與需求管理的分界中程在線信息產(chǎn)業(yè)培訓網(wǎng)需求開發(fā)與需求管理的分界中程在線信息產(chǎn)業(yè)培訓網(wǎng)75需求基線管理為何需要：頻繁的需求變更會破壞開發(fā)的節(jié)奏，使整個項目開發(fā)的進度陷入混亂和失控的狀態(tài)，而且會變成一個“救火隊”式的工作，整天都在處理突發(fā)事件.主要思想：將所有現(xiàn)在的、將來的需求進行優(yōu)先級評估，然后分解成為不同的組，每次迭代都選擇其中優(yōu)先級最高的部分進行開發(fā)，然后在迭代完成之前，開發(fā)工作不響應變更，這些劃入的需求項就是需求基線的組

成部分需求基線管理為何需要：頻繁的需求變更會破壞開發(fā)的節(jié)奏，使整個76需求基線管理--操作思路我們應該在分析的基礎上，將需求整合成為用例或功能項，然后對其進行優(yōu)先級、依賴性進行綜合性評估優(yōu)先級判斷：業(yè)務人員確定業(yè)務決定，技術人員確定技術決策；“滿意度/不滿意度”模型依賴性是指對于某些功能，在實現(xiàn)上有必須的依賴關系，即當某些功能沒有實現(xiàn)時，另

外的功能無法開始，這就需要對其

進行調(diào)整需求基線管理--操作思路我們應該在分析的基礎上，將需求整合成77需求變更管理需求變更是一定存在的，而需求變更管理并不是指逃避它，更不是說要避免它，它實際上是希望控制變更在基線內(nèi)的需求不響應變更，為開發(fā)人員提供一個安靜的工作時間狀態(tài)專門的需求變更管理來對所有的需求變更進行響應，了解需求變更的關鍵意圖、新產(chǎn)生的工作量，從而良好地進行重新計劃，以便能夠有效地解決其對整個開發(fā)帶來的麻煩需求變更管理需求變更是一定存在的，而需求變更管理并不是指逃避78對待軟件項目管理的組織必須確保做到以下幾點：在提交提議的需求變更之前要對其進行仔細的評估。請合適的人員就需求變更做出周全合理的業(yè)務決策。將已批準的變更傳達給受此影響的所有人員。項目以一致的方式將需求變更包含進來。采用一致的變更控制方法，就可以避免相關問題，避免開發(fā)工作的返工和浪費時間等情況的發(fā)生。對待軟件項目管理的組織必須確保做到以下幾點：79變更控制委員會變更控制委員會，有時也稱為配置控制委員會(configurationcontrolboard，CCB)，已被證實是軟件開發(fā)領域公認的最佳實踐(McConnell1996)。CCB是由人組成的團體，可以由一個小組擔任，也可以由多個不同的小組擔任，這些人共同決定將哪些已提議的需求變更和新提議的特性在產(chǎn)品中付諸實現(xiàn)。CCB也決定所報告的缺陷中哪些需要糾正，什么時候糾正。CCB可以評審和批準對項目中任何基線工作產(chǎn)品所做的變更，項目需求文檔只是其中的一個樣例。變更控制委員會變更控制委員會，有時也稱為配置控制委員會(co80CCB的組成CCB的成員應該能代表需要參與制定決策的所有小組，當然這些決策制定只能是在CCB的權(quán)力范圍之內(nèi)?？煽紤]從下面這些部門中選擇CCB代表：項目或程序管理部門產(chǎn)品管理或需求分析部門開發(fā)部門測試或質(zhì)量保證部門市場或客戶代表編寫用戶文檔的部門技術支持或幫助部門配置管理部門CCB的組成CCB的成員應該能代表需要參與制定決策的所有小組81CCB規(guī)章CCB規(guī)章描述了CCB的目的、權(quán)力范圍、成員構(gòu)成、運作規(guī)程和決策的制定過程等(Sorensen1999)。CCB的權(quán)力范圍規(guī)定了哪些決策由CCB決定，哪些決策則必須上報給高一級CCB或者由管理層來決定。1.制定決策決策制定過程的描述應該確定：CCB成員或主要角色的人數(shù)，這是制定決策的法定人數(shù)。所采用的決策規(guī)則是投票、少數(shù)服從多數(shù)、協(xié)商決定或其他方法。CCB規(guī)章CCB規(guī)章描述了CCB的目的、權(quán)力范圍、成員構(gòu)成、82CCB規(guī)章CCB主席是否可以否決CCB的集體決策。級別高的CCB或其他人是否必須認可CCB做出的決策。2.交流狀態(tài)CCB做出決策之后，應該指派專人對變更數(shù)據(jù)庫中的變更請求狀態(tài)進行更新。3.重新協(xié)商原先的約定在接受一個重大的需求變更之前，為了適應這一變更，需要同管理部門和客戶重新協(xié)商原先的約定(Humphrey1997)。協(xié)商的內(nèi)容可能包括，要求推遲產(chǎn)品交付時間，要求增派人手，或者要求推遲實現(xiàn)尚未實現(xiàn)的優(yōu)先級較低的需求等。CCB規(guī)章CCB主席是否可以否決CCB的集體決策。83變更需要付出代價：影響分析對軟件實施大的功能增強，則需要進行影響分析(impactanalysis)。但是，即使是小的變更請求，也可能潛伏著難以預料的復雜性。影響分析是需求管理的一個關鍵方面(Arnold和Bohner1996)。通過對影響進行分析，可以準確地理解提議的變更所涉及到的問題，有助于項目團隊就批準哪些提議做出周全合理的業(yè)務決策。影響分析:通過對所提議的變更進行檢查，確定可能必須創(chuàng)建、修改或廢棄哪些部分，并估計與實現(xiàn)這些變更相關的工作量。變更需要付出代價：影響分析對軟件實施大的功能增強，則需要進行84影響分析的過程影響分析有3個方面：1.理解進行變更可能涉及的問題。變更常常會產(chǎn)生大量的連鎖反應，產(chǎn)品包括的功能太多會降低其性能，甚至會到令人難以接受的地步。2.確定如果團隊將提議的變更包括到產(chǎn)品中，可能必須對哪些文件、模型和文檔進行修改。3.確定實現(xiàn)變更所需執(zhí)行的任務，并估計完成這些任務所需的工作量。注意: 跳過影響分析并不能改變?nèi)蝿盏囊?guī)模，只會使規(guī)模令人感到驚奇，而軟件方面令人驚奇卻很少是好消息。影響分析的過程影響分析有3個方面：注意: 85影響分析報告模板圖是一個推薦的報告模板，表示對每個需求變更造成的潛在影響的分析結(jié)果。如果采用標準模板，CCB成員就可以輕松地找到他們所需的信息，作出合理的決策。影響分析報告模板圖是一個推薦的報告模板，表示對每個需求變更造86需求的變化是永恒的。因而，對于需求變更應該正確對待，盡量將其負面影響降低。需求變更可能來自解決方案提供商、客戶或產(chǎn)品供應商等外部因素，也可能來源于項目組內(nèi)部。變更都是有代價的，應該評估一下變更的代價及其對項目的影響。在需求變更發(fā)生之前盡量減少需求變更，以將需求變更帶來的風險降低到最低。切忌在項目設計之前試圖消除需求變更。需求的變化是永恒的。因而，對于需求變更應該正確對待，盡量將其87需求變更的原因因競爭、成本等因素，工期已經(jīng)確定且極不合理.用戶在需求期提不出需求、或用戶的需求不明確.項目組對業(yè)務不熟悉、或者沒有與用戶密切結(jié)合、需求分析工作不細致.項目組沒有很好地實施需求管理.需求變更的原因因競爭、成本等因素，工期已經(jīng)確定且極不合理.88需求變更的惡性循環(huán)需求變更的惡性循環(huán)89需求變更的因素需求變更的因素90需求變更的代價需求變更的代價91減少需求變更減少需求變更92需求變更的過程管理認識到變更不可避免，為變更制訂計劃。確認需求基線。建立控制變更的唯一渠道。使用變更控制系統(tǒng)來捕獲變更。分層次地管理變更。需求變更的過程管理認識到變更不可避免，為變更制訂計劃。93基于配置管理的需求管理避免需求在未授權(quán)情況下變更，或在有潛在破壞性的情況下不受限制地隨意變更。保護隊需求文檔的修正。方便對文檔以前版本的檢索或重建。支持系統(tǒng)以增量的方式改進基線。避免對文檔的同時更新和沖突?；谂渲霉芾淼男枨蠊芾肀苊庑枨笤谖词跈?quán)情況下變更，或在有潛在94基線管理需求基線(requirementbaseline)是團隊成員已經(jīng)承諾將在某一特定產(chǎn)品版本中實現(xiàn)的功能性和非功能性需求的一組集合。基線：已經(jīng)通過正式評審和批準的某規(guī)約或產(chǎn)品，它可以作為進一步開發(fā)的基礎，并且只能通過正式的變化控制過程的改變。[IEEE]基線是一個軟件配置管理的概念。在軟件工程的范圍內(nèi)，基線是軟件開發(fā)中的里程碑，其標志是有一個或多個軟件配置項的交付，且已經(jīng)經(jīng)過正式技術評審而獲得認可。配置管理組或委員會（CCB）按照需求基線，對整個項目的進程進行控制和把握?；€管理需求基線(requirementbaseline95需求狀態(tài)的變化需求狀態(tài)的變化96需求管理過程注意 如果項目中無人負責執(zhí)行需求管理活動，那么就不要指望需求管理能夠運作。需求管理過程注意 97需求版本控制版本控制是管理需求規(guī)格說明和其他項目文檔必不可少的一個方面。需求文檔的每一個版本都必須惟一地標識出來。為了盡量減少混亂、沖突和誤傳，應該指派一個人專門負責更新需求，并確保只要需求有所變更就相應地改變其版本標識號。最簡單的版本控制機制是，根據(jù)標準約定，對每一個軟件需求規(guī)格說明版本進行手工標識。還有一種更復雜的技術，可以把需求文檔存儲在版本控制工具中。版本控制最有用的方法是將需求存儲在商業(yè)需求管理工具的數(shù)據(jù)庫中。需求版本控制版本控制是管理需求規(guī)格說明和其他項目文檔必不可少98需求屬性應該考慮為每個需求指定如下一些屬性：需求創(chuàng)建的日期。需求的當前版本號。創(chuàng)建需求的作者。負責確保該需求得到滿足的人員。需求的擁有者或一組涉眾列表。需求狀態(tài)。需求的最初來源。創(chuàng)建需求的理由。需求涉及的子系統(tǒng)。需求涉及的產(chǎn)品版本號。使用的驗證方法或驗收測試的標準。需求實現(xiàn)的優(yōu)先級。需求的穩(wěn)定性。

注意 如果選擇的需求屬性太多，那么開發(fā)團隊會望而生畏，結(jié)果是他們絕不可能提供所有需求的全部屬性值，也無法有效地使用這些屬性信息。需求屬性應該考慮為每個需求指定如下一些屬性：注意 99跟蹤需求狀態(tài)表列出了若干可能的需求狀態(tài)。有些跟蹤人員還添加了另外兩個狀態(tài)：“已設計(Designed)”和“已交付(Delivered)。狀態(tài)定義已提議(Proposed)

該需求已被有相應權(quán)限的人提出

已批準(Approved)

該需求已經(jīng)被分析，它對項目的影響已進行了估計，并且已經(jīng)被分配到某一特定版本的基線中。關鍵涉眾已同意包含這一需求，軟件開發(fā)團隊已承諾實現(xiàn)這一需求

已實現(xiàn)(Implemented)

實現(xiàn)這一需求的代碼已完成了設計、編碼和單元測試。這一需求已被跟蹤到相關的設計元素和編碼元素

已驗證(Verified)

已在集成產(chǎn)品中確認了這一需求的功能實現(xiàn)是正確的。這一需求已被跟蹤到相關的測試用例。這一需求目前可以被認為是已完成了

已刪除(Deleted)

已批準的需求又從需求基線中取消了。要解釋清楚為什么要刪除這一需求，以及是誰決定刪除的

已否決(Rejected)

需求已被提議，但并不計劃在下一版本中實現(xiàn)它。要解釋清楚為什么要否決這一需求，以及是誰決定否決的

跟蹤需求狀態(tài)表列出了若干可能的需求狀態(tài)。有些跟蹤人員還添加了100評估需求管理的工作量如果跟蹤在需求管理上投入了多少工作量，我們就可以評估工作量是太少，還是正合適，或者是太多，并且可以對當前過程和未來的計劃做出相應的調(diào)整。將下面這些活動中所投入的工作量加起來，就可以算出需求管理的工作量：提交需求變更和提議新的需求。評估已提議的變更，包括進行影響分析。變更控制委員會的活動。更新需求文檔或數(shù)據(jù)庫。向受影響的小組或個人傳達需求變更。跟蹤并報告需求狀態(tài)。收集需求的跟蹤信息。評估需求管理的工作量如果跟蹤在需求管理上投入了多少工作量，我101需求風險管理需求風險管理102所謂風險就是可能給項目的成功帶來某些損失或威脅的情況。由于需求在軟件項目中具有十分重要的地位，所以精明的項目管理者應盡早確定與需求相關的風險并積極主動地控制它們。典型的需求風險包括：誤解需求。用戶的參與不恰當。項目范圍和目標不確定或隨意進行變更。對需求不斷進行變更等。103所謂風險就是可能給項目的成功帶來某些損失或威脅的情況。44軟件風險管理基本原理對外部實體的依賴就是一種常見的風險來源。項目管理一直面臨各種風險的挑戰(zhàn)：評估不準確、管理人員拒絕開發(fā)人員的準確評估、對項目狀態(tài)不了解以及進行了人員調(diào)整等原因所引起的風險。技術風險威脅著高度復雜或很前沿的開發(fā)項目。知識的缺乏是風險的另一種來源，另外還有參與者對所用的技術或項目應用領域經(jīng)驗不足。經(jīng)常變更的或強制執(zhí)行的一些政府規(guī)定可能會使最好的項目規(guī)劃徹底作廢。軟件風險管理基本原理對外部實體的依賴就是一種常見的風險來源。104風險管理的要素風險管理(riskmanagement)就是使用某些工具和步驟把項目風險限制在一個可接受的范圍內(nèi)。風險管理提供了一種標準的方法，可以指出風險因素并將其編寫成文檔，評估這些風險的潛在威脅，并提出減少這些風險因素的戰(zhàn)略。風險管理的要素風險管理(riskmanagement)就是105風險管理包括圖所示的這些活動。風險評估(riskassessment)是一個對項目進行檢查以確定潛在風險領域的過程。風險避免(riskavoidance)是