【正文】 需求跟蹤 需求狀態(tài)跟蹤 ? 建議變更 ? 分析影響 ? 做出決策 ? 交流 ? 合并 ? 測(cè)量需求穩(wěn)定性 ? 確定需求文檔 版本 ? 定義對(duì)其他需求 的連接鏈 ? 定義對(duì)其他系統(tǒng) 元素的連接鏈 ? 定義需求狀態(tài) ? 跟蹤需求狀態(tài) 2023/1/30 57 需求管理與需求開發(fā)的關(guān)系 2023/1/30 58 需求獲取方法 2023/1/30 59 需求獲取的基本步驟 了解 領(lǐng)域背景知識(shí) 客戶分類 (按角色 ) CxO 部門經(jīng)理 業(yè)務(wù)員 管理員 交流 需求紀(jì)要 問(wèn)題？ 分類整理 功能需求 非功能需求 約束條件 業(yè)務(wù)規(guī)則 外部接口需求 建議解決方案 優(yōu)先級(jí)排序 沖突消解 簽字確認(rèn) 業(yè)務(wù)需求 用戶需求 2023/1/30 60 需求獲取的基本步驟 ? 第 1步： 了解相關(guān)背景和領(lǐng)域 /行業(yè)的知識(shí)， 確定產(chǎn)品所期望的用戶類； ? 第 2步：與客戶企業(yè)或組織的高層人員進(jìn)行 交流 ，了解實(shí)際用戶任務(wù)和目標(biāo) 以及這些任務(wù)所支持的 業(yè)務(wù)需求 ； ? 第 3步：與客戶企業(yè)或組織的底層人員進(jìn)行 交流 ，獲取 每個(gè)用戶類的 詳細(xì)的用戶需求； ? 第 4步： 整理需求紀(jì)要 ， 發(fā)現(xiàn)新問(wèn)題 ，并重復(fù) 13步； ? 第 5步： 需求分類和組織， 以區(qū)別 功能需求、非功能需求、約束條件、業(yè)務(wù)規(guī)則、外部接口需求 、建議解決方法和附加信息； ? 第 6步： 優(yōu)先排序和沖突解決； ? 第 7步：得到最終需求清單，并與客戶做 最終簽字確認(rèn)。 需求管理的任務(wù)是管理軟件系統(tǒng)的需求規(guī)格說(shuō)明和文檔，評(píng)估需求變更帶來(lái)的影響及成本費(fèi)用，跟蹤軟件需求的狀態(tài)，管理需求規(guī)格說(shuō)明的版本等。 利用描述語(yǔ)言、標(biāo)準(zhǔn)格式書寫軟件系統(tǒng)的需求規(guī)格說(shuō)明和文檔。 需 求 獲 取 需 求 分 析 需 求 描 述 需 求 驗(yàn) 證 需 求 管 理需 求 開 發(fā) 過(guò) 程 需 求 管 理 過(guò) 程2023/1/30 47 確定和 收集 與待開發(fā)的軟件系統(tǒng)相關(guān)的用戶需求信息。 6．當(dāng)需求變更時(shí)，對(duì)需求規(guī)格說(shuō)明及需求變更實(shí)施進(jìn)行管理。 2023/1/30 45 需求工程概念 需求工程的任務(wù)： 4．根據(jù)收集的需求信息和邏輯模型編寫需求規(guī)格說(shuō)明及文檔。 2．分析用戶的需求信息，并按需求類型分類，過(guò)濾掉非需求的信息。 ? 需求工程的目標(biāo)是獲取高質(zhì)量的軟件需求。 4. 與 5是矛盾的。 3. ―盡快”是不可驗(yàn)證的，應(yīng)該給出具體數(shù)量值。 …… 2023/1/30 39 好需求與壞需求 1. 在現(xiàn)實(shí)情況中，用戶存錢時(shí)并不需要信用檢查，因此這個(gè)需求描述是錯(cuò)誤的 2. ―適當(dāng)?shù)男袆?dòng)”對(duì)不同的人來(lái)說(shuō)有不同的解釋，顯然是歧義的。 Gerhard 那些化學(xué)專家都非常忙，沒有時(shí)間與你們?cè)敿?xì)討論各種細(xì)節(jié)，你不能讓你的手下的人說(shuō)明要做的系統(tǒng)嗎？ Cynthia 如果我們只是憑空猜想用戶要求，結(jié)果不會(huì)令人滿意。 Gerhard 你什么意思？我不是剛告訴你我的需求了嗎？ Cynthia 你只說(shuō)明了整個(gè)項(xiàng)目的概念與目標(biāo)，這些高層次的業(yè)務(wù)需求并不能為我們提供足夠的詳細(xì)信息以確定究竟要開發(fā)什么樣的軟件，以及需要多長(zhǎng)時(shí)間。全部要求是指軟件系統(tǒng)必須提供的功能和性能、約束條件和限制。 ? 系統(tǒng)可從各型號(hào)的 modem上讀取信號(hào)作為系統(tǒng)輸入。 ? 系統(tǒng)應(yīng)該在 1分鐘內(nèi)從 1000000條記錄中檢索出一個(gè)銷售訂單。 ? 系統(tǒng)必須有能力存儲(chǔ)平均操作連續(xù) 100天所產(chǎn)生的事務(wù)。 – 通常表達(dá)為“如果 … ，那么 …‖ 的形式 – 通常是一些容易發(fā)生變化的功能； ? 例如： – 如果借書卡類型為“教師”，那么一次借閱的最大數(shù)量為 8本； – 如果訂單金額大于 10000元，那么該訂單的折扣為 10%； – 如果采購(gòu)單金額在 10萬(wàn)到 50萬(wàn)之間，那么需要總經(jīng)理審批； 2023/1/30 29 7. 外部接口需求 ? 外部接口需求 (External Interface Requirement)： 描述系統(tǒng)與其所處的 外部環(huán)境之間如何進(jìn)行交互 ，包括： – 用戶接口需求 (UI) – 硬件接口需求 – 軟件接口需求 – 通信接口需求 ? 例如： – “從 某些設(shè)備 讀取信號(hào)” – “給 一些其它系統(tǒng) 發(fā)送消息” – “以 某種格式 讀取文件” – “能控制 一些硬件 ‖ – ―采用 某種類型的 用戶界面” 2023/1/30 30 關(guān)于需求的一些例子 ? 系統(tǒng)必須有能力支持 100個(gè)以上的并發(fā)用戶，每個(gè)用戶可以處理操作任務(wù)的任選組合，平均響應(yīng)時(shí)間應(yīng)該小于 1秒，最大響應(yīng)時(shí)間應(yīng)小于 5秒。 ? 來(lái)源：法規(guī)政策、硬件 /資源限制、開發(fā)語(yǔ)言、等等。 非功能需求的度量 非功能特性 度量指標(biāo) 速度 每秒處理的事務(wù) 用戶的響應(yīng)時(shí)間 屏幕的刷新速度 存儲(chǔ)空間 字節(jié)數(shù) RAM芯片數(shù) 可用性 培訓(xùn)時(shí)間 幫助頁(yè)面數(shù) 可靠性 平均失敗時(shí)間 系統(tǒng)無(wú)效的概率 失敗發(fā)生率 容錯(cuò)性 失敗后的重啟次數(shù) 事件引起失敗的比例 失敗時(shí)數(shù)據(jù)崩潰的可能性 2023/1/30 26 一個(gè)例子：拼寫檢查器 ? 業(yè)務(wù)需求： “用戶能有效地糾正文檔中的拼寫錯(cuò)誤” ； ? 用戶需求： “找出文檔中的拼寫錯(cuò)誤并通過(guò)一個(gè)提供的替換項(xiàng)列表來(lái)供選擇替換拼錯(cuò)的詞”； ? 功能性需求： – 找到拼寫錯(cuò)誤的單詞并以高亮度提示 – 顯示提供替換詞的對(duì)話框 – 實(shí)現(xiàn)整個(gè)文檔范圍的替換 ? 非功能性需求： – 正確的找到至少 95%以上的錯(cuò)詞并 100%的加以正確替換 – 拼寫檢查的速度應(yīng)至少達(dá)到 5000詞 /秒。在這樣的培訓(xùn)之后，一個(gè)有經(jīng)驗(yàn)的用戶每天的出錯(cuò)平均數(shù)不應(yīng)超過(guò) 2次。 ? 注意：非功能需求隱含了對(duì)可選設(shè)計(jì)方案的一些關(guān)鍵影響 – 體系結(jié)構(gòu)設(shè)計(jì) (., 體系結(jié)構(gòu)風(fēng)格選擇 ) – 算法設(shè)計(jì) (., 排序策略的選擇 ) 2023/1/30 24 非功能需求的度量 ? NFR：檢驗(yàn)起來(lái)非常困難，一般采用一些可度量的特性進(jìn)行描述。 2023/1/30 22 3. 功能需求 ? 功能需求 (Functional Requirements, FR)： 系統(tǒng)應(yīng)該提供的 功能或服務(wù) ，通常涉及用戶或外部系統(tǒng)與該系統(tǒng)之間的交互，不考慮系統(tǒng)內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)； ? [例 ] – 用戶可從圖書資料庫(kù)中查詢或者選擇其中一個(gè)子集； – 系統(tǒng)可提供適當(dāng)?shù)臑g覽器供用戶閱讀館藏文獻(xiàn)； – 用戶每次借閱圖書應(yīng)對(duì)應(yīng)一個(gè)唯一的標(biāo)識(shí)號(hào)，它被記錄到用戶的賬戶上； 2023/1/30 23 4. 非功能需求 ? 非功能需求 (NonFunctional Requirements, NFR)： 從各個(gè)角度對(duì)系統(tǒng)的約束和限制，反映了客戶對(duì)軟件系統(tǒng) 質(zhì)量和性能(quality and performance)的額外要求，如響應(yīng)時(shí)間、數(shù)據(jù)精度、可靠性等。 – 學(xué)生希望能夠在學(xué)期開始之前查詢所有開設(shè)課程的詳細(xì)信息，并能夠通過(guò)校園網(wǎng)進(jìn)行選課。 – 課程信息維護(hù)、選課管理、課程成績(jī)登記和查詢等業(yè)務(wù)全部由手工方式改為計(jì)算機(jī)應(yīng)用。 2023/1/30 20 2. 用戶需求 (目標(biāo)需求 ) ? 用戶需求 (User Requirements)： 從用戶角度描述的 系統(tǒng)功能需求與非功能需求 ，通常只涉及系統(tǒng)的 外部行為 而不涉及內(nèi)部特性。 2023/1/30 16 關(guān)于“需求”的例子 ? Course Registration System(學(xué)生選課系統(tǒng) ) – 某大學(xué)希望采用計(jì)算機(jī)管理學(xué)生的選課 – 學(xué)生可以在一個(gè)學(xué)期開始之前選擇該學(xué)期開設(shè)的某些課程 – 老師可以使用選課系統(tǒng)獲得選課學(xué)生的名單，并登記學(xué)生的課程學(xué)習(xí)成績(jī) – 學(xué)生不希望自己的學(xué)習(xí)成績(jī)被他人查閱 – ……( 你可以補(bǔ)充嗎？ ) ? 以下描述是否屬于需求？為什么？ – 系統(tǒng)通過(guò) JDBC與 Oracle數(shù)據(jù)庫(kù) CourseDB建立連接，并使用 TSQL語(yǔ)句從 CourseOffering數(shù)據(jù)表中獲得課程的開設(shè)信息。 ? 軟件需求： 以一種清晰、簡(jiǎn)潔、一致且無(wú)二義性的方式，描述用戶對(duì)目標(biāo)軟件系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望，是在開發(fā)過(guò)程中對(duì)系統(tǒng)的約束。 Phil 如果你一開始就告訴我你想隨時(shí)改變某人的名字，那這些就都不會(huì)發(fā)生！ …… 2023/1/30 10 “錯(cuò)誤的需求”的擴(kuò)散效應(yīng) 問(wèn)題 正確的需求 錯(cuò)誤的需求 正確的設(shè)計(jì) 基于“錯(cuò)誤的需求” 的設(shè)計(jì) 錯(cuò)誤的設(shè)計(jì) 基于“錯(cuò)誤的 設(shè)計(jì)”的編碼 正確的編碼 錯(cuò)誤的編碼 基于“錯(cuò)誤的需求” 的編碼 2023/1/30 11 “錯(cuò)誤的需求”的修復(fù)代價(jià) “構(gòu)建一個(gè)軟件系統(tǒng)最困難的部分是確定構(gòu)建什么 … 在出錯(cuò)之后會(huì)嚴(yán)重影響隨后實(shí)現(xiàn)的系統(tǒng)，并且在以后的修補(bǔ)是如此的困難 …‖ 2023/1/30 13 根本原因是什么？ 需求的鴻溝 (期望差異 )： 開發(fā)者開發(fā)的與用戶所想得到 的軟件存在著巨大期望差異。 Maria 可是每個(gè)人只要愿意就可以隨時(shí)改變自己的名字啊。 2023/1/30 6 主要困難 ： 1. 軟件開發(fā)人員與用戶雙方固有的矛盾 2. 需求具有易變性和難以表述性 3. 需求錯(cuò)誤的高頻性和修復(fù)的高成本性 2023/1/30 7 軟件開發(fā)的目標(biāo)是什么？ ? 開發(fā)高質(zhì)量的軟件； ? 在預(yù)定的時(shí)間和預(yù)算約束下完成； ? 軟件要能夠滿足顧客的需求。2023/1/30 1 第三章 需求工程 主講：任向民 2023/1/30 2 第三章 需求工程 2023/1/30 3 軟件需求定義 2023/1/30 4 軟件需求的分類 軟件需求的定義 2023/1/30 5 ? 軟件需求工程的目的是定義軟件所需要解決的問(wèn)題 。 ? 軟件需求是要把一個(gè)定義不足和模糊的問(wèn)題轉(zhuǎn)換為一個(gè)定義良好而準(zhǔn)確的問(wèn)題，進(jìn)而找到解決問(wèn)題的方案。 2023/1/30 8 但實(shí)際情況是什么樣子？ ? 調(diào)查報(bào)告的數(shù)字是這樣的 … ?Standish Group 2023 Succeeded Challenged Failed 用戶參與程度高： 16% 用戶高層的支持： 14% 對(duì)需求的清晰陳述： 12% 缺乏用戶參與： 13% 需求規(guī)格說(shuō)明不完整： 12% 需求頻繁的發(fā)生變化： 12% 結(jié)論： 對(duì)用戶需求的管理水平 是決定軟件成敗的重要原因 2023/1/30 9 [案例分析 1] ―只有結(jié)婚后才可以修改姓名嗎？” ? Phil開發(fā)了一套人力資源軟件，有一天他接到了人力資源部 Maria打來(lái)的電話 … Maria 一個(gè)同事想把自己名字改為 Sparkle Starlight，但系統(tǒng)不允許，能幫忙嗎？ Phil 她嫁給了一個(gè)姓 Starlight的人嗎？ Maria 不，她并沒有結(jié)婚，她只是想改名字而已； Phil 系統(tǒng)只支持在改變婚姻狀況時(shí)才可以改名字。 Phil 這并不是我的錯(cuò)！在開發(fā)系統(tǒng)之前，你從來(lái)沒有向我提起過(guò)有這種需求！ Maria 不管如何，請(qǐng)盡快把這個(gè)功能修改完畢，否則 Sparkle無(wú)法支付她的銀行帳單。 2023/1/30 14 什么是“軟件需求” ? 軟件需求 (Software Requirements)： – 用戶解決問(wèn)題以達(dá)到特定目標(biāo)所需的能力； – 系統(tǒng)或系統(tǒng)構(gòu)件要滿足的合同、標(biāo)準(zhǔn)、規(guī)范或其他正式文檔所需具備的能力； ——IEEE, 1997 – 指用戶對(duì)軟件的功能與性能需求 ,就是用戶希望軟件能夠做什么事情 ,完成哪些功能，達(dá)到哪些性能等 。 ? 需