2023/7/21軟件項目需求與變更管理課程學習目標掌握軟件需求的概念熟悉需求管理的方法與過程掌握任務分解的方法與步驟WBS了解需求變更的原因掌握需求變更控制的策略第7章項目招投標與合同管理2HotTip軟件需求定義需求是來源于用戶調查，即客戶的需要。需求分析是指軟件分析人員通過研究用戶在軟件問題上的需求意愿，分析出軟件系統的功能、性能、數據等諸方面應該達到的目標，從而獲得有關軟件的需求規格定義的過程。

8.1軟件項目需求管理概述3HotTip軟件需求定義1．用戶需求特點：（1）用戶需求直接來源于用戶（2）用戶需求需要以文檔的形式提供給用戶審查（3）可以把用戶需求理解為用戶對軟件的合理請求（4）用戶需求主要是為用戶方的管理層、用戶方的技術代表、操作者以及開發方的高層技術人員撰寫的？p1238.1軟件項目需求管理概述4HotTip2．系統需求（1）功能需求全面性一致性可理解可維護可追蹤等8.1軟件項目需求管理概述（2）非功能性需求性能需求、可靠性、可用性需求、系統安全以及系統對開發過程、時間、資源等方面的約束和標準關心系統的整體特性

（3）數據要求5業務需求用戶需求系統需求功能需求質量屬性其他非功能需求約束條件項目視圖與范圍文檔使用實例文檔軟件需求規格說明用戶能有效的糾正文檔中的拼寫錯誤找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞。找到并高亮度提示錯詞；顯示提供替換詞的對話框以及實現整個文檔范圍的替換。需求組成

業務需求：組織機構/客戶對軟件的高層次目標用戶需求：用戶對軟件的要求功能需求：軟件做什么，如何做

如小型超市商品查詢:業務需求：保證及時進貨；……用戶需求:查詢商品的價格，庫存，銷售及盈利功能需求：怎樣查詢/短信缺貨提示，提供哪些信息HotTip3．需求規格說明書的寫作規范1）清晰2）完整3）一致4）可測試

8.1軟件項目需求管理概述8需求管理活動需求過程所涉及的工作軟件項目需求管理的重要性影響軟件項目成敗的因素（1/3）軟件缺陷修復的成本HotTip需求管理1．需求管理復雜性分析需求的描述問題需求的完備程度問題需求開發的工期問題需求的細致程度問題需求的變化問題8.1軟件項目需求管理概述13HotTip需求管理2．需求管理的基本原則需求管理必須與需求工程的其它活動緊密整合需求必須是文檔化的、正確的、最新的、可管理的、可理解的只要需求變化了，需求變更的影響就必須被評估需求必須分優先級需求一定要分類管理8.1軟件項目需求管理概述14HotTip3．需求管理的方法確定需求變更控制過程進行需求變更影響分析建立需求基準版本和需求控制版本文檔維護需求變更的歷史記錄跟蹤每項需求的狀態衡量需求穩定性8.1軟件項目需求管理概述15HotTip需求管理過程1．定義需求2．需求確認3．建立需求狀態4．需求評審評判需求優劣的主要指標有：正確性、清晰性、無二義性、一致性、必要性、完整性、可實現性、可驗證性、可測性。

8.1軟件項目需求管理概述16HotTip需求管理過程5．需求承諾(簽字生效）6．需求跟蹤正向跟蹤：以用戶需求為切入點，檢查《需求規格說明書》中的每個需求是否都能在后繼工作產品中找到對應點。逆向跟蹤：檢查設計文檔、代碼、測試用例等工作產品是否都能在《需求規格說明書》中找到出處。7．需求變更控制8.1軟件項目需求管理概述17確定需求變更控制過程建立需求變更控制委員會進行需求變更影響分析建立需求基準版本和需求控制版本文檔維護需求變更的歷史記錄跟蹤每項需求的狀態跟蹤所有受需求變更影響的工作產品衡量需求穩定性（盡量避免、減少變化）需求變更管理活動：HotTip工作分解結構項目的分解結構就是將項目的產品或服務、組織、過程這3種不同的結構綜合為項目分解結構的過程，也就是給項目的組織人員分派各自角色和任務的過程。基于成果/功能的分解方法，以完成該項目應該交付的成果為導向，確定相關的任務、工作、活動和要素基于流程的分解方法，以完成該項目所應經歷的流程為導向，確定相關的任務、工作、活動和要素。8.2軟件項目任務分解208.2軟件項目任務分解項目分解目的——明確項目所包含的各項工作；項目分解的結果就是WBS（任務分解結構）圖項目分解意義——WBS（任務分解結構）圖是實施項目、創造最終產品或服務所必須進行的全部活動的一張清單，也是進度計劃、人員分配、預算計劃的基礎項目分解內容——項目分解就是先把復雜的項目逐步分解成一層一層的要素（工作），直到具體明確為止項目分解工具——項目分解的工具是工作分解結構ＷＢＳ原理，它是一個分級的樹型結構，是一個對項目工作由粗到細的分解過程軟件項目分解WBS——WorkBreakdownStructure主要是將一個項目分解成易于管理的幾個部分或幾個細目，以便確保找出完成項目工作范圍所需的所有工作要素它是一種在項目全范圍內分解和定義各層次工作包的方法WBS——WorkBreakdownStructure結構層次越往下層則項目組成部分的定義越詳細，WBS最后構成一份層次清晰，可以具體作為組織項目實施的工作依據WBS——WorkBreakdownStructure通常是一種面向“成果”的“樹”，其最底層是細化后的“可交付成果”，該樹組織確定了項目的整個范圍。但WBS的形式并不限于“樹”狀，還有多種形式。軟件項目分解WBS分解類型基于可交付成果的劃分上層一般為可交付成果為導向下層一般為可交付成果的工作內容基于工作過程的劃分上層按照工作的流程分解下層按照工作的內容劃分8.2軟件項目任務分解軟件項目分解基于可交付成果的劃分——WBS舉例:信息網絡工程信息網絡工程結構化布線網絡平臺建設布線設計采購布線驗收方案設計采購網絡平臺實施驗收0級1級2級軟件項目分解基于工作過程的劃分——WBS舉例:網絡系統工程網絡系統培訓設備準備設備采購設備驗收交接網絡系統設計布線設計平臺設計工程實施布線實施網絡集成軟件開發軟件需求確定系統設計編碼測試0級1級2級HotTip工作分解結構（1）圖表形式分解層次與結構

8.2軟件項目任務分解26軟件項目分解項目工作分解結構表項目名稱：項目負責人：單位名稱：制表日期：工作分解結構任務編碼任務名稱主要活動描述負責人1000

1100

1200

1x001x101x111x12

項目負責人審核意見：

簽名：日期：HotTip工作包是完成一項具體工作所要求的一個特定的、可確定的、可交付以及獨立的工作包，可為項目控制提供充分而合適的管理信息。（樹葉）WBS編碼設計（編號=》層次）8.2軟件項目任務分解28用PROJECT生成的WBS例HotTip（2）清單形式需求分析計劃流程優化編寫需求說明書編寫需求規格詞匯表繪制業務流程抽象業務類建立數據模型將需求分析圖示加入規格文檔需求規格測試需求規格確認8.2軟件項目任務分解30HotTip任務分解過程1．分解步驟（1）確認并分解項目的主要組成要素。（2）確定分解標準（3）確認分解是否詳細，分解結果是否可以作為費用和時間估計的標準，明確責任。（4）確定項目交付成果。（5）驗證分解正確性，驗證分解正確性后，建立一套編號系統。8.2軟件項目任務分解31HotTip任務分解過程2．分解的標準:一般不能采用雙重標準。選擇一種項目分解標準之后，在分解過程中應該統一使用此標準，避免因使用不同標準而導致的混亂。3．分解結果的檢驗核實分解的正確性：更低層次的細目是否必要和充分？最底層要素是否有重復？每個細目都有明確的、完整的定義嗎？是否每個細目可以進行適當的估算？誰能擔負起完成這個任務？8.2軟件項目任務分解32HotTip4．任務分解的注意事項注意收集與項目相關的所有信息。任務分解結果必須有利于責任分配。最底層的工作包一般要有全面、詳細和明確的文字說明，并匯集編制成項目工作分解結構詞典。避免不必要的過細，最好不要超過7層。按照軟件項目的平均規模來說，推薦任務分解時至少分解到一周的工作量（40小時）。8.2軟件項目任務分解33HotTip5．責任分配及成本分解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張明34WBS的要素WBS的每一個工作單元都是一個具體任務，它包括五個方面的要素：1．工作過程或內容：表明工作的性質或對工作的描述。2．人物的承擔者：明確責任者，多人承擔時應明確個人的職責分工。3．工作對象：工作對象不僅僅是物質的，也可能是非物質的。4．完成任務時間（工時）/工作量：估計完成任務所需時間。5．完成任務所需資源：執行任務所需空間，設備，人員，環境，資金等。HotTip需求變更原因分析1．范圍沒有圈定就開始細化2．沒有良好的軟件結構適應變化3．用戶改變需求管理變更請求1．控制需求漸變的策略需求一定要與投入有顯示的聯系，否則如果需求變更的成本由開發方來承擔，則項目需求的變更就成為必然了。軟件開發方和出資方都要明確這一條：需求變化，軟件開發的投入也要變化。8.3軟件需求的變更控制36HotTip需求的變更要經過出資者的認可,這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。小的需求變更也要經過正規的需求管理流程，否則會積少成多。精確的需求與范圍定義并不會阻止需求的變更。并非對需求定義的越細，越能避免需求的漸變，這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的，并非由于需求細化了，它就不會變化了。8.3軟件需求的變更控制37HotTip2．變更控制過程（1）項目啟動階段的變更預防（2）項目實施階段的變更控制（3）項目收尾階段的總結控制8.3軟件需求的變更控制38HotTip需求變更處理流程8.3軟件需求的變更控制39狀態跟蹤示例4041建議的需求狀態表狀態值定義已建議該需求已被有權提出需求的人建議已批準該需求已被分析，估計了其對項目余下部分的影響（包括成本和對項目其余部分的干擾），已用一個確定的產品版本號或創建編號分配到相關的基線中，軟件開發團隊已同意實現該項需求已實現已實現需求代碼的設計、編寫和單元測試已驗證使用所選擇的方法已驗證了實現的需求，例如測試和檢測，審查該需求跟蹤與測試用例相符。該需求現在被認為完成已刪除計劃的需求已從基線中刪除，但包括一個原因說明和做出刪除決定的人員已拒絕需求變更狀態轉換圖44RationalRequisiteProBorlandCaliber（代碼生成，animation）RationalRoseRationalXDERationalClearCase5.5需求管理工具45RequisiteProProjectOrganizationToolbarProjecticonPackageDocumentViewsRequirementsDeleteaRequirementinaDocument你是一個IT項目的項目經理。你項目團隊的一個信息專家在同與他一起工作的一個低級別客戶代表共進午餐后得知，在顯示中一項簡單的改造會給項目增加巨大的附加功能。你和項目發起人都已經對范圍簽字認可。那位信息專家進行了這項改造，沒有給項目進度帶來負面影響，也沒有增加額外的費用。你應該采取什么管理措施?A.沒有影響項目成本、進度，因此，這位信息專家應該受到表揚。B.項目經理應該在項目計劃中增加一項沒有相應時間的任務。C告訴他的行為是不可接受的，因它可能給整個項目帶來負面影響D.由于這項變更已經做了，項目經理做一份變更控制表并請客戶簽字。48 你正在做你的研發項目，這時你的客戶要求你在項目中增加一個特殊成分。你知道這意味著新的工作并且你也知道項目沒有剩余款。你應該怎么做？_______A.取消另一個優先等級低的任務，以便騰出更多的時間和資金。B.使用管理儲備的資金來支付新任務的成本。C.按合同變更控制過程辦理。D.向項目發起人要更多的資金。

49Clicktoeditcompanyslogan.謝謝！ThankYou!明確的需求是項目的基礎1需求的生命周期：需求產生（變化、內部、外部）需求認識（現存、潛在、超前、前景分析）需求表達：1、讓提出需求的人盡可能清楚地說明他們的需求；2、對需求提出一系列問題：明確的需求是項