本文强调了用例规划在软件研发项目中的重要性，并对如何做用例规划进行了分析。enjoy~

1. 概述

用例规划是需求分析中的第一步。

用例规划的前提条件就是前面已经进行了全方面多角度的调研，再此期间并编撰了内容完整、结构清晰、数据表现力充足、且被客户点头认可的需求调研文档，并且有相当充足的调研材料来形成根数据的基础。

所谓的用例规划说白了就是在冗长、复杂、多层面、多角度的调研文档里，找到核心且正确的方法，然后将这些数据进行有力有度有方向且有效的提炼和淬取，从中挖掘潜藏在里面的基本业务需求，并将这些业务需求以表格或者图例的形式一一展现出来。

2. 什么是用例图

用例图主要是用来获取核心需求、指导测试用的。

在软件研发项目中，用例图是业务调研之后，最先最易用来和用户进行沟通交流的UML视图，它相当于一个媒介，在这个时候是非常重要的。

用例图设计是软件需求分析的第一步，是参照业务调研报告而规划出来的可视化图例。它能够把客户的想法和要求用更加容易理解的图形化样式展现出来，用例描述的是参与者从系统外部看系统内应该有的功能。

在UML中，用例图是描述系统功能需求的，系统中的一个功能可以用一个相应的用例来描述，用例图中描述的是系统该有哪些功能，这里讨论的不包括功能是怎么实现的。因为，用例图是要拿去分析给客户看的，所以最好越直观越好，越容易理解越好，这就是用例图的优势和特点。

用例图是客户与开发人员交流的一种重要的方式，是对用户需求的一种描述。开发人员从用户的角度整体上理解系统的功能。

用例图包括参与者、用例以及用例间的关联关系、包含关系、扩展关系和泛化关系。

用例图的4个基本组件分别为：参与者（Actor）、用例（Use Case）、关系（Relationship）和系统。

本文主要讲解用例的组成以及如何解读业务调研报告并且规划用例。

2.1 用例

用例是系统给外部提供的可视化的功能单元，用例只显示其外部功能的表现，不考虑系统内部的实现过程。在UML中用例用椭圆来表示，用例名称一般写在椭圆的正下方。

用例图如此重要，那么用例图的基本元素用例是怎么确认的呢？一般在实际的系统设计中，因为用例图是通过业务调研报告得来的，所以用例也一样主要来自该项目的业务调研报告，一般是关键抽取业务调研报告中的动词或者动词词组。

2.1.1 包含（include）关系

当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示（在线上标注<<include>>），箭头从基用例指向子用例。

2.1.1.1 描述

如果从两个或两个以上的用例中提取公共行为的时候，应该使用包含的关系来表示它们。其中这个提取出来的公共用例就会成为抽象用例，而把原始用例成为基本用例或基础用例。其中“<<include>>”是包含关系的构造型，箭头指向抽象用例。

2.1.1.2 案例

例如，在某一个管理系统中“注册用户信息”和“信息录入”两个用例都需要操作员或者管理员登陆，为此，可以定义一个抽象用例“用户登陆”。用例“注册用户信息”和“信息录入”与用例“用户登陆”之间的关系就是包含关系。

有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以抽象出一个基用例，来包含这些颗粒的用例。

2.1.1.3 作用

当多个用例需要使用同一段事件流时，抽象成为公共用例，可以避免在多个用例中重复地描述这段事件流，也可以防止这段时间流在不同用例中的描述出现不一致的情况。当需要修改这段公共的需求时，也只要修改一个用例，避免同时修改多个用例而产生的不一致和重复性工作。另外，当某个用例的事件流过于复杂时，为了简化用例的描述，也可以将某段事件流抽象成为一个被包含的用例。

2.1.2 扩展关系

extend关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。

extend的基用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。 extend关系在用例图中使用带箭头的虚线表示（在线上标注<<extend>>），箭头从子用例指向基用例。

2.1.2.1 描述

如果一个用例明显地混合了两种或者两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样可能会使描述更加清晰。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此他能根据基用例中扩展点的当前状态来决定是否执行自己。而扩展用例对基用例不可见。

2.1.2.2 案例

例如某一个管理系统中“维护用户信息”操作时如果发现信息有误或者更新则需要使用“修改用户信息”用例完成更新，所以用例“查询上机记录”和“导出EXCEL”之间的关系就是扩展关系。“<<extend>>”是扩展关系的构造型，箭头指向基本用例。

2.1.2.3 包含关系和扩展关系之间的区别

• 联系：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
• 区别：扩展关系中基本用例的基本流执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行。
• 共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
• 包含关系中基本用例的基本流执行时，包含用例一定会执行。

2.1.3 泛化关系

泛化关系是一种继承关系，子用例将继承基用例的所有行为，关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例。

2.1.3.1 描述

当多个用例共同拥有一种类似的结构和行为时，可以将他们的共性抽象成为父用例，其他的用例作为泛化关系的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，它继承了父用例的所有结构、行为、关系。其中三角箭头指向父用例。

2.1.3.2 案例

假如，在某一个管理系统的注册可以通过本地注册和线上注册。则同样，一般用户，用户，管理员之间也存在泛化的关系。

2.1.3.3 包含关系、扩展关系和泛化关系之间的区别

泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：

• 泛化侧重表示子用例间的互斥性；
• 包含侧重表示被包含用例对Actor提供服务的间接性；
• 扩展侧重表示扩展用例的触发不定性；详述如下：

2.1.4 三种关系发生的条件

既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：

1. 无条件发生：肯定发生的；
2. 有条件发生：未必发生，发生与否取决于系统状态；

因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。

2.2 参与者

在一个系统中，不可能没有参与者，否则系统就没有任何的意义。在用例图中，可以说参与者的存在是为了执行用例的。参与者就是和用例有“来往”的人或者事物（包括外部系统、硬件以及其他用例等），是系统外部的实体。

在UML中，通常人形图标表示，如图：

参与者可以是人，也可以是与该系统有信息交互的其他系统或者机器，也可以是进程。当参与者是人时，一般不是指一个具体的某一个人，而是指对本系统而言具有相同属性和功能的一类人。

例如，现在某一个管理系统中，用户登录用例，这时的参与者就不能说是那个具体的人了，而是整个注册了该系统的所有人。所以说参与者不是一个实例，而是以整个类型。

参与者与用例连接在一起，表示两者之间有信息交互。参与者可以通过触发用例来进行信息的交换。单个参与者可与多个用例有信息交互，反过来一个用例可与多个参与者有信息交互。对同一个用例而言，不同参与者有着不同的作用，他们可以从用例中取值，同样也可以参与到用例当中去。

——用例规划是什么时间开始的？

一般等业务调研报告编写完成并通过评审之后，需求开发人员根据业务调研报告来完成用例规划。

——用例将体现在什么文档里？

将体现在需求分析报告文档里，是继业务调研报告后的一个非常重要的文档，是用来描述用户需求的图。

——为什么叫做用例？

用例的本质是反应用户的需求，其实就是功能需求，也就是描述功能需求的一种方法，只是面向对象分析方法的一种表达形式而已。

——用例来源于业务调研报告，如何从业务调研报告中获取需求用例呢？切入点是什么呢？

用例来源于业务调研报告，有时候业务调研报告会让我们看的眼花缭乱从而无从下手。用例的规划必须从先业务流程图中抽取，一般情况下将业务流程图中的运行节点作为用例的候选者，然后根据具体情况进行分析。

——用例和程序模块是一个概念吗？

虽然不是一个概念但是期间有一定的关系。在需求分析阶段一般不讨论代码的具体实现，所以也就谈不上什么程序模块的概念。在用例分析阶段不要考虑具体的实现问题，只要描述清楚用例就够了，这些问题应该是在系统架构和实现阶段思考。

——开发人员如何确定用例的参与者呢？

在用例确认的前提下，要明确这些关键点：

• 第一，谁将使用该系统的主要功能；
• 第二，谁将需求要该系统的支持以完成其工作；
• 第三，谁将维护、管理该系统，以及保持该系统处于工作状态；
• 第四，系统需要那些硬件设备才能有效运行；
• 第五，与该系统那个交互的是什么系统；
• 第六，谁或者什么系统对本系统产生的结果感兴趣。

——抽取用例时需要注意什么？特别是用例分析方法？

在用例的抽取过程中必须注意，用力必须是由某一个参与者触发而产生的活动，即每个用例至少一个参与者来启动。如果存在与参与者不进行交互的用例，就可以考虑将其并入其他用例。或者是检查该用例相对应的参与者是否被遗漏，如果是则补上该参与者；反之，每个参与者也必须至少涉及一个用例，如果发现有不与任何用力相关联的参与者存在，就应该考虑参与者是如何与系统发生对话的，或由参与者确定一个新的用例，或该参与者是一个多余的参与者，应该将其删除。

——用例命名应该注意哪些方面？

可视化建模的主要目的之一就是要增强团队的沟通，用例模型必须是易于理解的。用例建模往往是一个团队协作开发的过程，系统分析员在建模过程中必须注意参与者和用例的名称应该符合一定的命名约定，这样整个用例模型才能够符合一定的风格。如参与者的名称一般都是名词，用例名称一般都是动宾词组等。

3. 解读业务调研报告，规划需求用例

3.1 阅读业务调研报告

一般的业务调研报告文档包括，组织结构图及部门职责描述、岗位职责描述、业务流程图及运行节点的描述、数据表单整理。

阅读业务调研中的组织结构图，目标是可以宏观地掌握企业内部组织的结构；把握组织之间的关系；熟悉每个部门的业务内容。通过组织结构的分析，可以宏观地把握系统的范围边界，能够粗略地定位哪些部门业务是系统开发核心部门，哪些部门是业务核心部门，那些部门在系统开发过程中将要克服一些技术难点等。

比如，通过对XXX公司组织结构的了解发现：XXX公司的管理系统开发核心部门在XX部，而技术难点在XX室，业务核心在柜员。

通过组织结构图还发现，扫描室一方面负责XX工作，另一方面是业务员与其他部门之间的资料运输中心，通过这点可以分析在需求开发过程时，将XX室作为数据共享中心来设计。

关于岗位职责，岗位职责的核心内容是介绍每个职能岗位完成的核心工作内容，包括内部接口和外部接口以及处理的主业业务内容。

通过岗位职责的阅读，能够了解到系统中的每个步骤需要完成的工作内容是什么，每个岗位的业务内容是什么。

通过对岗位职责的描述，在需要开发室可以了解到那些业务具有系统的可代替性，哪些业务不具有可代替性，哪些业务如果实现计算机管理在技术实现上的难度等。

在系统中将定位哪些部分作为需求开发的重点，在系统中将定位那些作为系统开发的难点等。

业务流程图，绘制业务流程图的目标是将零散的岗位职责和业务流通过程通过图形化的形式展现出来。那么，业务流程图展现的是，能够清晰地看到所有业务过程中的每个细节行为以及它们的执行条件等。这样，为后期需求开发提供形式化表现内容。特别在业务流程中运行节点描述，可以将业务流程中的每个细节与其他节点之间的关系清楚地描述给需求开发人员，运行流程描述得详细清楚，为用例设计提供了更为详细的流程依据。

3.2 在业务调研报告中归纳需求方法

在业务调研报告中归纳需求，一般按照以下步骤运行：

将业务流程图中所有的运行节点进行归类，按照不同属性进行分析。

对这些业务进行分析，主要是分析本业务工作是否具有系统可代替的性能。如果没有可代替性，就说明不具备需求功能设计的前提条件，应该不予考虑。假设业务具有软件系统的可代替性，那么在此分析业务复杂度，业务复杂度指的在业务处理过程中业务系统处理的复杂程度，过于简单的业务一般情况下不考虑其需求实现。

然后分析共享性，如果一个业务处理的数据不具有数据共享性，一般情况下不归为需求开发的重点，当然复杂度较高的业务可以考虑完成系统开发。

优先级，是系统调研人员对系统的初次判断，假设这些系统是可行的，那么需要分析哪些业务将会是优先级较高的需求。通过对业务节点各个指标的分析，将从业务的角度出发，确定系统功能需求。初步确定系统的功能需求。

解读业务调研报告，将这些节点以表格的形式列出，分别从替代性、复杂度、共享性、优先级、可行性等多方面进行分析。

分析模板如表所示：

（2）在步骤（1）中如果已经确定了初选用例，由于步骤（1）中用例的描述很宽泛，使得在后期需求用例编写时缺乏指导意义，难以确定用例的个数及功能项。需求拆分完成的任务就是将宽泛的用例细化，需要进一步细化用例内容，将用例细化到最小粒度，这样可以方便的编写需求用例了。

如上表所示，分析了哪些运行节点可以成为基础用例，但是运行节点直接用做用例显然是不够的，因为有些用例过度的粗略，无法更加准确地设计用例。需求用例拆分分析模板：

（3）用例补充。当从业务的角度确定了用例后，可以发现仅仅依赖这些需求是无法达到系统开的总体目标的。比如，完成某些具有系统自动处理的用例，需要一些技术业务数据的支持。为满足系统的高效运行，需要增加一些系统维护方面的功能等，包括运行时基础数据的围护以及对系统维护等。

众所周知，用户说做什么就做什么是满足用户需求的前提，要满足用户需求往往不是一个简单地用力能够解决的，需要系统分析员做用例补充，这样才能够满足用户需求。

用例补充分析表如下：

（4）对用例进行汇总，将根据业务分析而导出的用例与补充用例整合起来，汇总成表格，可以作为开发需求用例的基础。用例汇总表模板如下：

（5）将已经确认的系统用例找到对应的至少一个参与者，如果任何一个用力没有了对应的人、系统或某个进程来使用它，否则这样的用例是无效用例。下面就用例参与者以及如何应用这些功能进行分析。

如前所述，如果任何一个用例如果没有参与者，等于用例的存在是没有实际意义的。这里，将系统中每个用例的参与者通过矩阵表的形式，表明每个用例的参与者以及这些参与者对这个用例的操作等。如下表所示，功能需求与参与者确定了用例与参与者之间的对应关系：

其中参与者完成的操作包括增加、修改、删除、查询、对比。根据这5步，基本完成了用例规划和设计。

4. 特别期许的用例规划

上节从功能需求的视角来归纳和分析需求的，但是业务调研报告中关于非业务调研方面的描述也不可忽视，因为某些非业务描述可能要对功能需求具有一定的影响。

比如，地域性分析会影响系统开发中关于安全性设计的要求以及分层问题。

部门变动性分析，影响功能需求用例规划方面的要求，如果用户的部门变动性较强，可以考虑需求用力规划到足够小，然后通过用户权限管理用力动态分配用户权限。

业务流程变化分析决定了是否使用工作流技术的问题。投核保系统中，业务流程的变化非常的大，所以将工作流技术应用于软件实现中，能够做到随着企业管理流程变化而软件应用不受影响。

岗位职责变化性分析，本质上也会影响到需求用例的规划粒度。

文档变化性经常受政策性的影响比较大。如XXX格式会随着政策和需求的变化经常会推出不同的版本。又如，在很早版本XXX的中不设置电子邮箱栏目，但是随着社会的发展，电子邮箱称为投保书的重要内容之一，这样就必须考虑系统实现阶段录入数据中页面中数据变化的灵活性，需要增加特别用例专门用于维护录入数据维护变更。如下面的特别期许用例表所示：

虽然系统用例确认表中的用例能够使得用户系统具有高度的灵活性和可扩展性，但是技术难度和开发周期却相对要长一些，所以通过与客户代表多次的沟通，客户同意在增加一定投资的前提下，系统用例确认表中XXX模板定义用例和用户权限分配用例会优先实现，其他用例计划在二期工程中予以完成，但是要求在一期开发时留有可扩展接口。

5. 小结

业务调研报告是用例设计的基础，首先分析每个运行节点的特性，然后决定是否将运行节点作为用例的依据。

即使某些用例具有系统开发的可行性，也要对这些用例分析，主要是分析用例的粒度大小。

如果用例粒度过小导致用例过于繁琐，未必能够完全满足用户的需求；如果用例粒度过大，更加无法实现用户需求了，所以需要对用例进行合理的拆分和合并。

当确定初步用例之后，需要对用例分析，分析其优先级以及是否在合同范围内的需求，如果两者都不能够满足，就应该放弃本用例的开发。任何一个用例如果没有了参与者，这个用例就没有存在的必要性。在确定了用例和参与者的关系之后，需要对用例进行最后一次的甄选，一旦用例甄选后并且用户以书面的形式确认了，那么这个用例表将作为软件开发所有活动的唯一入口，也是软件开发的唯一依据，软件开发所有的活动间围绕着本用例展开。

本文素材来自互联网