用例与用户故事

系统是由相互作用、相互依赖的若干部分结合而成的。系统可以由硬件组成，也可以由软件组成，还可以由人组成。一个系统可以包含另一个系统。

用例是对参与者发起的一组动作的描述。系统响应这组动作，并产生可观察到的显著结果。

换句话说，用例是用户在系统上做的事情，表述为“动词 + 宾语”的组合。事情就是任务或动作；动词强调的是人做出来的动作，而这个动作可以是一个动作，也可以是几个动作。

参与者是在系统之外和系统交互的人或物。可以进一步把参与者分成两类：

系统之外的人：会和系统交互，称为参与人或者使用者。这里强调交互对象是人。
系统之外的物：也会和系统交互，称为参与系统。这里强调交互对象是物。

所以，参与者 = 参与人 + 参与系统。

参与人可以分为主要参与人和辅助参与人。主要参与人也被称为启动人，辅助参与人也被称为支持人。

主要参与人是产品存在的原因，会主动发起一项业务。辅助参与人是支持产品运转的人员，会被动地响应业务请求。一个人既可以是辅助参与人，也可以是主要参与人。通常来说，产品经理应该先梳理主要参与人的需求，然后再梳理辅助参与人的需求。

干系人是对产品提意见的人，参与人是和产品进行交互的人。

有时候，一个人可以既是干系人，也是参与人；也可以只是干系人，而不是参与人。换句话说，参与人是干系人的子集。

参与人要使用产品，干系人可以不用。参与人是个体，而干系人可以是个体，也可以是组织。

通常来说，“参与人”比“角色”的表述更准确。因为“参与人”强调的是人的操作，而不是角色的操作，并且“参与人”的概念已经被业界普遍接受。

对于“角色”来说，抽象出角色的目的是梳理出相应的权限。

参与人既可以写成一个人的名字，也可以写成一个职位。参与人可以采用灵活的写法，这样就避免了一开始就考虑角色能做什么事情，也避免了陷入细节之中。

同时，因为对参与人的表述是灵活的，产品经理还可以带入不同类型的人，思考如何提供服务。

虽然角色和参与人的概念有区别，但把角色作为参与人，或者把职位名作为参与人，都没有问题。无论哪种做法，都不影响用例的表达。

参与系统可以和产品进行交互，但无法对产品提意见，所以不是干系人。

干系人只能是人或组织，而参与系统只能是软件或硬件。因此，我们说参与系统不是干系人。

产品经理不用把重点放在找参与系统上，但需要知道参与系统能提供什么信息或功能。

回到我们对“用例”这个概念的分析。用例有三个主要特点：

有宽度地梳理业务。

要想做到有宽度地梳理业务，就要有层次地进行梳理，不断把大的需求有层次地拆解成小的需求。虽然用例的定义里没有说用例的层次，但用例是可以分层的，可以分成目标层用例、实现层用例和步骤层用例。我们使用用例方法，是为了拓宽度，而不是增加深度。所谓深度，是指异常情况、分支流程之类的内容。

用例是业务梳理的起点。

用例描述了用户做的事。只有明确了用户要做的事，才会在宽度上不遗漏功能；只有明确用户要做的事，才会有描述该事情的流程图、状态图和原型图等内容，从而在实现、深度上不遗漏细节。

用例是定义功能的起点。

很多时候，用例和功能有一定的等价关系。

综合上述用例特点的分析，我们不难得出用例的本质：用例分析技术的核心在于用户视角的需求观，强调目的和场景的重要性。而用例图本身并不是本质。

在得出用例的特点和用例的本质之后，就可以知道用例可解决的问题有两个：

产品经理不会拆解任务。
在产品设计过程中经常遗漏功能。

如果采用面向功能的梳理，就必然导致产品无法满足需求。

用例的粒度是由组织分工决定的。前面我们说到用例及业务场景，而一个完整的业务场景应该是独立的、可汇报的、可暂停的单元。

对于不带业务流程的项目或者产品来说，用例就是一个用户的使用场景，也是一个相对独立、可以暂停的场景。

用例之间有两种关系：

包含关系：一个用例可以由多个用例组成。上级用例是下级用例的概括，下级用例是上级用例的细化。在这种包含关系里，还可以进一步表明可选关系。
实现关系：一个用例可以由多个用例来实现。

虽然用例描述了用户做了什么事，但如果这些用例没有层次和顺序，就会导致遗漏一些需求。产品经理固然可以凭借经验来梳理，但内容仍然很多，这就需要我们对用例进行分层。

用例可以划分为目标层用例、实现层用例、步骤层用例。

目标层用例要从“目标”和“用例”两方面来理解。既然称为目标层用例，那么该事物既是目标，也是用例。其中，目标是指用户使用系统的理由，或者要达到的效果；用例是指用户实际做的一件事。用户想做的事情有很多，但符合目标层用例的事情并不多。

要想分清目标层用例，就要注意以下几点：

用户在做完一件事之后就满意了，不需要做其他事，那么这件事就是目标层用例。
员工的目标层用例判定标准是：工作完成了，就是目标达成。员工的目标层用例往往就是员工的工作职责。
能够让用户满意离开的事情就是目标层用例。但是要注意，不应体现具体实现。
如果目标的判定比较模糊，也可以追问一下：要做的工作或者解决的问题是什么？

在梳理目标层用例的时候，要注意两点：

目标层用例可以再进一步分层表述，也就是拆分成大目标和小目标。
注册是目标层用例，但登录不是目标层用例。不过，我们在实际工作中可以不做这个区分。

为了实现用户的目标层用例，产品经理需要定义产品如何实现。这个实现方法就被称为实现层用例。

一个实现层用例同时也是一个解决方案，但实现层用例只是解决方案的子集。区分目标层用例和实现层用例是一个好习惯，有助于产品经理思考：为了满足业务目标，有哪些可选方案；但这些方案并不一定是必须要做的。

无论实现层用例是什么，都需要由系统来实现。用户使用系统的过程，就是一步一步的操作过程，这就是步骤层用例。

同时，对这些步骤进行拆分和合并，就可以划分出产品的设计单元。划分出产品的设计单元，是步骤层用例的目标，也是整个用例分析的最终目标。

做步骤层用例拆分时，可以按照页面来梳理步骤。但要注意，每个步骤都应该在同一个层面表述，不要出现有的步骤拆分过粗、有的步骤拆分过细的情况。如果无法在一个层面表述，可以将这个步骤拆分成多层。最后，还要注意去掉不必要的步骤。

进行步骤层用例拆分，是为了梳理出用户的操作步骤，避免需求遗漏。但我们还应该通过用例合并来划分出设计单元，这样产品经理可以分单元设计产品。合并的原则是：如果该步层用例比较小，就要合并这个步骤层用例。

步骤层用例没有严格的定义和划分，提炼时也比较灵活。虽然提炼很灵活，但步骤层用例也有认定原则：

大小适中。用例的目的是划分设计单元，而不是理清业务细节。一个用例就是设计细化的起点，在这之后才有这个用例的流程图、状态图、页面流程图、原型图等等。
高内聚、低耦合。每个步骤都是相对独立的，但步骤之间也有联系。用例内的多个功能紧密结合，这就是高内聚；用例之间也有联系，但并不紧密，这就是低耦合。

我们在对用例进行分层的时候要注意：思考应该结构化，但不应该过度结构化，也不应该过度区分层次。要更关注如何控制用例的大小和数量，不要过度细化，也不要过粗。只要划分层次合理，数量和大小合适，不遗漏需求即可，没有绝对的用例划分方式。

通常来说，一个中型软件系统的目标层用例数量为一层，每层 10 个用例以内；每个目标层用例下的实现层用例数量为一层，每层 1~3 个用例；每个实现层用例下的步骤层用例为一到两层，每层用例数量在 5 个以内。

在梳理用例的时候，要先梳理用例，再提炼设计单元。用例是在梳理用户的目标、实现的方案和执行的步骤，而执行的步骤就是设计单元。

用例不等于功能，两者是一个抽象过程、一个转化过程。用例这个方法比较适合梳理流程类业务，并且这些业务步骤较多，但业务本身通常并不多。

用例不太适合分析信息类内容，比如个人中心、首页或者详情页。这些页面以信息展现为主，没有太复杂的流程，可以直接画原型图。如果某些功能产品经理非常熟悉，也可以不做用例分析。

梳理出用例之后，就需要将用例正确地表达出来。通常来说，要画成用例图。

用例图有如下几个要素：

小人图案代表的参与者：代表参与人和参与系统。无论是哪种参与者，都可以用一个小人来表示，在小人下面写上参与者的名称即可。
椭圆形包裹的用例：用例名的写法为“动词 + 宾语”。宾语既可以是名词，有时也可以省略。
方框代表的系统：一般是在方框的上方写上系统名。方框要有边界，边界内部是系统要实现的用例，边界外部都是系统外的参与者。
用直线表示的关系：用直线连接参与者和用例，表示参与者和用例之间的关系。

当然，用例除了可以用用例图表达，还可以用文字形式的用户故事来表达。因为“用例”这个概念不容易理解，知道的人也不多，所以工作时可以将“用例”改成“用户故事”来表述。而用户故事在本质上还是用户视角，也具有业务场景的特性。

用户故事是一种轻量、有效的用户需求描述方式。用户故事期望用户或用户代表以“作为×××（角色），希望通过系统×××（解决方案、功能要求），以便达成×××业务目的、解决业务问题”的形式提出需求。

在梳理用户故事的过程中，不仅要梳理用户行为本身，还需要深入思考用户是如何完成任务的，是否存在替代方案，达成目标的有效路径，以及出现问题时的应对方式。

所以我们重新看一下用例和用户故事的关系。

用例本身是对系统分析的高层次设计抽象，通过对多角色的定位，基于流程梳理结构化的功能块。虽然它不是从体验和场景出发的，但也很适合软件设计本身的抽象要求。

用户故事是一种低粒度、基于场景的功能点描述，能够更好地贴合场景，而且应用灵活。但是用户故事缺少整体性的分析和定义，在功能细节的描述上也不够丰富。用例可以被拆解成用户故事，但很难通过用户故事还原用例的全貌。

对于 B 端产品设计，这种高度复杂的业务和抽象，单纯通过用户故事不可能把软件设计的全貌呈现出来。所以在实践里，一般采用用例和用户故事组合的方式，结合用例设计的思维方式，对软件背后的业务和需求场景进行整体的抽象梳理。

在具体的单一场景下，可以通过用户故事进行需求描述；在整个产品设计过程中，可以不编写繁重的用例说明。但是一定要知道如何从业务流程中梳理抽象业务。可以只通过用户故事描述功能，但是也要认识到用户故事的局限性。