当系统复杂到一定层次时，类图和顺序图可能不能足以描述其复杂程度。在该情况下，需要使用状态图来辅助阐述。状态图和顺序图之间使用事件联结在一起。它们之间的一致性问题，目前UML和ROSE没有提供解决方案。相对折衷的方法是使用事件的命名规范强制一致性。
可以说，之前说的所有的东西都是为了能够导出用例在需求中的作用。用例是从用户的角度看待系统，而不是基于程序员的角度。这样的话，用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体现。用户和程序员间通过用例沟通，避免了牛头马嘴的尴尬局面。 从前，系统开发者总是通过情节来获取需求，是问用户希望系统为他做什么。在Jacobson发明了用例的概念之后，需求获取就变成问用户要利用系统做什么。这是立场不同导致的结果。用户通常并不关心系统是如何实现的(也有少数可爱的技术狂是例外)。对他们来说，更重要的是要达到他的目的。相反的，大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求。所幸的是，用例方法能够调和双方的矛盾，因为虽然用例是来源于用户，服务于用户，但是它同样可以用于开发的流程。当系统的开发过程都是基于用例的，用用例获取需求，用用例设计，用用例编码，用用例测试的时候。这个开发过程就是用例驱动的。 用例和用例文档
《软件需求》一书中提到了几种方法来确定用例：
首先明确执行者和他们的角色，然后确定业务过程，在这一过程中每一个参与者都在为确定用例而努力。
确定系统所能反映的外部事件，然后把这些事件与参与的执行者和特定的用例联系起来。
以特定的说明形式表达业务过程或日常行为，从这些说明中获得用例，并确定参与到用例中的执行者，有可能从现在的功能需求说明中获得用例。如果有些需求与用例不一致，就应考虑是否真的需要它们。
用例代表了用户的需求，在你的系统中，应该直接从不同用户类的代表或至少应从代理那里收集需求。用例为表达用户需求提供了一种方法，而这一方法必须与系统的业务需求相一致。分析者和用户必须检查每一个用例，在把它们纳入需求之前决定其是否在项目所定义的范围内。基于“用例”方法进行需求获取的目的在于：描述用户需要使用系统完成的所有任务。在理论上，用例的结果集将包括所有合理的系统功能。在现实中，你不可能获得完全包容，但是比起我所知道的其它获取方法，基于用例的方法可以为你带来更好的效果。 当使用用例进行需求获取时，应避免受不成熟的细节的影响。在对切合的客户任务取得共识之前，用户能很容易地在一个报表或对话框中列出每一项的精确设计。如果这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制。你可能要周期性地检查需求获取，以确保用户参与者将注意力集中在与今天所讨论的话题适合的抽象层上。向他们保证在开发过程中，将会详尽阐述他们的需求。在一个逐次详细描述过程中，重复地详述需求，以确定用户目标和任务，并作为用例。然后，把任务描述成功能需求，这些功能需求可以使用户完成其任务，也可以把它们描述成非功能需求，这些非功能需求描述了系统的限制和用户对质量的期望。虽然最初的屏幕构思有助于描述你对需求的理解，但是你必须细化用户界面设计。 建立用例文档。在每一次的需求获取之后，都会生成很多未整理的需求，你必须将它们组织成用例文档。使用诸如模板的技术能够提高你的速度和需求的复用性。一个用例文档可以使用表格来组织，主要的要素包括了用例标识号、用例名称、父用例标志号、创建者、创建时间、审核者、修订记录、角色、说明、先决条件、请求结果、优先级、普通过程、可选过程、例外、非功能需求、假设、注释和问题。 虽然列举出了这么多的属性，但是实际中使用的属性这要看你的团体而定，看项目的大小而定。把大量的时间花在用例的描述上是没有意义的。用户需要的是一个软件系统，并不是一大堆的用例说明。
文章来源于领测软件测试网 https://www.ltesting.net/
