L-第三章 需求分析.ppt

軟件工程 03章需求分析 2 引言1用戶描述的可能不是他想要的 對用戶的描述每個人有不同的理解 3 引言2 開發(fā)人員和用戶之間的鴻溝 從前有一家汽車廠 想為年輕人設計一款新車型 企劃及設計部討論了許久始終找不到感覺 于是對25 35歲的年輕人進行問券調查 大伙辛苦了三個月 完成了一萬份的調查記錄 市場部門摘要了調查內容反映給設計部門 重點 省油 外型酷 顏色鮮艷 馬力足等 設計部門有了靈感開始設計 半年過去了 設計部門很得意的把雛型車展示給大伙看 這個時候 CEO 市場部 企劃部 都傻眼了 CEO開口說 為什么這車沒有 輪子 設計部回答 市場部給的調查報告里 沒說要有輪子市場部回說 問卷調查中 顧客沒有提到要有輪子企劃部生氣的說 你們都是白癡啊 汽車要有輪子是基本常識 你們都不知道嗎 就這樣現場吵翻天了 注 原文地址 4 引言3 做需求要很細 很專業(yè) 很有經驗 男孩反問 是無聲槍么 不是 槍聲有多大 80 100分貝 那就是說會震的耳朵疼 是 您確定那只鳥真的被打死啦 確定 鳥里有沒有聾子 沒有 沒有關在籠子里的 沒有 旁邊樹上還有其他鳥 沒有 有殘疾或餓的飛不動的鳥 沒有 算不算懷孕肚子里的小鳥 都是公的 打鳥的人眼里有沒有花 沒有 有沒有傻的不怕死的 都怕死 會不會一槍打死兩只以上 不會 所有的鳥都可以自由活動么 完全可以 它們受到驚嚇時不會互相撞上 不會 學生滿懷信心的回答 打死的鳥要是掛在樹上沒掉下來 那么就剩一只 如果掉下來 就一只不剩 某日老師在課堂上想考考學生們的智商 就問一個男孩 樹上有十只鳥 開槍打死一只 還剩幾只 5 結論 需求具有主觀性 二義性 多變性 模糊性 需求分析要求很專業(yè) 很仔細 很有經驗 需求分析是確定系統(tǒng)應具備的功能 是其他所有工作的基礎 因此非常重要 需求導致整個項目失敗占的比例非常大 6 第三章軟件需求分析 需求分析的任務與用戶溝通獲取需求的方法分析建模與規(guī)格說明實體一聯(lián)系圖數據規(guī)范化狀態(tài)轉換圖其他圖形工具驗證軟件需求小結習題 7 教學要求 教學目的 了解需求分析的任務和步驟 評審標準和過程 掌握基本技術 理解需求規(guī)格說明書的作用與組成 教學重點 基本技術 需求規(guī)格說明書的作用與組成 教學難點 基本技術 8 需求分折簡介 軟件需求指用戶對所開發(fā)的軟件在功能 性能 環(huán)境 可靠性等各方面的要求 需求分析主要回答待開發(fā)的系統(tǒng)必須 做什么 并用 需求規(guī)格說明書 的形式準確 詳細 規(guī)范地表達出來 9 注意 需求分析階段 系統(tǒng)分析員的主要關注點是 做什么 what 不是 怎樣做 how 需求分析階段 系統(tǒng)分析員應該給出軟件求規(guī)格書 10 3 1需求分析的任務 四項主要任務 1 確定對系統(tǒng)的綜合要求2 分析系統(tǒng)的數據要求3 導出系統(tǒng)的邏輯模型4 修正系統(tǒng)開發(fā)計劃 11 提問并思考 如果你是一個用戶 你會對將要開發(fā)的軟件有哪些要求 12 3 1 1確定對系統(tǒng)的綜合要求 功能需求 指定系統(tǒng)必須提供的服務 性能需求 指定系統(tǒng)必須滿足的定時約束或容量約束等 可靠性和可用性需求 應定量指定 出錯處理需求 指環(huán)境錯誤 非系統(tǒng)本身的錯誤 接口需求 常見的接口需求 用戶接口需求 硬件接口需求 軟件接口需求 通信接口需求 13 約束 常見的約束 精度 工具和語言約束 設計約束 應該使用的標準 應該使用的硬件平臺 逆向需求 指定系統(tǒng)不應該做什么 將來可能提出的要求 14 3 1 2分析系統(tǒng)的數據要求 提問并思考 如果你是設計者 除了上述需求以外 你覺得還需要得到哪些要求 答 軟件系統(tǒng)本質上是信息處理系統(tǒng) 要考慮數據和數據處理的問題 15 對系統(tǒng)數據的分析 建立數據 3 4節(jié) 描繪數據結構 3 7節(jié) 規(guī)范化 3 5節(jié) 16 3 1 3導出系統(tǒng)的邏輯模型 用數據流圖 實體一聯(lián)系圖 狀態(tài)轉換圖 數據字典和主要的處理算法描述這個邏輯模型 3 1 4修正系統(tǒng)開發(fā)計劃根據在分析過程中獲得的對系統(tǒng)的更深入更具體的了解 可以比較準確地估計系統(tǒng)的成本和進度 修正以前制定的開發(fā)計劃 17 圖 軟件需求分析的通信途徑 分析小組成員主要包括領域專家 系統(tǒng)分析員 客戶訪談問題分析與確認 18 與用戶溝通的方法 1 訪談2 面向數據流自頂向下求精3 簡易的應用規(guī)格說明技術4 快速建立軟件原型 19 3 2 1訪談 分正式和非正式訪談 可采用調查表形式可使用情景分析技術 20 例 某出版社系統(tǒng)調查表 21 3 2面向數據流自頂向下求精 結構化分析方法的實質 進一步細化可行性研究階段獲得到高層數據流圖 包括建立 詳細的數據流圖 描繪數據在軟件系統(tǒng)內從輸入移動到輸出的過程中所經受到變換 數據字典 定義數據流圖中包含的元素 實體關系 ER 圖 從用戶角度描述數據 IPO圖 描述數據流圖中處理框的功能和算法 22 面向數據流自頂向下求精過程 23 3 2 3簡易的應用規(guī)格說明技術 一種面向團隊的需求收集法 提倡用戶與開發(fā)者密切合作 共同標識問題 提出解決方案要素 商討不同方案并指定基本需求 24 3 2 4快速建立軟件原型 快速原形就是快速建立起來的旨在演示目標系統(tǒng)主要功能的可運行的程序 要點 實現用戶看得見的功能 省略目標系統(tǒng) 隱含 功能 25 3 2 4快速建立軟件原型 建立和修改原型的方法和工具 1 第四代技術 包括眾多數據庫查詢和報表語言 程序和應用系統(tǒng)生成器以及其他非常高級的非過程語言 能快速生成可執(zhí)行的代碼 2 可重用的軟件構件 使用一組已有的軟件構件 也稱為組件 來裝配 而不是從頭構造 原型 3 形式化規(guī)格說明和原型環(huán)境 在交互式環(huán)境下 用自動工具把基于形式語言的規(guī)格說明翻譯成可執(zhí)行的程序代碼 26 3 3分析建模與規(guī)格說明 3 3 1分析建模什么是模型 為了理解事物而對事物做出的一種抽象 是對事物的一種無歧義的書面描述 模型通常由一組圖形符號和組織這些符號的規(guī)則組成 27 模型的作用 在建模過程中了解系統(tǒng) 通過抽象降低復雜性 有助于回憶所有的細節(jié) 有助于開發(fā)小組間的交流 有助于與用戶的交流 為系統(tǒng)的維護提供文檔 28 例 結構化分析方法建立的需求模型 結構化分析 StructuredAnalysis SA 是面向數據流進行分析的方法 主要建立以下幾種模型 實體關系圖 Entity RelationshipDiagram E R圖 來創(chuàng)建數據模型 描述系統(tǒng)中所有重要的數據對象 數據流圖 DataFlowDiagram DFD 用來創(chuàng)建功能模型 描述了信息流和數據轉換 狀態(tài)轉換圖 State TransitionDiagram STD 用來創(chuàng)建行為模型 描述系統(tǒng)狀態(tài)如何響應外部事件 而進行轉換 29 例 面向對象分祈方法 OOA 所建立的摸型 對象模型 Objectmodel 定義實體 描述系統(tǒng)的靜態(tài)結構 定義 對誰做 動態(tài)模型 Dynamicmodel 描述對象之間的交互過程 規(guī)定 何時做 功能模型 Functionalmodel 描述內部數據的處理 指明系統(tǒng)應 做什么 30 軟件需求規(guī)格說明 軟件需求規(guī)格說明書 是需求分析階段最主要的文檔 對目標進行完善和補充 并寫出完整的需求說明 為消除自然語言中可能存在的不一致 歧義 含糊 不完整及抽象層次混亂等問題 有主張用形式化方法描述用戶對軟件系統(tǒng)的需求 例 GB8567 88計算機軟件產品開發(fā)文件編制指南 31 結構化分析方法 StructuredAnalysis SA 面向數據流進行需求分析的方法適合于數據處理類型軟件的需求分析 32 結構化分折模型的組成結構 33 3 4實體一聯(lián)系圖 實體一聯(lián)系圖 E一R圖 描繪系統(tǒng)的數據關系 分析實體一聯(lián)系有助于對業(yè)務或系統(tǒng)數據組成的理解和交互 ER圖中包含了實體 數據對象 關系和屬性三種基本成分一 基本概念 1 實體 客觀世界中存在的 可區(qū)分的事物 屬性 實體或數據對象所具有的性質 34 數據對象 實體 對軟件必須理解的復合信息的表示 所謂復合信息是指具有一系列不同性質或屬性的事物 因此僅有單個值的事物 例如姓名 不是數據對象 數據對象可能是 一個外部實體 例如生產或消費信息的任何事物 一個事物 例如一份報告 一次行為 例如一個電話呼叫 一個事件 例如一次警報 一個角色 例如教師 一個組織 例如學校教務處 一個地點 例如圖書館 一個結構 例如一個目錄 35 一 基本概念 2 聯(lián)系 客觀事物之間的聯(lián)系 聯(lián)系分為三種 一對一 1 1 班級和班長一對多聯(lián)系 1 N 班級和學生 系與教師 學生與宿舍多對多聯(lián)系 M N 課程與學生 教師和課程 學生和學會二 E一R圖的結構三種基本元素 36 例 教學E R圖 37 例 倉庫 職工 零件和供應商的ER圖 38 三 如何建立實體一聯(lián)系圖 1 在需求收集的過程中 列出應用軟件或業(yè)務過程涉及到的所有 事物 將其演化成數據對象 2 一次考慮一個對象 定義這個對象和其他對象之間是否存在連接 3 如果存在連接 應創(chuàng)建一個或多個關系 4 對每一個關系 確定其關聯(lián)類型 5 重復步驟 2 到步驟 4 直到定義了所有關系 6 定義每個實體的屬性 7 形式化并復審實體關系圖 8 重復步驟 1 到 7 直到數據建模完成 39 2 4數據流圖 DFD DataFlowDiagram 描述數據處理過程的工具 通過圖形的方法 從數據傳遞和數據處理的角度 刻畫數據流從輸入到輸出的移動變換過程 數據流三個重要屬性 數據流名字 數據組成 流向 40 2 4 1符號 1 說明 用圖形符號以黑盒子形式描繪組成系統(tǒng)的每個部件 程序 文檔 數據庫 人工過程等 表達數據在系統(tǒng)各部件之間流動的情況 41 符號 2 42 例1 描述銀行取款過程的數據流圖 43 應該注意的幾個問題 適當地命名 詳見教材p45 數據存儲 代表數據靜止狀態(tài) 數據流 代表數據的運動狀態(tài) 注意數據流與控制流的區(qū)別 通常數據流圖中忽略出錯處理 打開或關閉文件之類的事務處理 若數據的源點和終點相同 則應該有兩個箭頭和這個數據源 終 點相連 或重復畫一個源 終 點 44 數據流圖的層次結構 對于大型系統(tǒng) 往往采用自頂向下逐層分解的方法 用分層數據流圖表示所有數據流和加工 對任何一個數據流圖來說 它的上層圖為父圖 在它的下一層的圖為子圖 45 分層數據流圖 46 說明 在多層數據流圖中 頂層流圖僅包含一個數據處理 它代表被開發(fā)系統(tǒng) 它的輸入流是該系統(tǒng)的輸入數據 輸出流是系統(tǒng)所輸出數據底層流圖是指其數據處理不需再做分解的數據流圖 它處在最底層中間層流圖則表示對其上層父圖的細化 它的每一數據處理可能繼續(xù)細化 形成子圖 47 注意的原則 1 數據流圖上所有圖形符號只限于前述四種基本圖形元素 數據流圖的主圖必須包括前述四種基本元素 缺一不可 數據流圖的主圖上的數據流必須封閉在外部實體之間 每個數據處理至少有一個輸入數據流和一個輸出數據流 在數據流圖中 需按層給數據處理框編號 編號表明該處理所處層次及上下層的親子關系 48 注意的原則 2 規(guī)定任何一個數據流子圖必須與它上一層的一個數據加工對應 兩者的輸入數據流和輸出數據流必須一致 此即父圖與子圖的平衡 可以在數據流圖中加入物質流 幫助用戶理解數據流圖 圖上每個元素都必須有名字 數據流圖中不可夾帶控制流 初畫時可以忽略瑣碎的細節(jié) 以集中精力于主要數據流 49 例2 結構化分析方法步驟示例 商場業(yè)務處理系統(tǒng)假設某商場的經營業(yè)務 商場進貨時 先發(fā)訂貨單給供應商 供應商收到訂貨單 將商品發(fā)給商場 商場貨到付款 供應商收款后 將收據發(fā)給商場 當顧客到商場采購商品時 先下購物訂單 商場查詢庫存中是否有此種商品 若有則發(fā)貨給顧客 若沒有 則向供應商訂貨 貨到之后再銷售給顧客 顧客收到貨物之后付款 商場開收據給顧客 商場對貨物的管理方面要求知道每種貨物詳細的銷售情況 50 分析業(yè)務流程 訂貨過程 51 分析業(yè)務流程 采購過程 52 第一步 繪制頂層數據流圖 1 基本思想 任何計算機系統(tǒng)都是有若干個數據源 終 點加上一個事務處理組成 首先從問題的描述中提取數據流圖中的源 終 點 數據處理 數據流和數據存儲四種成份 分析源 終 點 分析數據處理 分析數據流和數據存儲 53 分析數據源點和終點 如果將商場的購 銷業(yè)務系統(tǒng)看成一個整體 則外部的與這個系統(tǒng)有交往的對象 機構 人員 或外部系統(tǒng) 是 供應商 和 顧客 二者是商場購銷系統(tǒng)源點和終點 54 分析源點 終點與商場之間的數據流 數據流方向分別是 供應商方給商場 發(fā)貨單 貨款收據顧客給商場 訂單 貨款商場給供貨商 訂貨單 貨款商場給顧客 貨物 收據 55 分析數據存儲 需要存儲的數據分別是庫存信息暫存訂單 缺貨訂單 采購訂單商品銷售歷史資金帳目 56 第一步 繪制頂層數據流圖 2 57 第一步 繪制頂層數據流圖 3 第一步 繪制頂層數據流圖 3 58 第二步 將頂層數據流圖細化 經過分析 商店業(yè)務處理的主要數據處理是銷售 采購 會計三大數據處理 三者之間的數據流 59 需要存儲的數據有 60 61 DFD L2 2 采購細化 62 DFD L2 1 銷售細化 63 數據詞典 DD datadictionary DD是對數據流圖中包含的所有元素的定義的集合 使得每個圖形元素的名字都有一個精確的 嚴格的定義 數據流圖和詞典結合在一起 能清楚地表達數據處理的要求 構成了 需求說明書 64 1數據字典的內容 主要描述數據流數據元素數據存儲數據處理 65 2定義數據的方法 66 1 定義數據流 數據流名 說明 簡要介紹作用即它產生的原因和結果 數據流來源 來自何方 數據流去向 去向何處 數據流組成 數據結構 數據量流通量 數據量 流通量 67 舉例 68 數據流定義 69 2 定義數據元素 數據元素 數據項 指數據處理中最小的 不可再分的單位 描述包括 數據元素名 類型 數字 離散值 連續(xù)值 文字 編碼類型 長度 取值范圍 相關的數據元素及數據結構 70 數據元素定義舉例 1 71 數據元素定義舉例 2 72 數據元素定義舉例 3 73 數據元素定義舉例 4 74 3 定義數據存儲 數據文件名 簡述 存放的是什么數據輸入數據 輸出數據 數據文件組成 數據結構存儲方式 順序 直接 關鍵碼存取頻率 75 數據存儲定義舉例 1 76 77 78 4 定義數據處理 數據處理定義舉例 1 79 數據處理定義舉例 2 80 加工邏輯詞條說明舉例 3 81 源點及匯 終 點詞條描述 名稱 外部實體名簡要描述 什么外部實體有關數據流 數目 82 數據規(guī)范化 1 第一范式每個屬性值都必須是原子值 2 第二范式滿足第一范式條件 而且每個非關鍵字屬性都由整個關鍵字決定 3 第三范式符合第二范式的條件 每個非關鍵字屬性都僅由關鍵字決定 而且一個非關鍵字屬性不能僅僅是對另一個非關鍵字屬性的進一步描述 范式低 冗余大 范式高 分解得細 冗余小 但處理過程復雜 83 狀態(tài)轉換圖 STD 為了直觀地分析系統(tǒng)的動作 從特定的視點出發(fā)描述系統(tǒng)的行為 需要采用動態(tài)分析的方法 狀態(tài)轉換圖是一種常用的動態(tài)分析方法 是描述系統(tǒng)的狀態(tài)如何響應外部信號 而進行轉換的一種圖形表示 84 1 狀態(tài) 指任何可以被觀察到的系統(tǒng)行為模式 一個狀態(tài)代表系統(tǒng)的一種行為模式 主要有 初態(tài) 終態(tài)和中間狀態(tài) 一個狀態(tài)圖中 只能有一個初態(tài) 但可以有0 多個終態(tài) 85 2 事件 某個特定時刻發(fā)生的事情 它是對引起系統(tǒng)做動作或 和 從一個狀態(tài)轉換到另一個狀態(tài)的外界事情的抽象 86 狀態(tài)轉換圖符號 活動表語法 事件名 參數表 動作表達式常用事件名 Entry Exit Do動作表達式 應做的具體動作事件表達式 觸發(fā)狀態(tài)轉換的事件 語法 事件說明 守衛(wèi)條件 動作表達式 其中 事件說明的語法 事件名 參數表 87 電話系統(tǒng)的狀態(tài)圖 電話系統(tǒng)的狀態(tài)圖 電話系統(tǒng)的狀態(tài)圖 88 其他圖形工具 層次方框圖 89 IPO圖 90 驗證軟件需求 問 從哪些方面驗證軟件需求的正確性 如何驗證 1 一致性自然語言書寫的需求說明 只能用人工方法驗證 形式化方法定義的可以借助驗證工具2 完整性需要用戶參與 合作 建立快速原型 3 現實性參照以往類似系統(tǒng) 進行真或性能模擬4 有效性 91 比較完整的數據流圖例子 例 教務管理系統(tǒng)某校準備開發(fā)一個學生成績管理系統(tǒng) 在該系統(tǒng)中 教務人員錄入學生信息 課程信息和成績信息 學生可以隨時查詢自己所選課程的成績 由于學生成績屬于敏感信息 系統(tǒng)必須提供必要的安全措施以防非法存取 92 0層DFD分析 源點終點 教務人員 源點 學生 終點 數據處理 將系統(tǒng)當成一個整體 學生成績管理 數據流 學生信息 課程信息和成績 教務人員錄入時 查詢請求 查詢結果 學生查詢時 數據文件 成績文件 學生文件 課程文件 93 第0層DFD圖 教務人員維護學生信息和課程信息 并登錄學生的選課成績 學生查詢自己的成績單 94 第1層DFD說明 學生信息 是教務人員需要錄入的一個信息 因此加入一個加入 錄入學生信息 同樣得到 錄入課程信息 登記成績 兩個數據處理 另外 數據流 查詢請求 和 查詢結果 應該由數據處理 查詢成績 來完成 95 第1層DFD說明 對第0層DFD的加工 學生成績管理 進行展開 數據處理 錄入學生信息錄入課程信息登記學生成績查詢學生成績數據存儲 增加這些數據流對應的數據存儲 即 學生 課程 和 成績 最后得到如圖所示的第1層DFD 96 第1層DFD圖 對第0層DFD的一個 學生成績管理 進行展開 97 第2層DFD說明 繼續(xù)分解第1層DFD中的加工 查詢學生成績 數據處理 分解為 合法性檢查 和 查詢成績 數據文件 合法的查詢條件 98 第2層DFD圖對第1層DFD圖中的一個加工 查詢學生成績 進行展開 99 部分數據字典 100 101 實例 圖書館圖書信息管理系統(tǒng) 102 需求 讀者來圖書館借書 可能先查詢館中的圖書信息 查詢可以按書名 作者 圖書編號 關鍵字查詢 如果查到則記下書號 交給流通組工作人員 等候辦理借書手續(xù) 如果該書已經被全部借出 可做預訂登記 等待有書時被通知 如果圖書館沒有該書的記錄 可進行缺書登記 辦理借書手續(xù)時先要出示圖書證 沒有圖書證則去圖書館辦公室申辦圖書證 如果借書數量超出規(guī)定 則不能繼續(xù)借閱 借書時流通組工作人員登記圖書證編號 圖書編號 借出時間和應還書時間 103 當讀者還書時 流通組工作人員根據圖書證編號 找到讀者的借書信息 查看是否超期 如果已經超期 則處罰 如果圖書有破損 丟失 則進行破損處罰 登記還書信息 做還書處理 同時查看是否有預訂登記 如果有則發(fā)出到書通知 圖書采購人員進行圖書采購時 要注意合理采購 如果有缺書登記則隨時進行采購 采購到貨后 編目人員進行驗收 編目 上架 錄入圖書信息 發(fā)到書通知 如果圖書丟失或舊書淘汰 則將該書從書庫中清除 即圖書注銷 需求 續(xù) 104 以上是圖書管理系統(tǒng)的基本需求 經過與圖書館工作人員反復交流 他們提出了下列建議 建議1 當讀者借閱的圖書到期時 希望能夠提前以一個短信息或電子郵件方式提示讀者 建議2 讀者希望能夠實現網上查詢和預訂圖書 建議3 應用系統(tǒng)的各種參數設置最好是靈活的 由系統(tǒng)管理人員根據需要設定 例如 借閱量的上限 還書提示的時間 預訂圖書的保持時間等參數 需求 續(xù) 105 用戶給出的上述需求式一個比較簡單的需求 沒有向我們前面介紹的那樣給出業(yè)務需求 用戶需求 遇到這種情況我們要進一步與用戶溝通 了解系統(tǒng)的目標 規(guī)模 范圍 不能自己想當然確定 本例中用戶給出的系統(tǒng)目標是實現讀者借還書的信息化 并且利用Internet網絡實現讀者與圖書館之間的互動和圖書館的人性化管理 提高圖書的利用率 系統(tǒng)的規(guī)模較小 只涉及圖書 讀者 借還書的管理 相關的部門有采編部 流通部 辦公室 需求 續(xù) 106 描繪系統(tǒng)流程圖 107 系統(tǒng)0層數據流程圖 108 描述 本例中的數據源 終點有讀者 采編部 辦公室 流通部 讀者提供的主要信息是讀者號 書號 辦公室是為讀者分配讀者號 定義處罰規(guī)則 借還書規(guī)則 采編部提供新書信息 流通部實現借還書操作 產生借還書信息 109 讀者使用該系統(tǒng)進行圖書信息查詢 讀者信息查詢 網上預訂圖書 所以應該增加查詢功能和預訂圖書功能 采購部的人員使用本系統(tǒng)完成圖書編目 新書信息發(fā)布功能 為此增加圖書編目和新書發(fā)布處理 流通部的工作人員使用本系統(tǒng)完成讀者借還書的事務 應該為他們設置借書 還書處理 辦公室的人員負責讀者信息管理 罰款信息管理和系統(tǒng)的參數制定 為他們添加讀者信息管理 處罰信息管理 系統(tǒng)參數維護三個處理 下面應該對圖書館信息管理系統(tǒng)這個 黑盒子 進行逐步分解 細化數據流程圖 110 系統(tǒng)1層數據流程圖 111 三個問題 一個是圖形元素的編號問題 為了在進行細化的過程中圖型元素保持原有的編號 我們在對圖形元素編號時應該有規(guī)劃 以保證在的細化過程中便于插入新的圖型元素 另一個問題是對于一個較大型的應用系統(tǒng) 數據流程圖往往會很復雜 因此可以將一個數據流