四、用例在同一时间只能有一个主要参与者（actor）。
　　用例充分关注用户使用系统到底做什么，但它只关注特定参与者与特定系统的交互而不包括参与者之间如何交互。如果在同一时间有两个主参与者在执行用例，意味着你描述的不只是系统需求还包括系统所处环境中参与者之间的协作关系。例如，如果你的用例中包括类似如下的描述：
　　1、学生准备申请助学金，系统提示学生输入学习成绩、家庭条件等信息。
　　2、学生提交以上信息等待审批。
　　3、助学金审批人员审查学生助学金申请，决定批准，系统提示输入核准意见。
　　4、助学金审批人员输入理由并确认。
　　那么，你的用例包括两个参与者，你的用例不是真正的用例。同一时间，用例之所以只能有一个参与者，是因为用例只定位在描述系统的需求上，而不是定位在描述参与者之间如何协作上。如果将让用例同时描述参与者间协作，那用例将不只是定义需求还将定义业务流程，用例的复杂性增加、针对性降低、实用性减弱。
　　那参与者之间协作在哪描述呢，我们也确实需要它。实际上那是业务用例实现的职责。
　　五、用例不是需求的定义形式，用例需要和其他需求定义形式一起定义完整的需求。
　　用例较其他需求方法具有优越性，但只使用用例是无法有效地定义完整的需求。用例主要定义的是功能性和行为性的需求，系统还有大量的非功能性需求需要定义，如易用性、性能、可支持性等等。这些需求以用例的方式定义都是不可行的，而定义他们好的形式还应该是特性。
　　另外对于一些功能性需求，可能也不适合使用用例来定义，如系统对外提供的服务接口等。而对于一些不与参与者交互的中间件产品中的大量需求尤其不适合使用用例定义。其需求定义的方式使用特性更为合适。
　　以上大致描述的什么是用例，用例有什么特点。实践中总是有人分不清用例和业务用例。业务用例是用例思想的延续，只是改变了使用场合。用例是从使用者的角度定义“软件系统”需求。而业务用例不研究“软件系统”需求，它更关心一个“业务组织”对外提供哪些服务。如住房公积金中心是一个业务组织，你或许是一个业务参与者（如果你准备作住房公积金贷款）。那么办理住房公积金贷款是一个业务用例。这个业务用例会描述什么呢？它会描述类似如下内容(由于内容复杂仅作示意)：
　　1、职工准备相关资料去住房公积金中心办理货款。业务用例开始。
　　2、职工向中心提交准备贷款的相关资料，中心工作人员对资料进行初审。
　　3、若审核通过，职工准备办理抵押合同，中心工作人员委托担保公司与职工签订抵押合同。
　　4、担保办理完成后，职工与中心签订理借款合同，中心工作人员要求职工办理银行卡并提供卡号。
　　5、借款合同签订后，中心工作人员要求贷款合同必须办理公证，职工与中心一道办理公证。
　　6、职工办理完公证后，中心发放贷款。业务用例结束。
　　可见，此处的业务用例描述的是业务参与者（职工）如何使用业务组织（中心）提供的服务的过程。因此业务用例实际上是一种业务流程。它以业务组织外部业务参与者的角度定义业务组织提供的服务。当然业务用例还包括一些内部流程，它可能不是由业务参与者启动的，如采购流程等。因此，业务用例只是使用了用例的思想和形式而已，研究的主题是完全不同的。用例研究软件系统，借助用例定义软件系统需求。而业务用例研究一个目标组织，借助业务用例定义目标组织应该具有哪些业务流程，以及这些流程应该是什么样子的。