上一篇博客寫了uml在軟件開發過程中的應用，這以篇要詳細介紹一下UML在需求分析過程中的應用。
以機房收費系統為例進行講解，先介紹一個該系統。
首先該系統的用戶分為三個等級，一般用戶，操作員，管理員，一般用戶的權限，能夠查看學生余額，充值記錄，上機記錄，學生上機狀態查看等。操作員可以進行學生注冊，充值，退卡，收取金額查詢，學生退卡查詢，學生基本信息的維護，查看操作員的工作記錄。管理員負責對上機的一些基本數據的設定，結賬。添加，刪除用戶，查看日結賬單，周結賬單。首先看一下設備連接圖：
讀卡器的工作就是讀取卡的id號，並觸發系統中一次enter 事件。
工作流程就是，
主要的流程就是這五個步驟，其他的在這個過程中，或者以后都可以進行實現。
一．用戶需求：
了解了工作過程之后，就可以開始獲取用戶需求了，所以開始進行需求分析。
通過了解，與系統相關的人員主要有以下幾種，
（1） 學生。提供細心給操作員，進行注冊。拿着卡進行刷卡上下機。
（2） 一般用戶。能夠查看學生余額，充值記錄，上機記錄，學生上機狀態查看，強制下機。
（3） 操作員。學生注冊，充值，退卡，收取金額查詢，學生退卡查詢，學生基本信息的維護，查看操作員的工作記錄。
（4） 管理員。基本數據的設定，結賬。添加，刪除用戶，查看日結賬單，周結賬單的打印。
（5） 系統開發人員。負責開發機房收費系統的項目組成員。
（6） 機房主任。查看所有賬務項目。
備注：在收集用戶的需求時，要考慮到關心軟件系統開發所有人員的需求，不僅要了解最終用戶的需求，還有了解其他使用系統的需求，（如機房主任），還要了解軟件開發人員的需求。
二．需求分析與描述
首先要對用戶提出的需求進行分析，以此來確定其中要實現的系統功能，然后再同用戶進行更加深入的討論交流，確定哪些需求是功能性，那些是非功能性的，哪些是軟件系統的需求，哪些不是，哪些需求是可以實現的，哪些需求是無法實現或暫時無法實現。
由於需求過多，所以以其中的一條需求為例
需求原文：操作員的學生注冊功能。
操作員需要對學校所有要上機的學生進行注冊，注冊的內容包括姓名，性別，學號，班級，年級，備注，和每個學生卡的卡號。他是機房收費系統中最基本的一項需求，在開發的過程中，要認真的進行考慮。
將所有的需求分析進行完成以后，得到了用戶需求分析結構，為了更好的表示一般采用表格的形式：（這里不全部例出）
表（1）
| 序號 |
用戶需求 |
軟件需求 |
功能需求 |
可以實現 |
| 01 |
提供自己關於注冊卡的所有信息給操作員，進行注冊 |
否 |
否 |
可以 |
| 02 |
查看學生卡內的余額 |
是 |
是 |
可以 |
| 03 |
學生卡注冊 |
是 |
是 |
可以 |
| 04 |
設定上機需要的基本數據 |
是 |
是 |
可以 |
| . |
…. |
…… |
… |
… |
三．用例分析
在需求分析完成后，開始進行用例分析，為了能夠正確的找出系統的用例，需要確定系統的邊界，找出系統的執行者。根據表1的需求結果進行用例分析。
1. 系統的邊界
從需求中可以看出，學生可以將卡放在讀卡器上進行讀取信息，讀卡器將信息發送到系統中，並觸發enter事件。
這時要考慮機房收費系統是否包括讀卡器。機房收費系統是一個軟件系統，因此不包括讀卡器。
2. 系統的執行者
有了系統的邊界，就可以更容易的找出系統的執行者，從系統的邊界中可以知道讀卡器是系統的執行者。
執行者主要分析每一個操作是由誰來執行的。由需求描述可以看出，用例的執行者還有，一般用戶，操作員，管理員。所有該系統總共有四個執行者。讀卡器，一般用戶，操作員，管理員。
3. 系統的用例
有了邊界和執行者，就可以分析這些執行者是如何與系統進行交互的，進一步找出系統的用例。通過需求的分析，可以看出每個執行者的目標和希望得到的價值。
讀卡器 讀取卡的卡號，發送給系統。
一般用戶。能夠查看學生余額，充值記錄，上機記錄，學生上機狀態查看。
操作員。學生注冊，充值，退卡，收取金額查詢，學生退卡查詢，學生基本信息的維護，查看操作員的工作記錄。
管理員。基本數據的設定，結賬。添加，刪除用戶，查看日結賬單，周結賬單的打印。
4. 畫出系統用例模型圖
可以看出這個系統有四個執行者，和24個用例。如果這里的每個用例需要進行詳細的解釋，還需要些用例描述，這里不再給出。
四．領域模型分析
這里所說的領域是用例的業務領域，也就是需要解決問題的領域。對領域知識的理解直接關系到系統開發的成敗。
1. 領域概念
領域概念就是描述一個現實世界中的某個問題的一些名詞和術語。建立領域模型的第一步是找出描述這些問題的概念和術語。
對機房收費系統的所有用例和用戶需求分析，找到盡力能找到的所有的明細，動詞，動詞詞組。
需求過程中的名詞
| 學生 |
讀卡器 |
一般用戶 |
操作員 |
管理員 |
機房管理人員 |
| 學生基本信息 |
日結賬單 |
周結賬單 |
充值記錄 |
基本數據 |
卡 |
需求過程中的動詞或動詞詞組
| 查看學生余額 |
基本數據設定 |
注冊 |
充值 |
退卡 |
收取金額查詢 |
| 學生退卡查詢 |
學生基本信息維護 |
強制下機 |
結賬 |
添加用戶 |
刪除用戶 |
| 打印賬單 |
|
|
|
|
|
在記錄用戶的需求時，應該盡可能的記錄所有出現過的詞匯，方便以后挑選，避免漏掉重要的詞匯。
2. 概念類
從上邊列出的名詞開始篩選，找出可能的概念類。
學生：是一個概念類。
卡：是一個概念類
讀卡器：與系統沒有關系，所以不是概念類。
一般用戶：是概念類，操作時，要知道是誰進行的操作
操作員：是概念類，操作時，要知道是誰進行的操作
管理員：是概念類，操作時，要知道是誰進行的操作
機房管理人員： 不是一個概念類，與系統的開發無關
學生基本信息：是一個概念類，注冊的時候需要。但是包含在學生類里。
日結賬單：是一個概念類
周結賬單：是一個概念類
基本數據：是一個概念類
經過上面對所有的名詞進行分析，可以得到所有的概念類，在應用時為了方便，每個概念類都有一個英文名稱。
| 概念類名稱 |
英文名稱 |
概念類名稱 |
英文名稱 |
概念類名稱 |
英文名稱 |
| 學生 |
Student |
一般用戶 |
General user |
操作員 |
Operator |
| 管理員 |
Admin |
日結賬單 |
Daycheck |
周結賬單 |
Weekcheck |
| 基本數據 |
BasicData |
卡 |
Card |
|
|
找出了所有的概念類以后，然后找到類與類之間的關系，並找到他們呢所具有的方法與屬性，如何找這里不再解釋，最后畫出一張類圖。
機房收費系統的領域模型 1
五．工作流程分析
流程圖
前邊建立的領域模型，描述了系統的各個類之間的靜態結構，下面使用活動圖順序圖來描述系統的動態行為。
機房收費系統的核心工作就是，注冊卡，充值，負責學生刷卡上下機，然后打印賬單。
機房收費系統學生卡注冊上機流程圖 1
管理員登陸系統以后，先要進行基本數據的設定，基本數據設定成功以后，就可以進行注冊，充值，然后就可以刷卡上機，刷卡下機，或者進行一些其他的操作(上邊需求分析提到的用例)。
順序圖
前邊分析了系統的領域模型，和系統流程，下面看一下系統是如何與外界進行交互的。用例描述時是用文字描述的，下面用順序圖來描述一個用例的執行過程。他主要描述系統的外在行為，即系統的輸入域輸出。
系統是軟件系統的抽象，順序圖描述了系統接受一條數據和對這條數據進行的處理過程。首先要從讀卡器哪里獲取數據。然后由系統或者操作員進行操作。
這個順序圖描述的內容與用例的文本是完全一樣的。順序圖更加直觀的描述了用例的執行過程。為進一步設計系統打下基礎。
需求分析是軟件開發的起始部分，也是軟件中最為關鍵的部分，對於用戶的需求理解，直接決定了系統的正確性。所以在進行需求分析的時候，一定要全面，正確的分析。