軟件工程導論—軟件需求分析

1. 需求分析概述

1.1. 軟件需求的概念

軟件需求就是用戶對目標軟件系統的期望。

爲了開發出真正滿足用戶需求的軟件產品，首先必須知道用戶的需求。對軟件需求的深入理解是軟件開發工作獲
得成功的前提條件，不論人們把設計和編碼工作做得如何出色，不能真正滿足用戶需求的程序只會令用戶失望,
並且給開發者帶來煩惱。

需求分析是軟件定義時期的最後一個階段，它的基本任務是準確地回答"系統必須做什麼"這個問題，最終的成品是一份"軟件需求規格說明書"。

通常來說，用戶的需求包含了以下幾個方面：

1. 功能需求
   這方面的需求指定系統必須提供的服務。通過需求分析應該劃分出系統必須完成的所有功能
2. 性能需求
   性能需求指定系統必須滿足的定時約束或容量約束，通常包括速度(響應時間)、信息量速率、主存容量、磁盤容量、安全性等方面的需求。
3. 可靠性和可用性需求
   可靠性需求定量地指定系統的可靠性，可用性與可靠性密切相關，它量化了用戶可以使用系統的程度。
4. 出錯處理需求
   這類需求說明系統對環境錯誤應該怎樣響應。例如，如果它接收到從另一個系統發來的違反協議格式的消息，應該做什麼。需要注意的是，這類錯誤並不是由該應用系統本身造成的。
5. 接口需求
   接口需求描述應用系統與它的環境通信的格式。常見的接口需求有：用戶接口需求、硬件接口需求、軟件接口需求、通信接口需求。
6. 約束
   設計約束或實現約束描述在設計或實現應用系統時應遵守的限制條件。常見的約束有：精度、工具和語言約束、設計約束、應該使用的標準、應該使用的硬件平臺。
7. 逆向需求
   逆向需求說明軟件系統不應該做什麼。理論上有無限多個逆向需求，人們應該僅選取能澄清真實需求且可消除可能發生的誤解的那些逆向需求。
8. 將來可能提出的要求
   應該明確地列出那些雖然不屬於當前系統開發範疇，但是據分析將來很可能會提出來的要求。這樣做的目的是，在設計過程中對系統將來可能的擴充和修改預做準備，以便一旦確實需要時能比較容易地進行這種擴充和修改。

1.2. 需求分析的準則

儘管目前有許多不同的用於需求分析的結構化分析方法，但是，所有這些分析方法都遵守下述準則。

1. 必須理解並描述問題的信息域，根據這條準則應該建立數據模型
   主要使用ERD工具，即實體—聯繫圖，描繪數據對象及數據對象之間的關係，是用於建立數據模型的圖形；
2. 必須定義軟件應完成的功能，這條準則要求建立功能模型
   主要使用DFD工具，即數據流圖，描繪當數據在軟件系統中移動時被變換的邏輯過程，指明系統具有的變換數據的功能，是建立功能模型的基礎；
3. 必須描述作爲外部事件結果的軟件行爲，這條準則要求建立行爲模型
   主要使用STD工具，即狀態轉換圖，指明瞭作爲外部事件結果的系統行爲，描繪了系統的各種行爲模式(稱爲"狀態")和在不同狀態間轉換的方式，是行爲建模的基礎；
4. 必須對描述信息、功能和行爲的模型進行分解，用層次的方式展示細節。

1.3. 需求分析的任務和步驟

需求分析的任務有：

1. 建立分析模型
2. 編寫需求說明

需求分析的步驟有：

1. 問題分析
2. 需求描述
3. 需求評審

關於需求分析的任務，可以用下圖來表示建立分析模型的過程：

2. 需求獲取的常用方法和步驟

1. 聯合分析小組
   由用戶代表、領域專家和系統分析員組成聯合分析小組對用戶需求進行分析
2. 客戶訪談
   充分準備，尋找共同語言，循序漸進、逐步逼近地引導客戶提出和細化需求。訪談是最早開始使用的獲取用戶需求的技術，也是迄今爲止仍然廣泛使用的需求分析技術。訪談有兩種基本形式，分別是正式的和非正式的訪談。
   正式訪談時，系統分析員將提出一些事先準備好的具體問題，例如，詢問客戶公司銷售的商品種類、僱用的銷售人員數目以及信息反饋時間應該多快等。在非正式訪談中，分析員將提出一些用戶可以自由回答的開放性問題，以鼓勵被訪問人員說出自己的想法，例如，詢問用戶對目前正在使用的系統有哪些不滿意的地方。
   訪談有兩種基本形式，分別是正式的和非正式的訪談。正式訪談時，系統分析員將提出一些事先準備好的具體問題，非正式訪談中，分析員將提出一些用戶可以自由郵答的開放性問題，以鼓勵被訪問人員說出自己的想法。在訪問用戶的過程中使用情景分析技術往往非常有效。所謂情景分析就是對用戶將來使用目標系統解決某個具體問題的方法和結果進行分析。
   情景分析技術的用處主要體現在下述兩個方面：
   （1）它能在某種程度上演示目標系統的行爲，從而便於用戶理解，而且還可能進一步揭示出一些分析員目前還不知道的需求。
   （2）由於情景分析較易爲用戶所理解，使用這種技術能保證用戶在需求分析過程中始終扮演一個積極主動的角色。
3. 實際觀察用戶工作流程
4. 問題分析與確認

3. 分析建模

3.1. 結構化分析模型

3.1.1. 結構化分析模型概述

結構化分析模型可以用下面一張圖來概括：

從圖中可以看出，結構化分析模型的核心是數據字典，其分析的三個方面：數據對象、加工和控制，分別用E-R圖、DFD、CFD和STD來描述。

結構化分析模型常用的分析工具有

1. DFD、DD、PSPEC
   數據流圖（DFD） 是描述系統信息在系統中的流動和處理的邏輯模型，它可以是用來交流信息的工具，也可以是結構化分析和設計的工具；
   數據字典（DD） 是 DFD中所有元素的定義的集合，它的內容包括：數據流、數據存儲和處理。DD一般用作分析階段的交流工具和數據庫設計的基礎；
   加工說明（PSPEC） 用來詳細說明DFD中的每個加工（處理）。

2. CFD、CSPEC、STD
   控制流圖（CFD）和控制加工圖（CSPEC） 適用於實時系統的分析，相互配合使用；
   狀態轉換圖（STD） 通過描繪系統的狀態及引起系統狀態轉換的事件，來表示系統的行爲模型。狀態是任何可以被觀察到的系統行爲模式，一個狀態代表系統的一種行爲模式。狀態規定了系統對事件的響應方式。在狀態圖中定義的狀態主要有：初態(即初始狀態)、終態(即最終狀態)和中間狀態。在一張狀態圖中只能有一個初態，而終態則可以有0至多個。
   一個典型的狀態轉換圖框架如圖所示：
   

3. E-R圖，用來描述數據

對以上的結構化分析工具有所瞭解之後，下面我們就可以更好地理解結構化分析方法的操作步驟：

1. 自頂向下，功能分解，使用分層DFD、
2. 由後向前，定義數據和加工，使用DD, PSPEC
3. 根據需要，分析複雜數據和動態模型，使用E-R圖，CFD，CSPEC，STD
4. 編寫SRS

3.1.2. 實體聯繫圖 E-R圖

實體-聯繫圖是一種概念性的數據模型，其數據對象是可以由一組屬性來定義的實體；屬性定義了數據對象的性質，數據對象彼此之間相互連接的方式稱爲聯繫，聯繫包含3種類型：

1. 一對一聯繫(1: 1)
2. 一對多聯繫(1: n)
3. 多對多聯繫(m: n)

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

例如如下的E-R圖

其中有四個數據對象：
“教師”（教工號，姓名，性別，職稱，職務）
“學生”（學號、姓名、性別、系、年級）
“課程”（課程號、課名，學時，學分）
“學”（學號，課程號，成績）
其中教師與課程是一對多聯繫、教師與學生是一對多聯繫、學生與課程是多對多聯繫，"學"這個數據對象是從學生-課程關係中派生出來的，因爲關係型數據庫無法處理多對多類型的聯繫，必須把多對多轉換爲一對多。

數據規範化
軟件系統經常使用各種長期保存的信息，這些信息通常以一定方式組織並存儲在數據庫或文件中，爲減少數據冗餘，避免出現插入異常或刪除異常，簡化修改數據的過程，通常需要把數據結構規範化。

通常用"範式(Normal Forms)"定義消除數據冗餘的程度。第一範式(1NF)數據冗餘程度最大，第五範式(5NF)數據冗餘程度最小。

但通常來說在實際設計數據庫時只採用到第三範式就足夠了，範式並非越高越好，要結合實際情況使用，原因是：

1. 範式級別越高，存儲同樣數據就需要分解成更多張表，對數據庫的編程就越麻煩；
2. 隨着範式級別的提高，數據的存儲結構與基於問題域的結構間的匹配程度也隨之下降，因此，在需求變化時數據的穩定性較差；
3. 範式級別提高則需要訪問的表增多，導致性能下降,

3.1.3. 數據流圖 DFD

DFD是描述系統信息在系統中的流動和處理的邏輯模型，它可以是用來交流信息的工具，也可以是結構化分析和設計的工具。

如下面的頂級DFD所示，展示的是一個"教材購銷系統"的外部界面，該圖中有兩個外部實體"學生"、“書庫管理員”，"學生"把購書單交給系統，然後從系統拿到領書單；書庫管理員從系統獲取到缺書單，然後給系統發送進書通知。

進一步將頂級數據流圖展開爲一級數據流圖，如下，其中銷售和採購還可以再度分解。

3.1.4. 結構化分析方法

結構化方法的基本思想和主要原則在系統分析中的應用所形成的一系列具體方法和有關工具的總稱。所謂結構化，就是用一組規範的步驟、準則和工具來進行某項工作。

它主要是爲了解決早期軟件開發過程中存在的一些主要問題，例如：

1. 工作階段劃分不明確，各階段的工作缺乏規範的章程、方法、表達工具與標準。用戶參與程度低，用戶與專業人員對話缺乏有效手段；
2. 系統分析、設計工作不深入，工作任務集中在了系統實施階段；
3. 系統實施採用"自底向上"的方法，系統總體功能與目標的實現難以保證。

結構化分析方法的基本思路是基本思路：把整個系統開發過程分成若干階段，每個階段進行若干活動，每項活動應用一系列標準、規範、方法和技術，完成一個或者多個任務，形成符合給定規範的產品。

在進行結構化分析時，主要遵循如下原則

1. 用戶參與
2. “先分析、後編碼”：重視調查、分析、論證，邏輯方案設計；
3. “自頂向下”："自頂向下"是主導原則，"自底向上"是輔助原則；
4. 工作成果描述標準化：文檔化、圖形化。

3.2. 面向對象分析模型

面向對象分析模型可以用下面一張圖來概括：

可以看出，面向對象分析模型分爲三個部分：類/對象模型、對象-關係模型、對象-行爲模型

面向對象分析模型常用的分析工具有

1. 用例圖、類對象圖
2. 對象-關係圖，用來表示靜態關係
3. 對象-行爲圖，用來表示動態關係

在掌握以上分析工具的基礎上，按照下面的步驟進行面向對象分析

1. 定義系統的用例
2. 領域分析，建立類對象模型
3. 建立對象-關係模型
4. 建立對象-行爲模型
5. 編寫SRS

4. 軟件需求說明 SRS

4.1. 需求規格說明

寫需求規格說明的目標是爲了便於用戶、分析人員、設計人員進行交流，並且支持目標軟件系統的確認，控制系統進化過程(追加需求)

4.2. 驗證軟件需求

需求分析階段的工作結果是開發軟件系統的重要基礎,大量統計數字表明，軟件系統中15%的錯誤起源於錯誤的需求。

爲了提高軟件質量，確保軟件開發成功，降低軟件開發成本，一旦對目標系統提出一組要求之後，必須嚴格驗證
這些需求的正確性。一般說來，應該從下述4個方面進行驗證。

1. 一致性。所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾；
2. 完整性。需求必須是完整的，規格說明書應該包括用戶需要的每一個功能或性能；
3. 現實性。指定的需求應該是用現有的硬件技術和軟件技術基本上可以實現的；
4. 有效性。必須證明需求是正確有效的，確實能解決用戶面對的問題。