軟件工程之需求分析涉及的圖與工具

????????需求分析與規格說明書是一項十分艱巨復雜的工作。用戶與分析員之間需要溝通的內容非常的多，在雙方交流信息的過程中很容易出現誤解或遺漏，也可能存在二義性。如何才能更加準確的表達雙方的意思，且清楚明了，繪制各類圖形就顯得非常有必要。

前文基礎：
1.軟件工程學概述：軟件工程學概述-CSDN博客?

2.軟件過程深度解析：軟件過程深度解析-CSDN博客?

一、實體-聯系圖

（一）基本思想與定義

實體 - 聯系圖（Entity-Relationship Diagram，ER 圖）是一種用于描述系統數據模型的圖形化工具，由 Peter Chen 于 1976 年提出。其核心思想是通過實體、屬性和關系三個基本要素，抽象現實世界中的數據對象及其關聯，為數據庫設計提供概念模型。

定義：ER 圖是一種基于實體、屬性和關系的建模工具，用于表示系統的數據結構，明確數據對象的靜態特征及其相互間的聯系，是需求分析階段的重要成果之一。

（二）表示形式與實現過程

1.表示形式：

實體：用矩形框表示，標注實體名稱（如“學生”“課程”）。

屬性：用橢圓表示，通過無向邊連接到實體（如“學生”實體的屬性“學號”“姓名”）。

關系：用菱形表示，標注關系名稱（如“選修”），通過無向邊連接相關實體，邊旁標注關系的基數（如“1:N”“M:N”）。

2.實現過程：

（1）需求分析：通過訪談、問卷等方式獲取用戶數據需求，識別關鍵實體（如“用戶”“訂單”）。

（2）屬性定義：確定每個實體的屬性，區分主鍵（唯一標識實體的屬性，如“學號”）和非主鍵屬性。

（3）關系建模：分析實體間的關聯，確定關系類型（如“學生”與“課程”的“選修”關系為 M:N）。

（4）繪制ER圖：使用工具（如PowerDesigner）繪制ER圖，標注實體、屬性和關系。

驗證與優化：與用戶確認模型的準確性，消除冗余或歧義。

圖1 選課系統的ER圖

（三）具體示例：圖書館管理系統

項目背景：某高校圖書館開發管理系統，需實現圖書借閱、歸還、預約等功能。

流程說明：

1.需求分析：

實體識別：圖書、讀者、借閱記錄、預約記錄。

2.屬性定義：

圖書：ISBN（主鍵）、書名、作者、出版社、庫存數量。

讀者：讀者 ID（主鍵）、姓名、學院、借閱上限。

借閱記錄：記錄 ID（主鍵）、圖書 ISBN（外鍵）、讀者 ID（外鍵）、借閱日期、歸還日期。

3.關系建模：

圖書與讀者的“借閱”關系為M:N，即一個讀者可借閱多本圖書，一本圖書可被多個讀者借閱。

借閱記錄與圖書、讀者的關系為1:1，即一條借閱記錄對應唯一的圖書和讀者。

4.ER 圖繪制：

圖2 圖書館管理系統 ER 圖

5.數據庫映射：

圖書表（ISBN, 書名，作者，出版社，庫存數量）。

讀者表（讀者 ID, 姓名，學院，借閱上限）。

借閱記錄表（記錄 ID, ISBN, 讀者 ID, 借閱日期，歸還日期）。

二、數據規范化

（一）基本思想與定義

數據規范化（Data Normalization）是通過規則將數據庫表結構分解，消除數據冗余和異常（插入、更新、刪除異常），提升數據一致性和存儲效率的過程。其核心思想是遵循范式（Normal Form）逐步優化數據結構。

定義：數據規范化是一種數據庫設計技術，通過應用范式規則，將數據表分解為更小、更穩定的表，減少數據冗余，確保數據依賴的合理性。

（二）表示形式與實現過程

1.表示形式：

范式規則：

（1）1NF（第一范式）：每個屬性為原子值，無重復組。

（2）2NF（第二范式）：在1NF基礎上，非主屬性完全依賴于主鍵。

（3）3NF（第三范式）：在2NF基礎上，消除非主屬性間的傳遞依賴。

依賴關系：

（1）函數依賴：X →?Y，表示屬性 Y 的值由屬性 X 唯一確定。

（2）傳遞依賴：若X →?Y且Y →?Z，則X →?Z（傳遞依賴）。

2.實現過程：

（1）1NF 處理：

拆分重復屬性，確保每個屬性為原子值。

示例：將“課程與成績”列拆分為“課程”和“成績”兩列。

（2）2NF 處理：

消除部分依賴，將部分依賴的屬性移至新表。

示例：選課表（學號，課程號，成績，系別）中，“系別”僅依賴“學號”，拆分為選課表（學號，課程號，成績）和學生表（學號，系別）。

（3）3NF 處理：

消除傳遞依賴，將傳遞依賴的屬性移至新表。

示例：學生表（學號，系別，系主任）中，“系主任”依賴“系別”，拆分為學生表（學號，系別）和系表（系別，系主任）。

（三）具體示例：電商訂單系統

項目背景：某電商平臺優化訂單表結構，解決數據冗余和更新異常問題。

流程說明：

1.初始表結構的SQL：

CREATE TABLE orders (order_id INT PRIMARY KEY,user_id INT,username VARCHAR(50),product_name VARCHAR(100),price DECIMAL(10,2),quantity INT,total DECIMAL(10,2),address VARCHAR(200));

問題：

（1）用戶名重復存儲（同一用戶多次下單）。

（2）產品名稱和價格重復存儲（同一產品多次被購買）。

（3）地址重復存儲（同一用戶多次使用同一地址）。

2.1NF 處理：

確保每個屬性為原子值（已滿足）。

3.2NF 處理：

主鍵為order_id，非主屬性username、product_name、price、address部分依賴于user_id或product_id。

拆分為：

CREATE TABLE users (user_id INT PRIMARY KEY,username VARCHAR(50),address VARCHAR(200));CREATE TABLE products (product_id INT PRIMARY KEY,product_name VARCHAR(100),price DECIMAL(10,2));CREATE TABLE order_items (order_id INT,product_id INT,quantity INT,total DECIMAL(10,2),PRIMARY KEY (order_id, product_id),FOREIGN KEY (order_id) REFERENCES orders(order_id),FOREIGN KEY (product_id) REFERENCES products(product_id));

4.3NF 處理：

檢查傳遞依賴：

（1）users.address依賴user_id，無傳遞依賴。

（2）products.price依賴product_id，無傳遞依賴。

最終表結構符合 3NF。

5.優化效果：

減少數據冗余：用戶名、產品信息、地址僅存儲一次。

消除更新異常：修改用戶地址只需更新users表。

三、狀態轉換圖

（一）基本思想與定義

狀態轉換圖（State Transition Diagram，STD）是一種行為建模工具，通過描繪系統的狀態及觸發狀態轉換的事件，描述系統的動態行為。其核心思想是將系統視為狀態機，狀態間的轉換由事件驅動。

定義：狀態轉換圖是一種圖形化工具，用于表示系統在不同狀態下的行為，以及事件如何觸發狀態之間的轉換。

（二）表示形式與實現過程

1.表示形式：

（1）狀態：用圓角矩形表示，標注狀態名稱（如“閑置”“復印”）。

（2）轉換：用帶箭頭的直線表示，標注事件名稱和動作（如“復印命令 / 開始復印”）。

（3）初始狀態：用實心圓表示，系統初始狀態。

（4）終止狀態：用同心圓表示，系統結束狀態。

圖3 狀態圖中使用的主要符號

2.實現過程：

（1）識別狀態：分析系統行為，確定所有可能的狀態（如電梯控制系統的“待載”“上升”“下降”“樓間停”）。

（2）定義事件：確定觸發狀態轉換的事件（如“進入電梯”“到達目標樓層”）。

（3）繪制轉換：使用工具（如PlantUML）繪制狀態轉換圖，標注事件和動作。

（4）驗證邏輯：檢查狀態轉換的完整性和合理性，確保無死鎖或不可達狀態。

圖4 全自動洗衣機的狀態圖

（三）具體示例：電梯控制系統

項目背景：某寫字樓電梯控制系統需實現樓層選擇、狀態監控等功能。

流程說明：

1.狀態識別：

（1）待載：電梯空閑，停在某一樓層。

（2）上升：電梯向上運行。

（3）下降：電梯向下運行。

（4）樓間停：電梯到達目標樓層，開門等待乘客進出。

2.事件定義：

（1）進入電梯：乘客進入電梯，選擇目標樓層。

（2）到達目標樓層：電梯到達目標樓層，觸發開門。

（3）無人：乘客全部離開電梯，觸發關門。

3.狀態轉換圖繪制：

plantuml工具代碼示例：

@startuml(*) --> 待載待載 --> 上升 : 進入(目標樓層>當前樓層)/關門上行待載 --> 下降 : 進入(目標樓層<當前樓層)/關門下行上升 --> 樓間停 : 到達目標樓層/停機開門下降 --> 樓間停 : 到達目標樓層/停機開門樓間停 --> 上升 : 目標樓層>當前樓層/關門上行樓間停 --> 下降 : 目標樓層<當前樓層/關門下行樓間停 --> 待載 : 無人/關門@enduml

4.邏輯驗證：

電梯在“待載”狀態時，根據目標樓層選擇上升或下降。

到達目標樓層后進入“樓間停”狀態，開門等待乘客進出。

乘客全部離開后返回“待載”狀態。

四、層次方框圖

（一）基本思想與定義

層次方框圖（Hierarchical Block Diagram）是一種樹形結構的圖形工具，用于描述數據或系統的層次分解關系。其核心思想是自頂向下逐步細化，將復雜對象分解為更簡單的子對象。

定義：層次方框圖是一種用矩形框表示數據或模塊，通過連線表示包含關系的圖形工具，用于展示系統的層次結構。

（二）表示形式與實現過程

1.表示形式：

（1）頂層矩形：表示整體對象（如“計算機系統”）。

（2）子矩形：表示子對象，通過連線連接到父矩形（如“硬件”“軟件”“服務”）。

（3）層次關系：逐層分解，直至最底層的基本元素。

圖5 層次方框圖示例

2.實現過程：

（1）確定主題：明確要分解的對象（如“企業 ERP 系統”）。

（2）頂層分解：將主題分解為主要子模塊（如“采購管理”“生產管理”“銷售管理”）。

（3）逐層細化：對每個子模塊進一步分解（如“采購管理”分解為“供應商管理”“訂單管理”“到貨驗收”）。

（4）標注說明：在矩形框內標注模塊名稱或功能描述。

（三）具體示例：企業ERP系統

項目背景：某制造企業開發 ERP 系統，需整合采購、生產、銷售等業務模塊。

流程說明：

1.頂層分解：

企業ERP系統 ?

├─ 采購管理 ?

├─ 生產管理 ?

└─ 銷售管理 ?

2.采購管理細化：

采購管理 ?

├─ 供應商管理 ?

├─ 訂單管理 ?

└─ 到貨驗收 ?

3.生產管理細化：

生產管理 ?

├─ 生產計劃排程 ?

├─ 工單下發 ?

└─ 進度跟蹤 ?

4.銷售管理細化：

銷售管理 ?

├─ 客戶管理 ?

├─ 訂單處理 ?

└─ 物流跟蹤 ?

5.層次方框圖：

企業ERP系統 ?

├─ 采購管理 ?

│ ?├─ 供應商管理 ?

│ ?├─ 訂單管理 ?

│ ?└─ 到貨驗收 ?

├─ 生產管理 ?

│ ?├─ 生產計劃排程 ?

│ ?├─ 工單下發 ?

│ ?└─ 進度跟蹤 ?

└─ 銷售管理 ?

???├─ 客戶管理 ?

???├─ 訂單處理 ?

???└─ 物流跟蹤 ?

圖6 企業ERP系統中采購管理層次方框圖

五、Warnier圖

（一）基本思想與定義

Warnier 圖（Warnier-Orr Diagram）是一種用于描述數據結構或程序邏輯的層次化圖形工具，由Jean-Dominique Warnier提出。其核心思想是通過樹形結構表示數據的層次關系，并支持重復項和條件判斷的標注。

定義：Warnier圖是一種用括號表示層次結構的圖形工具，用于清晰展示數據元素的組成、重復次數及條件關系。

（二）表示形式與實現過程

1.表示形式：

（1）層次結構：用括號表示數據元素的嵌套關系（如(A(B,C))表示 A 包含 B 和 C）。

（2）重復項：用數字標注重復次數（如(B{3})表示 B 重復 3 次）。

（3）條件項：用[條件]標注可選元素（如[B]表示 B 可選）。

圖7 Warnier圖示例

2.實現過程：

（1）數據分解：將復雜數據結構分解為基本元素（如“學生信息”分解為“姓名”“學號”“課程列表”）。

（2）標注重復與條件：確定元素的重復次數和可選性（如“課程列表”可能包含多門課程）。

繪制 Warnier 圖：使用工具或文本符號表示層次關系（如(學生信息(姓名, 學號, (課程{3})))）。

（三）具體示例：學生選課系統

項目背景：某高校學生選課系統需記錄學生信息及所選課程。

流程說明：

1.數據分解：

學生信息包含姓名、學號和課程列表。

課程列表包含多門課程，每門課程有課程號和成績。

2.標注重復與條件：

課程列表最多可選 3 門課程（{3}）。

成績為可選屬性（[成績]）。

3.Warnier 圖繪制：

(學生信息 ?(姓名, ?學號, ?(課程{3} ?(課程號, ?[成績])))) ?

4.數據庫映射：

學生表（學號，姓名）。

課程表（課程號，課程名稱）。

選課表（學號，課程號，成績）。

六、IPO圖

（一）基本思想與定義

IPO 圖（Input-Process-Output Diagram）是一種用于描述模塊輸入、處理和輸出關系的圖形工具，由IBM公司提出。其核心思想是明確模塊的功能邊界，展示數據流動和處理邏輯。

定義：IPO 圖是一種用表格或圖形表示模塊輸入、處理和輸出的工具，用于詳細設計階段的功能描述。

（二）表示形式與實現過程

1.表示形式：

（1）輸入（Input）：列出模塊接收的數據或參數。

（2）處理（Process）：描述模塊的處理邏輯或算法。

（3）輸出（Output）：列出模塊產生的結果或數據。

圖8 IPO圖示例

改進的IPO圖形式，變成IPO表

圖9 IPO表示例

2.實現過程：

（1）確定模塊：明確要描述的模塊（如“用戶登錄模塊”）。

（2）輸入分析：識別模塊的輸入數據（如用戶名、密碼）。

（3）處理設計：描述處理步驟（如驗證用戶名密碼、查詢數據庫）。

（4）輸出定義：確定輸出結果（如登錄成功 / 失敗）。

（三）具體示例：用戶登錄模塊

項目背景：某電商平臺開發用戶登錄功能，需驗證用戶名和密碼。

流程說明：

1.輸入分析：

用戶名（字符串）。

密碼（字符串）。

2.處理設計：

步驟 1：接收用戶名和密碼。

步驟 2：對密碼進行 MD5 加密。

步驟 3：查詢數據庫驗證用戶名和加密后的密碼。

步驟 4：返回驗證結果。

3.輸出定義：

登錄成功：返回用戶權限信息。

登錄失敗：返回錯誤碼。

IPO 圖：

輸入	處理	輸出
用戶名	1. 接收輸入數據	登錄成功：用戶權限
密碼	2. 密碼MD5加密	登錄失敗：錯誤碼
	3. 數據庫查詢驗證
	4. 返回驗證結果

圖10 用戶登錄IPO圖

Java代碼示例：

public class LoginModule {public User authenticate(String username, String password) {// 輸入處理String encryptedPassword = md5Encrypt(password);// 數據庫查詢User user = userDao.findByUsernameAndPassword(username, encryptedPassword);// 輸出結果if (user != null) {return user;} else {throw new AuthenticationException("Invalid username or password");}}}

七、驗證軟件需求

（一）基本思想與定義

驗證軟件需求是確保需求文檔準確、完整、一致且可實現的過程。其核心思想是通過多種方法（如評審、原型、形式化驗證）驗證需求的正確性和可行性。

定義：驗證軟件需求是對需求規格說明書進行審查和測試，確保其滿足用戶需求、技術可行性和項目約束。

（二）表示形式與實現過程

1.表示形式：

（1）需求評審：通過會議形式，由團隊成員和用戶共同審查需求文檔。

（2）原型驗證：構建可運行的原型系統，獲取用戶反饋。

（3）形式化驗證：使用數學模型和邏輯推理證明需求的正確性。

2.實現過程：

（1）需求評審：

準備評審材料（需求文檔、用例圖）。

召開評審會議，記錄問題并修改。

（2）原型驗證：

開發低保真原型（如線框圖）或高保真原型（如可交互界面）。

邀請用戶體驗并收集反饋，迭代優化。

（3）形式化驗證：

使用數學語言（如Z語言）描述需求。

通過模型檢查工具（如SPIN）驗證需求的一致性。

（三）具體示例：在線支付系統

項目背景：某電商平臺開發在線支付功能，需驗證支付流程的正確性。

流程說明：

1.需求評審：

評審內容：支付接口定義、異常處理邏輯。

問題記錄：未明確“支付超時”的處理流程。

修改方案：增加“支付超時”狀態及重試機制。

2.原型驗證：

開發支付流程原型，包含“選擇支付方式→輸入密碼→支付成功 / 失敗”流程。

用戶反饋：密碼輸入框無遮擋提示，存在安全隱患。

優化方案：增加密碼輸入時的遮擋掩碼。

3.形式化驗證：

使用Z語言描述支付狀態機：

PaymentSystem = [state: {idle, processing, success, failed};amount: ?;timeout: ?]processPayment(p: Payment) ≡state = idle ∧amount = p.amount ∧(state' = success ∨ state' = failed)

使用SPIN工具驗證“支付成功后狀態不可回退”的性質。

數學模型：需求覆蓋率計算公式：