-軟件需求分析[]PPT課件

1 第3章軟件需求分析 軟件需求需求分析過程傳統(tǒng)方法的分析建模舉例 2 3 1軟件需求 1 需求的概念需求 requirements Jones定義為用戶所需要的軟件必須達(dá)到的目標(biāo)和能力 Lethbridge定義為需求是關(guān)于系統(tǒng)將要完成什么工作的一段描述 他們必須經(jīng)過所有相關(guān)人員的認(rèn)可 其目的是徹底的解決用戶的問題 需求是一段描述 意思是每個(gè)需求是相對短小簡明的一段信息 表現(xiàn)為一個(gè)事實(shí) 它可以是一段話或用各種圖表示 一組需求的集合成為需求文檔 關(guān)于系統(tǒng)將要完成什么工作 需求描述了系統(tǒng)應(yīng)當(dāng)完成的任務(wù) 不描述系統(tǒng)將如何實(shí)現(xiàn) 必須經(jīng)過所有相關(guān)人員的認(rèn)可 意指需求必須經(jīng)過評審 才能成為正式的需求 其目的是徹底的解決用戶的問題 有助于解決用戶的問題 該需求才有存在的價(jià)值 3 2 需求的類型 1 功能性需求 描述系統(tǒng)應(yīng)該做什么 即為用戶和其它系統(tǒng)完成的功能 提供的服務(wù) 2 非功能性需求 必須遵循的標(biāo)準(zhǔn) 外部界面的細(xì)節(jié) 實(shí)現(xiàn)的約束條件 質(zhì)量屬性等等 非功能需求限定了選擇解決問題方案的范圍 如運(yùn)行平臺(tái) 實(shí)現(xiàn)技術(shù) 編程語言和工具等 例 將飛機(jī)訂票系統(tǒng)中的以下方面做如下的劃分 F代表 功能性 NF代表 非功能性 X代表 不應(yīng)當(dāng)是需求 簡要的說明功能性或非功能性需求的種類 對于不應(yīng)當(dāng)是需求的方面 說明其原因 4 如何輸入有關(guān)航班 乘客及訂票信息 F 輸入 什么信息要出現(xiàn)在機(jī)票和報(bào)告中 F 輸出 如何計(jì)算乘機(jī)費(fèi)用 F 計(jì)算 什么信息必須存儲(chǔ)在旅行社和其他人訪問的數(shù)據(jù)庫中 F 數(shù)據(jù)存儲(chǔ) 這個(gè)系統(tǒng)應(yīng)該設(shè)計(jì)成可以處理旅行?？陀?jì)劃 NF 增強(qiáng)的容限 這個(gè)系統(tǒng)在任何時(shí)候都必須是可用的 一周中只允許有2分鐘宕機(jī)時(shí)間 NF 有效性 必須使用排序算法根據(jù)離開時(shí)間對航班排序 X 這是一個(gè)設(shè)計(jì)問題 5 3 需求的描述 1 結(jié)構(gòu)化語言 2 圖形化表示 3 數(shù)學(xué)描述 形式化描述 4 軟件需求文檔 需求規(guī)格化說明 是需求分析階段的產(chǎn)品 是所有其他開發(fā)和管理活動(dòng)的基礎(chǔ) 對系統(tǒng)開發(fā)過程中其他活動(dòng)的影響 項(xiàng)目經(jīng)理根據(jù)它制定或修改開發(fā)計(jì)劃 設(shè)計(jì)人員根據(jù)它進(jìn)行系統(tǒng)設(shè)計(jì) 測試人員根據(jù)它編寫測試計(jì)劃 設(shè)計(jì)測試用例 產(chǎn)品發(fā)布人員根據(jù)它編寫產(chǎn)品介紹和用戶文檔 培訓(xùn)人員根據(jù)它編寫培訓(xùn)教程 6 IEEE標(biāo)準(zhǔn)為需求文檔提出了以下結(jié)構(gòu) 組織機(jī)構(gòu)內(nèi)部可以基于此標(biāo)準(zhǔn)擴(kuò)展 1 引言a 需求文檔的目的b 文檔約定c 預(yù)期的讀者和閱讀建議d 產(chǎn)品范圍e 參考文獻(xiàn) 2 綜合描述a 產(chǎn)品前景b 產(chǎn)品功能與優(yōu)先級c 用戶特征d 運(yùn)行環(huán)境e 設(shè)計(jì)與實(shí)現(xiàn)上的限制f 假設(shè)和依賴性 7 3 需求描述a 功能需求b 數(shù)據(jù)需求 與功能有關(guān)的數(shù)據(jù)定義和數(shù)據(jù)關(guān)系c 性能需求 響應(yīng)時(shí)間 容量要求 用戶數(shù)等d 外部接口 用戶界面 軟硬件接口 通信接口e 設(shè)計(jì)約束 軟件支持環(huán)境 報(bào)表 數(shù)據(jù)命名等f 軟件質(zhì)量屬性 可維護(hù)性 可靠性 可移植性 可用性 安全性等等 g 其他需求這一節(jié)是文檔中最實(shí)質(zhì)性的部分 由于在機(jī)構(gòu)組織的實(shí)踐中存在極大的變數(shù) 對這一節(jié)定義的標(biāo)準(zhǔn)結(jié)構(gòu)可以進(jìn)行增刪 4 附錄 詞匯表 分析模型 待定問題列表 5 索引 8 3 2需求分析過程 需求分析是指開發(fā)人員通過對應(yīng)用問題及其環(huán)境的調(diào)查分析 準(zhǔn)確的理解用戶的需求 將不規(guī)范的需求陳述轉(zhuǎn)化為完整的需求定義 再將需求定義編寫成需求規(guī)格化說明的過程 對于一些新的復(fù)雜的系統(tǒng) 如果沒有專門進(jìn)行可行性研究 需求分析過程前應(yīng)集中回答以下幾個(gè)問題 1 系統(tǒng)是否符合組織機(jī)構(gòu)的總題目標(biāo) 業(yè)務(wù)需求 2 系統(tǒng)是否可能在現(xiàn)在的技術(shù)條件 預(yù)算和時(shí)間限制內(nèi)完成 經(jīng)濟(jì) 技術(shù)上的可行性 3 系統(tǒng)能否與已經(jīng)存在的其他系統(tǒng)集成 當(dāng)收集到信息并評估后 需要對系統(tǒng)是否要開發(fā)給出意見和建議 書寫可行性報(bào)告 該過程可能提出對系統(tǒng)功能范圍的修正 對預(yù)算和時(shí)間安排的調(diào)整意見或者是對系統(tǒng)高層需求的建議 9 1 需求獲取 1 個(gè)別訪談和召集會(huì)議 2 觀察用戶工作流程 3 利用原型 4 使用實(shí)例 用例 用例把系統(tǒng)分成一組邏輯的 互相聯(lián)系很少的部分 每一部分都描述了系統(tǒng)運(yùn)行的某種方式 因此容易理解每個(gè)用例達(dá)到的功能 問題分析 問題描述 原型化 文件管理與確認(rèn) 需求獲取和分析 需求定義和說明 是否已經(jīng)記錄了用戶需要的所有部分 是否使用了正確的技術(shù) 功能是否可行 是否記錄了用戶期望的部分 確定需求的過程 10 例 列出圖書館系統(tǒng)中以下參與者的最小用例集 借閱者 借書員 圖書管理員 會(huì)計(jì)系統(tǒng) 借閱者 按題目查詢書籍 按作者查詢書籍 按主題查詢書籍 預(yù)定已被其他人借出的書籍 查詢借閱者的個(gè)人信息并列出借閱的書籍 11 借書員 所有借閱者的用例 再加上 為借閱者查找某一書籍 登記已歸還的書籍 續(xù)借一本書 登記繳納的罰款 添加新的借閱者 更新借閱者的個(gè)人信息 地址 電話號(hào)碼等 圖書管理員 所有借閱者和借書員的用例 再加上 添加藏書 刪除藏書 改變系統(tǒng)中對已有書籍的記錄信息會(huì)計(jì)系統(tǒng) 獨(dú)立運(yùn)行 獲得借閱者支付的超期罰款 12 3 分析與綜合用文字和圖形描述不同視圖以揭示更深的 易混淆的問題 確保與所有風(fēng)險(xiǎn)承擔(dān)者達(dá)成共識(shí) 1 分析需求的可行性 允許的成本 性能 與其他需求的沖突 外界因素的依賴和技術(shù)障礙等 2 對于漸增式開發(fā)要確定需求的優(yōu)先級別 以便確立產(chǎn)品版本 3 建模 圖形化的表示分析模型可以增強(qiáng)對軟件需求的理解 也為軟件設(shè)計(jì)奠定了基礎(chǔ) 模型包括 13 數(shù)據(jù)流圖 DFD 功能模型 實(shí)體關(guān)系圖 ERD 信息模型 狀態(tài)轉(zhuǎn)換圖 STD 行為模型 類圖 信息模型 順序圖 行為模型 合作圖 行為模型 等等 4 使用原型法 減少項(xiàng)目風(fēng)險(xiǎn) 5 建立數(shù)據(jù)字典 4 編寫需求文檔 14 5 需求驗(yàn)證需求驗(yàn)證的重要性 如果在后續(xù)的開發(fā)或當(dāng)系統(tǒng)投入使用時(shí)才發(fā)現(xiàn)需求文檔中的錯(cuò)誤 就會(huì)導(dǎo)致更大代價(jià)的返工 由需求問題而對系統(tǒng)做變更的成本比修改設(shè)計(jì)或代碼錯(cuò)誤的成本要大的多 假設(shè)需求階段引入1個(gè)錯(cuò)誤的需求 設(shè)計(jì)時(shí)對這個(gè)需求需要5 10條設(shè)計(jì)實(shí)現(xiàn) 1條設(shè)計(jì)需要5 10條程序 1條程序需要3 5種測試組合測試 原始需求 正確的規(guī)格說明錯(cuò)誤的規(guī)格說明 正確的設(shè)計(jì)錯(cuò)誤的設(shè)計(jì)對錯(cuò)誤需求的設(shè)計(jì) 正確的編碼錯(cuò)誤的編碼對錯(cuò)誤設(shè)計(jì)的編碼對錯(cuò)誤需求的編碼 正確功能測試到的錯(cuò)誤沒有測試到的錯(cuò)誤 一個(gè)錯(cuò)誤的需求 糾正成本100元 10糾正成本1000元 10 5 15 對需求文檔需執(zhí)行以下類型的檢查 1 有效性檢查檢查不同用戶使用不同功能的有效性 2 一致性檢查在文檔中 需求不應(yīng)該沖突 3 完備性檢查需求文檔應(yīng)該包括所有用戶想要的功能和約束 4 現(xiàn)實(shí)性檢查檢查保證能利用現(xiàn)有技術(shù)實(shí)現(xiàn)需求 16 驗(yàn)證技術(shù) 1 需求評審 由分析員 設(shè)計(jì)員 測試員 用戶參與的正式或非正式的會(huì)議評審 正式會(huì)議要有嚴(yán)格的評審程序 要有會(huì)議記錄 開發(fā)組根據(jù)缺陷建議修改需求說明并重審 2 利用原型檢驗(yàn)系統(tǒng)是否符合用戶的真正需要 3 對每個(gè)需求編寫概念性的測試用例 4 編寫用戶手冊 用淺顯易懂的語言描述用戶可見的功能 5 自動(dòng)的一致性分析 可用CASE工具檢驗(yàn)需求模型的一致性 17 3 3傳統(tǒng)方法的分析建模 分析建模是使用文本和圖表形式的組合 以相對容易理解和能直接評審正確性 完整性和一致性的方式來描述數(shù)據(jù) 功能和行為的需求 在過去的數(shù)年中 人們提出了許多種分析建模的方法 其中兩種在分析建模領(lǐng)域占有主導(dǎo)地位 第一種是結(jié)構(gòu)化分析 StructuredAnalysis SA 70年代末由DeMarco等人提出 這是傳統(tǒng)的建模方法 另一種方法是面向?qū)ο蟮姆治?將在后面介紹 結(jié)構(gòu)化分析方法不是被所有的使用者一致地使用的單一方法 眾多科學(xué)家對其進(jìn)行了擴(kuò)充 因此它是發(fā)展了超過30年的一個(gè)混合物 18 1 分析模型分析模型必須達(dá)到三個(gè)主要目標(biāo) 1 描述用戶的需要 使用戶和開發(fā)人員更好理解 2 建立創(chuàng)建軟件設(shè)計(jì)的基礎(chǔ) 3 定義在軟件完成后可以被確認(rèn)的一組需求 為了達(dá)到這些目標(biāo) 在結(jié)構(gòu)化分析中導(dǎo)出的分析模型如圖所示 圖3 1分析模型 19 數(shù)據(jù)字典 包含了軟件生產(chǎn)或使用的所有數(shù)據(jù)對象描述的中心存儲(chǔ)庫 實(shí)體 關(guān)系圖 ERD 描述數(shù)據(jù)對象間的關(guān)系 每個(gè)對象的屬性由 數(shù)據(jù)對象描述 來描述 數(shù)據(jù)流圖 DFD 用于兩個(gè)目的 指明數(shù)據(jù)在系統(tǒng)中移動(dòng)時(shí)如何被變換 反映對數(shù)據(jù)流進(jìn)行變換的功能 和子功能 在DFD中出現(xiàn)的每個(gè)功能的描述包含在 加工規(guī)約 中 狀態(tài)轉(zhuǎn)換圖 STD 指明作為外部事件的結(jié)果系統(tǒng)將如何動(dòng)作 有哪些行為 軟件控制方面的附加信息包含在 控制規(guī)約 中 20 2 數(shù)據(jù)建模在數(shù)據(jù)密集型應(yīng)用問題中 對復(fù)雜數(shù)據(jù)或數(shù)據(jù)間復(fù)雜關(guān)系的分析和建模是需求分析的重要任務(wù)之一 有助于數(shù)據(jù)庫的設(shè)計(jì) 數(shù)據(jù)建模回答與任何數(shù)據(jù)處理應(yīng)用相關(guān)的一組特定問題 系統(tǒng)處理哪些主要的數(shù)據(jù)對象 或?qū)嶓w 每個(gè)數(shù)據(jù)對象的組成如何 哪些屬性描述了這些對象 每個(gè)對象與其他對象有哪些關(guān)系 這些對象當(dāng)前位于何處 對象和變換它們的處理之間有哪些關(guān)系 21 分析人員經(jīng)常使用實(shí)體 聯(lián)系 EntityRelationship ER 圖來描述數(shù)據(jù)對象及相互之間的關(guān)系 ER模型包含了3種相互關(guān)聯(lián)的信息 數(shù)據(jù)對象 數(shù)據(jù)對象的屬性 數(shù)據(jù)對象相互連接的關(guān)系 1 1 1 N M N 下圖是一個(gè)教學(xué)管理的ER圖 22 教師 學(xué)生 課程 教 學(xué) M N M N 教師號(hào) 姓名 性別 職稱 系別 學(xué)號(hào) 姓名 性別 系別 班級 時(shí)間 成績 課程號(hào) 課名 學(xué)時(shí) 學(xué)分 其中 表示實(shí)體 表示屬性 表示聯(lián)系 為了降低圖的復(fù)雜性 有時(shí)屬性不畫在ER圖中 單獨(dú)造表 23 3 功能建模 1 數(shù)據(jù)流圖 DataFlowDiagram DFD DFD用來描述數(shù)據(jù)在處理序列中的流動(dòng) 由箭頭給出流動(dòng)的數(shù)據(jù) 泡泡表示對數(shù)據(jù)的變換 加工或處理 兩條平行橫線表示數(shù)據(jù)存儲(chǔ) 數(shù)據(jù)庫 矩形表示外部實(shí)體 數(shù)據(jù)源或數(shù)據(jù)池 圖3 2描述了一個(gè)反映 看病 功能的DFD DFD可以自頂向下 逐層分解 第0層DFD將整個(gè)系統(tǒng)表示為一個(gè)具有輸入和輸出數(shù)據(jù)的泡泡 反映了系統(tǒng)的語境 以下各層分別是上一層泡泡的分解 分解到可理解為止 表示在第1層的每個(gè)加工是表示在語境模型中的整個(gè)系統(tǒng)的子功能 見圖3 3 24 圖3 2 看病 的數(shù)據(jù)流圖 25 圖3 3數(shù)據(jù)流圖的分解 26 分解時(shí)注意保持每次精化的輸入輸出數(shù)據(jù)流一致 稱為分層數(shù)據(jù)流圖的平衡 圖形并不能充分反映軟件的需求 需要用數(shù)據(jù)字典和 加工規(guī)約 對分析模型進(jìn)行補(bǔ)充 數(shù)據(jù)字典對DFD中的元素進(jìn)行嚴(yán)格的定義與解釋 加工規(guī)約說明DFD中的 泡泡 隱含的處理細(xì)節(jié)并指出加工的約束與限制 DFD符號(hào)簡單 適用于數(shù)據(jù)處理系統(tǒng)的分析建模 關(guān)注的重點(diǎn)是數(shù)據(jù)流而不是控制流 不易于實(shí)時(shí)系統(tǒng)的分析 27 2 IDEF0圖美國國防部使用的圖形化建模技術(shù) 一個(gè)基本活動(dòng)圖如圖3 4所示 每個(gè)活動(dòng)包括4類要素 輸入 控制 機(jī)制和輸出 控制是限制所描述活動(dòng)的類型或活動(dòng)所受約束 機(jī)制是活圖3 4一個(gè)基本的IDEF0圖 A 0圖 動(dòng)的外部支持 如工具 技術(shù) 數(shù)據(jù)庫等 該圖如同DFD一樣 通過逐層分解展示系統(tǒng)的功能與子功能 每一層分解的活動(dòng)為3 6個(gè) 圖3 5為第1層的IDEF0圖 28 圖3 5 看病 的IDEF0圖 A0圖 29 4 行為建模SA的擴(kuò)展版本才使用STD進(jìn)行行為建模 STD通過描述狀態(tài)以及導(dǎo)致系統(tǒng)改變狀態(tài)的事件來表示系統(tǒng)的行為 STD一般用圓角矩形 以下例圖中用矩形 表示狀態(tài) 每個(gè)狀態(tài)代表系統(tǒng)的一種行為模式 狀態(tài)之間用箭頭連接 表示當(dāng)發(fā)生某個(gè)事件或滿足某條件時(shí) 激發(fā)某個(gè)動(dòng)作 引起對象或系統(tǒng)狀態(tài)間的轉(zhuǎn)移 圖3 6和圖3 7分別是復(fù)印機(jī)軟件的DFD和STD 行為模型有助于理解系統(tǒng)的預(yù)期行為 便于檢驗(yàn) 需求規(guī)格說明 是否包含了與狀態(tài)變化相關(guān)的功能需求 有利于對實(shí)時(shí)系統(tǒng)進(jìn)行分析 30 圖3 6復(fù)印機(jī)軟件的DFD 31 圖3 7復(fù)印機(jī)軟件的STD 32 5 數(shù)據(jù)字典 DataDictionary DD DD是對所有與系統(tǒng)相關(guān)的數(shù)據(jù)元素的一個(gè)有組織的列表和精確的 嚴(yán)格的定義 使得用戶和開發(fā)人員對于這些數(shù)據(jù)元素有共同的理解 它可以管理各種模型中的各種信息 盡管各工具中字典的形式各不相同 但都包含以下信息 名稱 別名 何處使用 如何使用 內(nèi)容描述 描述符號(hào)記號(hào)意義例1 西安交大電話號(hào)碼 由 構(gòu)成 82668 82669 82660 后綴號(hào)碼 和例2 學(xué)生名表 1 姓名 成績 30 或1 n1 n次重復(fù) 補(bǔ)充信息 可選數(shù)據(jù)類型 限制 約束等 33 5 加工規(guī)約和控制規(guī)約說明基本加工的處理邏輯以及一些附加信息 描述工具 結(jié)構(gòu)化語言 半形式化語言 表格 如判定表 加工激活表 下圖是某大學(xué) 錄取新生 滿足一組條件規(guī)則的判定表 規(guī)則1規(guī)則2規(guī)則3規(guī)則4規(guī)則5標(biāo)準(zhǔn)考試得分高TFFFF平時(shí)成績好 TFFF參加課外活動(dòng) TFF好的推薦材料 TF發(fā)送拒絕信 發(fā)送錄取通知 34 條件和動(dòng)作 或結(jié)果 列在表格的左邊 每列代表一組條件下系統(tǒng)要做的動(dòng)作 或取得的結(jié)果 也說明了當(dāng)系統(tǒng)處于列中所描述的狀態(tài)時(shí) 將要遵守的規(guī)則 T 表示本行的條件為 真 F 為 假 為 無所謂 表示在本列組合條件下采取的動(dòng)作 判定表用于反映系統(tǒng)在多個(gè)條件組合下 將要采取的行動(dòng) 如果有n個(gè)條件 就有2n個(gè)可能的條件組合 這樣表的結(jié)構(gòu)就會(huì)很大 注意規(guī)則3 4和5 是重復(fù)的 可以取消4和5 去掉表中冗余的規(guī)則 以減少表的規(guī)模并更容易理解 通過制作 分析判定表 可進(jìn)一步檢查需求說明的完整性 一致性 35 3 4例1 機(jī)票預(yù)訂系統(tǒng) 其功能為 旅行社把預(yù)訂機(jī)票的旅客信息 姓名 性別 身份證號(hào)碼 旅行時(shí)間 目的地等 輸入系統(tǒng) 系統(tǒng)為旅客安排航班 打印出取票通知單 旅客在飛機(jī)起飛的前一天憑取票通知單交款取票 系統(tǒng)檢驗(yàn)無誤 輸出機(jī)票給旅客 建立該系統(tǒng)DFD 機(jī)票預(yù)訂系統(tǒng) 旅行社 旅客 訂票單 取票單 取票單 機(jī)票 機(jī)票預(yù)訂系統(tǒng)頂層圖 36 預(yù)訂機(jī)票1 旅客取票2 訂票單 取票單 取票單 機(jī)票 機(jī)票文件 機(jī)票預(yù)訂系統(tǒng)0層圖 檢驗(yàn)有效性1 1 查詢航班1 2 登記機(jī)票1 3 打印取票單1 4 機(jī)票文件 航班目錄 訂票單 有效 有航班 已登記 取票單 預(yù)訂機(jī)票 子圖 1層圖 圖1 37 圖2 這樣逐步求精分解下去 直到每個(gè)加工相對簡單 整個(gè)圖的功能可理解為止 查詢機(jī)票文件檢驗(yàn)取票單2 1 記帳2 2 修改機(jī)票文件并打印機(jī)票2 3 機(jī)票文件 賬目文件 取票單 有效取票單 已交款 機(jī)票 旅客取票 子圖 1層圖 38 例2 家庭安全系統(tǒng) SafeHome 是一個(gè)基于微處理器的系統(tǒng) 能識(shí)別異常事件并采取相應(yīng)防護(hù)措施 異常事件包括 非法侵入 火災(zāi)等 一旦異常事件被傳感器識(shí)別出來 系統(tǒng)自動(dòng)啟動(dòng)電話向監(jiān)控中心報(bào)警 具體功能為 1 在安裝時(shí)允許用戶進(jìn)行系統(tǒng)配置 配置的信息有 每一個(gè)傳感器的類型和編號(hào) 報(bào)警電話號(hào)碼 啟動(dòng)和關(guān)閉系統(tǒng)的密碼 警報(bào)延遲和電話