1、第三章 軟件需求分析 在軟件整個生命周期中，首先是軟件計劃期，接著是軟件開發期，軟件需求分析是軟件開發第一個階段，也是關系到軟件開發成功是否關鍵一步。本章學習是基于已完畢軟件計劃基礎上進行，軟件計劃安排到第十二章講。 3.1 需求分析任務與環節 3.2 需求獲取慣用辦法 3.3 分析建模 3.4 軟件需求闡明 3.5 結構化分析辦法 3.6 面向對象分析辦法第1頁第1頁第三章 軟件需求分析 軟件在需求分析和設計階段占用工作量達到總工作量4050，闡明軟件開發前期活動多么主要。當然這也包括分階段開發原型開銷。大家熟悉編碼工作只占所有工作量1020，而軟件測試和調試工作量占到總工作量3040，甚至

2、50%。第2頁第2頁3.1 需求分析任務與環節 3.1 .1需求分析任務需求分析任務就是準確地回答“系統必須做什么?”這個問題，是通過系統分析員與用戶一起商定，清楚、準確、詳細地描述軟件產品必須含有功效、性能、運營規格等要求。軟件需求分析階段目的是澄清用戶要求，并把雙方共同理解明確地表示成一份書面文檔軟件需求規格闡明書。第3頁第3頁3.1 需求分析任務與環節 需求分析任務就是借助于當前系統邏輯模型導出目標系統邏輯模型。主要有兩個任務：1、建立分析模型數據、功效和行為模型2、編寫需求說明書。 其實現模型以下圖所表示：第4頁第4頁系統實現模型目的系統當前系統物理模型邏輯模型邏輯模型物理模型模型化抽

3、象化實例化詳細化理解需求表達需求導出做什么怎么做第5頁第5頁1.分析建模導出目的系統邏輯模型例子： 找出當前系統物理模型學生張秘書王會計李出納趙保管學生學生購買教材物理模型購書申請購書證實購書發票領書單書第6頁第6頁導出目的系統邏輯模型例子把當前系統物理模型轉換為邏輯模型學生審查有效性開發票開領書單發書學生購書單有效購書單領書單書發票學生購買教材邏輯模型第7頁第7頁導出目的系統邏輯模型例子把舊系統邏輯模型轉換為目的系統邏輯模型學生審查并開發票開領書單發書學生購書單發票領書單書計算機售書系統邏輯模型第8頁第8頁導出目的系統邏輯模型例子改進（優化）目的系統邏輯模型學生審查并開發票開領書單學生購書單

4、發票領書單改進了計算機售書系統模型無效書單第9頁第9頁分析階段中慣用模型（邏輯模型）數據流圖（DFD）實體聯系圖（ ERD ）層次方框圖、IPO圖、 Warnier圖類圖、實例圖、時序圖狀態圖、協作圖、 活動圖事件列表數據流定義數據元素定義 第10頁第10頁3.1 需求分析任務與環節 2.編寫軟件需求規格闡明： 主要包括描述目的系統概貌、功效要求、性能要求、運營要求和未來也許提出要求。數據流圖、用IPO圖或其它工具簡明描述系統主要算法都是該份文擋主要構成部分。另外，該份文檔還應包括用戶需求與系統功效之間關系、設計約束等等文字描述。 軟件需求規格闡明是需求分析階段最后結果。第11頁第11頁3.1

5、 需求分析任務與環節準確、完整和規范軟件需求是軟件開發成功關鍵！需求分析任務建立分析模型 描述軟件需求一組模型準確統計用于對原始問題和目的系統描述幫助分析人員發覺用戶需求中不一致性，排除不合理部分，挖掘潛在用戶需求編寫需求闡明應做到準確性和一致性清楚性和沒有二義性直觀、易讀和易于修改第12頁第12頁案例分析一個含有n部電梯電梯系統要安裝在一座m層大樓上。電梯和控制機構已造好。每個電梯內部機構也已給定。問題涉及電梯在樓層間移動邏輯：（1）每座電梯有一套按鈕，每層一個。按鈕按下時使鈕燈變亮，并使電梯到達相應樓層。當電梯到達相應樓層時按鈕燈熄滅。第13頁第13頁（2）除了底層和頂層外，每層都有兩個按

6、鈕，一個按鈕請求電梯上升，另一個按鈕請求電梯下降。這些按鈕在按下時按鈕燈亮。電梯到達指定樓層后按鈕燈熄滅，然后要么朝盼望方向移動，要么請求等待。在后一個情況下，假如一個樓層上兩個請求按鈕都按下，則只取消其中一個按鈕。決定先服務哪一層算法應當使兩個請求等待時間最小。案例分析第14頁第14頁（3）當一個電梯沒有服務請求時，應當停留在最后目的地，關上電梯門，并等待后面請求。（4）樓層上所有電梯請求必須最后得到服務，并且因此樓層含有相同優先權。（5）電梯內所有樓層請求必須最后得到服務，各層按電梯移動方向先后得到服務。（6）每個電梯有一個緊急按鈕。按下該按鈕時，將使一個報警信號發送到現場管理人員，然后強

7、制電梯“停止服務”。每一個電梯有一個取消其“停止服務”狀態機制。案例分析第15頁第15頁電梯狀態轉換圖舉例在一樓上升停滯下降回到一樓回一樓想要到達樓層想要到達樓層電梯行程開始向上向上向下第16頁第16頁需求分析環節需求分析環節1.需求獲取 目的：清楚地理解所要處理問題；完整地獲取用戶需求2.需求提煉 任務：分析建模 3.需求描述 結果：軟件需求闡明書4.需求驗證 改進需求闡明完整性，確保他可作為軟件設計和系統驗收依據。第17頁第17頁3.2 需求獲取慣用辦法聯合分析小組 用戶代表、領域專家和系統分析員客戶訪談 充足準備，尋找共同語言 循循序漸進、逐步迫近 采用情景分析技術 （比如制定一個減肥計

8、劃軟件）采用簡易規格闡明技術（用戶積極參與，不要區別“我們和他們”，開會討論且增刪需求項目）問題分析與確認 多個往返（采用軟件原型）第18頁第18頁調研問卷部分名稱、人員數量和結構部分發展或改變簡樸簡介部分主要任務業務處理流程業務處理過程中涉及哪些專業領域知識工作需要審批流程是什么？主要算法描述哪些業務需要實時處理？哪些業務需要交互操作？第19頁第19頁部門各崗位職責部門接受哪些部門或外界信息？信息內容和格式是什么？部門產生哪些信息？部門產生信息送到哪些其它部門？格式要求是什么？對信息輸入和輸出方式有要求嗎？輸入輸出設備是什么？數據要求實時備份嗎？備份設備是什么？時間策略？業務處理有高峰期嗎？

9、高峰時間是什么？時間策略？既有哪些設備要繼續使用？調研問卷第20頁第20頁對產品運營環境有要求嗎？對界面風格和操作方式有要求嗎？在系統運營過程中允許停機嗎？操作方式要依據操作環境和使用人員素質分類嗎？需要操作權限有哪些？需要統計系統操作運營日記嗎？用戶有能力進行系統維護嗎？需要分布式處理嗎？需要什么方式用戶操作培訓。需要制作聯機幫助嗎？調研問卷第21頁第21頁案例用戶提出某種需求：水質量信息必須馬上能夠顯示出來。分析員更準確描述：水質量統計必須在接到請求信號5秒內顯示出來。第22頁第22頁需求獲取三大挑戰問題空間理解人與人之間通信需求不斷改變第23頁第23頁某出版社系統調查表編號提出問題1您在

10、哪個部門工作？2出版業務流程是什么？3您每日都處理那些文獻、數據、報表？4工作中手工處理尤其麻煩事情是什么？5工作中手工處理什么問題處理不了？影響效率問題有哪些？6您認為提升工作效率，節約工作時間，減輕工作強度可采用哪些辦法？第24頁第24頁某出版社系統調查表編號提出問題7您部門需要成本核實和統計內容有哪些？8您部門采用計算機管理工作情況如何？9如何改進業務流程使之更合理？10哪些問題是當前老式手工辦法主線無法處理？11出版社計算機管理信息系統需要處理什么問題？第25頁第25頁需求獲取內容1.用戶需求分類 (1)功效性需求: 定義了系統做什么（描述系統必須支持 功效和過程） (2)非功效性需求

11、（技術需求）: 定義了系統工作時特性 （描述操作環境和性能目的）第26頁第26頁2. 兩類需求包括內容(1) 功效(2) 性能(3) 環境(4) 界面(5) 用戶或人原因(6) 文檔 (7) 數據(8) 資源(9) 安全保密(10)軟件成本消耗與開發進度(11)質量確保第27頁第27頁(1) 功效需求 系統做什么？ 系統何時做什么？ 系統何時及如何修改或升級？第28頁第28頁(2) 性能需求軟件開發技術性指標比如： 存儲容量限制 執行速度、相應時間 吞吐量第29頁第29頁(3) 環境需求硬件設備：機型、外設、接口、 地點、分布、溫度、 濕度、磁場干擾等軟件： 操作系統 網絡 數據庫第30頁第3

12、0頁(4) 界面需求 有來自其它系統輸入嗎？ 到自其它系統輸出嗎？ 對數據格式有要求嗎？ 對數據存儲介質有要求嗎？第31頁第31頁(5) 用戶或人原因 用戶類型？ 各種用戶純熟程度？ 需受何種訓練？ 用戶理解、使用系統難度？ 用戶錯誤操作系統也許性？第32頁第32頁(6) 文檔需求 需哪些文檔？ 文檔針對哪些讀者？第33頁第33頁(7) 數據需求 輸入、輸出數據格式？ 接受、發送數據頻率？ 數據準確性和精度？ 數據流量？ 數據需保持時間？第34頁第34頁(8) 資源需求 軟件運營時所需數據、軟件。 內存空間等資源。 軟件開發、維護所需人力、 支撐軟件、開發設備等。第35頁第35頁(9) 安全保

13、密要求 需對訪問系統或系統信息加以控 制嗎？ 如何隔離用戶之間數據？ 用戶程序如何與其它程序和操作 系統隔離？ 系統備份要求？第36頁第36頁(10) 軟件成本消耗與開發進度需求開發有要求時間表嗎？軟硬件投資有無限制？第37頁第37頁(11) 質量確保 系統可靠性要求？ 系統必須監測和隔離錯誤嗎？ 要求系統平均犯錯時間？ 犯錯后，重啟系統允許時間？ 系統改變如何反應到設計中？ 維護是否包括對系統改進？ 系統可移植性？第38頁第38頁3.3 分析建模所謂模型，就是為了理解事物而對事物做出一個抽象，是對事物一個無歧義書面描述。簡樸地說，模型就是某一事物抽象表示方式。 通過軟件需求分析建立起來模型能

14、夠稱之為分析模型或者需求模型。第39頁第39頁3.3 分析建模需求分析模型：數據字典數據模型功效模型行為模型第40頁第40頁功效模型 功效模型能夠用數據流圖(DFD)描述，因此又稱為數據流模型。 下面是數據流圖基本形式：3變換4變換1變換2變換外部實體外部實體外部實體外部實體數據文獻輸入數據中間數據輸出數據第41頁第41頁學生1審查開發票2開領書單學生購書單發票領書單計算機售書系統數據流圖無效書單各班學生用書表教材存量表功效模型-案例一第42頁第42頁 假定一家工廠采購部天天需要一張訂貨報表，報表按零件編號排序，表中列出所有需要再次訂貨零件。 對于每個需要再次訂貨零件應當勒出下列數據：零件編號

15、、名稱、訂貨數量、當前價格、主要供應者、次要供應者。 零件入庫或出庫稱為事務，通過放在倉庫中CRT終端把事務匯報給訂貨系統。當某種零件庫存量少于庫存量臨界值時就應當再次訂貨。功效模型-案例二第43頁第43頁 數據流圖含有四種成份：源點和終點、處理、數據存儲、數據流。 首先考慮數據源點和終點。從上面敘述可知：采購員是數據終點，而倉庫管理員是數據源點。 然后考慮處理。必須有一個用于產生報表處理；事務后果是改變庫存量，而任何改變數據操作都是處理，因此對事物加工是另一個處理。功效模型-案例二第44頁第44頁 最后，考慮數據流和數據存儲。系統把訂貨報表送給采購部，訂貨報表是一個數據流；事物需要從倉庫送到

16、系統中，顯然事物是另一個數據流。 產生報表和處理事務這兩個處理在時間上明顯不匹配-每當發生一個事務時要馬上處理它，而天天只產生一個訂貨報表。因此，訂貨報表數據應當有一個數據存儲。 另外，尚有一些隱含數據：零件庫存量、庫存臨界值等。功效模型-案例二第45頁第45頁功效模型-案例二源點/終點處理數據流數據存儲采購員產生報表訂貨報表訂貨信息倉庫管理員處理事務 零件編號 （見訂貨報表） 零件名稱庫存清單 訂貨數量 零件編號 當前價格 庫存量 主要供應者 庫存量臨界值 次要供應者事務 零件編號 事務類型 數量第46頁第46頁功效模型-案例二第47頁第47頁功效模型-案例二第48頁第48頁功效模型-案例二

17、第49頁第49頁數據模型 包括有3種相關信息：（1）數據對象 數據對象是幾乎所有必須被軟件理解復合信息表示。它只封裝數據，不包括作用于對象操作。（2）屬性 屬性定義了數據對象性質。（3）關系 數據對象彼此之間是相關聯，也稱為關系。第50頁第50頁數據模型 數據模型經常用“實體-關系圖(ERD)” 來描述。 ERD包括3種基本元素，即實體、屬性和關系。 通常，用矩形表示即數據對象，用圓角矩形或橢圓形表示實體屬性，用菱形連接相關實體表示關系。 下圖是一個簡化教學管理ERD：第51頁第51頁性別職稱姓名教工號姓名性別系學號年級課程號課程名學時學分課程教師學生教學數據模型-案例簡化教學管理ERD第52

18、頁第52頁行為模型及案例行為模型慣用狀態轉換圖（簡稱狀態圖）來描述，它又稱為狀態機模型。狀態圖中基本元素有事件、狀態和行為等。系統狀態機模型能夠理解為在任一個時刻，系統處于有限也許狀態中一個狀態，當某一個激勵（條件）到達時，它激發系統從一個狀態轉換到另一個新狀態。 下面是電話系統狀態圖：第53頁第53頁閑置撥號音do:響撥號音超時do:響蜂鳴音存儲信息do:播放信息接通中do:試接通振鈴do:振鈴撥號通話斷線忙音do:響忙音掛斷電話掛斷電話拿起話筒超時無效號碼有效號碼超時數字數字占線已接通受話人回話受話人掛斷電話信息播完第54頁第54頁數據字典 數據字典(Data Dictionary)用于描

19、述軟件系統中使用或者產生每一個數據元素，是系統數據信息定義集合。 數據字典作用，就是對軟件中每個數據要求一個定義條目，以保持數據在系統中一致性。 軟件中數據，可分為三種情況： 只含一個數據數據項(或數據元素)； 由多個相關數據項構成數據流； 數據文獻或數據庫。第55頁第55頁數據流“發票”字典條目數據流名：發票別 名：購書發票組 成： 學號姓名書號單價數量總價書費累計備 注：數據字典-案例第56頁第56頁3.3 分析建模下面簡介兩種需求模型：結構化分析模型和面向對象分析模型分析模型描述工具DFD、DD和PSPEC CFD、CSPEC和STD E-R圖 用例圖對象-關系圖：類、對象、構建等圖對象

20、-行為圖 ：狀態、時序、協作、活動等圖第57頁第57頁結構化分析模型數據對 加工象闡明 闡明 控制闡明(STD圖)E-R圖 DFD圖CFD圖DD數據模型功效模型行為模型第58頁第58頁面向對象分析模型屬性、操作、協作者類對象 對象-關模型 系模型對象-行為模型使用實例功效模型行為模型數據模型（靜態）（靜態）（動態）第59頁第59頁分析模型描述工具結構化分析工具DFD、DD和PSPEC（加工闡明）基本構成 CFD、CSPEC （控制闡明）和STD 擴展E-R圖 擴展（復雜數據結構能夠使用）面向對象分析工具用例圖，類對象圖對象-關系圖對象-行為圖第60頁第60頁1. 數據流圖（DFD）舉例：飛機票

21、預訂系統數據流圖：第61頁第61頁1. 數據流圖（DFD）描述系統邏輯模型信息在系統中流動和處理用途交流信息工具結構化分析和設計工具第62頁第62頁1. 數據流圖（DFD）數據流圖以圖形方式反應系統 數據流程 由四種基本元素構成，代表符號和名稱：加工名編號加工名編號文獻名文獻名數據流 加工、處理或變換數據文獻或數據庫數據原點或終點文獻名實體名第63頁第63頁用戶出版社驗證訂單匯總訂單訂單出版社 訂單圖書目錄文獻用戶檔案待處理訂單文獻正確訂單一批訂單出版社檔案文獻訂貨存根文獻DFD圖例子第64頁第64頁 畫數據流圖原則找出數據源點與終點把軟件系統當作一個大加工，依據外部實體輸出數據流和輸入數據流

22、，劃出系統輸入和輸出圖，即頂層圖（也稱第一層數據流圖）依據系統邏輯要求，從外部實體輸出數據流出發，把頂層圖中加工分解成若干個子加工，并用數據流把這些加工連接起來，此時系統內部圖稱為第二層圖進行檢查和修改按照上述環節，再從各加工出發，畫出所需若干層子圖（第三層、第四層.）第65頁第65頁 一家工廠采購部天天需要一張訂貨報表，報表按零件編號排序，表中列出所有需要再次訂貨零件。對于每個需要再次訂貨零件應當列出下述數據：零件編號，零件名稱，定貨數量，當前價格，主要供應者，次要供應者。零件入庫或出庫稱為事務，通過放在倉庫中CRT終端把事務匯報結訂貨系統。當某種零件庫存數量少于庫存量臨界值時就應當再次訂貨

23、。 由文字描述畫出數據流圖（案例）第66頁第66頁采購員訂貨系統事務訂貨報表訂貨系統數據頂層流程圖倉庫保管員由文字描述畫出數據流圖（案例）第67頁第67頁會計處理原始數據賬簿、報表會計信息系統數據頂層流程圖會計信息系統數據流圖（案例）第68頁第68頁 DFD能夠用來表示一個系統或軟件在任何層次上抽象。 較大型軟件系統DFD分成多層(子圖、父圖概念),能夠表示數據流和功效進一步細節。數據流圖分層結構第69頁第69頁S2132.22.12.33.13.2頂層(1層)（不編號）2層3層第70頁第70頁領書單 進書告知 購書單 缺書單 DFD練習售書系統學生教材購銷系統書庫保管員教材購銷系統-頂層數據流圖第71頁第71頁領書單 進書告知 進書告知 購書單缺書單 1銷售 2采購書庫保管員學生F1教材存量表 F2缺書登記表 DFD練習售書系統教材購銷系統-第二層數據流圖第72頁第72頁DFD練習售書系統第73頁第73頁DFD練習售書系統教材購銷系統第三層DFD-采購子系統第74頁第74頁實例 考務處理系統功效 (1)對考生送來報名單進行檢查;(2)對合格報名單編好準考證號后將準考證送給考生，并將匯總后考生名單送給閱卷站;(3)對閱卷站送來成績單進行檢查，并依據考試中心制定合格原則審定合格者;(4)制作考生告知單(含成績及合格/不合格標志)送給考生;(5