基本事件流

　　低限度，每一个用例都需要描述一个主场景或者典型事件流。主事件流一般是一组有编号的步骤，如：

　　1) 系统提示用户登录。

　　2) 用户输入他的名字和密码。

　　3) 系统验证用户信息。

　　4) 系统使该用户登录入系统

　　...其他

　　备选路径

　　用例可能包含第二条路径，或者和主题不同的备选场景。异常或当出错时会发生什么事情也需要描述出来，这种描述可以在备选路径中或者在它本身的部分。备选路径使用基本事件流中的序号来标示在哪一点上同基本场景不同，并且如果合适它从哪一点回到基本场景中。目的是避免不必要的重复信息。

　　备选路径的例子:

　　1) 系统识别用户机器上的cookie

　　2) 到步骤4（主路径）

　　异常路径的例子:

　　3) 系统不能识别用户登录信息

　　4) 到步骤1（主路径）

　　后置条件

　　后置条件 部分总结了在场景结束后事务的状态。

　　业务规则

　　业务规则是一些成文的或未成文的规则，对于用例来说它决定了一个组织是如何执行业务的。业务规则是一个特殊种类的假定。它可能适用于某一个用例或者整个用例，甚至整个业务。

　　注释

　　经验告诉我们，不管采用何种模版，分析人员发现总有重要的信息不适合模版的结构。因此每一种模版通常包含了这种明显不能避免的信息的部分。

　　作者与日期

　　这部分列出创建用例的版本和谁书写的。还需要列出开发过程中从早期阶段开始的每个用例版本的日期。作者习惯在下面列出，因为它不被认为是重要的信息；用例是共同努力的结晶，并且它们被所有人拥有。

　　用例的效益

　　用例是一个较新的，比较敏捷的捕获软件需求的形式。用例经常和大的，统一的文档形成对比。这些大文档想要在新系统开始构成前，完整的表达出所有可能的需求，但这种做法通常都是失败的。

　　用例的几点优势:

　　用例已经证实更容易被业务用户理解，因此它也是开发人员和终用户的很好的沟通桥梁。

　　用例对于确定范围很有用。用例使分阶段交付从而一步步完成项目变得容易； 它们能够在优先度变化时相对较容易的添加或从软件项目移去。

　　用例可跟踪。

　　用例能够作为估计，制定进度和验证成果的基础。

　　用例防止了不成熟的设计

　　用例不使用特定语言

　　用例允许我们去讲故事。能够容易的采用将需求转换为故事或场景这一具体的方法来描述用例。

　　用例在项目中可复用。 用例在每一次迭代中都能进一步演化，用例可以用于捕获需求，成为程序员的开发依据，发展为测试用例，到后成为用户手册。

　　用例与用户和系统交互相关。它们使软件开发者在开发之前或当中能够开始用户接口设计。

　　用例将需求置于上下文中，它们能够清楚地描述业务活动间的关系。

　　用例的局限

　　用例不是没有局限性:

　　用例在捕获系统功能需求上表现很，但是它们并不适合方便的捕获非功能需求。尽管一些用例支持者过于热心的主张，还是需要其它的方法去捕获非功能需求。

　　用例模版不能自动保证清晰。清晰要依靠书写者的技巧。

　　用例并不像支持者说的那样易于理解。 There is a learning curve involved in learning to interpret them correctly for end users and programmers alike.(如何正确地向终用户和程序员解释这些用例是一个需要花费时间学习的事情。)

　　极限编程的说明者通常认为用例是没用的文档，他们更喜欢用较简单的用户故事这一方法。

　　可用性设计人员批评用例在开发过程中过早的引入了用户接口设计。他们指出用例描述用户和系统之间的交互，很显然它和用户接口设计重叠了。不好的用例描述将过细的，专断的用户接口设计包含于交互的描述中，即使用例的一个原则是不要加入实现的细节。