上一篇博客写了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
管理员登陆系统以后，先要进行基本数据的设定，基本数据设定成功以后，就可以进行注册，充值，然后就可以刷卡上机，刷卡下机，或者进行一些其他的操作(上边需求分析提到的用例)。
顺序图
前边分析了系统的领域模型，和系统流程，下面看一下系统是如何与外界进行交互的。用例描述时是用文字描述的，下面用顺序图来描述一个用例的执行过程。他主要描述系统的外在行为，即系统的输入域输出。
系统是软件系统的抽象，顺序图描述了系统接受一条数据和对这条数据进行的处理过程。首先要从读卡器哪里获取数据。然后由系统或者操作员进行操作。
这个顺序图描述的内容与用例的文本是完全一样的。顺序图更加直观的描述了用例的执行过程。为进一步设计系统打下基础。
需求分析是软件开发的起始部分，也是软件中最为关键的部分，对于用户的需求理解，直接决定了系统的正确性。所以在进行需求分析的时候，一定要全面，正确的分析。