軟件工程課件之_需求分析(第五版)(張海潘編著)

1、 3.1 需求分析的任務 3.2 與用戶溝通獲取需求的方法 3.3 分析建模與規(guī)格說明 3.4 實體-聯(lián)系圖 3.5 數(shù)據(jù)標準化 3.6 狀態(tài)轉(zhuǎn)換圖 3.7 其他圖形工具 3.8 驗證軟件需求第3章 需求分析第3章 需求分析需求分析的任務：需求分析是軟件定義時期的最后一個階段，它的根本任務是準確地答復“系統(tǒng)必須做什么?這個問題。確定系統(tǒng)必須完成哪些工作，也就是對目標系統(tǒng)提出完整、準確、清晰、具體的要求。系統(tǒng)分析員應該寫出軟件需求規(guī)格說明書，以書面形式準確地描述軟件需求。 需求：正在構(gòu)建的系統(tǒng)必須符合的事務。需求管理：是一種獲取、組織并記錄系統(tǒng)需求的系統(tǒng)化方案以及一個使客戶與工程團隊不斷變更的系

2、統(tǒng)需求達成并保持一致的過程。傳統(tǒng)需求分析：強調(diào)需求的記錄，以一成不變的觀點對待需求，不重視需求實現(xiàn)與維護?，F(xiàn)代需求過程：包括需求的獲取、分析、處理、驗證、實現(xiàn)和全過程的需求管理。需求管理覆蓋軟件工程的整個過程。傳統(tǒng)與現(xiàn)代需求方法的比較： 需求管理過程需求管理功能需求管理思想方法傳統(tǒng)局限于需求分析這一個階段注重具體的需求分析方法一成不變的觀點，注重“描述”的方法和過程，是純技術(shù)性的轉(zhuǎn)換現(xiàn)代全過程的，注重整個產(chǎn)品過程的全部功能范圍更廣，包括獲取、分析、處理、驗證、實現(xiàn)和全過程的需求管理注重需求實現(xiàn)與維護過程，處理不斷變更的系統(tǒng)需求需求管理存在的問題：范圍問題：系統(tǒng)目標、邊界未被良好定義，用戶和開發(fā)

3、團隊理解不一致。理解問題：用戶不能完全了解自己需要什么，對系統(tǒng)能力、局限更加不清楚；工程師不理解用戶的問題域和應用環(huán)境。易變問題：需求隨時間發(fā)生變化。需求工程：20世紀80年代中期，形成了軟件工程的子領(lǐng)域需求工程。進入20世紀90年代后，需求工程稱為軟件界研究的重點之一。Alan Davis 把需求工程定義為“直到但不包括把軟件分解為實際架構(gòu)構(gòu)件之前的所有活動。需求工程的階段劃分：3.1 需求分析的任務 確定對系統(tǒng)的綜合要求 分析系統(tǒng)的數(shù)據(jù)要求 導出系統(tǒng)的邏輯模型 修正系統(tǒng)開發(fā)方案 3.1.1 確定對系統(tǒng)的綜合要求 1. 功能需求2. 性能需求3. 可靠性和可用性需求4. 出錯處理需求5. 接

4、口需求6. 約束7. 逆向需求8. 將來可能提出的要求3.1.2 分析系統(tǒng)的數(shù)據(jù)要求建立數(shù)據(jù)模型ER圖 描繪數(shù)據(jù)結(jié)構(gòu)層次方框圖和Warnier圖 數(shù)據(jù)結(jié)構(gòu)標準化 3.1.3 導出系統(tǒng)的邏輯模型 綜合上述兩項分析的結(jié)果可以導出系統(tǒng)的詳細的邏輯模型，通常用數(shù)據(jù)流圖、實體-聯(lián)系圖、狀態(tài)轉(zhuǎn)換圖、數(shù)據(jù)字典和主要的處理算法描述這個邏輯模型。 根據(jù)在分析過程中獲得的對系統(tǒng)的更深入更具體的了解，可以比較準確地估計系統(tǒng)的本錢和進度，修正以前制定的開發(fā)方案。 3.1.4 修正系統(tǒng)開發(fā)方案 3.2 與用戶溝通獲取需求的方法訪談 面向數(shù)據(jù)流自頂向下求精簡易的應用規(guī)格說明技術(shù) 快速建立軟件原型 需求分析綜合癥解決方案需

5、求誘導的方法：3.2.1 訪談1. 正式訪談系統(tǒng)分析員將提出一些事先準備好的具體問題。2. 非正式訪談分析員將提出一些用戶可以自由答復的開放性問題，以鼓勵被訪問人員說出自己的想法。3. 調(diào)查表經(jīng)過仔細考慮寫出的書面答復可能比被訪者對問題的口頭答復更準確。4. 情景分析技術(shù)對用戶將來使用目標系統(tǒng)解決某個具體問題的方法和結(jié)果進行分析。情景分析技術(shù)的用處：能在某種程度上演示目標系統(tǒng)的行為，從而便于用戶理解，而且還可能進一步揭示出一些分析員目前還不知道的需求。能保證用戶在需求分析過程中始終扮演一個積極主動的角色。讓用戶起積極主動的作用對需求分析工作獲得成功是至關(guān)重要的。3.2.2 面向數(shù)據(jù)流自頂向下求

6、精 1. 分析追蹤數(shù)據(jù)流圖需求分析的目標之一就是把數(shù)據(jù)流和數(shù)據(jù)存儲定義到元素級，通常從數(shù)據(jù)流圖的輸出端著手分析。2. 用戶復查必須請用戶對上述分析過程中得出的結(jié)果仔細地復查。復查過程驗證了的元素，補充了未知的元素，填補了文檔中的空白。隨著分析過程的進展，經(jīng)過問題和解答的反復循環(huán)，分析員越來越深入具體地定義了目標系統(tǒng)，最終得到對系統(tǒng)數(shù)據(jù)和功能要求的滿意了解。 面向數(shù)據(jù)流自頂向下求精過程3.2.3 簡易的應用規(guī)格說明技術(shù)簡易的應用規(guī)格說明技術(shù)是一種面向團隊的需求收集法。這種方法提倡用戶與開發(fā)者密切合作，共同標識問題，提出解決方案要素，商討不同方案并指定根本需求。 分析需求的典型過程如下：1. 初步

7、訪談，準備會議首先進行初步的訪談，初步確定待解決的問題的范圍和解決方案。然后開發(fā)者和用戶分別寫出“產(chǎn)品需求。選定會議的時間和地點，并選舉協(xié)調(diào)人。2. 會前審查需求，確定列表要求每位與會者在開會的前幾天認真審查產(chǎn)品需求，并且列出對象、操作這些對象或與這些對象交互的效勞、約束條件和性能標準。3. 會上討論列表，創(chuàng)立組合列表每位與會者展示列表供大家討論。大家共同創(chuàng)立一張組合列表。由協(xié)調(diào)人主持討論這些列表。4. 分組制定小型規(guī)格說明與會者分成更小的小組，為每張列表中的工程制定小型規(guī)格說明。每個小組都向全體與會者展示他們制定的小型規(guī)格說明，供大家討論。5. 制定確認標準，起草需求規(guī)格說明書每個與會者都制

8、定出產(chǎn)品的一整套確認標準，并提交會議討論，以創(chuàng)立出意見一致確實認標準。最后，起草完整的軟件需求規(guī)格說明書。簡易的應用規(guī)格說明技術(shù)的優(yōu)點：開發(fā)者與用戶不分彼此，齊心協(xié)力，密切合作；即時討論并求精；有能導出規(guī)格說明的具體步驟。 3.2.4 快速建立軟件原型 快速建立軟件原型是最準確、最有效、最強大的需求分析技術(shù)?？焖僭途褪强焖俳⑵饋淼闹荚谘菔灸繕讼到y(tǒng)主要功能的可運行的程序。構(gòu)建原型的要點是，它應該實現(xiàn)用戶看得見的功能，省略目標系統(tǒng)的“隱含功能。快速原型的特性：“快速。快速原型的目的是盡快向用戶提供一個可在計算機上運行的目標系統(tǒng)的模型。因此，原型的某些缺陷是可以忽略的。“容易修改。如果原型的第一

9、版不是用戶所需要的，就必須根據(jù)用戶的意見迅速地修改它，構(gòu)建出原型的第二版，以更好地滿足用戶需求。如果修改耗時過多，勢必延誤軟件開發(fā)時間。 快速原型通常使用下述3種方法和工具：(1) 第四代技術(shù)4GL第四代技術(shù)包括眾多數(shù)據(jù)庫查詢?nèi)鏢QL和報表語言如ADF、程序和應用系統(tǒng)生成器如Power Builder和Oracle的應用開發(fā)環(huán)境以及其他非常高級的非過程語言。第四代技術(shù)使得軟件工程師能夠快速地生成可執(zhí)行的代碼，它們是較理想的快速原型工具。 第四代技術(shù)特點：簡單易學，用戶界面良好，面向問題、非過程化程度高，用戶只需告知系統(tǒng)做什么，而無需說明怎么做。用4GL編程使用的代碼量較少，并可成數(shù)量級地提高軟

10、件生產(chǎn)率。程序設(shè)計語言劃代：1GL是匯編語言；2GL是高級程序設(shè)計語言，如FORTRAN，ALGOL，BASIC，LISP等；3GL是增強性的高級程序設(shè)計語言，如PASCAL，ALGOL68，F(xiàn)ORTRAN77等；4GL是按計算機科學理論指導設(shè)計出來的結(jié)構(gòu)化語言，如ADA，MODULA2，SMALLTALK80，JAVA，VB，VC，VF等。 (2) 可重用的軟件構(gòu)件另外一種快速構(gòu)建原型的方法，是使用一組已有的軟件構(gòu)件(也稱為組件)來裝配(而不是從頭構(gòu)造)原型。軟件構(gòu)件可以是數(shù)據(jù)結(jié)構(gòu)(或數(shù)據(jù)庫)，或軟件體系結(jié)構(gòu)構(gòu)件(即程序)，或過程構(gòu)件(即模塊)。(3) 形式化規(guī)格說明和原型環(huán)境非形式化方法：

11、自然語言描述半形式化方法：數(shù)據(jù)流圖或?qū)嶓w-聯(lián)系圖形式化方法：基于數(shù)學的技術(shù) 3.3 分析建模與規(guī)格說明3.3.1 分析建模模型：就是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。通常，模型由一組圖形符號和組織這些符號的規(guī)那么組成。結(jié)構(gòu)化分析過程：實質(zhì)上是一種創(chuàng)立模型的活動。系統(tǒng)分析員從不同角度抽象出目標系統(tǒng)的特性，使用精確的表示方法構(gòu)造系統(tǒng)的模型，驗證模型是否滿足用戶對目標系統(tǒng)的需求，并在設(shè)計過程中逐漸把和實現(xiàn)有關(guān)的細節(jié)加進模型中，直至最終用程序?qū)崿F(xiàn)模型。 分析模型的結(jié)構(gòu)需求分析過程應該建立3種模型，分別是：數(shù)據(jù)模型功能模型行為模型 數(shù)據(jù)字典：是分析模型的核心，它描述軟件

12、使用或產(chǎn)生的所有數(shù)據(jù)對象。實體-聯(lián)系圖：描繪數(shù)據(jù)對象及數(shù)據(jù)對象之間的關(guān)系，是用于建立數(shù)據(jù)模型的圖形。數(shù)據(jù)流圖：描繪當數(shù)據(jù)在軟件系統(tǒng)中移動時被變換的邏輯過程，指明系統(tǒng)具有的變換數(shù)據(jù)的功能，因此，數(shù)據(jù)流圖是建立功能模型的根底。狀態(tài)轉(zhuǎn)換圖(簡稱為狀態(tài)圖)：指明了作為外部事件結(jié)果的系統(tǒng)行為。為此，狀態(tài)轉(zhuǎn)換圖描繪了系統(tǒng)的各種行為模式(稱為“狀態(tài))和在不同狀態(tài)間轉(zhuǎn)換的方式。狀態(tài)轉(zhuǎn)換圖是行為建模的根底。 3.3.2 軟件需求規(guī)格說明 通過需求分析除了創(chuàng)立分析模型之外，還應該寫出軟件需求規(guī)格說明書，它是需求分析階段得出的最主要的文檔。通常用自然語言完整、準確、具體地描述系統(tǒng)的數(shù)據(jù)要求、功能需求、性能需求、可靠

13、性和可用性要求、出錯處理需求、接口需求、約束、逆向需求以及將來可能提出的要求。 我國定義了GB856D-1988國家標準，給出了需求規(guī)格說明的內(nèi)容框架：1 引言 1.1 編寫目的 1.2 項目背景（單位和其他系統(tǒng)的關(guān)系） 1.3 定義（專門術(shù)語和縮寫詞）2 任務概述 2.1 目標 2.2 運行環(huán)境 2.3 條件限制3 數(shù)據(jù)描述 3.1 靜態(tài)數(shù)據(jù) 3.2 動態(tài)數(shù)據(jù) 3.3 數(shù)據(jù)庫描述 3.4 數(shù)據(jù)字典 3.5 數(shù)據(jù)采集4 功能需求 4.1 功能劃分 4.2 功能描述5 性能需求 5.1 數(shù)據(jù)精確度 5.2 時間特性 5.3 適應性6 運行需求 6.1 用戶界面 6.2 硬件接口 6.3 軟件接口

14、 6.4 故障處理7 其他需求（檢測或驗收標準、可用性、可維護性、可移植性、安全保密性）練習題：習題3.3，畫數(shù)據(jù)流圖頂層數(shù)據(jù)流圖功能級數(shù)據(jù)流圖細化的數(shù)據(jù)流圖3.4 實體-聯(lián)系圖概念性數(shù)據(jù)模型是一種面向問題的數(shù)據(jù)模型，是按照用戶的觀點對數(shù)據(jù)建立的模型。它描述了從用戶角度看到的數(shù)據(jù)，它反映了用戶的現(xiàn)實環(huán)境，且與在軟件系統(tǒng)中的實現(xiàn)方法無關(guān)。數(shù)據(jù)模型中包含3種相互關(guān)聯(lián)的信息：數(shù)據(jù)對象數(shù)據(jù)對象的屬性數(shù)據(jù)對象彼此間相互連接的關(guān)系 3.4.1 數(shù)據(jù)對象 數(shù)據(jù)對象：是對軟件必須理解的復合信息的抽象。復合信息是指具有一系列不同性質(zhì)或?qū)傩缘氖挛?，僅有單個值的事物不是數(shù)據(jù)對象。數(shù)據(jù)對象可以是外部實體、事物、行為、

15、事件、角色、單位、地點或結(jié)構(gòu)等。數(shù)據(jù)對象彼此間是有關(guān)聯(lián)的。 3.4.2 屬性屬性：定義了數(shù)據(jù)對象的性質(zhì)。必須把一個或多個屬性定義為“標識符 。根據(jù)對問題的理解來確定特定數(shù)據(jù)對象的適宜的屬性。 3.4.3 聯(lián)系聯(lián)系：數(shù)據(jù)對象彼此之間相互連接的方式稱為聯(lián)系，也稱為關(guān)系。聯(lián)系可分為以下3種類型：一對一聯(lián)系(11)一對多聯(lián)系(1N)多對多聯(lián)系(MN)聯(lián)系也可能有屬性。3.4.4 實體-聯(lián)系圖的符號ER圖中包含：實體(即數(shù)據(jù)對象)，用矩形框表示；關(guān)系，用連接相關(guān)實體的菱形框表示；屬性，用橢圓形或圓角矩形表示，并用直線把實體(或關(guān)系)與其屬性連接起來。例1：某校教學管理系統(tǒng)的ER圖ER圖的優(yōu)點：比較接近人

16、的習慣思維方式；用簡單的圖形符號表達系統(tǒng)分析員對問題域的理解，用戶也容易理解，可以作為用戶與分析員之間有效的交流工具。 數(shù)據(jù)建模工具：以自動化的方式創(chuàng)立ER圖、數(shù)據(jù)字典及相關(guān)模型。AllFusion ERWin 輔助設(shè)計數(shù)據(jù)庫、數(shù)據(jù)對象、結(jié)構(gòu)、關(guān)鍵元素ER/Studio 支持實體-關(guān)系建模Oracle Designer 建模、應用系統(tǒng)和數(shù)據(jù)庫設(shè)計Meta Scope 圖形化顯示數(shù)據(jù)Model Sphere Visible Analyst 模型可視化分析例2：習題3.3，銀行儲蓄系統(tǒng)的ER圖 銀行計算機儲蓄系統(tǒng)的工作過程大致如下：儲戶填寫的存款單或取款單由業(yè)務員鍵入系統(tǒng)，如果是存款那么系統(tǒng)記錄存

17、款人姓名、住址(或 號碼)、身份證號碼、存款類型、存款日期、到期日期、利率及密碼(可選)等信息，并印出存單給儲戶；如果是取款而且存款時留有密碼，那么系統(tǒng)首先核對儲戶密碼，假設(shè)密碼正確或存款時未留密碼，那么系統(tǒng)計算利息并印出利息清單給儲戶。銀行儲蓄系統(tǒng)的ER圖 3.5 數(shù)據(jù)標準化數(shù)據(jù)結(jié)構(gòu)標準化：軟件系統(tǒng)經(jīng)常使用各種長期保存的信息，這些信息通常以一定方式組織并存儲在數(shù)據(jù)庫或文件中，為減少數(shù)據(jù)冗余，防止出現(xiàn)插入異?；騽h除異常，簡化修改數(shù)據(jù)的過程，通常需要把數(shù)據(jù)結(jié)構(gòu)標準化。 范式：通常用“范式(normal forms)定義消除數(shù)據(jù)冗余的程度。第一范式(1 NF)數(shù)據(jù)冗余程度最大，第五范式(5 NF)

18、數(shù)據(jù)冗余程度最小。范式級別越高，存儲同樣數(shù)據(jù)需要分解成更多張表，因此，“存儲自身過程越復雜。隨著范式級別的提高，數(shù)據(jù)的存儲結(jié)構(gòu)與基于問題域的結(jié)構(gòu)間的匹配程度也隨之下降，因此，在需求變化時數(shù)據(jù)的穩(wěn)定性較差。范式級別提高那么需要訪問的表增多，因此性能(速度)將下降。第一、第二和第三范式的定義：第一范式，每個屬性值都必須是原子值，即僅僅是一個簡單值而不含內(nèi)部結(jié)構(gòu)。第二范式，滿足第一范式條件，而且每個非關(guān)鍵字屬性都由整個關(guān)鍵字決定(而不是由關(guān)鍵字的一局部來決定)。第三范式，符合第二范式的條件，每個非關(guān)鍵字屬性都僅由關(guān)鍵字決定，而且一個非關(guān)鍵字屬性不能僅僅是對另一個非關(guān)鍵字屬性的進一步描述(即一個非關(guān)鍵

19、字屬性值不依賴于另一個非關(guān)鍵字屬性值)。 3.6 狀態(tài)轉(zhuǎn)換圖狀態(tài)轉(zhuǎn)換圖：通過描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來表示系統(tǒng)的行為。狀態(tài)圖還指明了作為特定事件的結(jié)果系統(tǒng)將做哪些動作(例如，處理數(shù)據(jù))。 3.6.1 狀態(tài) 狀態(tài)：是任何可以被觀察到的系統(tǒng)行為模式，一個狀態(tài)代表系統(tǒng)的一種行為模式。狀態(tài)規(guī)定了系統(tǒng)對事件的響應方式。狀態(tài)主要有：初態(tài)(即初始狀態(tài))，只能有1個終態(tài)(即最終狀態(tài))，可以有0至多個中間狀態(tài)狀態(tài)圖分類：表示系統(tǒng)循環(huán)運行過程，通常不關(guān)心循環(huán)是怎樣啟動的。表示系統(tǒng)單程生命期，需要標明初始狀態(tài)和最終狀態(tài)。3.6.2 事件事件：是在某個特定時刻發(fā)生的事情，它是對引起系統(tǒng)做動作或(和)從

20、一個狀態(tài)轉(zhuǎn)換到另一個狀態(tài)的外界事件的抽象。簡而言之，事件就是引起系統(tǒng)做動作或(和)轉(zhuǎn)換狀態(tài)的控制信息。 3.6.3 符號初態(tài)：用實心圓表示；終態(tài)：用一對同心圓(內(nèi)圓為實心圓)表示；中間狀態(tài)：用圓角矩形表示，分成上、中、下3局部。上面局部-為狀態(tài)的名稱；中間局部-為狀態(tài)變量的名字和值；下面局部-是活動表。 帶箭頭的連線：稱為狀態(tài)轉(zhuǎn)換，箭頭指明了轉(zhuǎn)換方向。 狀態(tài)圖中使用的主要符號活動表的語法格式： 事件名(參數(shù)表)/動作表達式“事件名可以是任何事件的名稱。常用的3種標準事件：entry事件指定進入該狀態(tài)的動作；exit事件指定退出該狀態(tài)的動作；do事件那么指定在該狀態(tài)下的動作。需要時可以為事件指定

21、參數(shù)表?；顒颖碇械膭幼鞅磉_式描述應做的具體動作。 事件表達式的語法： 事件說明守衛(wèi)條件動作表達式事件說明的語法為：事件名(參數(shù)表)。守衛(wèi)條件是一個布爾表達式。如果同時使用事件說明和守衛(wèi)條件，那么當且僅當事件發(fā)生且布爾表達式為真時，狀態(tài)轉(zhuǎn)換才發(fā)生。如果只有守衛(wèi)條件沒有事件說明，那么只要守衛(wèi)條件為真狀態(tài)轉(zhuǎn)換就發(fā)生。動作表達式是一個過程表達式，當狀態(tài)轉(zhuǎn)換開始時執(zhí)行該表達式。 3.6.4 例子例1： 系統(tǒng)例2：銀行儲蓄系統(tǒng)存款過程的狀態(tài)圖例2：銀行儲蓄系統(tǒng)取款過程的狀態(tài)圖3.7 其他圖形工具3.7.1 層次方框圖層次方框圖：用樹形結(jié)構(gòu)的一系列多層次的矩形框描繪數(shù)據(jù)的層次結(jié)構(gòu)。樹形結(jié)構(gòu)的頂層是一個單獨的

22、矩形框，它代表完整的數(shù)據(jù)結(jié)構(gòu)；下面的各層矩形框代表這個數(shù)據(jù)的子集；最底層的各個框代表組成這個數(shù)據(jù)的實際數(shù)據(jù)元素(不能再分割的元素)。某計算機公司的全部產(chǎn)品的層次方框圖3.7.2 Warnier圖Warnier圖：和層次方框圖類似，Warnier圖也用樹形結(jié)構(gòu)描繪信息，但是這種圖形工具比層次方框圖提供了更豐富的描繪手段。特點：用Warnier圖可以說明信息的邏輯組織，也可以表示特定信息在某一類信息中是有條件地出現(xiàn)的。因為重復和條件約束是說明軟件處理過程的根底，所以很容易把Warnier圖轉(zhuǎn)變成軟件設(shè)計的工具。 軟件產(chǎn)品的Warnier圖3.7.3 IPO圖IPO圖：是輸入、處理、輸出圖的簡稱，它

23、是美國IBM公司開展完善起來的一種圖形工具，能夠方便地描繪輸入數(shù)據(jù)、對數(shù)據(jù)的處理和輸出數(shù)據(jù)之間的關(guān)系。根本形式：是在左邊的框中列出有關(guān)的輸入數(shù)據(jù)，在中間的框內(nèi)列出主要的處理，在右邊的框內(nèi)列出產(chǎn)生的輸出數(shù)據(jù)。在IPO圖中還用類似向量符號的粗大箭頭清楚地指出數(shù)據(jù)通信的情況。主文件更新處理的IPO圖改進的IPO圖：這種圖中包含某些附加的信息，在軟件設(shè)計過程中將比原始的IPO圖更有用。在需求分析階段可以使用IPO圖簡略地描述系統(tǒng)的主要算法(即數(shù)據(jù)流圖中各個處理的根本算法)。 IPO表系統(tǒng)：定貨系統(tǒng) 作者：祁燕模塊：處理事務 日期：2010.3編號：1.0被調(diào)用： 定貨系統(tǒng)調(diào)用： 接受事務 更新庫存清單 處理定貨輸入： 事務輸出：定貨信息 庫存清單處理：（用