Question

我们如何正确使用Use Case？

Answer 1

    Use case, 作为UML重要的组成部分和类图，时序图，状态图，活动图等一同经常出现在各类产品设计和开发文档中，但Use case图却在实际运用UML图例化表达中，显得比较尴尬。不知你有没有这种感觉，我们的设计文档对于Use case的要求往往只是形式化存在，不是寥寥草草画几个收场，就是根本不画。那Use case 真的就无用了吗？

    和Use case相比，产品经理更喜欢用界面原型来表达用户和产品的交互，也难怪，想想最早的Use case概念是：Ivar Jacobson在1967年定义爱立信AXE系统的构架时开始提出的，毕竟那时的人机交互还是非常生涩难懂的，时隔半个世纪了，现在的设计理念更提倡简单，直观，所见即所得的模式。

架构师和开发工程师会喜欢用Use case吗？答案是：不，他们更喜欢用序列图，活动图，状态图等更细节和系统化，参数化的设计方式，来表达系统状态，数据变迁和行为，而用类图表达信息的静态结构。

测试工程师会用吗？也不会，她们直接根据功能设计和界面原型编写测试用例，测试用例（Test case）不同于Use case，测试用例更加系统化，更强调严谨的输入，输出定义。

那谁会用Use case呢？ 呵呵，经过上面的分析，你肯定觉得Use case就是鸡肋啊，完全可以废弃掉了。你先别忙，我还没有讲完，这并不是上面这些角色的错，也不是Use case完全无用，只是我们经常把Use case用错了地方， 其实Use case是业务分析过程而不是设计过程，准确来说Use case是衔接业务分析和系统设计的承上启下的过程。

    在软件工程中我们通常把软件的研发过程大体分为：分析，设计，开发和测试四个阶段，而在目前以电商经济作为主导的互联网产品研发体系中，对于软件的分析过程我们的确很容易忽略，这里不是说电商系统不用分析，而是由于这个行业同质化的产品太多，借鉴和抄袭的效率更高，那谁还愿意认真分析业务本质呢？

Use case被忽略的另一个原因是对敏捷开发的一些误解，敏捷开发提倡的是快速交付，用客户检验设计优劣，用市场检验产品成败。这就容易让我们误解为软件或者所服务行业的业务分析就不需要了，其实分析-设计-开发-测试的过程就像语言中的主谓宾结构一样，无论你用什么样的语速或者花哨的修辞手法，基本结构是不会变的。

敏捷的研发体系其实是一改过去传统的整体系统全部分析完成结束后，再进入设计和开发阶段的方式为：单一业务过程场景分析到设计到开发到测试的方式。而至于单一业务过程场景的划分粒度，可以参考我之前的文章： 《初建电商优先关注的7个流程（一）》 。

如果大家认同以上观点，我们继续聊聊Use case到底有什么用和怎么用？本文并不是讲解如何绘制UML的Use case图，因为网络上有太多这方面免费的介绍，你连书都可以不用买，就能理解。我们重点聊的是怎么使用Use case才能让它的功能发挥出来。

前面我讲到Use case是衔接业务分析和系统设计的承上启下的过程，目前在软件工程中对Use case常用的定义是：Use case是一种在开发新系统或者软件改造时捕获潜在需求的技术。其实仔细理解定义，你就能明白“捕获潜在需求”其实就是一种系统的分析过程。Use case最适合使用在对抽象业务过程活动开展进一步分解的过程。

下来我们将通过Use case和业务过程（Business process），界面原型和系统设计的相关关系讨论来认清Use case定位和作用。

一. Use case和业务过程分析的关系：

    要讲Use case就首先要讲讲什么是业务过程（Business process），因为他们是相辅相成的，Business process 在维基百科中的定义中是：一组相关的、结构化的活动或任务，它们为特定的客户或客户群体，提供特定的服务或产品(为特定的目标服务)。这里用Business process而不是用Business Flowing，是想和workFlow 区分开，WorkFlow是更系统化，更严谨，更技术化的活动描述。而Business process则和系统和技术无关，有些时候纯粹描述人工业务过程，这是真正描述业务需求的一种方式。 而业务过程分析和Use case分析各有侧重点，业务过程是采用流程化的方式表达业务发展的连续性和方向性；而Use case则重点对单个业务活动，开展面向对象的解构分析。

例如：我在 《初建电商优先关注的7个流程（一）》 中说到的： Request-to-answer（请求到响应）过程中所绘制的：

Request-to-answer过程是一种业务过程，他是企业运营体系中若干业务过程中的一种，因为他满足了从客户发起到满足客户为终止end2end的原则，所以我们可以可以单独分析该过程，这也符合敏捷理论的快速响应，闭环分析，最小价值开发理念。

Use case的作用是以人机交互和用户为中心的方式通过分析业务过程中的这些业务活动实体场景（比如：上图中的咨询，判断销售前景，匹配产品，提供销售建议书等），获取该活动详细的功能性需求。对， Use case是形成功能性需求的关键 ，所以是需求分析/系统分析工具，所以如果你已经先有了系统功能，再做Use case 分析你就会发现Use case完全是多余的， 这里再次重申Use case不是设计工具，而是业务分析工具。

为了证明此观点我们可以看看，UML 图例的主要结构：

从上图中我们可以看到Use case 是由Actor，case，relation，system/module构成，而这中间的关系又主要分为：包含，泛化，使用，扩展。怎么样？看到这些图例是不是觉得：这不就是用面向对象的系统思维方式来分析和解释业务活动嘛！对，当我们在处理陌生需求或者业务活动时，要将纯粹的业务需求和过程转化为面向对象思维的系统需求，就需要作Use case分析。这时是没有具体功能，没有类模型，没有数据模型，最多只有大致的系统或者模块。

二.  Use case和界面原型的关系

    在做Use case分析的时候，也许你已经有界面原型（因为当下的设计潮流是提倡界面原型和需求分析同步的，界面原型同时也是客户需求确认的工具），但你绝对不要在Use case中去表现界面需求或者用界面需求反推导出Use case，因为Use case的分析重点是分析业务过程的发生的本质（采用5W1H分析），有些可能有界面，有些则可能没有，有些是抽象实体，有些是实例实体。而界面原型的重点是用显性，可视化的表达手段，把业务过程分析的结果表现出来。 

例如上图中的：用户登录，泛化出了昵称登录和手机号登录两个case（实体），而在界面设计中也许是一个界面（通用登录界面），也许是两个界面（交互设计师会有一大堆理由告诉你那种设计更好，但一般没有一种是按照用户 业务可能性驱动 分析的，因为交互设计师不喜欢研究业务过程，哈哈！交互设计师不要打我哈！）。如果我们用界面设计来反推导Use case，就非常容易限制我们业务发展的可能性，上面的例子中，按照业务过程的抽象和泛化的分析结果，你完全还可以得出用扫码登录方式的case。所以Use case和界面原型是相互验证的关系，而不是相互替换。 而Use case的另外一个作用就是分析业务可能性。

三. Use case和系统设计的关系

    这里讲的系统设计涵盖了UML常见过程如：模块设计，类设计，时序设计，系统活动设计，以及领域驱动设计中的信息模型设计。Use case 分析除了能产生功能型需求和提供业务可能性分析外， 它还能为后续的系统设计提供了结构化设计和行为设计的一手素材 ，因为整个分析过程采用了系统化的面向对象的分析方法。

所以说Use case提供了用系统化语言翻译客户需求的能力，编写或者绘制Use case的人一定是业务分析能力和系统思维能力的结合体。Use case是衔接业务过程分析和系统设计的关键环节，Use case的好坏直接关系业务的可能性，是否能在系统功能上体现。

要作好Use case就要求产品经理要有足够的系统化思维，架构师要有足够的业务过程分析思维，但这却是目前互联网研发体系中比较弱的一环。在有些大型IT企业中，其实还有一类介于产品经理和架构师的角色：系统分析师或者业务架构师，只是因为由于目前产品经理角色在行业内兴起，大有逐渐代替了他们的趋势，但他们的实际工作内容却容易被遗忘，所以如果你的企业看中业务分析的能力，要不就要求产品经理具备有系统化分析思维，架构师具备业务过程分析思维，要不就请设置系统分析师和业务架构师的角色，只有这样才能真正将行业内的业务需求挖掘，转换和扩展延伸为优质的产品。

    确定Use case 的分析粒度，其实是整个分析过程中最麻烦的部分，也是最容易被大家忽略的地方，被忽略的结果就是我们选择的Use case既没有代表性，也没有承接性（承接业务过程分析），更没有全面性，而一旦Use case没有办法提供详细，完整的功能性需求和系统设计需要的结构和行为分析，Use case就变成了一份如同鸡肋般的形式化文档。

一. 首先，需要确定Use case 表达的粒度：

Use case 是衔接业务分析和系统设计的承上启下的过程，所以它一定不是靠经验，孤立设置或者直接拍脑袋定义出来的，它必须遵循业务分析的延续性，从业务过程分析到Use case的分析就是这是这种延续性，而Use case的粒度定义可以设置在业务过程中的业务活动上。 注意：设定Use case的基点就必须是业务过程中的活动而非界面结构。

以 《初建电商优先关注的7个流程（一）》 的Order-to-confirmation（订购到确认）为例，我们要建立Use case的分析粒度要从业务过程中的业务活动开始，也就是说我们需要对：发布订单，费用计算，拆解订单，交付产品，评估和跟踪，确认完成等这些活动，分别建立Use case描述。

这边特别要指明，Order-to-confirmation（订购到确认)只是抽象业务过程，由于行业的差异性和复杂程度不同，一个业务活动可能会继续拆解成更多业务活动，比如：“拆解订单”，就会分为“分解产品订单，分解服务订单和分解资源订单”等三个。请注意这里的业务活动不是指系统的具体操作步骤，所以千万不要把业务活动的最后分解为：增加，删除，修改，插入，查询等这些具体系统操作上，因为这些操作是建立在系统实现上的，而非业务分析的基础上。

把Use case建立在业务活动上的原因也正是看重业务活动无系统限制，无技术约束。业务活动一定是展现一种业务发展的可能性，而不是具体系统实现，Use case的粒度也是如此。

二. 其次，有了Use case 的粒度，我们怎么来生成Use case呢？我介绍一个生成Use case的方法。

    我们要为每个Use case提供一个脚本描述，描述要简洁意骇，而且基本语句结构要符合语句为：时间，地点，谁，做了什么，怎么做，为什么做的5W1H模式，而最终影响Use case 的变量需要系统分析师、业务架构师或者产品经理根据业务特征决定。

我们以Order-to-confirmation（订购到确认）中的“发布订单”的业务活动为例，建立了如下Use case分析模型如下：

    这是一个最简单也最有效的Use case生成工具，首先，由业务架构师定义和选择，可以影响该业务活动的 业务可能性 的维度，你可以参考5W1H方式，图中所提到的“时间区间”，“客户类型”，“渠道类型”，“订购方式”，“产品类型”和“触发条件”，只是我举例的维度，你可以根据自己行业的业务特征，定义自己的维度。定义维度的要点是寻找Case的差异性，如果无差异维度，可以直接丢弃掉，如：上午和下午对于发布订单的活动并无差异性，就忽略掉。其次，需要填充相关维度参数，也许是某种类型或者具体的实例。最后将这些维度参数做笛卡尔积运算，就能得出最直接的Case。

我们大多生成Use case的时候，都缺少方法，用经验也罢，看界面原型也罢，以至于拍脑袋等方式都很难保证不遗漏我们分析的 业务可能性， 所以我建议你采用以上方法试试。当然你看到有432条Case的时候肯定要疯了，什么，这么多？其实这432条Case只是 业务可能性 的Case，你可以根据自己行业的业务特征，用排除法很容易的就能排除掉不可能的，无效的，无差异的Use case，实际使用的Case，就能控制在2位数以内。

也许保留下来的就是：“晚上新客户，接受了平台推荐的商品，在线上自有渠道采用商品比较分析的方式订购了家电产品” 等，这就是Use case的脚本。而基于这个脚本你就可以接下来绘制Use case 图例了，而从中分析出业务的功能性需求，结构模型和行为模型的初稿和业务可能性。这里就不再讲述Use case UML图例绘制的过程，您可以参考UML 的Use case文稿。

三. 最后，我要再澄清一个业界关于Use case的概念争议

    对于Use case 业内有两种不同看法，一种认为Use case是抽象视图，往往不用带上具体的业务参数。另外一种认为Use case就是实例，是被参数化的视图。这两种说法都各有道理，前提是有没有把业务过程分析纳入和Use case的关联分析中，我们知道业务过程分析本身就是一种抽象分析，业务过程本身也有抽象过程和实例化过程之分，抽象过程用于系统分析，实例化过程用于系统工作流设计，而Use case承接的抽象化过程，所以对抽象化的业务活动进行实例化分析就是有必要的。而这个实例化其实也不是最终的系统实例化，因为在Use case创建过程中需要选择有差异化的Case，从而进行业务差异化分析，所以我们可以认为Use case的case实例化是有限度的实例化。

    本文并没有去重点阐述具体UML 的Use case绘制方法，因为你去百度一下，既能得到很多相关方法，我把重点放到了Use case到底有用无用和Use case如何生成的讨论上，我14年的系统设计，开发经验告诉我，很多的工具和方法如果不关联使用，不去了解它存在的意义和实际业务目的，那我们往往做出来的是形式化设计，对产品和系统不会有太多帮助。

Use case就有这样的问题，首先我们要搞清楚它是分析过程，不是设计过程，它是对业务过程分析到系统设计的承上启下的过程，如果不搞清楚这个问题，Use case可能对产品研发各角色来说都是鸡肋。

其次，我们要知道Use case到底能为我们提供什么？ 它可以帮助我们 分析功能性需求 和 业务可能性， 这是我觉得最为重要的部分，也就是说如果我们已经有了功能性需求或者限制了业务可能性的分析，那你再做Use case都会觉得完全是多余的。

再有，我强调了Use case的粒度选择一定要放到业务过程分析中的业务活动中，这样的分析过程才具备设计的连贯性和最小代价的完整性，这也符合敏捷设计的理念。

最后，我提供一套生成Use case的方法，可以帮助你快速生成有限实例化的Case，我们可以通过差异化的case分析， 生成功能性需求和业务可能性 ，并且为后面的系统结构化设计和行为设计提供必要的设计参考。

好了今天就到这里了，年前希望能再写一篇文章，题目待定。祝：各位新春快乐！