需求分析基礎 3 第三章 軟件需求作為軟件生命周期的第一個階段 其重要性越來越突出 到20世紀80年代中期 逐步形成了軟件工程的子領域 需求工程 90年代后 需求工程成為軟件界研究的重點之一 從1993年起 每兩年舉辦一次需求工程國際研討會 ISRE 1994年起 每兩年舉辦一次需求工程國際會議 ICRE 一些關于需求工程的工作小組相繼成立 使需求工程的研究得到了迅速進展 3 1軟件需求工程的基本概念 對系統應該提供的服務和所受到的約束進行理解 分析 建立文檔 檢驗的過程 需求工程 1 什么是軟件需求工程 2 軟件需求工程的任務是什么 3 需求工程過程4 軟件需求分析方法 軟件需求的重要性 軟件需求無疑是當前軟件工程中的關鍵問題 沒有需求就沒有軟件 美國于1995年開始對全國范圍內的8000個軟件項目進行跟蹤調查 分析失敗的原因發現 與需求過程相關的原因占了45 而其中缺乏最終用戶的參與以及不完整的需求又是兩大首要原因 各占13 和12 未完成 完成未實施 完成 軟件需求的困難 軟件需求是軟件工程中最復雜的過程之一 應用領域的廣泛性 它的實施無疑與各個應用行業的特征密切相關 非功能性需求建模技術的缺乏 及其與功能性需求有著錯綜復雜的聯系 大大增加了需求工程的復雜性 溝通上的困難 由于系統分析員 需求分析員等各方面人員有不同的著眼點和不同的知識背景 給需求工程的實施增加了人為的難度 軟件需求 軟件需求的內容 一 軟件需求內容 功能需求它是對系統應該提供的服務 功能以及系統在特定條件下的行為的描述 它與軟件系統的類型 使用系統的用戶等相關 有時需要詳細描述系統的功能 輸入 輸出 異常等 有時還需要申明系統不應該做什么 領域需求是由軟件系統的應用領域所決定的特有的功能需求 或是對功能的約束 傳統需求分析 在傳統軟件工程生命周期中 涉及需求的階段稱作需求分析 一般來說 需求分析的作用是 定義軟件的范圍及必須滿足的約束 確定軟件的功能和性能及與其他系統成分的接口 建立數據模型 功能模型和行為模型 最終提供需求規格說明 并用于作為評估軟件質量的依據 二 需求工程的活動 需求工程是系統工程和軟件工程的一個交叉分支 涉及到軟件系統的目標 軟件系統提供的服務 軟件系統的約束和軟件系統運行的環境 它還涉及這些因素和系統的精確規格說明以及系統進化之間的關系 它也提供現實需求和軟件能力之間的橋梁 需求工程 需求工程的基本活動包括 獲取需求 深入實際 在充分理解用戶需求的基礎上 獲取系統需求 需求分析與建模 進行需求建模 對模型或原型進行分析 確認需求 確保需求說明準確 完整地表達系統的主要特性 進化需求 客戶的需要總是不斷 連續 增長的 進化需求是必要的 一 需求獲取 requirementelicitation 是需求工程的主體 缺乏領域知識 應用領域的問題常常是模糊的 不精確的 存在默認的知識 如難以描述的常識問題 存在多個知識源 且多知識源之間可能有沖突 客戶可能的偏見 如不能提供或不想告知你所需要了解的事情 非常困難 主要原因有 需求獲取技術 需求抽取的方法一般有 1 面談法重要而直接 簡單的需求獲取技術 2 問卷調查法是對面談法的補充 3 需求專題討論會最有力的需求獲取技術 有利于培養高效團隊 4 觀察用戶的工作流程適用于用戶無法準確表達需求的情況 5 原型化方法6 基于用例的方法 還有知識工程方法等如 場記分析法 卡片分類法 分類表格技術和基于模型的知識獲取等 面談的對象主要有用戶和領域專家 1 面談前的準備要充分 2 面談后注意認真分析總結 3 注意掌握面談的人際交流技能 需求獲取技術 需求抽取的方法一般有 1 面談法重要而直接 簡單的需求獲取技術 2 問卷法調查法是對面談法的補充 3 需求專題討論會最有力的需求獲取技術 有利于培養高效團隊 4 觀察用戶的工作流程適用于用戶無法準確表達需求的情況 5 原型化方法6 基于用例的方法 是從多個用戶中收集需求信息的有效方式 一般問卷設計形式 1 多項選擇問題 2 評分問題 3 排序問題 需求獲取技術 需求抽取的方法一般有 1 面談法重要而直接 簡單的需求獲取技術 2 問卷法調查法是對面談法的補充 3 需求專題討論會最有力的需求獲取技術 有利于培養高效團隊 4 觀察用戶的工作流程適用于用戶無法準確表達需求的情況 5 原型化方法6 基于用例的方法 由開發方和用戶方共同召開 操作步驟 開發方根據雙方制定的 需求調研計劃 召開相關需求主題溝通會 會后開發方整理出 需求調研記錄 提交給用戶方確認 如果此主題還有未明確的問題則再次溝通 否則開始下一主題 所有需求都溝通清楚后 開發方根據歷次 需求調研記錄 整理出 用戶需求說明書 提交給用戶方確認簽字 因此系統應該具備以下功能 基本數據維護功能 基本業務功能 數據庫管理功能 信息查詢功能 例1 有一個大學圖書管理系統 該系統除了一般的圖書管理功能外 還能夠為學生和教工從其他圖書館借閱圖書和文獻資料提供服務 1 功能需求 基本數據維護功能 提供使用者錄入 修改并進行維護基本數據的途徑 基本數據包括讀者的信息 圖書資料的相關信息 可以對這些信息進行修改 更新 基本業務功能 讀者借 還書籍的登記管理功能 隨時根據讀者借 還書籍的情況更新數據庫系統 如果書籍已經借出 可以進行預留操作 書籍的編目 入庫 更新等操作 數據庫管理功能 對所有圖書信息及讀者信息進行統一管理維護的功能 對書籍的借還也要進行詳細的登記 以便協調整個圖書館的運作 信息查詢功能 提供對各類信息的查詢功能 如對本圖書館的用戶借書信息 還書的信息 書籍源信息 預留信息等進行查詢 對其他圖書館的書籍 資料源信息的查詢功能 2 非功能需求 系統安全性需求 為保證系統安全性 對本圖書館的各項功能進行分級 分權限操作 對各類用戶進行確認 對其它圖書館借閱圖書和文獻資料服務控制訪問范圍 如限IP 限用戶等 對系統可用性的需求 為了方便使用者 要求對所有交互操作提供在線幫助功能 對系統查詢速度的需求 要求系統在20S之內響應查詢服務請求 對系統可靠性的需求 要求系統失敗發生率小于1 3 領域需求例如 對 大學圖書管理系統 提出一些與圖書管理的業務相關的需求 圖書編目要求按照 中國圖書館分類法 進行 由于版權限制 某些文獻資料只能在圖書館規定的閱覽室閱讀 并限制復制和打印 第一條需求是對遵循我國圖書管理的規定 執行對圖書的分類管理的標準 而第二條需求則是版權法對圖書館文獻資料的保護的需要 描述了對一類文獻資料有限制的使用和服務 二 需求分析與建模 需求分析和建模又包含三個層次的工作 1 需求分析2 需求建模 分為企業建模 功能需求建模和非功能需求建模等 3 需求規格說明 不同的描述方式 主要對收集到的需求進行提煉 分析和認真審查 確保所有參加人員取得一致共識 找出錯誤 遺漏和不足 建立完整的分析模型 需求分析常用技術 為了降低軟件的復雜度 便于對問題的分析和理解 常采用以下技術 1 分解將大問題分解為小問題 通常是自頂而下 不斷細化的過程 2 抽象抓住問題的本質特性 從不同抽象層次進行分析 提出解決問題的方案 3 多視點注意從各類開發人員和不同用戶的角度考慮問題 才能獲得對系統的全面完整的需求 三 需求的有效性驗證 一 需求驗證的重要性 由于需求是軟件開發的第一階段 直接影響后面各階段的開發 需求的可變性必須進行驗證 做什么 怎么做 三 需求的有效性驗證 二 需求驗證的內容1 有效性檢查 指功能需求是否符合用戶所提出的需求 2 一致性檢查 系統功能描述及約束是否一致 3 完備性檢查 是否包含所有系統用戶的需求和約束 4 可檢驗性檢查 是否能設計出一組驗證方法 確定了檢驗的標準 四 需求管理 需求管理貫穿需求分析全過程 包括 四 需求管理 需求管理的所有活動中 最重要的是 需求變更管理 包括 問題分析和變更描述 變更分析和成本計算 變更實現 需求管理過程需要CASE ComputerAidedSoftwareEngineering 工具支持 1 傳統的變化管理基本內容包括軟件配置 軟件基線和變化審查 2 新的管理方法 軟件家族法 即軟件產品線方法 該方法是源于工業界產品線的概念 關注于一個軟件企業如何組織一組具有共性特征的 相似產品的生產 并應用軟件復用的相關原理與技術 多視點方法 它可以用于管理不一致性并進行關于變化的推理 是從多個視點出發在軟件工具的協助下對需求描述 進行自動需求建模 從而提高需求模型的完整性 需求變更管理方法 需求工程過程 3 2需求分析方法 功能分解方法將系統看作若干功能模塊的集合 每個功能又可以分解為子功能 子功能還可繼續分解 分解的結果即是系統的雛形 存在問題1 需要人工完成2 無法對描述的準確度進行驗證 3 難以適應需求的變化 1 客房預定系統2 前臺接待系統3 前臺收銀系統4 帳務系統5 管家系統6 電話系統7 客歷系統8 合約系統9 經理系統10 總經理系統11 密碼管理系統12 報表系統13 帳務報表 酒店管理系統 例 按照功能分解為以下子系統 例 盤存 銷售系統 用戶提出系統應有以下功能 計算買主訂單 準備銷售報表 建立買主文件和應收帳發票 運行更新的盤存文件 產生托運單和包裝單 保證庫存及時訂貨 計算銷售記錄1 1 1 產生銷售報表1 1 2 核對買主貸方金額1 1 3 3 2需求分析方法 結構化分析方法是一種以數據 數據的封閉性為基礎 從問題空間到某種表示的映射方法 由數據流圖 DFD圖 表示 3 2需求分析方法 面向對象的分析方法面向對象分析方法 OOA 的關鍵是識別問題域內的對象 分析它們之間的關系 并建立起三類模型 信息建模法是從數據的角度對現實世界建立系統的信息模型 基本工具是ER圖 是由實體 屬性和關系組成的網絡圖 E 實體 是一個或一組對象 R 關系 實體之間聯系或交互作用 注意 信息建模與面向對象分析的區別 3 2 1結構化分析方法 分解 對于一個復雜的系統 為了將復雜性降低到可以掌握的程度 可以把大問題分解成若干小問題 然后分別解決 如右圖 一 SA法的基本思想 分解 和 抽象 抽象 分解可以分層進行 即先考慮問題最本質的屬性 暫把細節略去 以后再逐層添加細節 直至涉及到最詳細的內容 這種用最本質的屬性表示一個系統的方法就是 抽象 基本思想與步驟 三 SA法的描述方法1 分層的數據流圖 DFD圖 2 數據詞典3 描述加工邏輯的結構化語言 判定表及判定樹 二 SA法的步驟 深入調查研究 分析用戶需求 用DFD圖描述 分析系統需求 用DFD圖描述 修改完善DFD圖 增添功能 顧客 出版社 驗證訂單 匯總訂單 訂單 出版社訂單 圖書目錄文件 正確訂單 一批訂單 出版社檔案文件 畫圖步驟 1 確定外部實體及輸入 輸出數據流 2 確定分解頂層的加工 3 確定使用的文件 4 用數據流將各部分連接起來 形成數據封閉 注意 標注各加工框及數據流名稱 例一圖書預定系統 頂層DFD圖 2020 1 9 37 三 數據流圖 數據流圖 DataFlowDiagram DFD 是描述系統中數據流程的圖形工具 它描述了將系統的邏輯輸入轉換為邏輯輸出所需的加工處理過程 還有一些輔助的圖例 一 數據流圖的圖符基本圖形符號 頂層 中間層 底層 先全局后局部 先整體后細節 先抽象后具體 0圖 1圖 2圖 1 1圖 2 1圖 2 2圖 分層DFD圖 需求案例分析 案例一醫院病房監護系統 采用結構化分析方法 案例二網上競拍系統 采用基于用例的方法 一 問題的描述在醫院ICU病房里 將病癥監視器安置在每個病床 對病人進行監護 監視器將病人的組合病癥信號實時地傳送到中央監護系統進行分析處理 在中心值班室里 值班護士使用中央監護系統對病員的情況進行監控 監護系統實時地將病人的病癥信號與標準的病診信號進行比較分析 當病癥出現異常時 系統會立即自動報警 并打印病情報告和更新病歷 根據醫生的要求隨時打印病人的病情報告 系統還定期自動更新病歷 案例一醫院病房監護系統 經過初步的需求分析 得到系統功能要求 1 監視病員的病癥 血壓 體溫 脈搏等 2 定時更新病歷 3 病情出現異常情況時報警 4 隨機地產生某一病員的病情報告 例2 醫院病房監護系統 監視病情 更新病歷 2 2 3實例 醫院病房監護系統 請分析軟件系統需求 1 監視病員的病癥 采集病癥信號 血壓 體溫 脈搏等 組合病癥信號 將模擬病癥信號轉換為數字信號 A D轉換 2 定時更新病歷 將病癥信號進行格式化并加入更新日期 時間 更新病歷庫中病人的信息 可人工設定更新病歷的時間間隔 3 病情出現異常情況時報警 根據標準病癥信號庫中的值 判斷是否報警 將報警信號轉換為各種模擬信號 D A轉換 實時打印病情報告 立即更新病歷 4 隨機地產生某一病員的病情報告 二 系統功能需求 局部監視 更新日志 產生病情報告 非功能需求 1 監視器與網絡的可靠性要求 涉及人的生命安全 2 效率需求中對時間 空間的需求 所采集的病癥信號數據量大 3 互操作需求 如要求監視器采樣頻率可人工調整等 4 對病人病歷的隱私的要求 頂層DFD圖 醫院病房監護系統分層DFD圖 頂層確定了系統的范圍 其外部實體為病員和護士 護士 病員 護士 第一層 醫院病房監護系統頂層DFD圖 第二層 加工 中央監視 分解 醫院病房監護系統二層DFD圖 醫院病房監護系統分層DFD圖 緊急報告 加工分解的原則自然性 概念上合理 清晰 均勻性 理想的分解是將一個問題分解成大小均勻的幾個部分 分解度 一般每一個加工每次分解最多不要超過 個子加工 分解應分解到基本加工為止 四 畫分層DFD圖的基本原則 數據守恒與數據封閉原則數據守恒是指加工的輸入 出數據流是否匹配 即每一個加工既有輸入數據流又有輸出數據流 數據封閉是對整個系統而言 合理使用文件當文件作為某些加工之間的交界面時 文件必須畫出來 一旦文件作為數據流圖中的一個獨立成份畫出來了 那么他同其他成份之間的聯系也應同時表達出來 注意 DFD圖不是流程圖 不表示軟件的控制流程 四 畫分層DFD圖的基本原則 子圖與父圖的 平衡 父圖中某個加工的輸入輸出數據流應該同相應的子圖的輸入輸出相同 相對應 分層數據流圖的這種特點稱為子圖與父圖 平衡 五 分層DFD圖的改進 DFD圖須經過反復修改 才能獲得最終的目標系統的DFD圖 從以下方面改進DFD圖 1 檢查數據流的正確性 數據守恒 子圖 父圖的平衡 文件使用是否合理 特別注意輸入 出文件的數據流 2 改進DFD圖的易理解性 簡化加工之間的聯系 聯系越少 獨立性越強 易理解性越好 改進分解的均勻性 適當命名 各成分名稱無二義性 準確 具體 分層數據流圖只是表達了系統的 分解 為了完整地描述這個系統 還需借助 數據詞典 和 小說明 對圖中的每個數據和加工給出解釋 對數據流圖中包含的所有元素的定義的集合構成了數據詞典 詞典中可有以下四種類型的條目 六 數據詞典 DD 數據流文件數據項加工 A 數據流條目給出某個數據流的定義 通常是列出該數據流的各組成數據項 例如 報名單 姓名 單位名 年齡 性別 課程名常用符號 C 數據項條目數據項條目給出某個數據單項的定義 通常是數據項的值類型 允許的取值范圍 B 文件條目給出某個文件的定義 文件的定義通常是列出文件記錄的組成數據流 例如 訂單文件 訂單編號 顧客名稱 產品名稱 訂貨數量 交貨日期 D 加工條目加工類條目就是 加工小說明 一般應該單獨列出 七 加工說明 結構化語言判定表判定樹 對DFD圖中每一個基本加工都必須有一個小說明給出該加工的精確描述 小說明中應精確地描述加工的激發條件 加工邏輯 優先級 執行頻率和出錯處理等 加工邏輯是其中最基本的部分 指用戶對這個加工的邏輯要求 對基本加工說明有三種描述方式 結構化語言是介于自然語言和形式語言之間的一種半形式語言 是自然語言的一個受限制的子集 一般分為兩層結構 外層語法較具體 為控制結構 順序 選擇 循環 內層較靈活 表達 做什么 一 結構化語言 例如 外層可為以下結構 1 順序結構2 選擇結構IF THEN ELSE CASE OF ENDCASE 3 循環結構WHILE DO REPEAT UNTIL 判定表是一種二維的表格 常用于較復雜的組合條件 與結構化語言比較 二 判定表 特點 可處理較復雜的組合條件 但不易理解 不易輸入計算機 通常由四部分組成 條件框 條件定義 操作框 操作的定義 條件條目 各條件的取值及組合 操作條目 在各條件取值組合下所執行的操作 例如 對商店每天的營業額所收稅率 例 一圖書銷售系統 其中一加工為 優惠處理 條件是 顧客的營業額大于1000元 同時必須信譽好 或者雖然信譽不好 但是20年以上的老主顧 判定表應用舉例 特點 描述一般組合條件較清晰 易理解 不易輸入計算機 如上例 三 判定樹 1992年由Jacobson提出了Usecase的概念及可視化的表示方法 Usecase圖 并加入由他提出的面向對象的軟件工程 OOSE Usecase的概念受到了IT界的歡迎 被廣泛應用到了面向對象的系統分析中 基于用例的需求方法 已成為面向對象的分析方法的主流 用例模型被推薦為獲取和識別需求的首選工具 基于用例的方法 3 2 2面向對象的分析方法 OOA Usecase圖 采用 基于用例的方法 來識別和獲取需求 是從外部的角度來看系統功能 建立系統的Usecase模型 描述外部執行者 Actor 所理解的系統功能 即待開發系統的功能需求 用例 表示一個子系統 或者系統一個獨立的功能 角色 表示外部的 執行者 ATM機驗證儲戶身份的Usecase圖 創建用例模型的工作包括 定義系統 確定執行者和用例 描述用例 定義用例間的關系 確認模型 3 2 2面向對象的分析方法 OOA 案例3網上拍賣系統隨著Internet技術的發展和互聯網的日益普及 互聯網用戶中約1 4的用戶使用Internet進行互聯網通信或經貿活動 電子商務總額每年可達到6萬億美元 網上拍賣系統就是一個在互聯網上模擬拍賣環境的典型的范例 可實現從展示產品 相互競價到最后產品成交等一系列功能 用戶可以輕松實現在線商品的拍賣和競標 建立系統的USECASE模型 一 競拍平臺1 競拍者資格審查2 競拍規則設定3 競拍過程控制 二 拍賣商品信息發布確定發布的商品信息對商品信息操作 三 拍賣步驟及在線幫助四 網上支付系統五 用戶管理 用戶需求 系統需求 1 執行者 用戶系統是通過網絡提供給商品的銷售者和購買者一個交易平臺 因此所有上網用戶都是本系統的用戶 具體又分為商品購買者和商品銷售者 系統管理員 考慮到一般用戶既可能是商品購買者也可能是商品銷售者 所以將用戶分為 非會員用戶和會員用戶 非會員 未注冊的用戶 只能在網站上瀏覽商品 不能參與競標 也不能提供物品出售 會員 已注冊的用戶 可以直接參與拍賣或競標 系統需求 2 用例 分析系統功能 提供高效的內容豐富的Web拍賣商業服務 展示產品 相互競價 產品成交 實現拍賣商品種類的更新和消息的發布 實現個人物品流通和網上信息發布 留言 初步確定以下功能 1 會員注冊2 會員天地3 商品分類瀏覽4 查找商品5 拍賣商品6 購買商品7 網上支付 系統需求 進一步確定以下功能 1 會員注冊 填寫用戶帳號 用戶名 密碼 Email等 2 會員天地 查看并修改個人信息 交易記錄 收