第22章需求風(fēng)險管理第22章需求風(fēng)險管理1所謂風(fēng)險就是可能給項目的成功帶來某些損失或威脅的情況。由于需求在軟件項目中具有十分重要的地位，所以精明的項目管理者應(yīng)盡早確定與需求相關(guān)的風(fēng)險并積極主動地控制它們。典型的需求風(fēng)險包括：誤解需求。用戶的參與不恰當(dāng)。項目范圍和目標(biāo)不確定或隨意進(jìn)行變更。對需求不斷進(jìn)行變更等。本章將對軟件風(fēng)險管理進(jìn)行簡要介紹(Wiegers1998b)。本章后面還會提到需求工程活動中出現(xiàn)的許多風(fēng)險因素2所謂風(fēng)險就是可能給項目的成功帶來某些損失或威脅的情況。2軟件風(fēng)險管理基本原理除了與項目范圍和需求有關(guān)的風(fēng)險外，項目還面臨著許多其他風(fēng)險。對外部實體的依賴就是一種常見的風(fēng)險來源。項目管理一直面臨各種風(fēng)險的挑戰(zhàn)：評估不準(zhǔn)確、管理人員拒絕開發(fā)人員的準(zhǔn)確評估、對項目狀態(tài)不了解以及進(jìn)行了人員調(diào)整等原因所引起的風(fēng)險。技術(shù)風(fēng)險威脅著高度復(fù)雜或很前沿的開發(fā)項目。知識的缺乏是風(fēng)險的另一種來源，另外還有參與者對所用的技術(shù)或項目應(yīng)用領(lǐng)域經(jīng)驗不足。經(jīng)常變更的或強(qiáng)制執(zhí)行的一些政府規(guī)定可能會使最好的項目規(guī)劃徹底作廢。軟件風(fēng)險管理基本原理除了與項目范圍和需求有關(guān)的風(fēng)險外，項目還3風(fēng)險管理的要素風(fēng)險管理(riskmanagement)就是使用某些工具和步驟把項目風(fēng)險限制在一個可接受的范圍內(nèi)。風(fēng)險管理提供了一種標(biāo)準(zhǔn)的方法，可以指出風(fēng)險因素并將其編寫成文檔，評估這些風(fēng)險的潛在威脅，并提出減少這些風(fēng)險因素的戰(zhàn)略。風(fēng)險管理的要素風(fēng)險管理(riskmanagement)就是4風(fēng)險管理包括圖所示的這些活動。風(fēng)險評估(riskassessment)是一個對項目進(jìn)行檢查以確定潛在風(fēng)險領(lǐng)域的過程。風(fēng)險避免(riskavoidance)是處理風(fēng)險的一種方法，也就是盡量不要做冒險的事。風(fēng)險管理包括圖所示的這些活動。5編寫項目風(fēng)險文檔只是認(rèn)識到項目所面臨的風(fēng)險是遠(yuǎn)遠(yuǎn)不夠的，我們還必須以某種方式對風(fēng)險進(jìn)行管理，以便在整個項目開發(fā)過程中可以將風(fēng)險問題和狀態(tài)傳達(dá)給項目的涉眾。圖展示了一個模板，用于對單個風(fēng)險編寫文檔。編寫項目風(fēng)險文檔只是認(rèn)識到項目所面臨的風(fēng)險是遠(yuǎn)遠(yuǎn)不夠的，我們6制定風(fēng)險管理計劃對于小型項目，可以把控制風(fēng)險的計劃包括在軟件項目管理計劃內(nèi)。但對一個大型項目，則應(yīng)該編寫一個單獨(dú)的風(fēng)險管理計劃，詳細(xì)說明打算采用哪些方法來識別、評估、編檔和跟蹤風(fēng)險。這一計劃還應(yīng)該包括風(fēng)險管理活動的角色和職責(zé)。要建立起周期性進(jìn)行風(fēng)險監(jiān)控的措施。

注意： 不要想當(dāng)然地以為，在識別出了風(fēng)險并采取了降低風(fēng)險的相應(yīng)活動之后，風(fēng)險就會處于您的控制之下。接下來還要實行風(fēng)險管理活動。制定風(fēng)險管理計劃對于小型項目，可以把控制風(fēng)險的計劃包括在軟件7與需求相關(guān)的風(fēng)險下面介紹的這些風(fēng)險因素，是按照需求工程的分支過程組織的，即需求獲取、需求分析、編寫需求規(guī)格說明、需求確認(rèn)和需求管理過程。推薦的方法可以減小風(fēng)險發(fā)生的可能性或風(fēng)險發(fā)生后給項目造成的影響。與需求相關(guān)的風(fēng)險下面介紹的這些風(fēng)險因素，是按照需求工程的分支8與需求有關(guān)的風(fēng)險無足夠用戶參與用戶需求的不斷增加模棱兩可的需求不必要的特性過于精簡的規(guī)格說明忽略了用戶分類不準(zhǔn)確的計劃與需求有關(guān)的風(fēng)險無足夠用戶參與9需求獲取產(chǎn)品前景和項目范圍應(yīng)該在項目早期，編寫一份包括業(yè)務(wù)需求在內(nèi)的前景和范圍文檔，并將它作為添加新需求和修改現(xiàn)有需求的指導(dǎo)。需求開發(fā)所需的時間將每個項目中需求開發(fā)所耗費(fèi)的實際工作量記錄下來，這樣就可以判斷出需求開發(fā)是否充分，并可以改進(jìn)未來項目的工作計劃。需求規(guī)格說明的完整性和正確性為了確保需求是客戶真正需要的，應(yīng)該以用戶任務(wù)為中心，應(yīng)用用例技術(shù)來獲取需求。創(chuàng)新產(chǎn)品的需求對某類產(chǎn)品中的第1個產(chǎn)品，不太容易把握市場對產(chǎn)品的反映。定義非功能需求由于我們一般都會強(qiáng)調(diào)產(chǎn)品的功能，所以很容易忽略產(chǎn)品的非功能性需求。需求獲取產(chǎn)品前景和項目范圍10需求獲取客戶對產(chǎn)品需求意見一致確定那些主要的客戶，并采用產(chǎn)品代言人的方法，保證有足夠的客戶代表的積極參與未加說明的需求客戶經(jīng)常會有一些隱含的期望要求，但并未以文檔的方式說明出來。盡量識別客戶可能做出的任何假設(shè)。把已有的產(chǎn)品作為需求基線來源將通過逆向工程發(fā)現(xiàn)的需求編寫成文檔，讓客戶評審這些需求，以確保其正確性和相關(guān)性。根據(jù)需要提出解決方案分析人員必須提煉出隱藏在客戶提出的解決方案背后的真正意圖。需求獲取客戶對產(chǎn)品需求意見一致11需求分析設(shè)定需求優(yōu)先級要確保對每一個功能需求、特性或用例都設(shè)定了優(yōu)先級，并安排在一個特定的系統(tǒng)版本或迭代中實現(xiàn)它們。技術(shù)上難以實現(xiàn)的特性采用項目狀態(tài)跟蹤來監(jiān)控落后于實現(xiàn)計劃的需求，并盡早采取糾正措施。不熟悉的技術(shù)、方法、語言、工具或硬件留出足夠的時間用于從錯誤中學(xué)習(xí)經(jīng)驗、實驗及制作原型。需求分析設(shè)定需求優(yōu)先級12編寫需求規(guī)格說明需求理解開發(fā)人員和客戶對需求的不同理解會導(dǎo)致彼此間的期望差距，并最終導(dǎo)致交付的產(chǎn)品無法滿足客戶的需要。盡管問題待確定但迫于時間壓力而繼續(xù)向前在軟件需求規(guī)格說明中，將需要進(jìn)一步研究的地方標(biāo)上TBD，不失為一個好主意。具有二義性的術(shù)語對于不同的讀者可能會有不同解釋的業(yè)務(wù)術(shù)語或技術(shù)術(shù)語，應(yīng)該創(chuàng)建一個術(shù)語表對這些術(shù)語進(jìn)行定義。需求中包括了設(shè)計軟件需求規(guī)格說明中所包含的設(shè)計對開發(fā)人員做出有效選擇造成了不必要的限制，會妨礙他們發(fā)揮創(chuàng)造性設(shè)計出最佳方案。編寫需求規(guī)格說明需求理解13需求確認(rèn)未經(jīng)確認(rèn)的需求軟件需求規(guī)格說明會令人望而生畏，在開發(fā)過程早期編寫測試用例的想法就是基于這一點。審查熟練程度要對參與需求文檔審查的所有團(tuán)隊成員進(jìn)行培訓(xùn)，請組織內(nèi)部有經(jīng)驗的審查人員或外界的咨詢顧問來評述早先的審查。需求確認(rèn)未經(jīng)確認(rèn)的需求14需求管理變更需求將前景和范圍文檔作為批準(zhǔn)需求變更的參照，可以減少范圍蔓延。需求變更過程與需求變更的處理方式相關(guān)的風(fēng)險包括，缺少已定義的變更過程，采用無效的變更機(jī)制，以及不遵循制定的過程來做出變更。未實現(xiàn)的需求需求跟蹤矩陣有助于在設(shè)計、構(gòu)造或測試期間避免遺漏任何需求。擴(kuò)大目范圍如果最初的需求定義不夠好，那么進(jìn)一步定義需求就會擴(kuò)大項目的范圍。需求管理變更需求15風(fēng)險管理是我們的好幫手周期性地進(jìn)行風(fēng)險跟蹤可以使項目經(jīng)理了解風(fēng)險對項目的威脅，沒有得到有效控制的風(fēng)險應(yīng)該上報高層管理人員，他們可能開始采取一些糾正措施，也可能不管風(fēng)險，依舊按照原來的業(yè)務(wù)決策思路進(jìn)行。即使不能控制項目可能遇到的所有風(fēng)險，風(fēng)險管理也能幫助我們看清形勢，做出合理的決策。風(fēng)險管理是我們的好幫手周期性地進(jìn)行風(fēng)險跟蹤可以使項目經(jīng)理了解16風(fēng)險管理的措施明確你當(dāng)前項目面臨的一些與需求有關(guān)的風(fēng)險，不要把當(dāng)前的問題當(dāng)作風(fēng)險，一定要是那些還未發(fā)生的事情。將風(fēng)險因素編寫成文檔，為每項風(fēng)險推薦至少一種可能的降低風(fēng)險的方法。風(fēng)險管理的措施明確你當(dāng)前項目面臨的一些與需求有關(guān)的風(fēng)險，不要17風(fēng)險管理的措施召集代表開發(fā)、市場、客戶和管理各方面的涉眾召開風(fēng)險“集體研討”會議。盡力找出更多與需求有關(guān)的風(fēng)險因素。估計每項風(fēng)險發(fā)生的可能性及其影響，兩者乘積就是風(fēng)險危害值。通過按風(fēng)險危害值降序排列找到最高的五項風(fēng)險。為每項風(fēng)險安排一個負(fù)責(zé)人負(fù)責(zé)實施降低風(fēng)險的活動。風(fēng)險管理的措施召集代表開發(fā)、市場、客戶和管理各方面的涉眾召開18第23章需求跟蹤需求跟蹤提供了一個表明與合同或說明一致的方法。更進(jìn)一步，需求跟蹤可以改善產(chǎn)品質(zhì)量，降低維護(hù)成本，而且很容易實現(xiàn)重用。需求跟蹤鏈?zhǔn)鼓隳芨櫼粋€需求使用期限的全過程。通用的跟蹤模型顯示了我們要在軟件開發(fā)的不同層面全面地跟蹤需求。第23章需求跟蹤需求跟蹤提供了一個表明與合同或說明一致的方19需求跟蹤動機(jī)CMM的第三層次要求具備需求跟蹤能力。需求跟蹤動機(jī)20需求跟蹤的定義[IEEE，1994]

開發(fā)過程的兩個或多個產(chǎn)品之間能夠建立關(guān)系的程度，尤其是那些具有前后關(guān)系或主從關(guān)系的產(chǎn)品。例如，某個給定組件的需求和設(shè)計的匹配程度。軟件開發(fā)產(chǎn)品中每個元素能夠建立其存在理由的程度；例如，數(shù)據(jù)流圖中的每個元素定位它所滿足需求的程度。需求跟蹤的定義[IEEE，1994]開發(fā)過程的兩個或多個產(chǎn)21跟蹤關(guān)系跟蹤關(guān)系22需求跟蹤鏈需求跟蹤鏈23通用的跟蹤模型通用的跟蹤模型24跟蹤矩陣：用戶需要與特性

跟蹤矩陣：用戶需要與特性25跟蹤矩陣：特性與用例跟蹤矩陣：特性與用例26跟蹤矩陣：特性與非功能性需求

跟蹤矩陣：特性與非功能性需求27在實現(xiàn)領(lǐng)域跟蹤需求在實現(xiàn)領(lǐng)域跟蹤需求28從用例跟蹤到用例實現(xiàn)（一）從用例跟蹤到用例實現(xiàn)（一）29從用例實現(xiàn)跟蹤到實現(xiàn)（二）從用例實現(xiàn)跟蹤到實現(xiàn)（二）30從補(bǔ)充需求跟蹤到實現(xiàn)從補(bǔ)充需求跟蹤到實現(xiàn)31在測試領(lǐng)域跟蹤需求在測試領(lǐng)域跟蹤需求32跟蹤場景到測試用例跟蹤場景到測試用例33從用例到測試用例的跟蹤矩陣

從用例到測試用例的跟蹤矩陣34第24章需求管理工具商業(yè)需求管理工具，包括讓用戶從源文檔中產(chǎn)生需求，定義屬性值，操作和顯示數(shù)據(jù)庫內(nèi)容，讓需求以各式各樣的形式表現(xiàn)出來，定義跟蹤能力聯(lián)系鏈，讓需求同其他軟件開發(fā)工具相連等功能。使用需求管理工具的益處。如何實現(xiàn)需求管理自動化。商業(yè)需求管理工具介紹。第24章需求管理工具商業(yè)需求管理工具，包括讓用戶從源文35基于文檔存儲需求的限制很難保持文檔與現(xiàn)實的一致。不太容易做到為每一個需求保存增補(bǔ)的信息。很難在功能需求與相應(yīng)的使用實例、設(shè)計、代碼、測試和項目任務(wù)之間建立聯(lián)系鏈。很難跟蹤每個需求的狀態(tài)?；谖臋n存儲需求的限制很難保持文檔與現(xiàn)實的一致。36商業(yè)需求管理工具以數(shù)據(jù)庫為核心的產(chǎn)品以文檔為核心的方法商業(yè)需求管理工具以數(shù)據(jù)庫為核心的產(chǎn)品37一些商業(yè)需求管理工具一些商業(yè)需求管理工具38實現(xiàn)需求管理自動化為需求管理工具定義項目需求。列出影響決策的10~15個因素。對上述步驟中列出的因素打分（總計100分）。獲得有關(guān)可用的需求管理工具的最新信息，根據(jù)影響決策的因素對候選工具排序。根據(jù)給每個因素的加權(quán)值來計算每個候選工具的得分，從而確定最合適的產(chǎn)品。從候選工具的其他用戶那里獲得一些體會。從候選工具中前三名的開發(fā)商處得到評估拷貝。最好用一個實際的項目來評估工具。經(jīng)過對排名、許可權(quán)費(fèi)、開發(fā)商后續(xù)支持費(fèi)、當(dāng)前用戶的輸入、工作小組主觀印象等的考慮之后做出決定。實現(xiàn)需求管理自動化為需求管理工具定義項目需求。39基于文檔的存儲需求的方法有許多局限性，例如：不容易保持文檔的最新和同步。需要將變更人工通知給受影響的所有團(tuán)隊成員。不容易存儲每一個需求的增補(bǔ)信息(屬性)。很難定義功能性需求和其他系統(tǒng)元素之間的聯(lián)系鏈。很難跟蹤需求狀態(tài)。很難同時管理多個分別用于不同產(chǎn)品版本或者相關(guān)產(chǎn)品的需求

集。想要重用需求，分析人員必須將文本從初始的軟件需求規(guī)格說明復(fù)制到每一個想要使用這一需求的系統(tǒng)或產(chǎn)品的軟件需求規(guī)格說明中。如果有多人參與項目，要修改需求是很困難的。沒有一個合適的地方可以方便地存儲提議之后被否決的那些需

求，以及已從基線中刪除的需求。基于文檔的存儲需求的方法有許多局限性，例如：40使用需求管理工具的益處

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

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

求。訪問控制需求管理工具可以定義單個用戶或用戶組的訪問權(quán)限，并通過到數(shù)據(jù)庫的Web接口與地域上分散的團(tuán)隊共享信息。與涉眾溝通有些需求管理工具允許團(tuán)隊成員通過電子聯(lián)系方式來討論需求問題。重用需求將需求保存在數(shù)據(jù)庫中，就可以方便地在多個項目或子系統(tǒng)中重用這些需求。使用需求管理工具的益處42需求管理工具的功能大多數(shù)需求管理工具都與Word有某種程度的集成，一般情況下，是在Word菜單欄中添加了一個專門的工具菜單。這些工具的輸出能力包括以用戶指定的專門格式或表格格式報告生成需求文檔的能力。產(chǎn)品有一個共同的趨勢，就是盡量與應(yīng)用程序開發(fā)所用的其他工具相集成，如圖所示。選購需求管理產(chǎn)品時，要考慮它是否能與所用的其他工具交換數(shù)據(jù)。需求管理工具的功能大多數(shù)需求管理工具都與Word有某種程度的43改變文化如果我們努力要從商用需求管理工具中獲得最大的投資回報，就應(yīng)該考慮下面幾個文化和過程問題：不要使用需求管理工具，甚至不要試用，直到書面創(chuàng)建了合適的軟件需求規(guī)格說明。在項目早期的需求獲取專題討論會期間，不要試圖直接用工具來捕獲需求。將需求工具作為軟件支持輔助工具，以方便不同地理位置的項目涉眾進(jìn)行交流。仔細(xì)考慮要定義的各種需求類型。改變文化如果我們努力要從商用需求管理工具中獲得最大的投資回報44改變文化為每一種需求類型定義一個擁有者，他對管理那一類型的數(shù)據(jù)庫內(nèi)容負(fù)有主要的職責(zé)。定義新的數(shù)據(jù)域或需求屬性時，要使用業(yè)務(wù)術(shù)語，而不要使用IT術(shù)語。在需求穩(wěn)定前不要定義跟蹤鏈接。為了加快從基于文檔的模式轉(zhuǎn)向使用工具，要設(shè)置一個日期。不要期望在項目早期就凍結(jié)需求，而要養(yǎng)成習(xí)慣將某一特定版本的一組需求納入基線。改變文化為每一種需求類型定義一個擁有者，他對管理那一類型的數(shù)45

使需求管理工具服務(wù)于自己

項目需求加載到數(shù)據(jù)庫、定義屬性和跟蹤鏈接、及時更新數(shù)據(jù)庫內(nèi)容、定義訪問小組和他們的權(quán)限、以及培訓(xùn)用戶，這些都需要付出勞動。管理層必須為這些操作分配所需的資源，確保在組織范圍內(nèi)確實將所選的產(chǎn)品用起來了，而不要讓昂貴的工具束之高閣。我們明白工具不能克服過程的缺陷，就很可能會發(fā)現(xiàn)，商用需求管理工具可以提高我們對軟件需求的控制能力。一旦我們使需求管理數(shù)據(jù)庫服務(wù)于自己，那么就再也不想重新使用普通紙了。

使需求管理工具服務(wù)于自己

項目需求加載到數(shù)據(jù)庫、定義屬46演講完畢，謝謝觀看！演講完畢，謝謝觀看！47第22章需求風(fēng)險管理第22章需求風(fēng)險管理48所謂風(fēng)險就是可能給項目的成功帶來某些損失或威脅的情況。由于需求在軟件項目中具有十分重要的地位，所以精明的項目管理者應(yīng)盡早確定與需求相關(guān)的風(fēng)險并積極主動地控制它們。典型的需求風(fēng)險包括：誤解需求。用戶的參與不恰當(dāng)。項目范圍和目標(biāo)不確定或隨意進(jìn)行變更。對需求不斷進(jìn)行變更等。本章將對軟件風(fēng)險管理進(jìn)行簡要介紹(Wiegers1998b)。本章后面還會提到需求工程活動中出現(xiàn)的許多風(fēng)險因素49所謂風(fēng)險就是可能給項目的成功帶來某些損失或威脅的情況。2軟件風(fēng)險管理基本原理除了與項目范圍和需求有關(guān)的風(fēng)險外，項目還面臨著許多其他風(fēng)險。對外部實體的依賴就是一種常見的風(fēng)險來源。項目管理一直面臨各種風(fēng)險的挑戰(zhàn)：評估不準(zhǔn)確、管理人員拒絕開發(fā)人員的準(zhǔn)確評估、對項目狀態(tài)不了解以及進(jìn)行了人員調(diào)整等原因所引起的風(fēng)險。技術(shù)風(fēng)險威脅著高度復(fù)雜或很前沿的開發(fā)項目。知識的缺乏是風(fēng)險的另一種來源，另外還有參與者對所用的技術(shù)或項目應(yīng)用領(lǐng)域經(jīng)驗不足。經(jīng)常變更的或強(qiáng)制執(zhí)行的一些政府規(guī)定可能會使最好的項目規(guī)劃徹底作廢。軟件風(fēng)險管理基本原理除了與項目范圍和需求有關(guān)的風(fēng)險外，項目還50風(fēng)險管理的要素風(fēng)險管理(riskmanagement)就是使用某些工具和步驟把項目風(fēng)險限制在一個可接受的范圍內(nèi)。風(fēng)險管理提供了一種標(biāo)準(zhǔn)的方法，可以指出風(fēng)險因素并將其編寫成文檔，評估這些風(fēng)險的潛在威脅，并提出減少這些風(fēng)險因素的戰(zhàn)略。風(fēng)險管理的要素風(fēng)險管理(riskmanagement)就是51風(fēng)險管理包括圖所示的這些活動。風(fēng)險評估(riskassessment)是一個對項目進(jìn)行檢查以確定潛在風(fēng)險領(lǐng)域的過程。風(fēng)險避免(riskavoidance)是處理風(fēng)險的一種方法，也就是盡量不要做冒險的事。風(fēng)險管理包括圖所示的這些活動。52編寫項目風(fēng)險文檔只是認(rèn)識到項目所面臨的風(fēng)險是遠(yuǎn)遠(yuǎn)不夠的，我們還必須以某種方式對風(fēng)險進(jìn)行管理，以便在整個項目開發(fā)過程中可以將風(fēng)險問題和狀態(tài)傳達(dá)給項目的涉眾。圖展示了一個模板，用于對單個風(fēng)險編寫文檔。編寫項目風(fēng)險文檔只是認(rèn)識到項目所面臨的風(fēng)險是遠(yuǎn)遠(yuǎn)不夠的，我們53制定風(fēng)險管理計劃對于小型項目，可以把控制風(fēng)險的計劃包括在軟件項目管理計劃內(nèi)。但對一個大型項目，則應(yīng)該編寫一個單獨(dú)的風(fēng)險管理計劃，詳細(xì)說明打算采用哪些方法來識別、評估、編檔和跟蹤風(fēng)險。這一計劃還應(yīng)該包括風(fēng)險管理活動的角色和職責(zé)。要建立起周期性進(jìn)行風(fēng)險監(jiān)控的措施。

注意： 不要想當(dāng)然地以為，在識別出了風(fēng)險并采取了降低風(fēng)險的相應(yīng)活動之后，風(fēng)險就會處于您的控制之下。接下來還要實行風(fēng)險管理活動。制定風(fēng)險管理計劃對于小型項目，可以把控制風(fēng)險的計劃包括在軟件54與需求相關(guān)的風(fēng)險下面介紹的這些風(fēng)險因素，是按照需求工程的分支過程組織的，即需求獲取、需求分析、編寫需求規(guī)格說明、需求確認(rèn)和需求管理過程。推薦的方法可以減小風(fēng)險發(fā)生的可能性或風(fēng)險發(fā)生后給項目造成的影響。與需求相關(guān)的風(fēng)險下面介紹的這些風(fēng)險因素，是按照需求工程的分支55與需求有關(guān)的風(fēng)險無足夠用戶參與用戶需求的不斷增加模棱兩可的需求不必要的特性過于精簡的規(guī)格說明忽略了用戶分類不準(zhǔn)確的計劃與需求有關(guān)的風(fēng)險無足夠用戶參與56需求獲取產(chǎn)品前景和項目范圍應(yīng)該在項目早期，編寫一份包括業(yè)務(wù)需求在內(nèi)的前景和范圍文檔，并將它作為添加新需求和修改現(xiàn)有需求的指導(dǎo)。需求開發(fā)所需的時間將每個項目中需求開發(fā)所耗費(fèi)的實際工作量記錄下來，這樣就可以判斷出需求開發(fā)是否充分，并可以改進(jìn)未來項目的工作計劃。需求規(guī)格說明的完整性和正確性為了確保需求是客戶真正需要的，應(yīng)該以用戶任務(wù)為中心，應(yīng)用用例技術(shù)來獲取需求。創(chuàng)新產(chǎn)品的需求對某類產(chǎn)品中的第1個產(chǎn)品，不太容易把握市場對產(chǎn)品的反映。定義非功能需求由于我們一般都會強(qiáng)調(diào)產(chǎn)品的功能，所以很容易忽略產(chǎn)品的非功能性需求。需求獲取產(chǎn)品前景和項目范圍57需求獲取客戶對產(chǎn)品需求意見一致確定那些主要的客戶，并采用產(chǎn)品代言人的方法，保證有足夠的客戶代表的積極參與未加說明的需求客戶經(jīng)常會有一些隱含的期望要求，但并未以文檔的方式說明出來。盡量識別客戶可能做出的任何假設(shè)。把已有的產(chǎn)品作為需求基線來源將通過逆向工程發(fā)現(xiàn)的需求編寫成文檔，讓客戶評審這些需求，以確保其正確性和相關(guān)性。根據(jù)需要提出解決方案分析人員必須提煉出隱藏在客戶提出的解決方案背后的真正意圖。需求獲取客戶對產(chǎn)品需求意見一致58需求分析設(shè)定需求優(yōu)先級要確保對每一個功能需求、特性或用例都設(shè)定了優(yōu)先級，并安排在一個特定的系統(tǒng)版本或迭代中實現(xiàn)它們。技術(shù)上難以實現(xiàn)的特性采用項目狀態(tài)跟蹤來監(jiān)控落后于實現(xiàn)計劃的需求，并盡早采取糾正措施。不熟悉的技術(shù)、方法、語言、工具或硬件留出足夠的時間用于從錯誤中學(xué)習(xí)經(jīng)驗、實驗及制作原型。需求分析設(shè)定需求優(yōu)先級59編寫需求規(guī)格說明需求理解開發(fā)人員和客戶對需求的不同理解會導(dǎo)致彼此間的期望差距，并最終導(dǎo)致交付的產(chǎn)品無法滿足客戶的需要。盡管問題待確定但迫于時間壓力而繼續(xù)向前在軟件需求規(guī)格說明中，將需要進(jìn)一步研究的地方標(biāo)上TBD，不失為一個好主意。具有二義性的術(shù)語對于不同的讀者可能會有不同解釋的業(yè)務(wù)術(shù)語或技術(shù)術(shù)語，應(yīng)該創(chuàng)建一個術(shù)語表對這些術(shù)語進(jìn)行定義。需求中包括了設(shè)計軟件需求規(guī)格說明中所包含的設(shè)計對開發(fā)人員做出有效選擇造成了不必要的限制，會妨礙他們發(fā)揮創(chuàng)造性設(shè)計出最佳方案。編寫需求規(guī)格說明需求理解60需求確認(rèn)未經(jīng)確認(rèn)的需求軟件需求規(guī)格說明會令人望而生畏，在開發(fā)過程早期編寫測試用例的想法就是基于這一點。審查熟練程度要對參與需求文檔審查的所有團(tuán)隊成員進(jìn)行培訓(xùn)，請組織內(nèi)部有經(jīng)驗的審查人員或外界的咨詢顧問來評述早先的審查。需求確認(rèn)未經(jīng)確認(rèn)的需求61需求管理變更需求將前景和范圍文檔作為批準(zhǔn)需求變更的參照，可以減少范圍蔓延。需求變更過程與需求變更的處理方式相關(guān)的風(fēng)險包括，缺少已定義的變更過程，采用無效的變更機(jī)制，以及不遵循制定的過程來做出變更。未實現(xiàn)的需求需求跟蹤矩陣有助于在設(shè)計、構(gòu)造或測試期間避免遺漏任何需求。擴(kuò)大目范圍如果最初的需求定義不夠好，那么進(jìn)一步定義需求就會擴(kuò)大項目的范圍。需求管理變更需求62風(fēng)險管理是我們的好幫手周期性地進(jìn)行風(fēng)險跟蹤可以使項目經(jīng)理了解風(fēng)險對項目的威脅，沒有得到有效控制的風(fēng)險應(yīng)該上報高層管理人員，他們可能開始采取一些糾正措施，也可能不管風(fēng)險，依舊按照原來的業(yè)務(wù)決策思路進(jìn)行。即使不能控制項目可能遇到的所有風(fēng)險，風(fēng)險管理也能幫助我們看清形勢，做出合理的決策。風(fēng)險管理是我們的好幫手周期性地進(jìn)行風(fēng)險跟蹤可以使項目經(jīng)理了解63風(fēng)險管理的措施明確你當(dāng)前項目面臨的一些與需求有關(guān)的風(fēng)險，不要把當(dāng)前的問題當(dāng)作風(fēng)險，一定要是那些還未發(fā)生的事情。將風(fēng)險因素編寫成文檔，為每項風(fēng)險推薦至少一種可能的降低風(fēng)險的方法。風(fēng)險管理的措施明確你當(dāng)前項目面臨的一些與需求有關(guān)的風(fēng)險，不要64風(fēng)險管理的措施召集代表開發(fā)、市場、客戶和管理各方面的涉眾召開風(fēng)險“集體研討”會議。盡力找出更多與需求有關(guān)的風(fēng)險因素。估計每項風(fēng)險發(fā)生的可能性及其影響，兩者乘積就是風(fēng)險危害值。通過按風(fēng)險危害值降序排列找到最高的五項風(fēng)險。為每項風(fēng)險安排一個負(fù)責(zé)人負(fù)責(zé)實施降低風(fēng)險的活動。風(fēng)險管理的措施召集代表開發(fā)、市場、客戶和管理各方面的涉眾召開65第23章需求跟蹤需求跟蹤提供了一個表明與合同或說明一致的方法。更進(jìn)一步，需求跟蹤可以改善產(chǎn)品質(zhì)量，降低維護(hù)成本，而且很容易實現(xiàn)重用。需求跟蹤鏈?zhǔn)鼓隳芨櫼粋€需求使用期限的全過程。通用的跟蹤模型顯示了我們要在軟件開發(fā)的不同層面全面地跟蹤需求。第23章需求跟蹤需求跟蹤提供了一個表明與合同或說明一致的方66需求跟蹤動機(jī)CMM的第三層次要求具備需求跟蹤能力。需求跟蹤動機(jī)67需求跟蹤的定義[IEEE，1994]

開發(fā)過程的兩個或多個產(chǎn)品之間能夠建立關(guān)系的程度，尤其是那些具有前后關(guān)系或主從關(guān)系的產(chǎn)品。例如，某個給定組件的需求和設(shè)計的匹配程度。軟件開發(fā)產(chǎn)品中每個元素能夠建立其存在理由的程度；例如，數(shù)據(jù)流圖中的每個元素定位它所滿足需求的程度。需求跟蹤的定義[IEEE，1994]開發(fā)過程的兩個或多個產(chǎn)68跟蹤關(guān)系跟蹤關(guān)系69需求跟蹤鏈需求跟蹤鏈70通用的跟蹤模型通用的跟蹤模型71跟蹤矩陣：用戶需要與特性

跟蹤矩陣：用戶需要與特性72跟蹤矩陣：特性與用例跟蹤矩陣：特性與用例73跟蹤矩陣：特性與非功能性需求

跟蹤矩陣：特性與非功能性需求74在實現(xiàn)領(lǐng)域跟蹤需求在實現(xiàn)領(lǐng)域跟蹤需求75從用例跟蹤到用例實現(xiàn)（一）從用例跟蹤到用例實現(xiàn)（一）76從用例實現(xiàn)跟蹤到實現(xiàn)（二）從用例實現(xiàn)跟蹤到實現(xiàn)（二）77從補(bǔ)充需求跟蹤到實現(xiàn)從補(bǔ)充需求跟蹤到實現(xiàn)78在測試領(lǐng)域跟蹤需求在測試領(lǐng)域跟蹤需求79跟蹤場景到測試用例跟蹤場景到測試用例80從用例到測試用例的跟蹤矩陣

從用例到測試用例的跟蹤矩陣81第24章需求管理工具商業(yè)需求管理工具，包括讓用戶從源文檔中產(chǎn)生需求，定義屬性值，操作和顯示數(shù)據(jù)庫內(nèi)容，讓需求以各式各樣的形式表現(xiàn)出來，定義跟蹤能力聯(lián)系鏈，讓需求同其他軟件開發(fā)工具相連等功能。使用需求管理工具的益處。如何實現(xiàn)需求管理自動化。商業(yè)需求管理工具介紹。第24章需求管理工具商業(yè)需求管理工具，包括讓用戶從源文82基于文檔存儲需求的限制很難保持文檔與現(xiàn)實的一致。不太容易做到為每一個需求保存增補(bǔ)的信息。很難在功能需求與相應(yīng)的使用實例、設(shè)計、代碼、測試和項目任務(wù)之間建立聯(lián)系鏈。很難跟蹤每個需求的狀態(tài)。基于文檔存儲需求的限制很難保持文檔與現(xiàn)實的一致。83商業(yè)需求管理工具以數(shù)據(jù)庫為核心的產(chǎn)品以文檔為核心的方法商業(yè)需求管理工具以數(shù)據(jù)庫為核心的產(chǎn)品84一些商業(yè)需求管理工具一些商業(yè)需求管理工具85實現(xiàn)需求管理自動化為需求管理工具定義項目需求。列出影響決策的10~15個因素。對上述步驟中列出的因素打分（總計100分）。獲得有關(guān)可用的需求管理工具的最新信息，根據(jù)影響決策的因素對候選工具排序。根據(jù)給每個因素的加權(quán)值來計算每個候選工具的得分，從而確定最合適的產(chǎn)品。從候選工具的其他用戶那里獲得一些體會。從候選工具中前三名的開發(fā)商處得到評估拷貝。最好用一個實際的項目來評估工具。經(jīng)過對排名、許可權(quán)費(fèi)、開發(fā)商后續(xù)支持費(fèi)、當(dāng)前用戶的輸入、工作小組主觀印象等的考慮之后做出決定。實現(xiàn)需求管理自動化為需求管理工具定義項目需求。86基于文檔的存儲需求的方法有許多局限性，例如：不容易保持文檔的最新和同步。需要將變更人工通知給受影響的所有團(tuán)隊成員。不容易存儲每一個需求的增補(bǔ)信息(屬性)。很難定義功能性需求和其他系統(tǒng)元素之間的聯(lián)系鏈。很難跟蹤需求狀態(tài)。很難同時管理多個分別用于不同產(chǎn)品版本或者相關(guān)產(chǎn)品的需求

集。想要重用需求，分析人員必須將文本從初始的軟件需求規(guī)格說明復(fù)制到每一個想要使用這一需求的系統(tǒng)或產(chǎn)品的軟件需求規(guī)格說明中。如果有多人參與項目，要修改需求是很困難的。沒有一個合適的地方可以方便地存儲提議之后被否決的那些需

求，以及已從基線中刪除的需求?；谖臋n的存儲需求的方法有許多局限性，例如：87使用需求管理工具的益處

項目需求的收集工作做得很好，也應(yīng)該使用自動化工具幫助您在開發(fā)過程中管理這些需求。隨著時間的推移，團(tuán)隊成員對需求細(xì)節(jié)的記憶會逐漸變得模糊，這時使用需求管理工具的益處就得到了最大程度的體現(xiàn)。下面介紹這種工具可以幫助我們完成哪些任務(wù)：管理版本和變更項目應(yīng)該定義需求基線，基線就是某一版本的產(chǎn)品要