【正文】 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 6 主要困難 ： 1. 軟件開(kāi)發(fā)人員與用戶雙方固有的矛盾 2. 需求具有易變性和難以表述性 3. 需求錯(cuò)誤的高頻性和修復(fù)的高成本性 2023/1/30 7 軟件開(kāi)發(fā)的目標(biāo)是什么？ ? 開(kāi)發(fā)高質(zhì)量的軟件； ? 在預(yù)定的時(shí)間和預(yù)算約束下完成； ? 軟件要能夠滿足顧客的需求。 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開(kāi)發(fā)了一套人力資源軟件，有一天他接到了人力資源部 Maria打來(lái)的電話 … Maria 一個(gè)同事想把自己名字改為 Sparkle Starlight，但系統(tǒng)不允許，能幫忙嗎？ Phil 她嫁給了一個(gè)姓 Starlight的人嗎？ Maria 不，她并沒(méi)有結(jié)婚，她只是想改名字而已； Phil 系統(tǒng)只支持在改變婚姻狀況時(shí)才可以改名字。 Maria 可是每個(gè)人只要愿意就可以隨時(shí)改變自己的名字啊。 Phil 這并不是我的錯(cuò)！在開(kāi)發(fā)系統(tǒng)之前，你從來(lái)沒(méi)有向我提起過(guò)有這種需求！ Maria 不管如何，請(qǐng)盡快把這個(gè)功能修改完畢，否則 Sparkle無(wú)法支付她的銀行帳單。 Phil 如果你一開(kāi)始就告訴我你想隨時(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 根本原因是什么？ 需求的鴻溝 (期望差異 )： 開(kāi)發(fā)者開(kāi)發(fā)的與用戶所想得到 的軟件存在著巨大期望差異。 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á)到哪些性能等 。 ? 軟件需求： 以一種清晰、簡(jiǎn)潔、一致且無(wú)二義性的方式，描述用戶對(duì)目標(biāo)軟件系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望，是在開(kāi)發(fā)過(guò)程中對(duì)系統(tǒng)的約束。 ? 需求通常用于表達(dá) “做什么” ，而不描述“ 如何做 ”。 2023/1/30 16 關(guān)于“需求”的例子 ? Course Registration System(學(xué)生選課系統(tǒng) ) – 某大學(xué)希望采用計(jì)算機(jī)管理學(xué)生的選課 – 學(xué)生可以在一個(gè)學(xué)期開(kāi)始之前選擇該學(xué)期開(kāi)設(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ù)表中獲得課程的開(kāi)設(shè)信息。 2023/1/30 17 軟件需求的分類 軟件需求的分類 2023/1/30 18 不同層次的軟件需求 業(yè)務(wù)需求項(xiàng)目視圖與范圍文檔業(yè)務(wù)規(guī)則用例文檔功能需求軟件需求規(guī)格說(shuō)明外部接口需求用戶需求功能性需求 非功能性需求約束條件非功能需求2023/1/30 19 1. 業(yè)務(wù)需求 ? 業(yè)務(wù)需求 (Business Requirements)： 客戶對(duì)于系統(tǒng)的 高層次目標(biāo)要求 (highlevel objectives) ，定義了項(xiàng)目的 遠(yuǎn)景和范疇 (vision and scope) – 業(yè)務(wù)：屬于哪類業(yè)務(wù)范疇？應(yīng)完成什么功能？為何目的？ – 客戶：軟件為誰(shuí)服務(wù)？目標(biāo)客戶是誰(shuí)？ – 特性：區(qū)別于其他競(jìng)爭(zhēng)產(chǎn)品的特性是什么？ – 價(jià)值：價(jià)值體現(xiàn)在那些方面？ – 優(yōu)先級(jí)：功能特性的優(yōu)先級(jí)次序是什么？ ? [例 ]―圖書(shū)資料管理系統(tǒng)”的業(yè)務(wù)需求 – 該系統(tǒng)使用計(jì)算機(jī)實(shí)現(xiàn)圖書(shū)資料日常管理，提高工作效率和服務(wù)質(zhì)量； – 該系統(tǒng)可讓用戶在網(wǎng)絡(luò)上查詢與瀏覽電子資料，改變?cè)械慕栝喣Ｊ剑? – 由于版權(quán)的限制，某些電子資料只能瀏覽 /打印，但不能下載。 2023/1/30 20 2. 用戶需求 (目標(biāo)需求 ) ? 用戶需求 (User Requirements)： 從用戶角度描述的 系統(tǒng)功能需求與非功能需求 ，通常只涉及系統(tǒng)的 外部行為 而不涉及內(nèi)部特性。 ? [例 ]用戶可以通過(guò) Inter隨時(shí)查詢圖書(shū)信息和個(gè)人借閱情況，并可以快速查找和瀏覽需要的電子資料； – [功能需求 ]用戶通過(guò) Inter查詢圖書(shū)信息； – [功能需求 ]用戶通過(guò) Inter瀏覽個(gè)人借閱情況； – [功能需求 ]用戶通過(guò) Inter查找和瀏覽電子資料； – [非功能需求 ]隨時(shí)、快速 2023/1/30 21 業(yè)務(wù)需求與用戶需求的對(duì)比 ? 針對(duì) Course Registration System ? 業(yè)務(wù)需求 – 由于實(shí)行學(xué)分制管理，學(xué)校領(lǐng)導(dǎo)希望用計(jì)算機(jī)管理學(xué)生選課。 – 課程信息維護(hù)、選課管理、課程成績(jī)登記和查詢等業(yè)務(wù)全部由手工方式改為計(jì)算機(jī)應(yīng)用。 ? 用戶需求 – 教務(wù)管理員希望能夠增加、修改和刪除學(xué)校的課程目錄，并且設(shè)置各學(xué)期課程的開(kāi)設(shè)信息。 – 學(xué)生希望能夠在學(xué)期開(kāi)始之前查詢所有開(kāi)設(shè)課程的詳細(xì)信息，并能夠通過(guò)校園網(wǎng)進(jìn)行選課。 – 學(xué)生希望在選課期間系統(tǒng)能夠 24小時(shí)使用，系統(tǒng)使用方便快捷。 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é)； ? [例 ] – 用戶可從圖書(shū)資料庫(kù)中查詢或者選擇其中一個(gè)子集； – 系統(tǒng)可提供適當(dāng)?shù)臑g覽器供用戶閱讀館藏文獻(xiàn)； – 用戶每次借閱圖書(shū)應(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ù)精度、可靠性等。 ? [例 ] – 系統(tǒng)在 20秒內(nèi)響應(yīng)所有的請(qǐng)求； – 系統(tǒng)應(yīng)該每周 7天、每天 24小時(shí)都可使用； – 對(duì)一個(gè)沒(méi)有經(jīng)驗(yàn)的用戶而言，經(jīng)過(guò) 2小時(shí)培訓(xùn)即可使用系統(tǒng)所有功能。 ? 注意：非功能需求隱含了對(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)行描述。 ? 例如： – 即使對(duì)一個(gè)沒(méi)有經(jīng)驗(yàn)的用戶，系統(tǒng)也應(yīng)該很容易使用，且是用戶錯(cuò)誤降到最少； ? 修改為： – 對(duì)一個(gè)沒(méi)有經(jīng)驗(yàn)的用戶來(lái)說(shuō)，經(jīng)過(guò) 2個(gè)小時(shí)的培訓(xùn)就應(yīng)該使用系統(tǒng)的全部功能。在這樣的培訓(xùn)之后，一個(gè)有經(jīng)驗(yàn)的用戶每天的出錯(cuò)平均數(shù)不應(yīng)超過(guò) 2次。 2023/1/30 25 ? NFR：檢驗(yàn)起來(lái)非常困難，一般采用一些可度量的特性進(jìn)行描述。 非功能需求的度量 非功能特性 度量指標(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è)例子：拼寫(xiě)檢查器 ? 業(yè)務(wù)需求： “用戶能有效地糾正文檔中的拼寫(xiě)錯(cuò)誤” ； ? 用戶需求： “找出文檔中的拼寫(xiě)錯(cuò)誤并通過(guò)一個(gè)提供的替換項(xiàng)列表來(lái)供選擇替換拼錯(cuò)的詞”； ? 功能性需求： – 找到拼寫(xiě)錯(cuò)誤的單詞并以高亮度提示 – 顯示提供替換詞的對(duì)話框 – 實(shí)現(xiàn)整個(gè)文檔范圍的替換 ? 非功能性需求： – 正確的找到至少 95%以上的錯(cuò)詞并 100%的加以正確替換 – 拼寫(xiě)檢查的速度應(yīng)至少達(dá)到 5000詞 /秒。 2023/1/30 27 5. 約束條件 ? 約束條件 (Constraints)： 系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)時(shí)必須滿足的 限制條件 ，對(duì)其進(jìn)行權(quán)衡或調(diào)整是相當(dāng)困難的，甚至是不可能的； ? 例如： – 系統(tǒng)必須用 C++或其他面向?qū)ο笳Z(yǔ)言編寫(xiě)； – 系統(tǒng)用戶接口需要采用圖形化界面； – 任取 10秒，一個(gè)特定應(yīng)用所消耗的可用計(jì)算能力平均不超過(guò) 50%； – 系統(tǒng)開(kāi)發(fā)過(guò)程和交付文檔需遵循 GB/T 85672023標(biāo)準(zhǔn)； – 通訊接口必須符合 ISO七層架構(gòu)。 ? 來(lái)源：法規(guī)政策、硬件 /資源限制、開(kāi)發(fā)語(yǔ)言、等等。 2023/1/30 28 6. 業(yè)務(wù)規(guī)則 ? 業(yè)務(wù)規(guī)則 (Business Rule)： 對(duì)某些功能的可執(zhí)行性或 內(nèi)部執(zhí)行邏輯 的一些限定條件。 – 通常表達(dá)為“如果 … ，那么 …‖ 的形式 – 通常是一些容易發(fā)生變化的功能； ? 例如： – 如果借書(shū)卡類型為“教師”，那么一次借閱的最大數(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秒。 ? 必須在對(duì)話窗口的中間顯示錯(cuò)誤警告，使用紅色的、 14點(diǎn)加粗 Arial字體。 ? 系統(tǒng)必須有能力存儲(chǔ)平均操作連續(xù) 100天所產(chǎn)生的事務(wù)。 ? 系統(tǒng)應(yīng)該在 5分鐘內(nèi)計(jì)算出給定季度的總銷(xiāo)售稅。 ? 系統(tǒng)應(yīng)該在 1分鐘內(nèi)從 100