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

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

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

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

外的功能無(wú)法開(kāi)始，這就需要對(duì)其

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

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

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

已批準(zhǔn)(Approved)

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

已實(shí)現(xiàn)(Implemented)

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

已驗(yàn)證(Verified)

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

已刪除(Deleted)

已批準(zhǔn)的需求又從需求基線中取消了。要解釋清楚為什么要?jiǎng)h除這一需求，以及是誰(shuí)決定刪除的

已否決(Rejected)

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

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

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

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

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

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

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

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

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

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

外的功能無(wú)法開(kāi)始，這就需要對(duì)其

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

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

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

已批準(zhǔn)(Approved)

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

已實(shí)現(xiàn)(Implemented)

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

已驗(yàn)證(Verified)

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

已刪除(Deleted)

已批準(zhǔn)的需求又從需求基線中取消了。要解釋清楚為什么要?jiǎng)h除這一需求，以及是誰(shuí)決定刪除的

已否決(Rejected)

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

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