用例建模是实现系统需求分析的一个很好的方法，通过它可以使得系统分析员和客户之间能够更好地沟通系统的需求。
在介绍中我们说到用例图是显示一组用例、参与者之间关系的图。接下来的内容详细的阐述了什么是用例、什么是参与者以及他们之间有什么样的关系。
参与者也叫角色，它表示了系统的用户。这里需要注意的是：这里的用户并不特指人，如果我们开发的是公共API项目，那么这个时候，API的调用者就是我们的用户。
参与者指的不是用户本身，而是它在系统中所扮演的角色。举个例子来说，张三是淘宝店的店主，这个时候他参与淘宝的交互时，他既可以是店主这个角色，也可以作为买家在淘宝上购买东西，这个时候张三在系统中扮演了两个角色，这两个角色是两个不同的参与者即买家和卖家。
参与者的作用是：
我们先来看两个案例：
例：销售员每天下班前将当日销售情况通过邮件发送给销售经理，由销售经理将总的销售记录进行汇总录入到系统中。
这个时候和系统进行交互的人是销售经理，所以销售经理是系统的参与者。
参与者在我们代码中，本质上还是类，所以在参与者中也存在继承的关系（分析阶段一般用泛化关系来表示继承）。泛化关系(Generalization)表示一个一般性的参与者（父参与者）和另一个特殊参与者（子参与者）之间的联系。参与者之间的泛化关系用带空心箭头的实线来表示，箭头端表示父参与者。
在上面的图中，我们可以发现，管理员和普通用户都是用户的特殊化，所以可以抽象出一个父参与者来，管理员和普通用户都拥有用户的全部特性，同时还具有自己特殊的特性。
需求分析是软件开发流程中必不可少的一个环节，其主要目的就是建立待开发系统的模型，而用例则是建立这些的最好方法。
用例是对一组动作的描述，系统通过执行这些动作将对用例的参与者产生可以看到的结果。用来描述参与者可以感受到的系统服务或者功能。
在UML中，用例通常用一个椭圆形符号来表示：
在电商系统中，“加入购物车”就是一个用例，在社交软件中，“发送消息给某人”就是一个用例。
使用用例进行系统需求分析的特点：
一般情况下，我们如果向其他人描述一个一个功能的具体信息呢？我们通过文字来对功能进行讲解。用例图只是简单的用图形方式描述系统，关于功能的完整解说还是需要用文字来表达。所以，对于用例，我们需要由详细的说明，这样才能让其他人更加清楚的了解这个系统。这个时候我们就需要编写用例描述了。
通常不会对用例描述做硬性规定，但是一些复杂的或者是重要的用例还是要编写用例描述。用例描述一般包括用例编号、用例说明、前置条件、基本事件流、其他事件流、异常事件流和后置条件等。
下面是“加入购物车”用例的详细描述：
说完用例，我们来说说用例之间的关系
包含关系指的是两个用例之间，其中一个用例(基本用例)的行为包含了另外一个用例(包含用例)。
扩展关系是对基本用例的扩展，基本用例是一个完整的用例，即使没有子用例参与，也可以完成一个完整的功能。扩展的基本用例中存在一个扩展点，只有扩展点被激活时，子用例才会被执行。扩展关系是从扩展用例到基本用例的关系，它说明扩展用例如何插入到基本用例中。
扩展用例的使用场景：
泛化关系指的是一般(父用例)与特殊(子用例)的关系。当多个用例共同拥有一种类似的结构和行为时，可以将它们的共性抽象为父用例，其他的用例作为泛化关系中的子用例。
在一些用例图中，用例数量可能很多，这个时候就需要把这些用例组织起来。
创建用例图模型主要包含3部分内容：
这部分工作通常由系统分析员通过和客户沟通来完成。
要获取系统的用例，首先要找出系统的角色。
要获取系统角色可以在与客户沟通时，询问用户一些问题来识别角色。可以参考下列问题：
当我们获取到系统角色后，我们可以通过角色来列出它的用例。可以通过回答下列问题来识别用例：
将已经确定并细化的角色和用例放入用例图。再借助包含、扩展和泛化的关系给出用例之间的结构模型。
在系统需求分析中需要考虑系统用例图模型需要哪些视图、每个视图包含什么内容，以及视图中成员是否需构成包。
用例建模是实现系统需求分析的一个很好的方法，使得系统分析员和用户之间能够更好地沟通系统的需求。