1、信息系統(tǒng)項目管理師需求管理,閆波,需求管理,用戶需求是軟件項目成敗的關鍵 需求問題： 需求的隱含錯誤 需求不明確、含糊 用戶刁難、用戶不斷增加需求 需求變更,本章要點,17.1 需求管理概述 17.2 制定需求管理計劃 17.3 需求管理規(guī)格說明的版本控制 17.4 需求變更管理 17.5 需求跟蹤,需求管理,需求：指的是由項目接受的或項目產(chǎn)生的產(chǎn)品和產(chǎn)品構(gòu)件需求。包括由組織征集的對項目的需求。 Requirement Management 需求管理 確保各方對需求的一致理解，管理和控制需求的變更，從需求到最終產(chǎn)品的雙向跟蹤。,軟件需求定義,需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟

2、件能做什么事情，完成什么樣的功能，達到什么性能。,軟件需求,特征： 模糊性 不確定性 變化性 主觀性,軟件需求的層次,軟件需求的類型,功能需求 性能需求 環(huán)境需求 用戶界面需求 資源使用需求 成本消耗需求 開發(fā)進度需求 預先估計以后系統(tǒng)可能達到的目標,軟件需求的重要性,需求管理與項目管理的關系,項目需求是制定項目計劃，開發(fā)項目產(chǎn)品和從事項目活動的依據(jù)。 項目的計劃、項目的開發(fā)活動及開發(fā)的產(chǎn)品應與項目需求保持一致，隨需求的變化而調(diào)整。,需求工程（RE）,需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統(tǒng)的所有外部特征一門學科。 需求開發(fā) 需求管理

3、,軟件需求工程管理的過程,需求獲取,擴展需求,需求獲取,用戶要求,基線需求,軟件需求,通過與用戶的交流，對現(xiàn)有系統(tǒng)的觀察及對任務進行分析，從而開發(fā)、捕獲和修訂用戶的需求。,獲取需求的活動,了解用戶類型及潛在類型 訪談和調(diào)研（要有記錄） 對用戶需求進一步整理和提取 將用戶需求反饋用戶,注意事項,識別真正的客戶. 正確理解客戶的需求 具備較強的忍耐力和清晰的思維 說服和教育客戶,需求分析,定義：需求分析是為最終用戶所看到的系統(tǒng)建立一個概念模型，是對需求的抽象描述。 需求分析也稱為需求建模,需求分析模型,需求分析的時間,設計方案的時候 項目開始的時候 接管一個項目的時候 需求變更的時候,需求分析基本

4、策略,頭腦風暴 專家評審 焦點會議組 目的：進行具體的流程細化、數(shù)據(jù)項確認，必要時可以提供原型系統(tǒng)和明確的業(yè)務流程報告、數(shù)據(jù)項表，并能清晰的向用戶描述系統(tǒng)的業(yè)務流設計目標。,需求分析的難點,問題的復雜性（不了解業(yè)務） 交流的障礙 不完備性和不一致性 需求的易變性,需求定義,需求分析工作完成的一個基本標志是形成了一份完整的、規(guī)范的需求規(guī)格說明書（SRS） 需求規(guī)格說明書的編制是為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個共同的理解，使之成為整個開發(fā)工作的基礎。,軟件需求規(guī)格說明的原則,從現(xiàn)實中分離功能，即描述要“做什么”而不是“怎樣實現(xiàn)” 要求使用面向處理的規(guī)格說明語言（或稱系統(tǒng)定義語言）

5、 如果被開發(fā)軟件只是一個大系統(tǒng)中的一個元素，那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中 規(guī)格說明必須包括系統(tǒng)運行環(huán)境 規(guī)格說明必須是一個認識模型 規(guī)格說明必須是可操作的 規(guī)格說明必須容許不完備性并允許擴充,需求規(guī)格說明書文檔參考,引言 系統(tǒng)定義 應用環(huán)境 功能規(guī)格 性能需求 產(chǎn)品提交 實現(xiàn)約束 質(zhì)量描述 其它 簽字認證,需求驗證,開發(fā)方和用戶方共同對需求文檔進行評審，經(jīng)雙方對需求達成共識后做出書面承諾，使需求文檔具有商業(yè)合同效果。,需求驗證,需求是正確的嗎？ 需求是一致的嗎？ 需求是完全的嗎？ 需求是實際可行的嗎？ 需求是客戶需要的嗎？ 需求是可檢驗的嗎？ 需求是可跟蹤的嗎？ 最后的簽字,需求驗

6、證,快速原型法,需求管理,需求管理中要收集需求的變更和變更的理由，維持對原有需求和所有產(chǎn)品及產(chǎn)品構(gòu)件需求的雙向跟蹤。,需求變更,項目失敗主要的原因在于需求變更!,需求建模的方法,創(chuàng)建體系結(jié)構(gòu)的表示形式以捕獲需求、就解決方案方法進行交流、以及分析所提出的系統(tǒng)設計。其目的是使用模型來表現(xiàn)系統(tǒng)中的關鍵方面。,原型分析法,定義： 按照用戶的需要，快速形成一個操作流程界面 可能只是一個框架，具體的功能沒有實現(xiàn)，只是結(jié)果 靜態(tài)的操作流程，以便與用戶快速就需求達成一致 主要考慮系統(tǒng)的功能需求，很少考慮非功能需求,原型方法,需求分析,原型開發(fā),原型評價,原型方法的類型,進化型 開發(fā)出來用于了解問題，并形成被交

7、付軟件的部分或全部的基礎 拋棄型 開發(fā)出來獲以便更多地了解問題或探究可能的方案的靈活性或者合理性，是嘗試性軟件，不用于被交付軟件的實際部分,結(jié)構(gòu)化分析法,定義（SA,Structured Analysis） 20世紀70年發(fā)展起來的面向數(shù)據(jù)流的方法 是一種自頂向下逐步求精的分析方法 根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關系進行分析的,結(jié)構(gòu)化分析方法技術,數(shù)據(jù)流圖(DFD) 數(shù)據(jù)字典(DD) 系統(tǒng)流程圖,數(shù)據(jù)流圖,是一種描述軟件系統(tǒng)邏輯模型的圖形符號,表示數(shù)據(jù)的起始點和終點,表示對數(shù)據(jù)的加工處理,表示數(shù)據(jù)流,箭頭表示數(shù)據(jù)的流動方向,表示對數(shù)據(jù)的存儲,銀行取款過程數(shù)據(jù)流圖,數(shù)據(jù)流圖的層次結(jié)構(gòu),為了表達數(shù)據(jù)

8、處理過程的數(shù)據(jù)加工情況，需要采用層次結(jié)構(gòu)的數(shù)據(jù)流圖。按照系統(tǒng)的層次結(jié)構(gòu)進行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關系，能清楚地表達和容易理解整個系統(tǒng),分層數(shù)據(jù)流圖,分層數(shù)據(jù)流圖,頂層流圖僅包含一個加工，它代表被開發(fā)系統(tǒng)。它的輸入流是該系統(tǒng)的輸入數(shù)據(jù)，輸出流是系統(tǒng)所輸出數(shù)據(jù) 底層流圖是指其加工不需再做分解的數(shù)據(jù)流圖，它處在最底層 中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續(xù)細化，形成子圖。,數(shù)據(jù)字典,描述系統(tǒng)中涉及的每個數(shù)據(jù),是數(shù)據(jù)描述的集合,通常配合數(shù)據(jù)流圖使用,用來描述數(shù)據(jù)流圖中出現(xiàn)的各種數(shù)據(jù)和加工. 組成： 數(shù)據(jù)項:數(shù)據(jù)元素 數(shù)據(jù)流:由數(shù)據(jù)項組成的數(shù)據(jù)流 數(shù)據(jù)文件:表示對數(shù)據(jù)

9、文件的存儲,數(shù)據(jù)字典關系符號,數(shù)據(jù)流圖需求分析實例,建立學生管理系統(tǒng) 學管科 體檢科 學籍科 學生處,頂層數(shù)據(jù)流圖,學管科,體檢科,學籍科,學生管理 信息系統(tǒng),學生處領導,學生基本信息,學生健康信息,學生成績,學生健康情況表,學生成績單,查詢要求,不及格人數(shù),人數(shù)統(tǒng)計表,第0層數(shù)據(jù)流圖,第1層數(shù)據(jù)流圖,系統(tǒng)流程圖,系統(tǒng)包含的部分以及各個部分之間的關系 是描述物理系統(tǒng)的工具 用圖形符號表示系統(tǒng)中的元素 表達了系統(tǒng)中各個元素之間的信息流動情況,系統(tǒng)流程圖符號,用例分析法,面向?qū)ο蟮能浖こ蹋∣OSE） OOA OOD OOP (object oriented programming ) OOT .

10、,用例（User Case）,表示一個動作序列的定義，包括執(zhí)行的變量和外界交互的過程。 提款機取款用例,OOA,是OO軟件工程的第一項技術活動 將現(xiàn)實世界的“視圖”轉(zhuǎn)化為用對象來描述的模型 描述對象之間的各種關系，以滿足軟件系統(tǒng)的要求。,用例需求分析,用例需求分析方法采用一種面向?qū)ο蟮那榫胺治龇椒?用例是系統(tǒng)向用戶提供一個有價值的結(jié)果的某項功能 所有的用例結(jié)合起來就構(gòu)成了用例模型 從用戶角度出發(fā)考慮的功能需求,用例需求分析,從前：問用戶希望系統(tǒng)為他做什么？ 現(xiàn)在：問用戶利用系統(tǒng)做什么？,UML,Unified Modeling Language統(tǒng)一建模語言，是一種通用的模擬語言。 Booch,

11、Rumbaugh 和Jocobson 基礎上發(fā)展起來的。 1997年11月國際對象管理組織OMG批準將UML作為基于面向?qū)ο蠹夹g的標準建模語言。 UML制定了一整套完整的面向?qū)ο蟮臉擞浐吞幚矸椒ā?UML需求視圖,用例視圖（Use case Diagram） 順序圖（Sequence Diagram） 狀態(tài)圖（State Diagram） 活動圖（Activity Diagram）,USE CASE視圖,用例視圖主要是展示了外部行為者所觀察到的系統(tǒng)將提交的功能.即:各類外部行為者與系統(tǒng)所提供的用例的連接 用例（Use case）：系統(tǒng)所提供的功能描述 角色（Actor）：可能使用用例的人或者外

12、部系統(tǒng),UML圖符,USER CASE實例,序列（Sequence）圖,順序圖展示了幾個對象之間的動態(tài)協(xié)作關系，主要用來顯示對象之間發(fā)送消息的順序，還顯示對象之間的交互，即系統(tǒng)執(zhí)行某一特定時間點所發(fā)生的事。,Sequence實例,狀態(tài)視圖,狀態(tài)圖是對類描述的補充，它說明該類的對象所有可能的狀態(tài)以及那些事件將導致狀態(tài)的改變。 它是一個類對象所可能經(jīng)歷的所有歷程的模型圖。,活動（Activity）視圖,活動圖用來描述執(zhí)行工作流程中涉及的活動，展示了連續(xù)的活動流,活動圖例,Use Case需求分析方法綜述,識別出系統(tǒng)的Actor 描述主要的Use case 實現(xiàn)用例視圖 實現(xiàn)順序視圖，活動視圖,狀態(tài)

13、視圖等,功能列表法,對項目的功能需求進行詳細說明，既可以單獨使用，也可以作為用例分析方法的附加說明來詳細說明用例的具體功能。,為什么會有需求變更？,與用戶交互不夠，對問題理解有差異 模糊的需求 用戶需求增加 開發(fā)方需求人員重視程度不夠 開發(fā)人員理解偏差,有效控制變更合理的方法,需求階段盡可能采用原型或用例法明確用戶需求。 采用嚴格的需求管理變更流程。 采用良好的體系結(jié)構(gòu) 采用面向?qū)ο笏枷?需求變更處理,CMMI中的需求管理流程,1 制定需求管理計劃 2 求得對需求的理解 3 求得對需求的承諾 4 管理需求變更 5 維護對需求的雙向跟蹤性 6 識別項目工作與需求之間的不一致,CMMI中的需求管理

14、流程,1 制定需求管理計劃 確定需求管理的軟硬件資源、需求跟蹤矩陣、需求變更請求表。,CMMI中的需求管理流程,2 求得對需求的理解 需求確認。避免需求蔓延和遺漏,CMMI中的需求管理流程,3 求得對需求的承諾 為實現(xiàn)需求活動所需的活動人員之間達成一致和建立承諾。,CMMI中的需求管理流程,4 管理需求變更 5 維護對需求的雙向跟蹤性 6 識別項目工作與需求之間的不一致,需求的屬性,創(chuàng)建需求的時間 需求的版本號 需求創(chuàng)建的作者 負責認可需求的人員 需求狀態(tài) 已建議；已批準；已實現(xiàn)； 需求涉及到的子系統(tǒng) 需求的穩(wěn)定性 ,本章要點,17.1 需求管理概述 17.2 制定需求管理計劃 17.3 需求

15、管理規(guī)格說明的版本控制 17.4 需求變更管理 17.5 需求跟蹤,1 建立并維護需求管理的組織方針,對需求進行管理，確定項目計劃與工作產(chǎn)品之間需求不一致之處。,2 確定需求管理需使用的資源,人力、財力、物力,3 分配責任,確定需求管理負責人及其責任 確認需求管理員的權限責任,4培訓計劃,對需求人員的培訓 應用領域、需求分析、分析、審查和管理、需求管理工具、配置管理,5 確定需求管理的項目干系人,解決對需求的共識問題，評估需求變更的影響，通報雙向跟蹤情況，識別項目工作與需求不一致的情況。,6 制定判斷項目工作與需求不一致的準則和糾正規(guī)程,依據(jù)此判斷項目工作與需求不一致；不一致時啟動糾正規(guī)程。,

16、7 制定需求跟蹤性矩陣,正向跟蹤、逆向跟蹤 該矩陣保存了需求與后續(xù)工作成果的對應關系,8 制定需求變更審批程序,為保證項目順利進行和產(chǎn)品質(zhì)量，必須嚴格控制需求的變更。,9 制定審批規(guī)程,需求管理計劃的審批規(guī)程,本章要點,17.1 需求管理概述 17.2 制定需求管理計劃 17.3 需求管理規(guī)格說明的版本控制 17.4 需求變更管理 17.5 需求跟蹤,版本管理,版本 Check out Check in,本章要點,17.1 需求管理概述 17.2 制定需求管理計劃 17.3 需求管理規(guī)格說明的版本控制 17.4 需求變更管理 17.5 需求跟蹤,需求變更,仔細評估已建議的變更 挑選合適的人選對

17、變更做出決定 變更應及時通知所有涉及的人員 項目按一定的程序來采納需求變更,控制項目范圍的擴展,擴展需求是指在軟件需求基線已經(jīng)確定后又要增添新的功能或進行較大的改動。 需求變更不可避免，但必須控制。,變更控制過程,1 變更控制策略 達成一個策略，如何控制需求 所有需求變更必須遵循的過程； 未獲批準的變更，不做過多工作； CCB決定實現(xiàn)哪些變更 項目風險承擔者應了解變更數(shù)據(jù)庫的內(nèi)容； 不能從數(shù)據(jù)庫中刪除或修改變更請求的原始文檔；,變更控制過程,2 變更控制步驟 開始條件 Entry Criteria 通過合適渠道接受一個合法的變更請求； 過程和步驟 驗證任務正確完成的步驟 Verify 結(jié)束條件

18、 Exit Criteria,變更控制過程,3 變更控制狀態(tài)報告 用報告、圖表方式來總結(jié)變更控制數(shù)據(jù)庫的內(nèi)容和按狀態(tài)分類的變更請求數(shù)量。,變更控制過程,4 變更控制工具 自動工具幫助有效的執(zhí)行變更控制過程。,InfoSys公司對需求變更的處理,處理步驟： 1. 記錄變更 2. 分析變更對工作產(chǎn)品的影響 3. 估計變更申請所需的工作量 4. 重新估計交付時間表 5. 執(zhí)行累積的成本影響分析 6. 如果影響超出一定的限度，則與高級主管一起 評審影響 7. 客戶不再提出變更申請 8. 修改工作產(chǎn)品,示例,變更日志跟蹤累積變更影響,變更度量活動,接收、未作決定、結(jié)束處理的變更請求的數(shù)量； 已實現(xiàn)的變更需求的合計數(shù)量； 每個方面發(fā)出的變更請求數(shù)量； 每個已應用的需求建議變更和實現(xiàn)變更的數(shù)量； 投入處理變更的人力、物力；,本章要點,17.1 需求管理概述 17.2 制定需求管理計劃 17.3 需求管理規(guī)格說明的版本控制 17.4 需求變更管理 17.5 需求跟蹤,需求跟蹤,編制每個需求同系統(tǒng)元素之間的聯(lián)系文檔。如需求、體系結(jié)構(gòu)、源代碼、測試用例、