打开“需求用例”的正确姿势 - 你 get 了么？

需求用例是由需求分析到最终实现的第一步，用来描述用户如何使用一个系统。

忙碌了近一个月的项目，最近终于有点正式进入轨道的意思了，也可以抽出点时间来分享分享最近学到新知识了。上次分享了营销学的４Ｐ理论和４Ｃ理论，反应还不错，浏览量算是出乎我意料了，说明咱产品同仁们的学习欲望还是很强烈的，有兴趣了解的可以关注查看。

那么今天我们就来聊一聊“需求用例”那些事儿。

• 什么是“需求用例”？

需求用例是由需求分析到最终实现的第一步，用来描述用户如何使用一个系统。用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约，需求用例描述了在不同条件下，系统对某一项目相关人员的请求所作出的响应，是系统执行的动作集合的规格说明，包含有用例图和文字描述的部分。

• 何时要用到“需求用例”？

需求用例的文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他是PRD中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。

• “需求用例”怎么写？

１、工具

Word Visio Axurerp等，可根据自己使用习惯选择。

２、内容

（１）、描述涉及到的角色－参与者

即与系统发生交互的角色，参与者通过向系统输入或请求系统输入某些事件来触发系统的执行动作，参与者可以是人、设备、外部系统等。例如一台电脑操作系统的参与者可能有普通用户、管理员、系统维护员等等。

（２）、用例

针对某个特定的外部参与者，系统通过与其交互而执行的，能够产生可观测、有价值的结果的一个动作序列。例如使用贴吧，可能涉及到的用例有注册、登录、发布帖子等等。

用例之间有三种常见的关系：包含、扩展、泛化。

包含《include》 ：一个用例可以简单地包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。包含用例执行，则被包含用例必须执行。例如网上预订这个用例就包含了填写电子表单这个用例。

扩展《extend》 ：基础用例之外的增量扩展，一个用例可以有多个扩展，但基础用例的执行不涉及到扩展用例，只有特定条件发生时，扩展用例才被执行。扩展用例是指向基础用例的，一个用例中有许多替代物或选择时，使用扩展关系可以流畅的管理变更。例如指向打电话的扩展用例可以有呼叫等待、呼叫转移等等。

泛化《generalization》 ：一个用例可以被特别列举为一个或多个用例，在泛化关系中，子用例表示父用例的特殊形式，当父用例能够被使用时，任何子用例也可以被使用。例如订票的泛化用例可以有网络订票、电话订票等等。

（３）、用例描述

对指定用例的功能定义、要实现的业务需求，以及参与者该如何使用进行描述。同时，这部分还可以整体概述实现业务需求的主要流程，以及与其它用例、其它外部系统的关系。通过用例描述，阅读者可以对该用例有一个整体的认识。

上图是一个比较简单的用例描述模板，基本包含了所涉及到全部信息。需要特别注意的就是其中的异常和分支事件流，即用例失败的事件，往往容易被漏掉，导致后续系统突发异常时，不能及时有效的解决。下面举一个实例：

• 写“需求用例”的五个要点

使用例易于阅读

文档尽量短小明了、易于阅读，只写真正需求的东西，不写与需求无关的。从头开始，用一条主线贯穿始终。顶部是一些对全局有重要意义的用例，再从这里分离出用户目标和最终的子功能用例。从触发事件开始一直连续，直到目标实现或者被取消。确保每一步中参与者及其意图是可见的。突出失败条件，并使恢复动作是可读的，最好是不必为每个步骤编号，人们就能清楚地知道下一步该做什么。

仅使用一种句型

在编写用例的每个执行步骤的时候，只采用一种句型：现在时态的句子。在主动语句中使用主动动词。描述参与者成功到达的目标，这些目标推动了整个过程的前进。在扩展的条件部分可以使用不同的语法形式，这样就不会使它和执行步骤产生混淆。

“包含”子用例

当有子用例加入时，大部分都使用“包含”关系，混合使用包含、扩展与泛化往往使读者产生混淆。也就是只在必要的时候使用扩展，当然在框架（Framework）设计的时候使用泛化有一定的好处，但只是在需要的时候使用。

两个结局

每个用例都有两个可能的结局：成功和失败；当一个执行步骤调用一个子用例的时候，被调用的用例可能成功也可能失败。如果是在主事件流中调用，则把失败处理放在扩展中。如果调用来自扩展，则成功和失败的处理均放在同一个扩展中。

项目相关人员需要保证

用例不仅仅记录了主参与者和系统之间公共可见的交互操作。系统是为了达到项目相关人员利益上的目的。其中一个相关人员便是主参与者，在一般的用例格式中，其它相关人员并没有被列出来。但是用例需要满足这些项目相关人员的利益，并提供满足这些利益的保证。

一般主事件流和它的扩展瞄准了项目相关人员的利益，所以从主事件流开始阅读，看看是不是考虑了所有相关人员的利益。例如，没有想到失败，因而没有记录下恢复信息。

欢迎大家一起讨论相关的问题！共同学习 共同进步！

文\JeremyLIN 微信公众号：NewbieCamp

关键字：产品经理

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！