需求的用例表达

需求需要表达出来（将需求文档化），其表达方式有多种多样。近年来，使用“用例”来表达已逐步成为主流，特例是“用例”的图形符号是UML的基本符号之一，纳入了面向对象的分析与设

关键字：需求 用例 表达

需求需要表达出来（将需求文档化），其表达方式有多种多样。近年来，使用“用例”来表达已逐步成为主流，特例是“用例”的图形符号是UML的基本符号之一，纳入了面向对象的分析与设计的标准化体系中。

用例(use case)有如下特点：

用例是需求开发的结果，它的表述形式使它在这些方面的作用更加突出：a、涉众交流的工具；b 、开发与测试的依据；c、具有重用性（作为今后类似需求的参照和重用）。

用例是对一组动作序列（其中包括它的变体）的描述，系统执行该动作序列来为参与者产生一个可观察的结果值。这个动作序列就是业务工作流程，项目的涉众都能理解，基于它所进行的讨论，能较好地完善这个序列。

用例是对用户目标或用户需要执行的业务工作的一般性描述；是一组相关的使用场景。描述了系统与外部角色之间交互。使用场景（usage scenario）则是某个用例的一条特定路径。是用例的特定的实例。通过用例描述，能将业务的交互过程用类似于流程的方式文档化。阅读用例能了解交互流程。

用例特别适用于描述用户的功能性需求，它描述的是一个系统做什么（what），而不是说明怎么做（how）。用例不关心系统设计，编写用例的最昂贵的错误包括太多细节和用户界面说明，使得用例变长，难以阅读。

用例特别适用于增量开发，一方面通过优先级指导增量开发，另一方面用例开发的本身也是强调采用迭代的、宽度优先的方法进行开发，即先辨认出尽可能多的用例（宽度），再细化用例中的描述，再回过头来看还有哪些用例（下一次迭代）。

在UML的图形中，用例一般用一个椭圆（其中写上用例名）来代表，而具体的用例描述在UML中未作强制性规定，即可以用你所习惯的方式来描述，例如：我结合自己的经验设计了如下表格方式来描述用例。在【 】中的文字是说明性的。