《軟件需求分析》PPT課件

《《軟件需求分析》PPT課件》由會員分享，可在線閱讀，更多相關(guān)《《軟件需求分析》PPT課件（27頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、 2008 BUPT TSEG 軟件工程模型與方法 Models & Methods of SE第四章 軟件需求分析肖 丁 2 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 引言u為何要進行軟件的需求分析？u軟件的需求分析處于軟件生命周期的那個階段？起到什么作用？u怎樣才能做好軟件需求分析？u軟件需求分析的過程和步驟是什么？u軟件需求分析的最終結(jié)果是什么？ 3 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.1 需求的定義u需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產(chǎn)品“必須或應(yīng)當”做什么 。u Boehm 給

2、出軟件需求的定義：研究一種無二義性的表達工具，它能為用戶和軟件人員雙方都接受，并能夠把“需求”嚴格地、形式地表達出來。 u“需求、設(shè)計、編程、測試四者究竟哪個環(huán)節(jié)最重要？” 首先，每個環(huán)節(jié)都是很重要，任何一個環(huán)節(jié)出現(xiàn)問題，都會導(dǎo)致軟件的質(zhì)量問題。但是，從管理的角度來看，需求是軟件產(chǎn)品的起源，因而是最重要的一個環(huán)節(jié) 4 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.2 一個需求分析的案例u某大型的電信設(shè)備供應(yīng)商，案例中涉及6個部門A,B,C,D,E和F，它們之間的關(guān)系如下圖所示： F客戶E：網(wǎng)管軟件承包商D銷售機構(gòu)A：增值業(yè)務(wù)研發(fā)機構(gòu)C：項目管理機構(gòu)B：核心平臺研發(fā)機構(gòu)一 年

3、 前 ， B研 制 了 一 種 數(shù) 據(jù) 接 入 服 務(wù) 器 的 原 型 。 B對 A講 ： “ 我們 的 接 入 服 務(wù) 器 前 途 很 好 ， 請 你 們 幫 助 開 發(fā) 網(wǎng) 管 軟 件 （ 屬 于 增值 業(yè) 務(wù) 范 疇 ） ， 大 家 合 作 把 產(chǎn) 品 做 好 ， 一 起 發(fā) 財 。 ”D對 B和 A講 ： “ 你 們 把 接 入 服 務(wù) 器 和 網(wǎng) 管 軟 件 做 好 ， 我 們 負 責(zé)賣 ， 掙 了 錢 大 家 一 起 分 。 ” 5 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.2 一個需求分析的案例u A覺 得 機 會 難 得 ， 于 是 向 C申 請 立 項

4、 。u 立 項 后 ， A把 項 目 外 包 給 專 業(yè) 做 網(wǎng) 管 軟 件 的 公 司 E， 期 望 半 年 內(nèi) 完 成 。u 由 于 接 入 服 務(wù) 器 是 B的 ， 于 是 A和 E就 派 開 發(fā) 人 員 到 B處 搞 需 求 分 析 。u B的 接 入 服 務(wù) 器 并 不 成 熟 ， 老 在 變 ， 三 方 折 騰 了 好 久 ， 最 終 E用 了 一 年時 間 把 接 入 服 務(wù) 器 的 網(wǎng) 管 軟 件 做 出 來 了 。 u E把 網(wǎng) 管 軟 件 交 付 給 A， A付 清 了 E的 開 發(fā) 費 用 ， 再 把 網(wǎng) 管 軟 件 交 付 給D， D再 賣 給 客 戶 F（ 某 地 電

5、 信 局 ） 。 u F對 D講 ： “ 你 們 的 網(wǎng) 管 軟 件 不 是 我 們 想 要 的 東 西 ， 等 你 們 把 軟 件 改 好后 我 們 再 付 錢 。 ”u D趕 緊 對 A講 ： “ 兄 弟 阿 ， 貨 已 經(jīng) 出 手 了 ， 但 是 不 對 路 ， 請 趕 緊 把 它改 好 ， 不 然 大 家 都 沒 錢 賺 。 ”u A很 憤 怒 ， 怨 天 不 公 ： “ 我 們 辛 苦 了 一 年 ， 又 花 了 很 多 錢 ， 可 是 產(chǎn) 品做 完 了 卻 沒 人 要 ， 豈 有 此 理 ！ ” 6 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.2 一個需求分析

6、的案例u 禍 不 單 行 的 是 ， C來 找 A的 麻 煩 ： “ 你 們 的 項 目 延 期 半 年 多 了 ， 經(jīng) 費也 用 光 了 ， 請 盡 快 結(jié) 束 項 目 。 ”u A的 那 位 項 目 經(jīng) 理 為 此 每 天 愁 眉 苦 臉 ， 他 的 上 司 請 來 幾 位 參 謀 商 量 對策 ， 設(shè) 法 把 事 情 搞 定 。u 大 家 挖 空 心 思 只 想 出 一 個 餿 主 意 ： 既 然 套 子 是 B下 的 ， 那 么 就 把 套 子還 給 B。 要 設(shè) 法 把 “ 那 么 好 ” 的 網(wǎng) 管 產(chǎn) 品 轉(zhuǎn) 讓 給 B， 只 要 B能 給 我 們 成本 費 ， 以 后 就 跟

7、B拜 拜 。u 這 個 案 例 的 問 題 根 源 在 于 進 行 軟 件 開 發(fā) 之 前 沒 有 搞 清 楚 網(wǎng)管 軟 件 的 需 求 ， 這 都 是 B,A,E閉 門 造 車 惹 的 禍 。 u 最 可 悲 的 是 ， 相 關(guān) 責(zé) 任 人 關(guān) 心 的 是 如 何 把 事 情 “ 完 成 ” ，而 不 是 深 刻 了 解 用 戶 的 具 體 需 求 。u 這 種 類 似 的 事 情 在 軟 件 開 發(fā) 行 業(yè) 中 經(jīng) 常 發(fā) 生 而 且 還 會 繼 續(xù)發(fā) 生 ， 最 主 要 的 是 每 發(fā) 生 一 次 就 損 失 大 量 的 人 力 和 物 力 。 7 2008 BUPT TSEG 北京郵電

8、大學(xué) 通信軟件工程中心 4.3 需求分析的必要性u需求分析是一項必須的軟件工程活動。它在系統(tǒng)需求分析和軟件設(shè)計之間起到橋梁的作用：它使得軟件開發(fā)人員在系統(tǒng)分析的基礎(chǔ)上深入描述軟件的功能和性能、指明軟件和其他系統(tǒng)元素的接口，建立軟件必須滿足的約束條件。 它允許軟件開發(fā)人員對關(guān)鍵問題進行細化，并構(gòu)建相應(yīng)的分析模型：數(shù)據(jù)、功能和行為模型。分析模型成為設(shè)計模型的基礎(chǔ)，需求規(guī)格說明書也為軟件測試人員和用戶提供了軟件質(zhì)量評估的依據(jù)。它能準確表達用戶對系統(tǒng)的各項要求。 8 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.4 需求分析的對象、任務(wù)和目標u軟件需求分析的對象是用戶要求。u其任務(wù)

9、是要準確地定義新系統(tǒng)的目標?；卮鹣到y(tǒng)必須“做什么”的問題并編制需求規(guī)格說明書。u作為目標系統(tǒng)的參考，需求分析的任務(wù)就是借助于（業(yè)務(wù)）系統(tǒng)的邏輯模型導(dǎo)出目標系統(tǒng)的邏輯模型，解決目標系統(tǒng)的“做什么”的問題。 9 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.5 需求分析建模的原則u需求分析方法的一組操作性原則是：1.問題的信息域必須被表示和理解。2.軟件將完成的功能必須被定義。3.軟件的行為（作為外部事件的結(jié)果）必須被表示。4.描述信息、功能和行為的模型必須被劃分，使得可以用層次的方式揭示細節(jié)。 5.分析過程應(yīng)該遵從自頂向下，逐層細化的原則。 u一組三元模型：第1條原則表示需要

10、建立數(shù)據(jù)模型，第2條和第3條原則表示需要建立功能和行為模型。 10 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.6需求工程的指導(dǎo)性原則 u首先要正確地理解問題，再建立分析模型。u記錄每個需求的起源及原因，保證需求的可回溯性。u開發(fā)一個能使用戶能夠了解人機交互過程的原型。因為對軟件質(zhì)量的感覺經(jīng)?；趯缑妗坝押眯浴钡母杏X。u使用多個需求視圖。建立數(shù)據(jù)模型、功能模型和行為模型，為軟件工程師提供三種不同的視圖，增加識別不一致性的基礎(chǔ)。 u給需求賦予優(yōu)先級。緊張的開發(fā)時間要求盡量避免一次性實現(xiàn)每個軟件需求，應(yīng)采用迭代增量的開發(fā)模型。u努力刪除歧義性。因為大多數(shù)需求以自然語言描述，

11、存在歧義性的可能性，正式的技術(shù)評審是發(fā)現(xiàn)并刪除歧義性的一種有效方法。 11 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.6.1 數(shù)據(jù)建模u需求分析的第1條操作性分析原則表明需要對信息域進行檢查并創(chuàng)建數(shù)據(jù)模型。u信息域包含三個不同的數(shù)據(jù)和控制視圖：信息內(nèi)容和關(guān)系；信息流； 信息結(jié)構(gòu)。 信 息 流 表 示 了 數(shù) 據(jù) 和 控制 在 系 統(tǒng) 中 流 動 時 變 化的 方 式 信 息 內(nèi) 容 表 示 了 個 體 數(shù) 據(jù)和 控 制 對 象 ；數(shù) 據(jù) 和 控 制 對 象 可 和 其 他的 數(shù) 據(jù) 和 控 制 對 象 關(guān) 聯(lián) 信 息 結(jié) 構(gòu) 表 示 了 各 種 數(shù)據(jù) 和 控 制 項 的

12、 內(nèi) 部 組 織 12 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.6.2 功能及行為建模u功能模型：對進入軟件的信息和數(shù)據(jù)進行變換和處理的模塊，它必須至少完成三個常見功能：輸入、處理和輸出。u行為模型：大多數(shù)軟件對來自外界的事件做出反應(yīng)，這種刺激反應(yīng)特征形成了行為模型的基礎(chǔ)。行為模型創(chuàng)建了軟件狀態(tài)的表示，以及導(dǎo)致軟件狀態(tài)變化的事件的表示。u功能模型和行為模型的作用如下： 模型能夠幫助軟件開發(fā)人員快速準確的理解系統(tǒng)所涉及的信息、功能和動態(tài)行為；模型可成為后期軟件設(shè)計的基礎(chǔ)，為軟件設(shè)計人員提供了設(shè)計軟件功能的視圖化表示；模型能夠成為軟件測試和軟件評審的重要依據(jù) 13 200

13、8 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.6.3 問題劃分u需求問題域涉及面廣泛而且復(fù)雜，以至于難以進行整體理解。為此，需要將這樣的問題劃分為易于理解的子問題，并建立各子問題間的關(guān)系以使得可以完成整個功能。u第4條和第5條操作性分析原則建議軟件的信息、功能和行為域可以被劃分。u在本質(zhì)上，劃分將問題分解為其構(gòu)成成分。在概念上，建立信息或功能的層次結(jié)構(gòu)表示，通過進行自頂向下的分析，進而暴露更多的細節(jié)問題，并在各層次上進行各功能元素的分配。 14 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.7 需求工程u軟件的需求分析是一系列復(fù)雜的軟件工程活動，為了便于對需求

14、進行更好的管理，人們把所有與需求直接相關(guān)的活動通稱為需求工程。需 求 工 程 需 求 開 發(fā) 需 求 變 更 控 制需 求 管 理需 求 確 認需 求 跟 蹤需 求 獲 取需 求 分 析需 求 定 義用 戶 需 求 說 明 書軟 件 需 求規(guī) 格 說 明 書 需 求 跟 蹤 矩 陣 需 求 評 審 報 告 15 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.7.1 需求獲取u需求獲取的目的是清楚地理解所要解決的問題，完整地獲得用戶的需求。并提出這些需求實現(xiàn)條件，以及需求應(yīng)達到的標準。u需求獲取的對象用戶：使用軟件的人員客戶：購買軟件的人員u需求獲取的難點 用戶無法清楚地表達

15、需求 需求的理解問題 用戶經(jīng)常變更需求 16 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.7.2 需求獲取流程目 的 獲 取 用 戶 （ 客 戶 與 最 終 用 戶 ） 的 需 求 信 息 ， 經(jīng) 過 分 析 后 產(chǎn) 生 用 戶 需 求 說 明 書 。角 色 與 職 責(zé) 需 求 分 析 員 調(diào) 查 、 分 析 用 戶 的 需 求 ， 客 戶 與 最 終 用 戶 提 供 必 要 的 需 求 信 息 。啟 動 準 則 需 求 分 析 員 已 經(jīng) 確 定輸 入 任 何 與 用 戶 需 求 相 關(guān) 的 材 料主 要 步 驟 第 一 步 ： 準 備 調(diào) 查第 二 步 ： 調(diào) 查 與

16、 記 錄 第 三 步 ： 分 析 需 求 信 息第 四 步 ： 撰 寫 用 戶 需 求 說 明 書 第 五 步 ： 需 求 確 認輸 出 用 戶 需 求 說 明 書 結(jié) 束 準 則 需 求 分 析 員 已 經(jīng) 撰 寫 完 成 用 戶 需 求 說 明 書 ， 確 保 無 拼 寫 、 排 版 等 錯 誤 。 并 確 保 用 戶 需 求 說 明 書 的 內(nèi) 容 無 二 義 性 ， 且 涵 蓋 了 所 有 的 用 戶 需 求 。度 量 需 求 分 析 員 統(tǒng) 計 工 作 量 和 上 述 文 檔 的 規(guī) 模 ， 匯 報 給 項 目 經(jīng) 理 。 17 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工

17、程中心 4.7.3 需求獲取的準備u需求獲取的準備工作圍繞三項展開：調(diào)查什么？通過什么方式去調(diào)查？“何人”在“何時”調(diào)查？ u首先，應(yīng)起草需求調(diào)查問題表，將重點鎖定在該問題表內(nèi)，否則調(diào)查工作將變得漫無邊際。 u其次，應(yīng)當確定需求調(diào)查的方式，比如：與用戶交談，向用戶提問題。參觀用戶的工作流程，觀察用戶的操作。向用戶群體發(fā)調(diào)查問卷。與同行、專家交談，聽取他們的意見。 18 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.7.4 需求獲取的記錄u準備工作完畢后，需求分析員按照計劃執(zhí)行調(diào)查。在調(diào)查過程中隨時記錄（或存儲）需求信息，建議采用表格的形式，如下圖：需 求 標 題 1調(diào) 查

18、方 式 調(diào) 查 人調(diào) 查 對 象時 間 、 地 點需 求 信 息 記 錄 基 本 要 素 如 “ 是 什 么 ” 、 “ 為 什 么 ” 等 19 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.7.5 撰寫用戶需求說明書u最后對收集到的所有需求信息進行分析，消除錯誤，歸納與總結(jié)共性的用戶需求。u然后按照規(guī)定的文檔模板撰寫用戶需求說明書，調(diào)查過程中獲取的需求信息可以作為用戶需求說明書的附件。u之后應(yīng)當邀請同行專家和用戶一起評審用戶需求說明書，盡最大努力使用戶需求說明書能夠正確無誤地反映用戶的真實意愿。 20 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.7

19、.6 用戶需求說明書與軟件需求規(guī)格說明書的區(qū)別u前者主要采用自然語言來表達用戶需求，其內(nèi)容相對于后者而言比較粗略，不夠詳細。u后者是前者的細化，更多地采用計算機語言和圖形符號來刻畫需求，軟件需求是軟件系統(tǒng)設(shè)計的直接依據(jù)。u兩者之間可能并不存在一一影射關(guān)系，因為軟件開發(fā)商會根據(jù)產(chǎn)品發(fā)展戰(zhàn)略、企業(yè)當前狀況適當?shù)卣{(diào)整軟件需求，例如用戶需求可能被分配到軟件的數(shù)個版本中。軟件開發(fā)人員應(yīng)當依據(jù)軟件需求規(guī)格說明書來開發(fā)當前產(chǎn)品。 21 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.8 需求類別u功能需求：列舉出所開發(fā)軟件在功能上應(yīng)做什么，這是最主要的需求。u性能需求：給出所開發(fā)軟件的技術(shù)

20、性能指標，尤其是系統(tǒng)的實時性和其他時間要求，如響應(yīng)時間、處理時間、消息傳送時間等；資源配置要求，精確度，數(shù)據(jù)處理量等要求。u環(huán)境需求：是對軟件系統(tǒng)運行時所處環(huán)境的要求。 在硬件方面，采用什么機型、有什么外部設(shè)備、數(shù)據(jù)通信接口等等。在軟件方面，采用什么支持系統(tǒng)運行的系統(tǒng)軟件（指操作系統(tǒng)、網(wǎng)絡(luò)軟件、數(shù)據(jù)庫管理系統(tǒng)等）。在使用方面，需要使用部門在制度上、操作人員的技術(shù)水平上應(yīng)具備什么樣的條件等等。 22 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.8 需求類別u可靠性需求：指軟件的有效性和數(shù)據(jù)完整性。各種軟件在運行時失效的影響各不相同。在需求分橋時，應(yīng)對所開發(fā)軟件在投入運行后不

21、發(fā)生故障的概率，按實際的運行環(huán)境提出要求。u安全保密要求：工作在不同環(huán)境的軟件對其安全、保密的要求顯然是不同的，應(yīng)當把這方面的需求恰當?shù)刈龀鲆?guī)定。 u用戶界面需求：軟件與用戶界面的友好性是用戶能夠方便有效愉快地使用該軟件的關(guān)鍵之一。 23 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.8 需求類別u資源使用需求：指所開發(fā)軟件運行時所需的數(shù)據(jù)、軟件、內(nèi)存空間等各項資源，以及軟件開發(fā)時所需的人力、支撐軟件、開發(fā)設(shè)備等。u軟件成本消耗與開發(fā)進度需求：在軟件項目立項后，要根據(jù)合同規(guī)定，對軟件開發(fā)的進度和各步驟的費用提出要求，作為開發(fā)管理的依據(jù)。u預(yù)先估計以后系統(tǒng)可能達到的目標：在開

22、發(fā)過程中，可對系統(tǒng)將來可能的擴充與修改做準備。一旦需要時，就比較容易進行補充和修改。 24 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.9 需求的分析與綜合u需求獲取之后就需要對比較復(fù)雜的需求進行建模分析，進而逐步細化所有的軟件功能，找出系統(tǒng)各元素之間的聯(lián)系、接口特性和設(shè)計上的限制，分析它們是否滿足功能要求，是否合理。 u依據(jù)功能需求，性能需求，運行環(huán)境需求等，剔除其不合理的部分，增加其需要部分。最終綜合成系統(tǒng)的解決方案，給出目標系統(tǒng)的詳細邏輯模型。 u分析和綜合工作需要反復(fù)地進行，其過程將一直持續(xù)到分析員與用戶雙方都感到有把握正確地制定該軟件的需求規(guī)格說明為止。 25

23、2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.9.1 需求的定義目 的 定 義 準 確 無 誤 的 軟 件 產(chǎn) 品 需 求 ， 產(chǎn) 生 軟 件 需 求 規(guī) 格 說 明 書 。角 色 與 職 責(zé) 需 求 分 析 員 定 義 軟 件 需 求 。 客 戶 與 最 終 用 戶 確 認 軟 件 需 求 。啟 動 準 則 用 戶 需 求 說 明 書 已 經(jīng) 撰 寫 完 成 。輸 入 用 戶 需 求 說 明 書 主 要 步 驟 第 一 步 ： 細 化 并 分 析 用 戶 需 求第 二 步 ： 撰 寫 軟 件 需 求 規(guī) 格 說 明 書第 三 步 ： 軟 件 需 求 確 認輸 出 軟 件

24、需 求 規(guī) 格 說 明 書 結(jié) 束 準 則 軟 件 需 求 規(guī) 格 說 明 書 已 經(jīng) 撰 寫 完 成 。 開 發(fā) 方 和 客 戶 方 已 經(jīng) 對 產(chǎn) 品 需 求進 行 了 確 認 。度 量 需 求 分 析 員 統(tǒng) 計 工 作 量 和 上 述 文 檔 的 規(guī) 模 ， 匯 報 給 項 目 經(jīng) 理 。 26 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.9.2 需求建模u軟件開發(fā)人員還需要構(gòu)造系統(tǒng)的分析模型，著重于描述系統(tǒng)必須做什么、而不是如何去做系統(tǒng)。 u給出系統(tǒng)的邏輯視圖，以及系統(tǒng)的物理視圖。邏輯模型給出軟件要達到的功能和處理數(shù)據(jù)之間的關(guān)系，而不是實現(xiàn)的細節(jié)。 物理模型給出處理功能和數(shù)據(jù)結(jié)構(gòu)的實際表示形式，這往往是由設(shè)備決定的。 u常用的建模分析方法有：面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（簡稱SA）面向數(shù)據(jù)結(jié)構(gòu)的Jackson方法（簡稱JSD）面向?qū)ο蟮姆治龇椒ǎê喎QOOA）等以及用于建立動態(tài)模型的狀態(tài)遷移圖或Petri網(wǎng)等 27 2008 BUPT TSEG 北京郵電大學(xué) 通信軟件工程中心 4.10 編制需求分析文檔u通常把描述需求的文檔叫做軟件需求規(guī)格說明書。u同時，為了確切表達用戶對軟件的輸入輸出要求，還需要制定數(shù)據(jù)詞典及編寫初步的用戶手冊，著重反映被開發(fā)軟件的用戶界面和用戶使用的具體要求。