对小公司的产品经理来说，经常会要求写需求用例。这篇文章， 作者分享了如何又快又好写好需求用例的方法，供大家参考学习。

一、什么是需求用例

用例（Use Case），指实际工作中可能发生的场最。在需求分析阶段的用例，称为“需求用例”，是指用户通过产品解决特定问题、完成指定任务的方式与步骤，也包括各步骤用到的约束、规则等。一个用例，往往对应着用户需要完成的某个明确而具体的任务。

但也有两种特殊的用例：一种是上层用例，另一种是底层用例。

• 上层用例，指结合一些有关联的普通用例完成一个抽象的由若干普通任务组成的大任务。
• 底层用例，指完成某些小任务的用例，这种用例可能会在许多普通用例中被引用。

二、用例的构成

一个完整的用例，一般包括：用户、前置条件、后置条件、主场景、扩展场景、规则等方面。

1. 用户

用例的重点在于用户的操作场景，在考虑用例的场景之前，需要先确定用例的用户，因为所有的使用场景都是为某些特定的用户服务的。一个用例可以面向一种或多种用户，例如，用例“仓库结账”，只是面向仓库核算员的，而用例“仓库交易分析”，会面向多种用户，如仓管员、核算员、计划员、采购员等。

根据面向的用户不同，可以将用例分成几大类：面向普通用户的用例、面向关键用户的用例、面向系统管理员的用例、面向所有用户的用例。

• 面向普通用户的用例，是普通用户从事业务处理的用例。由于使用者是一般工作人员，学习能力、文化水平、软件知识参差不齐，设计这种用例时往往会在易学性、健壮性、易用性上下更多的工夫。这种用例设计得不好，会影响工作效率。
• 面向关键用户的用例，主要用于系统数据的初始化、业务功能的配置、基础数据的管理等，如“用户管理”“仓库配置”“组织结构建立”之类的用例。使用这种用例的用户，虽然没有系统管理员对软件理解深刻，但对软件比较熟悉，使用这种功能进行操作对系统的影响非常大，但一般来说影响的幅度与程度不及面向管理员的用例。
• 面向系统管理员的用例，主要用于系统配置、运行监控、异常分析，功能维护等，这些用例一般会涉及系统的正常运行，操作稍有不慎就可能导致系统异常甚至崩溃，所以一般只能给系统管理员使用。
• 面向所有用户的用例，提供给所有登录本系统的用户的用例。如“修改密码”“工作日志”之类，只要是登录本系统的用户，就可以使用这些用例。当然，既然是面向所有用户的，自然也应该归于面向普通用户的用例，这是一种特殊形式。

2. 前置条件

前置条件，是为了保证本用例可以成功执行，而需要满足的前提条件。例如，在某电商网站，用例“下订单”的前置条件是会员登录成功，并且会员信息中的一些必备资料填写完整；用例“撤销订单”的前置条件是会员登录成功，并且订单还没有发货：而用例“退货”的前置条件是订单已经发货。

3. 后置条件

后置条件，是指用例执行结束后的系统状态，无论成功还是失败。例如。年前一般都会取现金包红包。就拿这个举例来讲，银行ATM机，用例“提款”的后置条件是：如果用例执行成功，ATM机钞票减少，减少额等于用户的提款金额；如果用例执行不成功，ATM机钞票不变，用户的银行账号余额不变。

4. 主场景

“场景”指用户使用软件功能完成工作任务的操作过程。场景是由一系列人机交互的步骤构成的，强调的是人做了什么操作，机（软件系统）有什么应答，来来往往，经过若干回合后，结束了某项任务，有可能成功，也有可能不成功。

由于用例都是有明确的任务的，因此，每个用例都应该有个主目标，这个主目标就是支持用户通过这个用例完成某项具体任务，但为了使这个目标实现得更高效、更准确、更容易，犯了错误可以得到纠正，一些异常事件可以得到处理，需要软件提供一系列的额外功能。

根据二八法则，平均下来应该有20％的功能是用来完成主目标的，而80%的功能是为了提高效率、降低错误率、纠正错误的。

例如，用例“仓管员根据采购单收货”，它的主要目标是将收货记录录入到系统，因此录入并保存收货记录是主目标。

而编辑功能是为了纠正错误或应对变化，删除功能是为了纠正错误，导入功能是为了录入更快速，这些都不能称为这个用例的主目标。

用户为实现自己的主目标而进行操作的过程，称为用例的主场景。大部分情况下，一个用例只有一个主目标，只有**一个主场景。**如果主场景不明确，往往说明这个用例是上层用例（文章开头第二段有解释，忘了的回去看）。

例如：“会员登录”用例主场景包括：用户录入会员卡号、密码，登录成功这个过程。

别的处理密码输入错误、忘记密码之类的场景，不属于主场景，因为用户到这里是为了登录，输错了密码，或者忘记了密码只是一些意外情况。

主场景是实现用户主目标的过程，但未必是最常用的场景。例如：“文员进行客户档案维护”用例，录入客户信息是这个用例的主目标，是主场景，但最常用的场景却是浏览客户信息。所以，我们要注意判断。

5. 扩展场景

每一个用例，都有各种各样的使用场景，主场景只是若干种场景中的一种。主场景之外的场景，称为“扩展场景”。例如，一个简单的用例“用户登录”，主场景是用户输入用户名、密码，验证成功后进入系统。但还有别的可能，如用户密码输错了怎么办，用户忘记了密码怎么办等，这些都要有相应的处理场景，称为扩展场景。

用“用户登录”的扩展场景用例，列举2个场景进行分析，包括：密码输入错误、用户忘记密码。

扩展场景一：密码输入错误。

• 用户录入用户名、密码，确认登录。
• 系统验证用户名、密码，密码验证错误，提醒用户只允许输入三次。
• 用户重新输入密码。
• 系统验证密码，如果验证正确，则进入系统。如果验证错误，且输入已经超过三次则锁定该用户，并提醒用户账号已经被锁定，如果没有超过三次，则用户重新输入密码。

扩展场景二：用户忘记密码。

• 用户录入用户名、密码，确认登录。
• 系统验证用户名、密码，密码验证错误，系统提醒是否需要取回密码。
• 用户确认取回密码。
• 系统发送验证短信到本账号所绑定的手机。
• 用户提交短信验证码。
• 系统确认验证码正确。
• 用户录入新密码。
• 系统将当前用户的密码重置为新密码。

6. 规则

规则是指本用例用到的业务规则、逻辑算法等。有的用例逻辑简单，几乎没有什么规则；无非只是些数据的录入、保存而己，而有些用例，逻辑非常复杂，需要进行大量的运算、判断，在这种情况下，就需要整理进行运算、判断的规则。

在这里整理的规则更倾向于用户，描述用语以一般用户能理解基本要求，应当尽量避免使用太多技术化的IT语言，另外，这里也不是用户在需求调研时提供的规则的简单记录；应该有一个整理、分析、抽取、加工的过程。

三、总结

在互联网软件研发工作中，大家听到最多的是测试人员写的测试用例，需求用例听到的相对较少，但是需求用例也是非常重要的。由于在实际工作中，产品经理的工作内容比较繁杂，而且很多时候是多任务并行，不一定会产出像测试那么细致的测试用例文档。 但是我们在思考产品功能和撰写PRD文档时，要有必要的需求用例思维，去设计和验收产品功能。

目前主流互联网公司，大多采用敏捷研发。至于产品经理是不是需要写需求用例，根据公司情况、部门要求、任务的复杂程度、自己的工作任务灵活决定。 所有的工具和方法都是为了辅助我们，更好的完成工作的，不可生搬硬套而忽略了自己的实际情况。

专栏作家

忻芸，人人都是产品经理专栏作家。专注于B端、SaaS产品，擅长技能用户体验设计、交互设计、用户研究、数据分析、项目管理。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。