用例说明.docVIP

用例说明 用例图可以直观地展现需求中的所有用例、参与者、系统边界，以及它们之间的关系，但这还不足以表达需求分析所要求表达的内容。用例图必须辅之以用例说明，才能完整清楚地表达。用例模型是需求分析阶段的主要成果，因此它担负的职责繁重。用例模型必须做到以下要求： ? 1、语言的互通。用例模型采用的语言必须达到，既能让业务人员看懂，以便给予业务确认，又能让技术人员看懂，以便进行日后的设计开发。因此，用例模型的描述必须是对业务需求最平实的表述，站在业务人员的角度说事儿，不能参杂过多的技术语言。同时，又要站在技术的角度进行分析，详细清楚地表述各个功能的操作流程，并不能使用过于专业的业务术语，或者对必要的业务术语进行解释，让技术人员看懂。 ? 2、清晰准确。用例模型必须清晰准确地表达每一个业务需求，因此我们在建立用例模型的时候，必须明确每一个术语，每一段表述，不能存在二义性。 ? 3、最全面和详尽的业务需求。用例模型必须从各个角度，全面地反映客户对系统的期望。用例模型对业务需求把握得越全面和详尽，项目出现偏差和风险的几率就越小。这要求我们进行分析时，各个角度都要分析到。 ? 要做到以上几点其实并不容易，所幸的是，用例说明为我们提供了一个良好的范例。用例说明在用例模型中的作用，甚至超过了用例图。寥寥几页的用例图，需要数十页甚至上百页的用例说明来描述。用例说明需要按照一定的格式，对所有用例图中的所有用例进行描述，如果有必要，还要对参与者、系统边界和部分术语进行描述。下面我们来看看用例说明是怎样编写的。 ? 按照用例分析的特点，用例说明也应当从粗到细依次进行编写。首先是对整个系统进行概述，编写总用例图的说明，然后依次编写各个支用例图的说明。在编写每个用例图时，首先贴上该用例图，然后为每个用例编写说明。 ? 1.概述 在用例说明的概述部分并没有固定格式，但我认为至少应当包括以下内容： ? 1、项目概述（或者背景说明），这是通过文字，对整个项目的情况、相关利益攸关者、项目目标及执行计划的整体概述。 ? 2、参与者，这是对整个项目所有参与者及其相互关系的描述。在这部分，首先应当贴出参与者的用例图（该图主要是描述参与者的相互关系，不包含任何用例），然后依次对每个参与者的角色定义、拥有职能、与其它参与者的关系进行描述。 ? 3、系统范围，这是对整个项目范围的详尽描述。 ? 4、词汇解释，这是对该文档中使用的专业术语的解释说明。 ? 5、基本流程，这是对整个项目总体流程的描述，它通常是一个行动图。 ? 2.为用例编写说明 下面就是从主用例图开始，依次对所有用例图进行说明。在对每个用例图进行说明时，先贴出用例图，然后为每个用例编写说明。在这部分，每个用例的说明可以按照如下格式编写： ? ? 用例标识：用例的编号。 ? 用例名称：根据用例表达的功能而取的简短明了的名称。用例命名其实是有讲究的，即必须是一个动词短语或句子，而不是一个名词短语，通常建议为一个动宾短语（如：提取存款），一个被动句（如：发票填报），或者一个主谓句（如：用户提款）。用例的命名表现了用例的特点，即它代表的是参与者的操作，是一个动作。尽量不要取 “××管理”或“维护××”，因为这个动作应当是一个非常明确的动作，而“××管理”代表的是插入、修改、删除等一系列动作，操作就变得不明确了。 ? 应用范围：就是要设计的系统。 ? 用例类型：“用户目标”还是“子功能”，即是用户需要操作的目标功能，还是从“用户目标”中提取出来的“子功能”。“用户目标”应当至少有一个参与者，来驱动它完成相关操作，而“子功能”通常没有，因为它往往是被系统所驱动。 ? 用例描述：对该用例的功能定义、要实现的业务需求，以及谁（参与者）如何进行使用进行描述。同时，这部分还可以整体概述实现业务需求的主要流程，以及与其它用例、其它外部系统的关系。 ? 参与者：列出与该用例相关的参与者，包括进行操作的人（角色）和相关的外部系统。 ? 涉众利益：关注该用例的人对该用例的要求，它往往是非功能需求，或者是功能需求中的一些常常为我们所忽视的细节。如客户要求在填写一些表单的时候能够快速进行查找，而另一些系统管理员希望提高可维护性（虽然他们可能不是该用例的参与者）。编写涉众利益应当按照如下格式：使用数字编写序号，而每个涉众利益应当书写为“谁期望怎么样”。 ? 前置条件：在触发该用例相关操作前必须达到的条件。 ? 事件流：是用例说明中最重要的部分，它详细描述了该用例可能出现的所有流程。 ? 基本流程：又称为“主流程”或“主成功场景”，它描述的是该用例以最正常的方式流转，并且最终获得成功的流程。基本流程在编写时，应当通过数字，对流程中的每一步进行编号。 ? 扩展流程：又称为“替代流程”、“分支流程”或“交替场景”，它描述的是基本流程在流转过程中可能出现