195.需求分析

第3章  需求分析

   

• 基本任務是準確地回答：「系統必須作什麼?」 。

       對目標系統提出完整、準確、清晰、具體的要求。

• 系統分析員應該寫出軟件需求規格說明書。

 

需求分析應遵照下述準則：

 

(1) 必須理解並描述問題的信息域，創建數據模型。

(2) 必須定義軟件應完成的功能，創建功能模型。

(3) 必須描述做爲外部事件結果的軟件行爲，創建行爲模型。

(4) 必須對描述信息、功能和行爲的模型進行分解，用層次的方式展現細節。

 

3.1  需求分析的任務

 3.1.1  肯定對系統的綜合要求

1. 功能需求

    指定系統必須提供的服務，劃分出系統必須完成的全部功能。

2. 性能需求

    指定系統必須知足的定時約束或容量約束，一般包括速度(響應時間)、信息量速率、主存容量、磁盤容量、安全性等方面的需求。

3. 可靠性和可用性需求

4. 出錯處理需求

    當應用系統發現它本身犯下一個錯誤時所採起的行動。可是，僅限於對系統的關鍵部分有選擇地提出這類出錯處理需求。

5. 接口需求

    描述應用系統與它的環境通訊的格式。 

    常見的接口需求有：用戶接口需求；硬件接口需求；軟件接口需求；通訊接口需求。

6. 約束

    描述在設計或實現應用系統時應遵照的限制條件。

    常見的約束有：精度；工具和語言約束；設計約束；應該使用的標準；應該使用的硬件平臺。

7. 逆向需求

    說明軟件系統不該該作什麼。

    用於澄清真實需求，消除可能發生的誤解的那些逆向需求。

8. 未來可能提出的要求

    對系統未來可能的擴充和修改預作準備。

 

3.1.2  分析系統的數據要求

這是軟件需求分析的一個重要任務。

    一般採用創建數據模型的方法(ER圖)。

表示方法：

    數據結構（表示數據元素之間的邏輯關係）

    數據字典（不夠形象直觀）

    層次方框圖和Warnier圖（3.7節介紹）

存儲方式：

    數據庫或文件。

 

3.1.3  導出系統的邏輯模型

• 綜合上述兩個步驟的結果導出系統的邏輯模型

• 用如下工具描述

    數據流圖

    實體聯繫圖

    狀態轉換圖

    數據字典

    主要的處理算法

 

3.1.4  修正系統開發計劃

•修正可行性分析中制定的開發計劃

•估計比較準確的系統成本和進度

 

3.2  與用戶溝通獲取需求的方法

3.2.1 訪談

• 正式

• 非正式

• 調查表

• 情景分析技術

 

3.2.2  面向數據流自頂向下求精

    結構化分析方法就是面向數據流自頂向下逐步求精進行需求分析的方法。

• 可行性研究得出的是目標系統的高層數據流圖

• 需求分析的目標之一就是把數據流和數據存儲定義到元素級。

•  從數據流圖的輸出端着手分析，輸出數據決定了系統必須具備的最基本的組成元素。

　　輸出數據組成元素經過調查訪問不難搞清。

       每一個輸出數據元素又是從哪裏來的呢?

       或者是從外面輸入到系統中來，或者是經過計算由系統中產生出來的。

• 從輸出端往輸入端回溯，可肯定每一個數據元素的來源，及有關的算法。

    可是，高層數據流圖中許多細節沒有包括，所以回溯時經常遇到下述問題：

         某個數據元素須要用到數據流圖中目前尚未的數據元素，

         或者得出這個數據元素須要用的算法尚不徹底清楚。

• 數據元素納入數據字典

• 算法記錄在IPO圖中

• 增補數據流圖

• 請用戶複查

    複查過程驗證了已知的元素，補充了未知的元素，填補了文檔中的空白。

• 追蹤更詳細的數據流，把數據流圖擴展到更低的層次。經過功能分解完成數據流圖的細化。

    在分析追蹤時可能產生新的問題，這些問題的答案可能又在數據字典中增長一些新條目，或產生新的或精化的算法描述。

    最終獲得對系統數據和功能要求的滿意瞭解。

   下頁圖3.1粗略地歸納了上述分析過程。

 

 

圖3.1 面向數據流自頂向下求精過程

 

3.2.3  簡易的應用規格說明技術

    爲了解決上述問題，人們研究出一種面向團隊的需求收集法，稱爲簡易的應用規格說明技術。

    這種方法提倡用戶與開發者密切合做，商討不一樣方案並指定基本需求。

•初步訪談，肯定問題和解決方案

•開發者和用戶分別寫「產品需求」

•開會前，將「產品需求」分發

•每一個人審查「產品需求」，列出系統對象

•開會，合併對象（消去冗餘），獲得意見一致的列表

•分小組討論，制定小型規格說明

•綜合討論，起草軟件規格說明書

 

3.2.4  快速創建軟件原型

•快速原型就是快速創建起來的旨在演示目標系統主要功能的可運行的程序。其特性：

      快速

      容易修改

•爲了快速地構建和修改原型，一般使用下述3種方法和工具：

    第四代技術（使得軟件工程師可以快速地生成可執行的代碼，是較理想的快速原型工具）

    可重用的軟件構件（使用一組已有的軟件構件來裝配原型）

    形式化規格說明和原型環境（調用自動工具把基於形式語言的規格說明翻譯成可執行的程序代碼）

 

3.3  分析建模與規格說明  

3.3.1  分析建模

    爲了更好地理解復瑣事物，人們經常採用創建事物模型的方法。

    所謂模型，是爲了理解事物而對事物作出的一種抽象，是一種無歧義的書面描述。

    模型由一組圖形符號和組織這些符號的規則組成。

 

    根據結構化分析準則，需求分析過程應該創建3種模型，它們分別是數據模型、功能模型和行爲模型。

數據模型

實體－聯繫圖，描繪數據對象及數據對象之間的關係，用於創建數據模型。

功能模型

數據流圖，描繪當數據在軟件系統中移動時被變換的邏輯過程，指明系統具備變化數據的功能，是創建功能模型的基礎。

行爲模型

3.6節狀態轉換圖（狀態圖），指明做爲外部事件結果的系統行爲。描繪了系統的各類行爲模式(稱爲「狀態」)和在不一樣狀態間轉換的方式。是行爲建模的基礎。

 

3.3.2  軟件需求規格說明

    是需求分析階段得出的最主要的文檔。

•   用天然語言完整、準確、具體地描述系統的數據要求、功能需求、性能需求、可靠性和可用性要求、出錯處理需求、接口需求、約束、逆向需求以及未來可能提出的要求。

•  天然語言的規格說明具備容易書寫、容易理解的優勢，爲大多數人所歡迎和採用。

 

 3.4 實體——聯繫圖

數據模型中包含3種相互關聯的信息：數據對象、數據對象的屬性及數據對象彼此間相互鏈接的關係。

3.4.1 數據對象

數據對象是對軟件必須理解的複合信息的抽象。

數據對象能夠是外部實體、事物、行爲、事件、角色、單位、地點或結構等。總之，能夠由一組屬性來定義的實體均可以被認爲是數據對象。

3.4.2 屬性

屬性定義了數據對象的性質。
必須把一個或多個屬性定義爲「標識符」，也就是說，當人們但願找到數據對象的一個實例時，用標識符屬性做爲「關鍵字」(一般簡稱爲「鍵」)。

3.4.3 聯繫

客觀世界中的事物彼此間每每是有聯繫的。
數據對象彼此之間相互鏈接的方式稱爲聯繫，也稱爲關係。聯繫可分爲如下3種類型。

一對一聯繫(1∶1)
一對多聯繫(1∶N)
多對多聯繫(M∶N)

(1) 一對一聯繫(1∶1)
例如，一個部門有一個經理，而每一個經理只在一個部門任職，則部門與經理的聯繫是一對一的。
(2) 一對多聯繫(1∶N)
例如，某校教師與課程之間存在一對多的聯繫「教」，即每位教師能夠教多門課程，可是每門課程只能由一位教師來教(見圖3.2)。
(3) 多對多聯繫(M∶N)
例如，圖3.2表示學生與課程間的聯繫(「學」)是多對多的，即一個學生能夠學多門課程，而每門課程能夠有多個學生來學。

 

 

 

3.4.四、實體聯繫圖的符號

一般，使用實體聯繫圖(entityrelationship diagram)來創建數據模型。能夠把實體聯繫圖簡稱爲ER圖，相應地可把用ER圖描繪的數據模型稱爲ER模型。

ER圖中包含了實體(即數據對象)、關係和屬性3種基本成分，一般用矩形框表明實體，用鏈接相關實體的菱形框表示關係，用橢圓形或圓角矩形表示實體(或關係)的屬性，並用直線把實體(或關係)與其屬性鏈接起來。

ER模型能夠做爲用戶與分析員之間有效的交流工具。

 

 

 3.5  數據規範化

 

    軟件系統常用的各類長期保存的信息，一般以必定方式組織並存儲在數據庫或文件中，爲減小數據冗餘，避免出現插入異常或刪除異常，一般須要把數據結構規範化。

3.6  狀態轉換圖

    用於創建軟件系統的行爲模型。

    經過描繪系統的狀態及引發系統狀態轉換的事件，來表示系統的行爲。

    此外，還指明瞭做爲特定事件的結果系統將作哪些動做(例如，處理數據)。

    所以，狀態圖提供了行爲建模機制。

3.6.1  狀態

狀態：

    是任何能夠被觀察到的系統行爲模式，一個狀態表明系統的一種行爲模式。

在狀態圖中定義的狀態主要有：

    初態(即初始狀態)、終態(即最終狀態)和中間狀態。

    在一張狀態圖中只能有一個初態，而終態則能夠有0至多個。

    當描繪單程生命期時，須要標明

        初始狀態(系統啓動時進入初始狀態)和

        最終狀態(系統運行結束時到達最終狀態)。

     描繪循環運行過程時沒必要。

3.6.2  事件

    事件是在某個特定時刻發生的事情，它是對引發系統作動做或(和)從一個狀態轉換到另外一個狀態的外界事件的抽象。

    例如，內部時鐘代表某個規定的時間段已通過去，用戶移動或點擊鼠標等都是事件。

    簡而言之，事件就是引發系統作動做或(和)轉換狀態的控制信息。

3.6.3  符號

初態用實心圓表示，

終態用一對同心圓(內圓爲實心圓)表示。

中間狀態用圓角矩形表示，

    能夠用兩條水平橫線把它分紅上、中、下3個部分。

   上面部分爲狀態的名稱，這部分是必須有的；

   中間部分爲狀態變量的名字和值，這部分是可選的；

   下面部分是活動表，這部分也是可選的。

 

 

 

活動表的語法格式：事件名(參數表)/動做表達式

• 「事件名」能夠是任何事件的名稱。

    常用下述3種標準事件：entry，exit和do。

        entry指定進入該狀態的動做，

        exit指定退出該狀態的動做，

        do指定在該狀態下的動做。

• 須要時能夠爲事件指定參數表。

• 動做表達式描述應作的具體動做。

• 兩個狀態之間帶箭頭的連線稱爲狀態轉換，箭頭指明瞭轉換方向。

   狀態變遷一般是由事件觸發的，在狀態轉換的箭頭線上標出觸發轉換的事件表達式；若是在箭頭線上未標明事件，則表示在源狀態的內部活動執行完以後自動觸發轉換。

 

事件表達式的語法以下：

事件說明［守衛條件］／動做表達式

• 事件說明的語法爲：事件名(參數表)。

• 守衛條件是一個布爾表達式。

    若是同時使用事件說明和守衛條件，則當且僅當事件發生且布爾表達式爲真時，狀態轉換才發生。

    若是隻有守衛條件沒有事件說明，則只要守衛條件爲真狀態轉換就發生。

• 動做表達式是一個過程表達式，當狀態轉換開始時執行該表達式。

3.6.4  例子

圖3.4（見書57頁）

    沒有人打電話時電話處於閒置狀態；

    有人拿起聽筒則進入撥號音狀態，到達這個狀態後，電話的行爲是響起撥號音並計時；

    這時若是拿起聽筒的人改變主意不想打了，他把聽筒放下(掛斷)，電話重又回到閒置狀態；

    若是拿起聽筒很長時間不撥號(超時)，則進入超時狀態；……。

 

 

3.7  其餘圖形工具  

3.7.1  層次方框圖

    用樹形結構的一系列多層次的矩形框描繪數據的層次結構。

    樹形結構頂層的矩形框，表明完整的數據結構，

    下面的各層矩形框表明這個數據的子集，

    最底層的各個框表明組成這個數據的實際數據元素(不能再分割的元素)。

    例如，描繪一家計算機公司所有產品的數據結構能夠用圖3.5中的層次方框圖表示。

 

 

 

圖3.5 層次方框圖的一個例子

 

 3.7.1  層次方框圖

 

 

    從對頂層信息的分類開始，沿圖中每條路徑反覆細化，直到肯定了數據結構的所有細節時爲止。

3.7.2  Warnier圖

    表示信息層次結構的另一種圖形工具。

    但這種圖形工具比層次方框圖提供了更豐富的描繪手段。

用Warnier圖能夠代表信息的邏輯組織，

    它能夠指出一類信息或一個信息元素是重複出現的，

    也能夠表示特定信息在某一類信息中是有條件地出現的。

 

 圖3.6中的Warnier圖表示

    一種軟件產品要麼是系統軟件要麼是應用軟件。

    系統軟件中有P1種操做系統，P2種編譯程序，此外還有軟件工具。

    軟件工具是系統軟件的一種，它又能夠進一步細分爲編輯程序、測試驅動程序和設計輔助工具，並標出了每種軟件工具的數量。

 

 

圖3.6 Warnier圖的一個例子

3.7.3  IPO圖

    IPO圖是輸入、處理、輸出圖的簡稱，它是美國IBM公司發展完善起來的一種圖形工具，可以方便地描繪輸入數據、對數據的處理和輸出數據之間的關係。

    IPO圖使用的基本符號既少又簡單，所以很容易學會使用這種圖形工具。

    在左邊的框中列出有關的輸入數據，

    在中間的框內列出主要的處理，

    在右邊的框內列出產生的輸出數據。

    處理框中列出處理的次序暗示了執行的順序。

    在IPO圖中還用粗大箭頭指出數據通訊的狀況。

   

圖3.7是一個主文件更新的例子，經過這個例子不難了解IPO圖的用法。

 

 

 

圖3.7 IPO圖的一個例子圖

    建議使用一種改進的IPO圖(也稱爲IPO表)，圖中包含某些附加的信息，比原始的IPO圖更有用。如圖3.8所示。

    在需求分析階段可使用IPO圖簡略地描述系統的主要算法(即數據流圖中各個處理的基本算法)。

   當許多附加信息暫時還不具有時，在軟件設計階段能夠進一步補充修正這些圖，做爲設計階段的文檔。

    這正是在需求分析階段用IPO圖做爲描述算法的工具的重要優勢。

 

 

圖3.8 改進的IPO圖的形式

3.8  驗證軟件需求  

3.8.1  從哪些方面驗證軟件需求的正確性

    軟件系統中15%的錯誤起源於錯誤的需求。

通常說來，應該從下述4個方面進行驗證：

(1) 一致性：全部需求必須是一致的，任何一條需求不能和其餘需求互相矛盾。

(2) 完整性：需求必須是完整的，規格說明書應該包括用戶須要的每個功能或性能。

(3) 現實性：指定的需求應該是用現有的硬件技術和軟件技術基本上能夠實現的。

(4) 有效性：必須證實需求是正確有效的，確實能解決用戶面對的問題。

3.8.2  驗證軟件需求的方法

1. 驗證需求的一致性

•人工審查（正確性不能保證）

•形式化描述軟件需求的方法：當軟件需求規格說明書是用形式化的需求陳述語言書寫時，能夠用軟件工具驗證需求的一致性。

2. 驗證需求的現實性

• 經驗

• 應該採用仿真或性能模擬技術，輔助分析軟件需求規格說明書的現實性。

3. 驗證需求的完整性和有效性

• 用戶是需求的權威，可是不能很好表達本身的需求

• 根據需求開發一個軟件系統，用戶試用，成本翻倍

• 創建快速原型系統，使用戶提出更符合實際的要求

 

3.8.3  用於需求分析的軟件工具

     爲了有效地保證軟件需求的正確性，特別是一致性，須要有適當的軟件工具支持需求分析工做。

這類軟件工具應該知足下列要求：

(1) 必須有形式化的語法(或表)，使能夠用計算機自動處理使用這種語法說明的內容；

(2) 使用這個軟件工具可以導出詳細的文檔；

(3) 必須提供分析(測試)規格說明書的不一致性和冗餘性的手段，而且應該可以產生一組報告指明對完整性分析的結果；

(4) 使用這個軟件工具以後，應該可以改進通訊情況。