2.1.3　用例描述

一些人误以为用例分析就是简单地画几张用例图。实际情况却不是这样的，用例图只是用例分析的一个开始，还要为用例图中的每个用例编写用例描述，要细化用例。从这个角度来说，用例模型分析最终的产出物就是一个用例分析文档，如表2-1所示。

表2-1　用例描述

表2-1是一个用例描述的范例，在用例模型中的每一个层次中的每一个用例都要编写用例描述。可能有的同学会说，我们的项目不进行用例分析这个环节，但是，所有的项目在需求分析这个阶段都要编写《需求规格说明书》。以往我们在编写《需求规格说明书》时，是通过大段的文字来描述业务的。然而，这样大段的文字没有任何的规范可言，最终的结果就是，编写需求往往想到哪里就做到哪里。采用这种方式，一些问题想到了就做了，没有想到则被忽略了。这种方式将会给后期的软件研发带来巨大的风险。正因为如此，越来越多的团队都选择采用用例描述的方式来编写需求规格说明书。

采用用例描述的方式，每个用例都用这样一个表格来描述需求。表格中有许多项目，代表的是业务需求方方面面需要关注的内容。当我们将这个表格中所有的项目都填写了一遍以后，我们就对该需求方方面面的问题都考量了一遍，就能保证需求分析的完整，也规避了软件项目中最大的风险。

接着，我们来看一看用例描述都包含哪些项目。用例标识、用例名称、创建人、创建日期和版本号就不用说了。用例类型是一个非常重要的项目，因为对于不同的用例类型，我们的关注点是不一样的。譬如，最常见的用例类型是“业务功能”，它描述的是用户在系统中的一系列操作流程。因此，在这种用例中，在需求分析的时候我们主要关注的是那个业务流程及其分支。

相反，如果用例类型是“查询报表”，那么我们最关注的就不是那个业务流程了，而是查询报表所拥有的过滤条件、数据项及其计算关系、数据来源与数据链接。如果用例类型是“图表展示”，则关注的需求是图表内容、展现形式、数据频率、数据来源与数据链接，等等。也就是说，用例类型的不同，用例描述的格式也是不一样的。用例描述的目标是把需求描述得清晰而完整，为了实现这个目标，应当在用例描述时尽量体现出重点，即该用例中最需要被关注的内容，剔除不太重要的信息。

用例描述，就是用简短的一两句话对用例的业务进行的概括性描述。用例描述应当简单明了，如果某个用例需要用很多句话才能说清楚，那么说明该用例职责不够单一，应当考虑拆分。

角色就是参与者，触发事件就是参与者做了什么事情就进入该用例，前置条件则是参与者能够进入这个用例的前提条件。比如，患者就诊之前必须先挂号，挂号就是患者就诊的前置条件。

事件流是“业务功能”这种类型的用例最主要的描述内容，它分为基流、分支流与替代流。当用例完成了一系列事件流以后，还有一个后置条件。所谓后置条件，就是在完成这一系列事件流以后应当达到的目标、可以完成的操作以及可以开始进行哪些后续操作。

业务需求除了功能性需求，还有非功能性需求。对于非功能性需求，在需求规格说明书中有两个地方进行描述：对于那些整个系统所有功能都必须循序的非功能性需求，通常在需求规格说明书最后一章集中进行描述；对于那些某个功能个性化的非功能性需求，则在此处的“非功能性需求”栏目中进行描述。