第3章需求分析3.1需求分析的任務3.2與用戶溝通獲取需求的方法3.3分析建模與規格說明3.4實體-聯系圖3.5數據規范化3.6狀態轉換圖3.7其他圖形工具3.8驗證軟件需求3.9小結需求分析的意義

軟件需求的深入理解是軟件開發工作獲得成功的前提條件，不論我們把設計和編碼做得如何出色，不能真正滿足用戶需求的程序只會令用戶失望，給開發帶來煩惱。

需求分析是軟件定義時期的最后一個階段，它的基本任務不是確定系統怎樣完成它的工作，而是確定系統必須完成哪些工作，也就是對目標系統提出完整、準確、清晰、具體的要求。并在需求分析階段結束之前，由系統分析員寫出軟件需求規格說明書，以書面形式準確地描述軟件需求。即：

----準確地回答“系統必須做什么?”

在分析軟件需求和書寫軟件需求規格說明書的過程中，分析員和用戶都起著關鍵的、必不可少的作用。

3.1.1確定對系統的綜合要求1、功能需求：劃分出系統必須完成的所有功能。2、性能需求：包括響應時間、信息量的速率、主存容量、磁盤容量、安全性等方面內容。3、可靠性和可用性需求4、出錯處理需求：說明系統對環境錯誤應該怎樣響應。5、接口需求：用戶接口需求、通信接口需求、軟件/硬件接口需求。6、約束：如精度、工具和語言約束、設計約束、應該使用的標準和平臺。7、逆向需求：說明系統不應該做什么。8、將來可能提出的要求：以便將來擴充和修改3.1需求分析的具體任務3.1需求分析的具體任務（續）3.1.2分析系統的數據要求:建立數據模型，用圖形化的工具描述數據結構（如層次方框圖和warnier圖）。3.1.3導出系統的邏輯模型：數據流圖、實體－聯系圖、狀態轉換圖、數據字典等。3.1.4修正系統開發計劃：由分析過程準確地估計系統的成本和進度，修正以前制定的開發計劃。需求分析步驟:獲取需求(3.2節)

分析建模與規格說明(3.3節,3.5節,3.6節,3.7節)驗證軟件需求(3.8節)

3.2與用戶溝通獲取需求的方法3.2.1訪談3.2.2面向數據流自頂向下逐步求精3.2.3簡易的應用規格說明技術3.2.4快速建立軟件原型（它應該實現用戶看得見的功能，原型要具有快速并容易修改的特點）3.2.2面向數據流自頂向下求精結構化分析方法就是面向數據流自頂向下層步求精。提倡用戶與開發者密切合作，共同標識問題，提出解決方案要素，商討不同方案并指定基本需求。進行初步的訪談開發者和用戶雙方組織的代表出席會議每個小組為每張列表中的項目制定小型規格說明根據會議成果起草完整的軟件需求規格說明書3.2.3簡易的應用規格說明技術3.2.4快速建立軟件原型該方法是最準確、最有效、最強大的需求分析技術。快速原型就是快速建立起來的旨在演示目標系統主要功能的可運行的程序。構建原型的要點是，它應該實現用戶看得見的功能(例如，屏幕顯示或打印報表)，省略目標系統的“隱含”功能(例如，修改文件)。應該具備的第一個特性是“快速”。第二個特性是“容易修改”。原型的“修改－試用－反饋”過程可能要重復多次。3.3分析建模與規格說明3.3.1分析建模

模型

----就是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。通常，由一組圖形符號和組織這些符號的規則組成。

建模方法在過去的數年中，人們提出了許多種分析建模的方法，其中兩種在分析建模領域占有主導地位：第一種是結構化分析(StructuredAnalysis，SA)，70年代末由DeMarco等人提出，這是傳統的建模方法。該方法不是被所有的使用者一致地使用的單一方法，眾多科學家對其進行了擴充，因此它是發展了超過30年的一個混合物。（模型由一組圖形符號和組織這些符號的規則組成。結構化分析實質上是一種創建模型的活動。）具體的建模方法/表達方式需求分析過程應該建立3種模型，它們分別是數據模型、功能模型和行為模型。功能模型（面向流的建模）：數據流圖（DFD），指明系統具有的變換數據的功能，是建立功能模型的基礎。數據模型（數據建模）：如實體關系圖（ERD），描繪數據對象及數據對象之間的關系，是用于建立數據模型的圖形。行為模型（基于行為的建模）：

Petri網、狀態圖，指明了作為外部事件結果的系統行為，是行為建模的基礎。3.3.2軟件需求規格說明(SRS)

SoftwareRequirementSpecification

通常用自然語言+模型，完整、準確、具體地描述系統的數據要求、功能需求、性能需求、可靠性和可用性要求、出錯處理需求、接口需求、約束、逆向需求以及將來可能提出的要求。

軟件需求規格說明書，是需求分析階段得出的最主要的文檔。軟件需求說明書的編寫提示（GB-T-8567-2006）3.4實體-聯系圖(ER)

EntityRelationshipDiagramER圖

----是用來建立數據模型的工具。數據模型

----是一種面向問題的數據模型，是按照用戶的觀點對數據建立的模型。它描述了從用戶角度看到的數據，反映了用戶的現實環境，而且與在軟件系統中的實現方法無關。數據模型中包含3種相互關聯的信息：數據對象（實體）、數據對象的屬性及數據對象彼此間相互連接的關系。實體-聯系圖的符號ER圖中包含了實體(即數據對象)、關系和屬性等3種基本成分。通常用矩形框代表實體；用連接相關實體的菱形框表示關系；用橢圓形或圓角矩形表示實體(或關系)的屬性；并用直線把實體(或關系)與其屬性連接起來。舉例圖3.2某校教學管理ER圖對象教師屬性學生屬性課程屬性聯系屬性關系3.5數據規范化為什么數據要規范化？規范化的目的是：消除數據冗余，即消除表格中數據的重復；消除多義性，使關系中的屬性含義清楚、單一；使關系的“概念”單一化，讓每個數據項只是一個簡單的數或字符串，而不是一個組項或重復組；方便操作。使數據的插入、刪除與修改操作可行并方便；使關系模式更靈活，易于實現接近自然語言的查詢方式。3.6狀態轉換圖----行為模型

狀態轉換圖(簡稱為狀態圖)

通過描繪系統的狀態及引起系統狀態轉換的事件，來表示系統的行為。1).狀態

狀態規定了系統對事件的響應方式。系統對事件的響應，既可以是做一個(或一系列)動作，也可以是僅僅改變系統本身的狀態，還可以是既改變狀態又做動作。

初態(即初始狀態)狀態終態(即最終狀態)中間狀態一張狀態圖中只能有一個初態，而終態則可以有0至多個。2).事件事件就是引起系統做動作或(和)轉換狀態的控制信息。

例如，用戶移動或點擊鼠標等都是事件。初態用實心圓表示，終態用一對同心圓(內圓為實心圓)表示。中間狀態用圓角矩形表示，可以用兩條水平橫線把它分成上、中、下3個部分。3).符號活動表（可選）狀態變量的名字和值（可選）狀態的名稱（必須有的）初態終態中間狀態狀態轉換（1）“事件名”可以是任何事件的名稱。在活動表中經常使用下述3種標準事件：entry，exit和do。

entry事件指定進入該狀態的動作，exit事件指定退出該狀態的動作，而do事件則指定在該狀態下的動作。需要時可以為事件指定參數表。（2）動作表達式描述應做的具體動作。3).符號事件名(參數表)/動作表達式活動表的語法格式：事件表達式的語法：

守衛條件是一個布爾表達式，如果既有事件說明又有守衛條件，則當事件發生且守衛條件為真是狀態轉換才發生，如果只有守衛條件沒有事件說明，則守衛條件為真時，發生狀態轉換。事件說明[守衛條件]/動作表達式事件說明：事件名（參數表）動作表達式：當狀態轉換開始時執行該表達式。4).舉例電話系統的狀態圖課堂作業：P73第6題。從問題陳述可知，復印機的狀態主要有“閑置”、“復印”、“缺紙”和“卡紙”。引起狀態轉換的事件主要是“復印命令”、“完成復印命令”、“發現缺紙”、“裝滿紙”、“發生卡紙故障”和“排除了卡紙故障”。3.7其他圖形工具

層次方框圖

Warnier圖

IPO圖3.7.1層次方框圖層次方框圖用樹形結構的一系列多層次矩形框描繪數據的層次結構。樹形結構的頂層是一個單獨的矩形框，它代表完整的數據結構，下面的各層矩形框代表這個數據的子集，最底層的各個框代表組成這個數據的實際數據元素(不能再分割的元素)。隨著結構的精細化，層次方框圖對數據結構也描繪得越來越詳細，這種模式非常適合于需求分析階段的需要。系統分析員從對頂層信息的分類開始，沿圖中每條路徑反復細化，直到確定了數據結構的全部細節時為止。舉例領導層輔助決策系統查詢輔助決策物資信息重點供料信息商情信息人員狀況合同監視財務信息計劃執行情況工程進展情況超儲低儲情況經營指標歷年對比價格預測物資用量預測庫存定額核定庫存結構分析經濟采購批量保本保利分析3.7.2Warnier圖法國計算機科學家Warnier提出了表示信息層次結構的另外一種圖形工具。Warnier圖也用樹形結構描繪信息，但是這種圖形工具比層次方框圖提供了更豐富的描繪手段。用Warnier圖可以表明信息的邏輯組織。它可以指出一類信息或一個信息元素是重復出現的，也可以表示特定信息在某一類信息中是有條件地出現的。重復和條件約束是說明軟件處理過程的基礎，所以很容易把Warnier圖轉變成軟件設計的工具。舉例圖中表示一種軟件產品要么是系統軟件要么是應用軟件。系統軟件中有P1種操作系統，P2種編譯程序，此外還有軟件工具。軟件工具是系統軟件的一種，它又可以進一步細分為編輯程序、測試驅動程序和設計輔助工具，圖中標出了每種軟件工具的數量。3.7.3IPO圖左邊的框中列出有關的輸入數據。中間的框內列出主要的處理，處理框中列出處理的次序暗示了執行的順序，但是用這些基本符號還不足以精確描述執行處理的詳細情況。在右邊的框內列出產生的輸出數據。在IPO圖中還用類似向量符號的粗大箭頭清楚地指出數據通信的情況。一種改進的IPO圖(也稱為IPO表)在需求分析階段可以使用IPO表簡略地描述系統的主要算法(即數據流圖中各個處理的基本算法)。需求分析階段，IPO表中的許多附加信息暫時還不具備，但在設計階段可以進一步補充修正這些圖，作為設計階段的文檔。這正是在需求分析階段用IPO表作為描述算法的工具的重要優點。3.8驗證軟件需求驗證軟件需求的正確性，一般應從4個方面進行：(1)一致性

所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。(2)完整性

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

指定的需求應該是用現有的硬件技術和軟件技術基本上可以實現的。(4)有效性

必須證明需求是正確有效的，確實能解決用戶面對的問題。3.9小結需求分析是發現、求精、建模