第8章 軟件項目需求與變更管理

1、軟件項目管理軟件項目管理 軟件項目需求管理概述軟件項目需求管理概述 1軟件項目任務分解軟件項目任務分解 2第第8章章 軟件項目需求與變更管理軟件項目需求與變更管理3軟件需求的變更控制軟件需求的變更控制 學習目標學習目標掌握軟件需求的概念掌握軟件需求的概念熟悉需求管理的方法與過程熟悉需求管理的方法與過程掌握任務分解的方法與步驟掌握任務分解的方法與步驟掌握需求確認、變更控制和需求跟蹤的方法和過程掌握需求確認、變更控制和需求跟蹤的方法和過程第第8章章 軟件項目需求與變更管理軟件項目需求與變更管理Hot Tip軟件需求定義軟件需求定義 需求是來源于用戶調(diào)查，即客戶的需要。需求是來源于用戶調(diào)查，即客戶的

2、需要。 需求分析是指軟件分析人員通過需求分析是指軟件分析人員通過研究用戶在軟件問研究用戶在軟件問題上的需求意愿題上的需求意愿，分析出，分析出軟件系統(tǒng)的功能、性能、軟件系統(tǒng)的功能、性能、數(shù)據(jù)數(shù)據(jù)等諸方面應該達到的目標，從而獲得有關(guān)軟件等諸方面應該達到的目標，從而獲得有關(guān)軟件的的需求規(guī)格定義需求規(guī)格定義的過程。的過程。 8 .1 軟件項目需求管理概述軟件項目需求管理概述Hot Tip軟件需求定義軟件需求定義1用戶需求用戶需求特點：特點： （1）用戶需求直接來源于用戶）用戶需求直接來源于用戶 （2）用戶需求需要以文檔的形式提供給用戶審查）用戶需求需要以文檔的形式提供給用戶審查（3）可以把用戶需求理解

3、為用戶對軟件的合理請求）可以把用戶需求理解為用戶對軟件的合理請求（4）用戶需求主要是為用戶方的管理層、用戶方的技）用戶需求主要是為用戶方的管理層、用戶方的技術(shù)代表、操作者以及開發(fā)方的高層技術(shù)人員撰寫的術(shù)代表、操作者以及開發(fā)方的高層技術(shù)人員撰寫的8 .1 軟件項目需求管理概述軟件項目需求管理概述Hot Tip2系統(tǒng)需求系統(tǒng)需求（1）功能需求）功能需求 全面性全面性 一致性一致性 可理解可理解 可維護可維護 可追蹤等可追蹤等8 .1 軟件項目需求管理概述軟件項目需求管理概述（2）非功能性需求）非功能性需求性能需求、可靠性、可性能需求、可靠性、可用性需求、系統(tǒng)安全以及用性需求、系統(tǒng)安全以及系統(tǒng)對開發(fā)

4、過程、時間、系統(tǒng)對開發(fā)過程、時間、資源等方面的約束和標準資源等方面的約束和標準關(guān)心系統(tǒng)的整體特性關(guān)心系統(tǒng)的整體特性 （3）數(shù)據(jù)要求）數(shù)據(jù)要求Hot Tip3需求規(guī)格說明書的寫作規(guī)范需求規(guī)格說明書的寫作規(guī)范1）清晰）清晰 2）完整）完整 3）一致）一致 4）可測試）可測試 8 .1 軟件項目需求管理概述軟件項目需求管理概述需求的需求的重要性重要性需求是業(yè)務的根源，需求工作的優(yōu)劣對業(yè)務影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。8 .1 軟件項目需求管理概述軟件項目需求管理概述需求是缺陷主要來源需求是缺陷主要來源Requirem ents5 6 %D esign2 7 %O

5、 ther1 0 %C ode7 %錯誤定位費用分析錯誤定位費用分析Requirem ents82%D esign13%O ther4%C ode1%James Martin：超過50%的缺陷由不完善的、不正確的、不準確的和/或不明確的需求所引起James Martin：80%以上的用于定位業(yè)務錯誤的費用是基于業(yè)務系統(tǒng)需求定義的錯誤8 .1 軟件項目需求管理概述軟件項目需求管理概述一個小故事一個小故事如何練就需求分析的火眼金晴？如何練就需求分析的火眼金晴？ v5W + 1H + 8C v5W就是就是 Who、When、Where、What、WhyvWhy是關(guān)鍵是關(guān)鍵v1H就是就是 How 需求

6、本身的流程需求本身的流程v8C指的是指的是8個約束和限制，即個約束和限制，即8個個Constraints：v包括性能包括性能Performance、成本、成本Cost、時間、時間Time、可靠性可靠性Reliability、安全性、安全性Security、合規(guī)性、合規(guī)性Compliance、技術(shù)性、技術(shù)性Technology、兼容性、兼容性CompatibilityvDFX-Design for X 面向產(chǎn)品生命周期各環(huán)節(jié)的設(shè)面向產(chǎn)品生命周期各環(huán)節(jié)的設(shè)計。計。DFC、DFS明確的需求是項目的基礎(chǔ)明確的需求是項目的基礎(chǔ)1需求的生命周期：需求的生命周期：v需求產(chǎn)生（變化、內(nèi)部、外部）需求產(chǎn)生（變化

7、、內(nèi)部、外部）v需求認識（現(xiàn)存、潛在、超前、前景分析需求認識（現(xiàn)存、潛在、超前、前景分析）v需求表達：需求表達：1、讓提出需求的人盡可能清楚地說明他們的需、讓提出需求的人盡可能清楚地說明他們的需求；求；2、對需求提出一系列問題：、對需求提出一系列問題：明確的需求是項目的基礎(chǔ)明確的需求是項目的基礎(chǔ)明確的需求是項目的基礎(chǔ)明確的需求是項目的基礎(chǔ)2？提出需求的人是如何描述需求的提出需求的人是如何描述需求的？需求真實嗎，是真正需求還是表面現(xiàn)象？需求真實嗎，是真正需求還是表面現(xiàn)象？我們能滿足這個需求嗎，其他人能滿足嗎，是不是真的有？我們能滿足這個需求嗎，其他人能滿足嗎，是不是真的有解決方法解決方法？需求重

8、要嗎，值得去滿足他嗎？需求重要嗎，值得去滿足他嗎 ？滿足需求的關(guān)鍵問題在那里，會不會有新的需求產(chǎn)生，還？滿足需求的關(guān)鍵問題在那里，會不會有新的需求產(chǎn)生，還要進一步滿足其他需求嗎，新的需求能取代目前這個需求要進一步滿足其他需求嗎，新的需求能取代目前這個需求嗎嗎？需求直接涉及什么人，他們認為這是一個必要的需求嗎，？需求直接涉及什么人，他們認為這是一個必要的需求嗎，滿族足需求后對他們有什么影響，他們的反映會怎么樣滿族足需求后對他們有什么影響，他們的反映會怎么樣？需求對機構(gòu)的影響是什么，對我的影響是什么？需求對機構(gòu)的影響是什么，對我的影響是什么明確的需求是項目的基礎(chǔ)明確的需求是項目的基礎(chǔ)明確的需求是項

9、目的基礎(chǔ)明確的需求是項目的基礎(chǔ)33、作一些必要的研究工作，更好地理解需求作一些必要的研究工作，更好地理解需求4、根據(jù)以上三步得出結(jié)論，盡可能清楚地描述這個、根據(jù)以上三步得出結(jié)論，盡可能清楚地描述這個需求需求5、聽聽用戶對你的闡述的反映，并作適當修改。、聽聽用戶對你的闡述的反映，并作適當修改。v功能和技術(shù)要求功能和技術(shù)要求1、把需求變成功能要求；、把需求變成功能要求；2、功能要求應描述項目最終交付產(chǎn)品的特征、功能要求應描述項目最終交付產(chǎn)品的特征3、技術(shù)要求根據(jù)功能要求產(chǎn)生、技術(shù)要求根據(jù)功能要求產(chǎn)生4、功能要求應用日常語言陳述清楚、功能要求應用日常語言陳述清楚明確的需求是項目的基礎(chǔ)明確的需求是項目

10、的基礎(chǔ)定義需求時的問題定義需求時的問題1v含糊的需求：含糊的需求：1、不斷變化的需求（人員變化、預算變化、不斷變化的需求（人員變化、預算變化、技術(shù)變化、商業(yè)環(huán)境變化）技術(shù)變化、商業(yè)環(huán)境變化）2、誤解需求、誤解需求（我說不清楚我所需要的是什么，但我見到（我說不清楚我所需要的是什么，但我見到東西時就會知道東西時就會知道感覺會隨環(huán)境變化）感覺會隨環(huán)境變化）v過早作出結(jié)論（過早作出結(jié)論（截斷需要表達過程截斷需要表達過程需求分析需求分析需要耐心和自我控制需要耐心和自我控制）v與真正的用戶討論需求與真正的用戶討論需求定義需求時的問題定義需求時的問題定義需求時的問題定義需求時的問題2v多種用戶，多種需求（多

11、種用戶，多種需求（確定優(yōu)先級，即需求層次確定優(yōu)先級，即需求層次）v曲解用戶的需求曲解用戶的需求需求鍍金需求鍍金對用戶的需求有選擇的過濾對用戶的需求有選擇的過濾包辦代替包辦代替定義需求時的問題定義需求時的問題 需求和目標需求和目標v 基本需求基本需求: : 項目實施范圍、質(zhì)量要求、項目實施范圍、質(zhì)量要求、 利潤或成本目標、時間目標以及必須滿利潤或成本目標、時間目標以及必須滿 足的法規(guī)要求等足的法規(guī)要求等v 期望要求期望要求: : 如一種新產(chǎn)品性能之外的外形、如一種新產(chǎn)品性能之外的外形、使用舒適使用舒適Hot Tip 需求管理需求管理1需求管理復雜性分析需求管理復雜性分析 需求的描述問題需求的描述

12、問題 需求的完備程度問題需求的完備程度問題 需求開發(fā)的工期問題需求開發(fā)的工期問題 需求的細致程度問題需求的細致程度問題 需求的變化問題需求的變化問題 8 .1 軟件項目需求管理概述軟件項目需求管理概述Hot Tip 需求管理需求管理2需求管理的基本原則需求管理的基本原則 需求管理必須與需求工程的其它活動緊密整合需求管理必須與需求工程的其它活動緊密整合 需求必須是文檔化的、正確的、最新的、可管理的、需求必須是文檔化的、正確的、最新的、可管理的、可理解的可理解的 只要需求變化了，需求變更的影響就必須被評估只要需求變化了，需求變更的影響就必須被評估 需求必須分優(yōu)先級需求必須分優(yōu)先級 需求一定要分類管

13、理需求一定要分類管理 8 .1 軟件項目需求管理概述軟件項目需求管理概述Hot Tip3需求管理的方法需求管理的方法 確定需求變更控制過程確定需求變更控制過程 進行需求變更影響分析進行需求變更影響分析 建立需求基準版本和需求控制版本文檔建立需求基準版本和需求控制版本文檔 維護需求變更的歷史記錄維護需求變更的歷史記錄 跟蹤每項需求的狀態(tài)跟蹤每項需求的狀態(tài) 衡量需求穩(wěn)定性衡量需求穩(wěn)定性8 .1 軟件項目需求管理概述軟件項目需求管理概述Hot Tip 需求管理過程需求管理過程1定義需求定義需求2需求確認需求確認3建立需求狀態(tài)建立需求狀態(tài)4需求評審需求評審 評判需求優(yōu)劣的主要指標有：正確性、清晰性、評

14、判需求優(yōu)劣的主要指標有：正確性、清晰性、無二義性、一致性、必要性、完整性、可實現(xiàn)無二義性、一致性、必要性、完整性、可實現(xiàn)性、可驗證性、可測性。性、可驗證性、可測性。 8 .1 軟件項目需求管理概述軟件項目需求管理概述Hot Tip 需求管理過程需求管理過程5需求承諾需求承諾6需求跟蹤需求跟蹤 正向跟蹤：以用戶需求為切入點，檢查正向跟蹤：以用戶需求為切入點，檢查需求需求規(guī)格說明書規(guī)格說明書中的每個需求是否都能在后繼工中的每個需求是否都能在后繼工作產(chǎn)品中找到對應點。作產(chǎn)品中找到對應點。 逆向跟蹤：檢查設(shè)計文檔、代碼、測試用例等逆向跟蹤：檢查設(shè)計文檔、代碼、測試用例等工作產(chǎn)品是否都能在工作產(chǎn)品是否都

15、能在需求規(guī)格說明書需求規(guī)格說明書中找中找到出處。到出處。 7需求變更控制需求變更控制8 .1 軟件項目需求管理概述軟件項目需求管理概述 需求分析在工程中的位置需求分析在工程中的位置用戶用戶/ /系統(tǒng)系統(tǒng)業(yè)務業(yè)務管理者管理者初始需求初始需求變更的需求變更的需求獲取獲取, ,分分析析, ,定義定義, ,驗證需求驗證需求控制需求控制需求變更變更需求規(guī)格說明需求規(guī)格說明項目項目環(huán)境環(huán)境需求開發(fā)需求開發(fā)需求管理需求管理需求工程活動綜合關(guān)系需求工程活動綜合關(guān)系三要點三要點：需求確認、需求變更控制、需求跟蹤：需求確認、需求變更控制、需求跟蹤需求管理的需求管理的三要點三要點 需求管理的目的是在用戶與開發(fā)方之間

16、建需求管理的目的是在用戶與開發(fā)方之間建立對需求的共同理解，維護需求與工作成立對需求的共同理解，維護需求與工作成果的一致性，并控制需求的變更。果的一致性，并控制需求的變更。 需求工程貫穿開發(fā)全過程需求工程貫穿開發(fā)全過程質(zhì)量屬性DFX功能需求非功能需求書面標準事實標準Hot Tip 工作分解結(jié)構(gòu)工作分解結(jié)構(gòu) 項目的分解結(jié)構(gòu)就是將項目的產(chǎn)品或服務、組項目的分解結(jié)構(gòu)就是將項目的產(chǎn)品或服務、組織、過程這織、過程這3種不同的結(jié)構(gòu)綜合為項目分解結(jié)構(gòu)的過種不同的結(jié)構(gòu)綜合為項目分解結(jié)構(gòu)的過程，也就是給項目的組織人員分派各自角色和任務的程，也就是給項目的組織人員分派各自角色和任務的過程。過程。 基于成果或功能的分

17、解方法，以完成該項目應該交付基于成果或功能的分解方法，以完成該項目應該交付的成果為導向，確定相關(guān)的任務、工作、活動和要素的成果為導向，確定相關(guān)的任務、工作、活動和要素。 基于流程的分解方法，以完成該項目所應經(jīng)歷的流程基于流程的分解方法，以完成該項目所應經(jīng)歷的流程為導向，確定相關(guān)的任務、工作、活動和要素。為導向，確定相關(guān)的任務、工作、活動和要素。8 .2 軟件項目任務分解軟件項目任務分解Hot Tip 工作分解結(jié)構(gòu)工作分解結(jié)構(gòu)（1）圖表形式）圖表形式 分解層次與結(jié)構(gòu)分解層次與結(jié)構(gòu) 8 .2 軟件項目任務分解軟件項目任務分解Hot Tip 工作包是完成一項具體工作所要求的一個工作包是完成一項具體工

18、作所要求的一個特定的、可確定的、可交付以及獨立的工作包特定的、可確定的、可交付以及獨立的工作包，可為項目控制提供充分而合適的管理信息。，可為項目控制提供充分而合適的管理信息。 WBS編碼設(shè)計編碼設(shè)計 8 .2 軟件項目任務分解軟件項目任務分解Hot Tip（2）清單形式）清單形式需求分析計劃需求分析計劃流程優(yōu)化流程優(yōu)化編寫需求說明書編寫需求說明書編寫需求規(guī)格詞匯表編寫需求規(guī)格詞匯表繪制業(yè)務流程繪制業(yè)務流程抽象業(yè)務類抽象業(yè)務類建立數(shù)據(jù)模型建立數(shù)據(jù)模型將需求分析圖示加入規(guī)格文檔將需求分析圖示加入規(guī)格文檔需求規(guī)格測試需求規(guī)格測試 需求規(guī)格確認需求規(guī)格確認8 .2 軟件項目任務分解軟件項目任務分解Ho

19、t Tip 任務分解過程任務分解過程1分解步驟分解步驟（1）確認并分解項目的主要組成要素。）確認并分解項目的主要組成要素。（2）確定分解標準）確定分解標準（3）確認分解是否詳細，分解結(jié)果是否可以作為）確認分解是否詳細，分解結(jié)果是否可以作為費用和時間估計的標準，明確責任。費用和時間估計的標準，明確責任。（4）確定項目交付成果。）確定項目交付成果。（5）驗證分解正確性，驗證分解正確性后，）驗證分解正確性，驗證分解正確性后，建立建立一套編號系統(tǒng)一套編號系統(tǒng)。8 .2 軟件項目任務分解軟件項目任務分解Hot Tip 任務分解過程任務分解過程2分解的標準分解的標準:一般不能采用雙重標準。選擇一種項一般不

20、能采用雙重標準。選擇一種項目分解標準之后，在分解過程中應該統(tǒng)一使用此標目分解標準之后，在分解過程中應該統(tǒng)一使用此標準，避免因使用不同標準而導致的混亂。準，避免因使用不同標準而導致的混亂。 3分解結(jié)果的檢驗分解結(jié)果的檢驗 核實分解的正確性：核實分解的正確性： 更低層次的細目是否必要和充分？更低層次的細目是否必要和充分？ 最底層要素是否有重復？最底層要素是否有重復？ 每個細目都有明確的、完整的定義嗎？每個細目都有明確的、完整的定義嗎？ 是否每個細目可以進行適當?shù)墓浪?？誰能擔負起完是否每個細目可以進行適當?shù)墓浪悖空l能擔負起完成這個任務？成這個任務？8 .2 軟件項目任務分解軟件項目任務分解Hot T

21、ip4任務分解的注意事項任務分解的注意事項 注意收集與項目相關(guān)的所有信息。注意收集與項目相關(guān)的所有信息。 任務分解結(jié)果必須有利于責任分配。任務分解結(jié)果必須有利于責任分配。 最底層的工作包一般要有全面、詳細和明確的文字最底層的工作包一般要有全面、詳細和明確的文字說明，并匯集編制成項目工作分解結(jié)構(gòu)詞典。說明，并匯集編制成項目工作分解結(jié)構(gòu)詞典。 避免不必要的過細，最好避免不必要的過細，最好不要超過不要超過7層層。按照軟件。按照軟件項目的平均規(guī)模來說，推薦任務分解時至少分解到項目的平均規(guī)模來說，推薦任務分解時至少分解到一周的工作量（一周的工作量（40小時）小時）。8 .2 軟件項目任務分解軟件項目任務

22、分解Hot Tip5責任分配及成本分解責任分配及成本分解8 .2 軟件項目任務分解軟件項目任務分解WBS編號編號預算預算責任者責任者WBS編號編號預算預算責任者責任者10.1張明張明3.30.15李立李立20.46李立李立3.40.1李立李立30. 46張明、李立張明、李立3.50.02張明張明3.10.04張明張明40.08萬風萬風3.20.15李立李立50.1張明張明Hot Tip需求確認需求確認 需求確認是指開發(fā)方和用戶共同對需求文檔進需求確認是指開發(fā)方和用戶共同對需求文檔進行評審，雙方對需求達成共識后做出書面承諾，行評審，雙方對需求達成共識后做出書面承諾，使需求文檔具有商業(yè)合同效果。使

23、需求文檔具有商業(yè)合同效果。8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤項目開發(fā)面臨的實際問題8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤需求確認需求確認項目開發(fā)面臨的實際問題8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤需求確認需求確認項目開發(fā)面臨的實際問題8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤需求確認需求確認需求驗證的目的和任務需求驗證的目的和任務需求確認的目的和任務需求確認的目的和任務需求驗證的目的就是要確保軟件需求具有良好的特需求驗證的目的就是要確保軟件需求具有良好的特性（如完整性

24、，正確性等）。性（如完整性，正確性等）。需求驗證包含的活動需求驗證包含的活動滿足性（功能需求是否滿足需要）滿足性（功能需求是否滿足需要）滿意性（非功能需求是否滿意）滿意性（非功能需求是否滿意）明確及含蓄的需求明確及含蓄的需求(失敗失敗)、(成功成功)共識行（是否能共同理解）可行性（技術(shù)是否可行）共識行（是否能共同理解）可行性（技術(shù)是否可行）明晰性（信息是否存在含混性）明晰性（信息是否存在含混性）8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤需求確認需求確認需求確認的方法：需求確認的方法：1、為需求進行正式評審、為需求進行正式評審2、為需求寫測試用例、為需求寫測試用例3、

25、用檢查單識別常見問題、用檢查單識別常見問題4、為需求設(shè)定優(yōu)先級、為需求設(shè)定優(yōu)先級5、最后：形成總體共識、最后：形成總體共識8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤需求確認需求確認1、為需求進行正式評審、為需求進行正式評審v1、為需求進行正式評審、為需求進行正式評審8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤需求確認需求確認需求評審做不好的后果：需求評審做不好的后果： 需求變更需求變更 需求不明確需求不明確 需求不可測需求不可測 需求不可實現(xiàn)需求不可實現(xiàn) 導致后續(xù)工作難于開展或經(jīng)常出現(xiàn)變更導致后續(xù)工作難于開展或經(jīng)常出現(xiàn)變更 由于需求未能得到

26、有效管理，由于需求未能得到有效管理， 在最終項目在最終項目驗收過程中出現(xiàn)了令人不愉快的情況，實際驗收過程中出現(xiàn)了令人不愉快的情況，實際開發(fā)的軟件沒能完全反映用戶的需求，導致開發(fā)的軟件沒能完全反映用戶的需求，導致用戶不滿意，項目延期。用戶不滿意，項目延期。8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤需求確認做不好的后果需求確認做不好的后果如何進行需求評審如何進行需求評審1、為需求進行正式評審、為需求進行正式評審 如何進行需求評審如何進行需求評審 參與需求分析和評審的人員的管理參與需求分析和評審的人員的管理 軟件需求文檔的管理軟件需求文檔的管理 需求分析過程的管理需求分析

27、過程的管理 需求變更的管理需求變更的管理8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤v例1：“產(chǎn)品應在不少于每秒的正常周期內(nèi)提供狀態(tài)信息?！眝分析：這個需求是不完整的：分析：這個需求是不完整的：v 狀態(tài)信息是什么，如何顯示給用戶。這個需求有狀態(tài)信息是什么，如何顯示給用戶。這個需求有幾處含糊。我們在談論產(chǎn)品的哪部分？狀態(tài)信息間幾處含糊。我們在談論產(chǎn)品的哪部分？狀態(tài)信息間隔真的假定為不少于秒？，甚者每隔真的假定為不少于秒？，甚者每10年顯示一條新年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應的狀態(tài)信息也可以？也許它的意圖是消息間隔不應超過秒，那么超過秒，那么1毫

28、秒是不是太短？毫秒是不是太短？“每每”這個詞導這個詞導致了不確定性。問題的后果，就是需求的不可證實。致了不確定性。問題的后果，就是需求的不可證實。8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤例1需求： 后臺任務管理器因以誤差上下不超過后臺任務管理器因以誤差上下不超過10秒的秒間隔，秒的秒間隔，在用戶界面的指定位置顯示狀態(tài)信息；在用戶界面的指定位置顯示狀態(tài)信息； 如果后臺進程處理正常，那么應該顯示任務已完成如果后臺進程處理正常，那么應該顯示任務已完成的百分數(shù)的百分數(shù)/比；比； 任務完成時，應顯示相關(guān)的信息；任務完成時，應顯示相關(guān)的信息； 后臺任務出錯應該顯示錯誤信息；后

29、臺任務出錯應該顯示錯誤信息； 為了測試和追蹤，將需求分解多個子需求。使在構(gòu)為了測試和追蹤，將需求分解多個子需求。使在構(gòu)造和測試時，被易于分別執(zhí)行。造和測試時，被易于分別執(zhí)行。8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤v例2：“產(chǎn)品應瞬間在文本中的顯示和隱藏不可打印字符間切換” 計算機在瞬間不能做任何事，所以這個需求不計算機在瞬間不能做任何事，所以這個需求不切實可行。它的不完整性表現(xiàn)在沒有聲明觸發(fā)狀態(tài)切實可行。它的不完整性表現(xiàn)在沒有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？或者切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些什么動作？而且

30、，在文用戶為了模仿更改要做一些什么動作？而且，在文檔中改變顯示的范圍是多大：選中的文本？整個的檔中改變顯示的范圍是多大：選中的文本？整個的文檔，或其他的？這也是個模模糊的問題。不可打文檔，或其他的？這也是個模模糊的問題。不可打印字符和隱藏字符一樣嗎？或者是一些屬性標志或印字符和隱藏字符一樣嗎？或者是一些屬性標志或一些控制字符？問題的后果，就是需求的不可證實。一些控制字符？問題的后果，就是需求的不可證實。8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤例2需求： 用戶能夠在一個由特定觸發(fā)條件激活處于編用戶能夠在一個由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏所有輯的文檔中

31、在顯示和隱藏所有HTML標記間標記間切換。切換。v現(xiàn)在就很清楚，不可打印字符是現(xiàn)在就很清楚，不可打印字符是HTML標記。標記。由于沒有定義觸發(fā)條件，需求對設(shè)計沒有約由于沒有定義觸發(fā)條件，需求對設(shè)計沒有約束力。只有設(shè)計人員選定了觸發(fā)條件后，你束力。只有設(shè)計人員選定了觸發(fā)條件后，你才能編寫測試驗證觸發(fā)的正確操作。才能編寫測試驗證觸發(fā)的正確操作。8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤v例3：“HTML分析器可以產(chǎn)生HTML標記錯誤報告，幫助HTML入門者快速解決錯誤”。v單詞單詞“快速快速”使其模糊，沒有加進錯誤報告使其模糊，沒有加進錯誤報告的定義也是不完整的。我不知

32、道，你怎么驗的定義也是不完整的。我不知道，你怎么驗證這個需求。找一個自稱為證這個需求。找一個自稱為HTML的入門者，的入門者，看看能不能根據(jù)錯誤報告快速解決錯誤？看看能不能根據(jù)錯誤報告快速解決錯誤？8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤例3需求：v“HTML分析器可以產(chǎn)生一個錯誤報告，錯分析器可以產(chǎn)生一個錯誤報告，錯誤報告包含有在被分析文件中出錯的誤報告包含有在被分析文件中出錯的HTML文本和行號以及錯誤的描述。如果沒有錯誤，文本和行號以及錯誤的描述。如果沒有錯誤，就不會產(chǎn)生錯誤報告就不會產(chǎn)生錯誤報告”。v現(xiàn)在我們知道了，什么會被加到出錯報告中，現(xiàn)在我們知道了，

33、什么會被加到出錯報告中，但是出錯報告是個什么樣子，則留由設(shè)計人但是出錯報告是個什么樣子，則留由設(shè)計人員決定。我們還指定了一個例外：如果沒有員決定。我們還指定了一個例外：如果沒有發(fā)現(xiàn)錯誤，不產(chǎn)生錯誤報告。發(fā)現(xiàn)錯誤，不產(chǎn)生錯誤報告。8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤 練習：以下描述哪些屬于不精確的用戶需求描述？如果不精確，應如何改正？ 1）系統(tǒng)應表現(xiàn)出良好的響應速度。）系統(tǒng)應表現(xiàn)出良好的響應速度。 不精確，應指出具體項目和響應時間。不精確，應指出具體項目和響應時間。 2）系統(tǒng)必須用菜單驅(qū)動。）系統(tǒng)必須用菜單驅(qū)動。 “必須必須”不精確，因系統(tǒng)還可以用其他方式驅(qū)動。

34、不精確，因系統(tǒng)還可以用其他方式驅(qū)動。 3）在數(shù)據(jù)錄入界面，應該有）在數(shù)據(jù)錄入界面，應該有10個按鈕。個按鈕。 不精確，因過于細致，限制了設(shè)計的自由度。不精確，因過于細致，限制了設(shè)計的自由度。 4）系統(tǒng)運行時占用的內(nèi)存不得超過）系統(tǒng)運行時占用的內(nèi)存不得超過200M。 僅是一個約束條件。僅是一個約束條件。 5）電梯應平穩(wěn)運行。）電梯應平穩(wěn)運行。 不精確，應指出加速、減速、運行速度的大小。不精確，應指出加速、減速、運行速度的大小。 6）即使系統(tǒng)崩潰，也不能損壞用戶數(shù)據(jù)。）即使系統(tǒng)崩潰，也不能損壞用戶數(shù)據(jù)。 不精確，因這是一個難以保證的不精確，因這是一個難以保證的“用戶需求用戶需求”。8 .3 軟件需

35、求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤2、為需求寫測試用例、為需求寫測試用例2、為需求寫測試用例、為需求寫測試用例v目標是識別需求的含混性目標是識別需求的含混性 以需求為基礎(chǔ)，并視其為黑盒子，然后編寫測試用例。以需求為基礎(chǔ)，并視其為黑盒子，然后編寫測試用例。 要覆蓋需求常見的測試點要覆蓋需求常見的測試點入口條件入口條件出口條件出口條件主事件流主事件流可選事件流可選事件流1. 非功能需求非功能需求8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤3、用檢查單識別常見問題用檢查單識別常見問題4、為需求設(shè)定優(yōu)先級、為需求設(shè)定優(yōu)先級4、為需求設(shè)定優(yōu)先級v支持項目分期

36、交付v支持需求取舍之道v支持需求的模式化8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤 為什么要設(shè)定需求的優(yōu)先級為什么要設(shè)定需求的優(yōu)先級軟件開發(fā)受時間、成本、質(zhì)量等多種資源的限制，同時軟件開發(fā)的高不確定性，導致 需求在項目結(jié)束時往往難以被全部實現(xiàn)。需求在項目結(jié)束時往往難以被全部實現(xiàn)。因此需要在需求開發(fā)階段，對需求進行分解，設(shè)定優(yōu)先級設(shè)定優(yōu)先級，先實現(xiàn)優(yōu)先級別較高的需求，有助于維護項目收益和提高項目成功率。有助于維護項目收益和提高項目成功率。v 基于價值、費用和風險的優(yōu)先級設(shè)定基于價值、費用和風險的優(yōu)先級設(shè)定 費用方法（費用方法（CostCost）：）： 價值方法（價值方

37、法（ValueValue）：）： 風險方法（風險方法（RiskRisk）：）：最小費用優(yōu)先原則最小費用優(yōu)先原則最高價值優(yōu)先原則最高價值優(yōu)先原則最低風險優(yōu)先原則最低風險優(yōu)先原則 它們本質(zhì)上從單一視角探尋適用標準來評價它們本質(zhì)上從單一視角探尋適用標準來評價每個需求，并且計算出一個分值用于編排需求的每個需求，并且計算出一個分值用于編排需求的優(yōu)先級。優(yōu)先級。 如何設(shè)定需求的優(yōu)先級如何設(shè)定需求的優(yōu)先級基于價值、費用和風險的優(yōu)先級設(shè)定基于價值、費用和風險的優(yōu)先級設(shè)定XXXXX%XXX%XXX%XXXXn. XXXXX優(yōu)先級 風險% 相對風險 費用% 相對費用 價值% 總價值 相對損失 相對利潤 需求/特性

38、XXXXX%XXX%XXX%XXXX1. XXXXX總計XXXX相對權(quán)值在一個平面中列出要設(shè)定優(yōu)先級的所有需求、特性或使用實例；在這個例子中，我們將使用特性來設(shè)定優(yōu)先級。所有項都必須在同一抽象級別上；不要把個人需求與產(chǎn)品特性混合在一起。如果某些特性有邏輯上的聯(lián)系（例如，只有包括特性A的情況下才能實現(xiàn)特性B）那么在分析中只要列出驅(qū)動特性就可以了。這種模型在其有效范圍內(nèi)可以容納幾十種特性。如果你有更多的項，那么就把相關(guān)的特性歸成一類，并建立一個可管理的初始化列表。如果你需要的話，可以在更詳細的級別上進行第二輪分析。估計每一個特性提供給客戶或業(yè)務的相關(guān)利益，并用1 9劃分等級，1代表可忽略的利益，9

39、代表最大的價值。這些利益等級表明了與產(chǎn)品的業(yè)務需求的一致性。客戶代表是判斷這些利益的最佳人選。在缺省情況下，利潤和損失的權(quán)值是相等的，作為一種精化，你可以更改這兩個因素的相對權(quán)值。估計出如果沒有把應該實現(xiàn)的特性包括到產(chǎn)品中，將會給客戶或業(yè)務上帶來的損失。使用1 9劃分等級，這里1代表基本無損失， 9代表嚴重損失?？們r值相對利潤相對損失價值%=總價值/總計價值100 根據(jù)需求的復雜度，所需求的用戶界面的實現(xiàn)情況、重用當前代碼的潛在能力、所需要的測試量和文檔等等，開發(fā)者可以估算出費用。 估計實現(xiàn)每個特性的相對費用，使用1（低） 9（高）劃分等級。平面圖將計算出由每一個特性所構(gòu)成的總費用的百分比。開

40、發(fā)者應該要估計出與每個特性相關(guān)的技術(shù)或風險相對程度，并利用1 9劃分等級。1級表示你可以輕而易舉地實現(xiàn)編程，而9級表示需要極大地關(guān)注其可行性、缺乏具有專門知識的人員，或者使用不成熟或不熟悉的工具和技術(shù)。平面圖將計算出每個特性所產(chǎn)生的風險百分比。在缺省情況下，利潤損失，費用和風險的權(quán)值是相等的，但是你可以在平面圖中調(diào)整其權(quán)值。如果你無需在模型中考慮風險，就把風險的權(quán)值設(shè)為0。 價值%優(yōu)先級（費用%費用權(quán)值）（風險%風險權(quán)值）基于價值、費用和風險的優(yōu)先級設(shè)定基于價值、費用和風險的優(yōu)先級設(shè)定優(yōu)先級設(shè)定演示優(yōu)先級設(shè)定演示相對權(quán)相對權(quán)值值2 21 11 10.5 0.5 需求需求/ / 特性特性相對相對

41、利潤利潤 相對相對損失損失 總總價值價值 價值價值% % 相對相對費用費用 費用費用% % 相對相對風險風險 風險風險% % 優(yōu)先級優(yōu)先級 UC1UC15 53 313138.48.42 28 81 13.03.01.3451.345UC2UC29 97 7252516.216.25 511.911.93 39.19.10.9870.987UC3UC35 55 515159.79.73 37.17.12 26.16.10.9570.957UC4UC42 21 15 53.23.21 12.42.41 13.03.00.8330.833UC5UC54 49 9171711.011.04 49.5

42、9.54 412.112.1 0.7080.708UC6UC64 43 311117.17.13 37.17.12 26.16.10.7020.702UC7UC76 62 214149.19.14 49.59.53 39.19.10.6460.646UC8UC89 98 8262616.916.97 716.716.78 822220.5860.586UC9UC93 34 410106.56.54 49.59.52 26.16.10.5170.517UC10UC107 74 48 811.711.79 921.421.47 721.221.2 0.3650.365總計總計54544646154

43、15410010042421001003333100100迭代迭代1 BaseLine=UC1-3迭代迭代2BaseLine=UC4-6迭代迭代3 BaseLine=UC7-95、最后：形成總體共識、最后：形成總體共識 本需求文檔建立在雙方對需求的共同理解基礎(chǔ)上，我本需求文檔建立在雙方對需求的共同理解基礎(chǔ)上，我同意后續(xù)的開發(fā)工作根據(jù)該需求文檔開展。如果需求發(fā)同意后續(xù)的開發(fā)工作根據(jù)該需求文檔開展。如果需求發(fā)生變化，我們將按照生變化，我們將按照“需求變更控制規(guī)程需求變更控制規(guī)程”執(zhí)行。我明白，執(zhí)行。我明白，需求的變更將導致雙方重新協(xié)商成本、資源和進度等。需求的變更將導致雙方重新協(xié)商成本、資源和進度

44、等。 甲方負責人簽字甲方負責人簽字 乙方負責人簽字乙方負責人簽字8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤1 1、什么是需求變更？、什么是需求變更？需求變更控制、需求變更控制、（范圍控制）（范圍控制）初始需求變更的需求對問題的初始理解對問題的新理解時間時間二、控制需求變更二、控制需求變更8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤Hot Tip 需求的變更要經(jīng)過出資者的認可需求的變更要經(jīng)過出資者的認可,這樣才會對需求的這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。變更有成本的概念，能夠慎重地對待需求的變更。 小的需求變更也要經(jīng)

45、過正規(guī)的需求管理流程，否則小的需求變更也要經(jīng)過正規(guī)的需求管理流程，否則會積少成多。會積少成多。 精確的需求與范圍定義并不會阻止需求的變更。并精確的需求與范圍定義并不會阻止需求的變更。并非對需求定義的越細，越能避免需求的漸變，這是非對需求定義的越細，越能避免需求的漸變，這是兩個層面的問題。太細的需求定義對需求漸變沒有兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的，并非由于需任何效果。因為需求的變化是永恒的，并非由于需求細化了，它就不會變化了。求細化了，它就不會變化了。8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤二、控制需求變更二、控制需求變

46、更受控的需求需求文檔V1系統(tǒng)實現(xiàn)V1系統(tǒng)實現(xiàn)V2需求變更二、控制需求變更二、控制需求變更8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤Hot Tip2變更控制過程變更控制過程（1）項目啟動階段的變更預防）項目啟動階段的變更預防（2）項目實施階段的變更控制）項目實施階段的變更控制（3）項目收尾階段的總結(jié)控制）項目收尾階段的總結(jié)控制 8 .3 軟件需求的變更控制軟件需求的變更控制Hot Tip 3、需求變更處理流程、需求變更處理流程 8 .3 軟件需求的變更控制軟件需求的變更控制受控的需求變更需求文檔需求文檔V1V1需求文檔需求文檔V2V2系統(tǒng)實現(xiàn)系統(tǒng)實現(xiàn)V1V1系統(tǒng)實現(xiàn)系

47、統(tǒng)實現(xiàn)V2V2需求變更需求變更由由CCBCCB委員會裁定委員會裁定8 .3 軟件需求的確認、變更控制和跟蹤軟件需求的確認、變更控制和跟蹤CCBCCB的解釋的解釋vCCB 變更控制委員會(Change Control Board)vCCB 是系統(tǒng)集成項目的所有者權(quán)益代表，負載裁定接受那些變更。CCB由項目所涉及的多方成員共同組成，通常包括用戶和實施方的決策人員。CCB是決策機構(gòu)，不是作業(yè)機構(gòu)，通常CCB的工作是通過評審手段來決定項目是否能變更，不提出變更方案。 需求變更申請單（我國）需求變更申請單（我國）變更管理五級成熟度模型變更管理五級成熟度模型需求變更案例分析需求變更案例分析p面對客戶的需求

48、變更，接受還是拒面對客戶的需求變更，接受還是拒絕？絕？在某公司的項目管理課堂上，小李，小在某公司的項目管理課堂上，小李，小王、小林等人正在七嘴八舌地議論紛紛。王、小林等人正在七嘴八舌地議論紛紛。原來，大家正在討論公司最近遇到的兩原來，大家正在討論公司最近遇到的兩個頗為有趣的項目。個頗為有趣的項目。情況情況1：盡量滿足用戶需要：盡量滿足用戶需要據(jù)小王介紹，這兩個項目分別由兩個項據(jù)小王介紹，這兩個項目分別由兩個項目經(jīng)理來擔任。其中，項目經(jīng)理目經(jīng)理來擔任。其中，項目經(jīng)理A A屬于屬于“謙虛謙虛”型，對于客戶提出的問題，無型，對于客戶提出的問題，無論大小都給與解決，客戶對此非常滿意，論大小都給與解決，

49、客戶對此非常滿意，然而，項目進度卻拖得比較長，而且，然而，項目進度卻拖得比較長，而且，客戶總想把所有的問題都改完再說，項客戶總想把所有的問題都改完再說，項目已經(jīng)一再延期。目已經(jīng)一再延期。情況情況2：嚴格執(zhí)行項目計劃：嚴格執(zhí)行項目計劃v相比之下，項目經(jīng)理相比之下，項目經(jīng)理B B顯得稍有些顯得稍有些“盛盛氣凌人氣凌人”，對于客戶提出的問題，大多，對于客戶提出的問題，大多都不予理睬，客戶對此不是很滿意，不都不予理睬，客戶對此不是很滿意，不過，該項目的進度控制得比較好，基本過，該項目的進度控制得比較好，基本能夠按期完成項目。能夠按期完成項目。分析分析1 不太遷就用戶不太遷就用戶小王：小王：“對項目經(jīng)理

50、來說，成本、質(zhì)量對項目經(jīng)理來說，成本、質(zhì)量和時間是最為重要的三要素。與客戶的和時間是最為重要的三要素。與客戶的關(guān)系當然很重要，但也要全盤考慮項目關(guān)系當然很重要，但也要全盤考慮項目的各要素。對于用戶的要求，應該在有的各要素。對于用戶的要求，應該在有限的范圍內(nèi)給與解決，但不可以做出太限的范圍內(nèi)給與解決，但不可以做出太大的犧牲。一味的遷就用戶將會使整個大的犧牲。一味的遷就用戶將會使整個項目失敗。項目失敗?！狈治龇治? 堅持原則，適當調(diào)節(jié)用戶關(guān)系堅持原則，適當調(diào)節(jié)用戶關(guān)系小林：小林：“當前，國內(nèi)的項目一般情況下是由當前，國內(nèi)的項目一般情況下是由銷售處面簽單，再由項目經(jīng)理接手后續(xù)的工銷售處面簽單，再由項

51、目經(jīng)理接手后續(xù)的工作，因此客戶關(guān)系多在事前已經(jīng)搞定。發(fā)生作，因此客戶關(guān)系多在事前已經(jīng)搞定。發(fā)生新的情況后，可以由公司的公關(guān)部出面與客新的情況后，可以由公司的公關(guān)部出面與客戶進行協(xié)調(diào)，項目經(jīng)理可以在此過程中堅持戶進行協(xié)調(diào)，項目經(jīng)理可以在此過程中堅持一下原則，與公司的公關(guān)部一個紅臉，一個一下原則，與公司的公關(guān)部一個紅臉，一個白臉，唱出一出好戲。白臉，唱出一出好戲?！狈治龇治? 用戶就是上帝用戶就是上帝小李：小李：“不管怎樣，客戶才是第一位的。不管怎樣，客戶才是第一位的?？蛻艨梢越o你帶來收入，也可以給你帶客戶可以給你帶來收入，也可以給你帶來更多的客戶和工作，有什么道理不多來更多的客戶和工作，有什么道

52、理不多配合一下他們呢？說實話我對配合一下他們呢？說實話我對B B的做法的做法蠻欣賞的，可惜行不通。因為客戶是上蠻欣賞的，可惜行不通。因為客戶是上帝，如果照帝，如果照B B的做法，后果會造成做一的做法，后果會造成做一次項目丟掉一個客戶，太不劃算了。次項目丟掉一個客戶，太不劃算了?！?問題：問題： 1 1、如果你的項目遇到需求變更問題，、如果你的項目遇到需求變更問題，你會采用哪種方式去應對？你會采用哪種方式去應對？ 2 2、分析這兩種應對需求變更方式的優(yōu)、分析這兩種應對需求變更方式的優(yōu)缺點。缺點。需求變更案例分析需求變更案例分析指導策略：合理控制指導策略：合理控制v對于客戶的需求，如何是合理的，在自己的對于客戶的需求，如何是合理的，在自己的范圍之內(nèi)，是可以變更的，但是如果在對前范圍之內(nèi)，是可以變更的，但是如果在對前面的主體框架是做以否定的話，那就斷然拒面的主體框架是做以否定的話，那就斷然拒絕！絕！指導策略：合理控制指導策略：合理控制項目的目的是在規(guī)定的時間內(nèi)完成規(guī)定的內(nèi)容。項目的目的是在規(guī)