【正文】 2023/1/30 1 第三章 需求工程 主講：任向民 2023/1/30 2 第三章 需求工程 2023/1/30 3 軟件需求定義 2023/1/30 4 軟件需求的分類 軟件需求的定義 2023/1/30 5 ? 軟件需求工程的目的是定義軟件所需要解決的問題 。 ? 軟件需求是要把一個定義不足和模糊的問題轉換為一個定義良好而準確的問題，進而找到解決問題的方案。 2023/1/30 6 主要困難 ： 1. 軟件開發(fā)人員與用戶雙方固有的矛盾 2. 需求具有易變性和難以表述性 3. 需求錯誤的高頻性和修復的高成本性 2023/1/30 7 軟件開發(fā)的目標是什么？ ? 開發(fā)高質量的軟件； ? 在預定的時間和預算約束下完成； ? 軟件要能夠滿足顧客的需求。 2023/1/30 8 但實際情況是什么樣子？ ? 調查報告的數(shù)字是這樣的 … ?Standish Group 2023 Succeeded Challenged Failed 用戶參與程度高： 16% 用戶高層的支持： 14% 對需求的清晰陳述： 12% 缺乏用戶參與： 13% 需求規(guī)格說明不完整： 12% 需求頻繁的發(fā)生變化： 12% 結論： 對用戶需求的管理水平 是決定軟件成敗的重要原因 2023/1/30 9 [案例分析 1] ―只有結婚后才可以修改姓名嗎？” ? Phil開發(fā)了一套人力資源軟件，有一天他接到了人力資源部 Maria打來的電話 … Maria 一個同事想把自己名字改為 Sparkle Starlight，但系統(tǒng)不允許，能幫忙嗎？ Phil 她嫁給了一個姓 Starlight的人嗎？ Maria 不，她并沒有結婚，她只是想改名字而已； Phil 系統(tǒng)只支持在改變婚姻狀況時才可以改名字。 Maria 可是每個人只要愿意就可以隨時改變自己的名字啊。 Phil 這并不是我的錯！在開發(fā)系統(tǒng)之前，你從來沒有向我提起過有這種需求！ Maria 不管如何，請盡快把這個功能修改完畢，否則 Sparkle無法支付她的銀行帳單。 Phil 如果你一開始就告訴我你想隨時改變某人的名字，那這些就都不會發(fā)生！ …… 2023/1/30 10 “錯誤的需求”的擴散效應 問題 正確的需求 錯誤的需求 正確的設計 基于“錯誤的需求” 的設計 錯誤的設計 基于“錯誤的 設計”的編碼 正確的編碼 錯誤的編碼 基于“錯誤的需求” 的編碼 2023/1/30 11 “錯誤的需求”的修復代價 “構建一個軟件系統(tǒng)最困難的部分是確定構建什么 … 在出錯之后會嚴重影響隨后實現(xiàn)的系統(tǒng)，并且在以后的修補是如此的困難 …‖ 2023/1/30 13 根本原因是什么？ 需求的鴻溝 (期望差異 )： 開發(fā)者開發(fā)的與用戶所想得到 的軟件存在著巨大期望差異。 2023/1/30 14 什么是“軟件需求” ? 軟件需求 (Software Requirements)： – 用戶解決問題以達到特定目標所需的能力； – 系統(tǒng)或系統(tǒng)構件要滿足的合同、標準、規(guī)范或其他正式文檔所需具備的能力； ——IEEE, 1997 – 指用戶對軟件的功能與性能需求 ,就是用戶希望軟件能夠做什么事情 ,完成哪些功能，達到哪些性能等 。 ? 軟件需求： 以一種清晰、簡潔、一致且無二義性的方式，描述用戶對目標軟件系統(tǒng)在功能、行為、性能、設計約束等方面的期望，是在開發(fā)過程中對系統(tǒng)的約束。 ? 需求通常用于表達 “做什么” ，而不描述“ 如何做 ”。 2023/1/30 16 關于“需求”的例子 ? Course Registration System(學生選課系統(tǒng) ) – 某大學希望采用計算機管理學生的選課 – 學生可以在一個學期開始之前選擇該學期開設的某些課程 – 老師可以使用選課系統(tǒng)獲得選課學生的名單，并登記學生的課程學習成績 – 學生不希望自己的學習成績被他人查閱 – ……( 你可以補充嗎？ ) ? 以下描述是否屬于需求？為什么？ – 系統(tǒng)通過 JDBC與 Oracle數(shù)據(jù)庫 CourseDB建立連接，并使用 TSQL語句從 CourseOffering數(shù)據(jù)表中獲得課程的開設信息。 2023/1/30 17 軟件需求的分類 軟件需求的分類 2023/1/30 18 不同層次的軟件需求 業(yè)務需求項目視圖與范圍文檔業(yè)務規(guī)則用例文檔功能需求軟件需求規(guī)格說明外部接口需求用戶需求功能性需求 非功能性需求約束條件非功能需求2023/1/30 19 1. 業(yè)務需求 ? 業(yè)務需求 (Business Requirements)： 客戶對于系統(tǒng)的 高層次目標要求 (highlevel objectives) ，定義了項目的 遠景和范疇 (vision and scope) – 業(yè)務：屬于哪類業(yè)務范疇？應完成什么功能？為何目的？ – 客戶：軟件為誰服務？目標客戶是誰？ – 特性：區(qū)別于其他競爭產(chǎn)品的特性是什么？ – 價值：價值體現(xiàn)在那些方面？ – 優(yōu)先級：功能特性的優(yōu)先級次序是什么？ ? [例 ]―圖書資料管理系統(tǒng)”的業(yè)務需求 – 該系統(tǒng)使用計算機實現(xiàn)圖書資料日常管理，提高工作效率和服務質量； – 該系統(tǒng)可讓用戶在網(wǎng)絡上查詢與瀏覽電子資料，改變原有的借閱模式； – 由于版權的限制，某些電子資料只能瀏覽 /打印，但不能下載。 2023/1/30 20 2. 用戶需求 (目標需求 ) ? 用戶需求 (User Requirements)： 從用戶角度描述的 系統(tǒng)功能需求與非功能需求 ，通常只涉及系統(tǒng)的 外部行為 而不涉及內部特性。 ? [例 ]用戶可以通過 Inter隨時查詢圖書信息和個人借閱情況，并可以快速查找和瀏覽需要的電子資料； – [功能需求 ]用戶通過 Inter查詢圖書信息； – [功能需求 ]用戶通過 Inter瀏覽個人借閱情況； – [功能需求 ]用戶通過 Inter查找和瀏覽電子資料； – [非功能需求 ]隨時、快速 2023/1/30 21 業(yè)務需求與用戶需求的對比 ? 針對 Course Registration System ? 業(yè)務需求 – 由于實行學分制管理，學校領導希望用計算機管理學生選課。 – 課程信息維護、選課管理、課程成績登記和查詢等業(yè)務全部由手工方式改為計算機應用。 ? 用戶需求 – 教務管理員希望能夠增加、修改和刪除學校的課程目錄，并且設置各學期課程的開設信息。 – 學生希望能夠在學期開始之前查詢所有開設課程的詳細信息，并能夠通過校園網(wǎng)進行選課。 – 學生希望在選課期間系統(tǒng)能夠 24小時使用，系統(tǒng)使用方便快捷。 2023/1/30 22 3. 功能需求 ? 功能需求 (Functional Requirements, FR)： 系統(tǒng)應該提供的 功能或服務 ，通常涉及用戶或外部系統(tǒng)與該系統(tǒng)之間的交互，不考慮系統(tǒng)內部的實現(xiàn)細節(jié)； ? [例 ] – 用戶可從圖書資料庫中查詢或者選擇其中一個子集； – 系統(tǒng)可提供適當?shù)臑g覽器供用戶閱讀館藏文獻； – 用戶每次借閱圖書應對應一個唯一的標識號，它被記錄到用戶的賬戶上； 2023/1/30 23 4. 非功能需求 ? 非功能需求 (NonFunctional Requirements, NFR)： 從各個角度對系統(tǒng)的約束和限制，反映了客戶對軟件系統(tǒng) 質量和性能(quality and performance)的額外要求，如響應時間、數(shù)據(jù)精度、可靠性等。 ? [例 ] – 系統(tǒng)在 20秒內響應所有的請求； – 系統(tǒng)應該每周 7天、每天 24小時都可使用； – 對一個沒有經(jīng)驗的用戶而言，經(jīng)過 2小時培訓即可使用系統(tǒng)所有功能。 ? 注意：非功能需求隱含了對可選設計方案的一些關鍵影響 – 體系結構設計 (., 體系結構風格選擇 ) – 算法設計 (., 排序策略的選擇 ) 2023/1/30 24 非功能需求的度量 ? NFR：檢驗起來非常困難，一般采用一些可度量的特性進行描述。 ? 例如： – 即使對一個沒有經(jīng)驗的用戶，系統(tǒng)也應該很容易使用，且是用戶錯誤降到最少； ? 修改為： – 對一個沒有經(jīng)驗的用戶來說，經(jīng)過 2個小時的培訓就應該使用系統(tǒng)的全部功能。在這樣的培訓之后，一個有經(jīng)驗的用戶每天的出錯平均數(shù)不應超過 2次。 2023/1/30 25 ? NFR：檢驗起來非常困難，一般采用一些可度量的特性進行描述。 非功能需求的度量 非功能特性 度量指標 速度 每秒處理的事務 用戶的響應時間 屏幕的刷新速度 存儲空間 字節(jié)數(shù) RAM芯片數(shù) 可用性 培訓時間 幫助頁面數(shù) 可靠性 平均失敗時間 系統(tǒng)無效的概率 失敗發(fā)生率 容錯性 失敗后的重啟次數(shù) 事件引起失敗的比例 失敗時數(shù)據(jù)崩潰的可能性 2023/1/30 26 一個例子：拼寫檢查器 ? 業(yè)務需求： “用戶能有效地糾正文檔中的拼寫錯誤” ； ? 用戶需求： “找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞”； ? 功能性需求： – 找到拼寫錯誤的單詞并以高亮度提示 – 顯示提供替換詞的對話框 – 實現(xiàn)整個文檔范圍的替換 ? 非功能性需求： – 正確的找到至少 95%以上的錯詞并 100%的加以正確替換 – 拼寫檢查的速度應至少達到 5000詞 /秒。 2023/1/30 27 5. 約束條件 ? 約束條件 (Constraints)： 系統(tǒng)設計和實現(xiàn)時必須滿足的 限制條件 ，對其進行權衡或調整是相當困難的，甚至是不可能的； ? 例如： – 系統(tǒng)必須用 C++或其他面向對象語言編寫； – 系統(tǒng)用戶接口需要采用圖形化界面； – 任取 10秒，一個特定應用所消耗的可用計算能力平均不超過 50%； – 系統(tǒng)開發(fā)過程和交付文檔需遵循 GB/T 85672023標準； – 通訊接口必須符合 ISO七層架構。 ? 來源：法規(guī)政策、硬件 /資源限制、開發(fā)語言、等等。 2023/1/30 28 6. 業(yè)務規(guī)則 ? 業(yè)務規(guī)則 (Business Rule)： 對某些功能的可執(zhí)行性或 內部執(zhí)行邏輯 的一些限定條件。 – 通常表達為“如果 … ，那么 …‖ 的形式 – 通常是一些容易發(fā)生變化的功能； ? 例如： – 如果借書卡類型為“教師”，那么一次借閱的最大數(shù)量為 8本； – 如果訂單金額大于 10000元，那么該訂單的折扣為 10%； – 如果采購單金額在 10萬到 50萬之間，那么需要總經(jīng)理審批； 2023/1/30 29 7. 外部接口需求 ? 外部接口需求 (External Interface Requirement)： 描述系統(tǒng)與其所處的 外部環(huán)境之間如何進行交互 ，包括： – 用戶接口需求 (UI) – 硬件接口需求 – 軟件接口需求 – 通信接口需求 ? 例如： – “從 某些設備 讀取信號” – “給 一些其它系統(tǒng) 發(fā)送消息” – “以 某種格式 讀取文件” – “能控制 一些硬件 ‖ – ―采用 某種類型的 用戶界面” 2023/1/30 30 關于需求的一些例子 ? 系統(tǒng)必須有能力支持 100個以上的并發(fā)用戶，每個用戶可以處理操作任務的任選組合，平均響應時間應該小于 1秒，最大響應時間應小于 5秒。 ? 必須在對話窗口的中間顯示錯誤警告，使用紅色的、 14點加粗 Arial字體。 ? 系統(tǒng)必須有能力存儲平均操作連續(xù) 100天所產(chǎn)生的事務。 ? 系統(tǒng)應該在 5分鐘內計算出給定季度的總銷售稅。 ? 系統(tǒng)應該在 1分鐘內從 100