三、用例主要以事件流的方式定义需求，但不是唯一的方式，用例形式化程度很高。

　　用例的主体是事件流，事件流分为基本流和备选流。基本流是用户使用系统时，最常用路径，一般不包括异常和分支。备选流则相反，一般是分支或异常等。不论是基本流还是备选流，都是以用户与系统的交互方式定义的，即用户如何使用系统，系统如何响应，但描述中不应夹杂UI设计信息。

　　除了主事件流之外，参与者描述了谁会使用这个用例。前置条件描述了必须具备什么样的条件或状态才能执行该用例。后置条件描述用户成功执行后应处于什么样的状态。特殊需求则会以特性的方式描述与用例相关的其他功能或非功能性需求，一般以非功能性需求居多。与XP、FDD等敏捷方法相比，用例更加形式化，定义需求更为严谨，当然花费的时间也会相对较多。

　　四、用例在同一时间只能有一个主要参与者（actor）。

　　用例充分关注用户使用系统到底做什么，但它只关注特定参与者与特定系统的交互而不包括参与者之间如何交互。如果在同一时间有两个主参与者在执行用例，就意味着你描述的不只是系统需求还包括系统所处环境中参与者之间的协作关系。例如，如果你的用例中包括类似如下的描述：

　　1、学生准备申请助学金，系统提示学生输入学习成绩、家庭条件等信息。

　　2、学生提交以上信息等待审批。

　　3、助学金审批人员审查学生助学金申请，决定批准，系统提示输入核准意见。

　　4、助学金审批人员输入理由并确认。

　　那么，你的用例就包括两个参与者，你的用例就不是真正的用例。同一时间，用例之所以只能有一个参与者，是因为用例只定位在描述系统的需求上，而不是定位在描述参与者之间如何协作上。如果将让用例同时描述参与者间协作，那用例将不只是定义需求还将定义业务流程，用例的复杂性增加、针对性降低、实用性减弱。

　　那参与者之间协作在哪描述呢，我们也确实需要它。实际上那是业务用例实现的职责。

　　五、用例不是需求的唯一定义形式，用例需要和其他需求定义形式一起定义完整的需求。

　　用例较其他需求方法具有优越性，但只使用用例是无法有效地定义完整的需求。用例主要定义的是功能性和行为性的需求，系统还有大量的非功能性需求需要定义，如易用性、性能、可支持性等等。这些需求以用例的方式定义都是不可行的，而定义他们最好的形式还应该是特性。

　　另外对于一些功能性需求，可能也不适合使用用例来定义，如系统对外提供的服务接口等。而对于一些不与参与者交互的中间件产品中的大量需求尤其不适合使用用例定义。其需求定义的方式使用特性更为合适。

　　以上大致描述的什么是用例，用例有什么特点。实践中总是有人分不清用例和业务用例。业务用例是用例思想的延续，只是改变了使用场合。用例是从使用者的角度定义“软件系统”需求。而业务用例不研究“软件系统”需求，它更关心一个“业务组织”对外提供哪些服务。如住房公积金中心是一个业务组织，你或许就是一个业务参与者（如果你准备作住房公积金贷款）。那么办理住房公积金贷款就是一个业务用例。这个业务用例会描述什么呢？它会描述类似如下内容(由于内容复杂仅作示意)：

　　1、职工准备相关资料去住房公积金中心办理货款。业务用例开始。

　　2、职工向中心提交准备贷款的相关资料，中心工作人员对资料进行初审。

　　3、若审核通过，职工准备办理抵押合同，中心工作人员委托担保公司与职工签订抵押合同。

　　4、担保办理完成后，职工与中心签订理借款合同，中心工作人员要求职工办理银行卡并提供卡号。

　　5、借款合同签订后，中心工作人员要求贷款合同必须办理公证，职工与中心一道办理公证。

　　6、职工办理完公证后，中心发放贷款。业务用例结束。

　　可见，此处的业务用例描述的是业务参与者（职工）如何使用业务组织（中心）提供的服务的过程。因此业务用例实际上是一种业务流程。它以业务组织外部业务参与者的角度定义业务组织提供的服务。当然业务用例还包括一些内部流程，它可能不是由业务参与者启动的，如采购流程等。因此，业务用例只是使用了用例的思想和形式而已，研究的主题是完全不同的。用例研究软件系统，借助用例定义软件系统需求。而业务用例研究一个目标组织，借助业务用例定义目标组织应该具有哪些业务流程，以及这些流程应该是什么样子的。