对小公司的产品经理来说，经常会要求写需求用例。这篇文章， 作者分享了如何又快又好写好需求用例的方法，供大家参考学习。
———— / BEGIN / ————
什么是需求用例
用例（Use Case），指实际工作中可能发生的场最。在需求分析阶段的用例，称为“需求用例”，是指用户通过产品解决特定问题、完成指定任务的方式与步骤，也包括各步骤用到的约束、规则等。一个用例，往往对应着用户需要完成的某个明确而具体的任务。
但也有两种特殊的用例：一种是上层用例，另一种是底层用例。
用例的构成
一个完整的用例，一般包括：用户、前置条件、后置条件、主场景、扩展场景、规则等方面。
1. 用户
用例的重点在于用户的操作场景，在考虑用例的场景之前，需要先确定用例的用户，因为所有的使用场景都是为某些特定的用户服务的。一个用例可以面向一种或多种用户，例如，用例“仓库结账”，只是面向仓库核算员的，而用例“仓库交易分析”，会面向多种用户，如仓管员、核算员、计划员、采购员等。
根据面向的用户不同，可以将用例分成几大类：面向普通用户的用例、面向关键用户的用例、面向系统管理员的用例、面向所有用户的用例。
面向普通用户的用例，是普通用户从事业务处理的用例。由于使用者是一般工作人员，学习能力、文化水平、软件知识参差不齐，设计这种用例时往往会在易学性、健壮性、易用性上下更多的工夫。这种用例设计得不好，会影响工作效率。
面向关键用户的用例，主要用于系统数据的初始化、业务功能的配置、基础数据的管理等，如“用户管理”“仓库配置”“组织结构建立”之类的用例。使用这种用例的用户，虽然没有系统管理员对软件理解深刻，但对软件比较熟悉，使用这种功能进行操作对系统的影响非常大，但一般来说影响的幅度与程度不及面向管理员的用例。
面向系统管理员的用例，主要用于系统配置、运行监控、异常分析，功能维护等，这些用例一般会涉及系统的正常运行，操作稍有不慎就可能导致系统异常甚至崩溃，所以一般只能给系统管理员使用。
面向所有用户的用例，提供给所有登录本系统的用户的用例。如“修改密码”“工作日志”之类，只要是登录本系统的用户，就可以使用这些用例。当然，既然是面向所有用户的，自然也应该归于面向普通用户的用例，这是一种特殊形式。
2. 前置条件
前置条件，是为了保证本用例可以成功执行，而需要满足的前提条件。例如，在某电商网站，用例“下订单”的前置条件是会员登录成功，并且会员信息中的一些必备资料填写完整；用例“撤销订单”的前置条件是会员登录成功，并且订单还没有发货：而用例“退货”的前置条件是订单已经发货。
3. 后置条件
后置条件，是指用例执行结束后的系统状态，无论成功还是失败。例如。年前一般都会取现金包红包。就拿这个举例来讲，银行ATM机，用例“提款”的后置条件是：如果用例执行成功，ATM机钞票减少，减少额等于用户的提款金额；如果用例执行不成功，ATM机钞票不变，用户的银行账号余额不变。
4. 主场景
“场景”指用户使用软件功能完成工作任务的操作过程。场景是由一系列人机交互的步骤构成的，强调的是人做了什么操作，机（软件系统）有什么应答，来来往往，经过若干回合后，结束了某项任务，有可能成功，也有可能不成功。
由于用例都是有明确的任务的，因此，每个用例都应该有个主目标，这个主目标就是支持用户通过这个用例完成某项具体任务，但为了使这个目标实现得更高效、更准确、更容易，犯了错误可以得到纠正，一些异常事件可以得到处理，需要软件提供一系列的额外功能。
根据二八法则，平均下来应该有20％的功能是用来完成主目标的，而80%的功能是为了提高效率、降低错误率、纠正错误的。
例如，用例“仓管员根据采购单收货”，它的主要目标是将收货记录录入到系统，因此录入并保存收货记录是主目标。
而编辑功能是为了纠正错误或应对变化，删除功能是为了纠正错误，导入功能是为了录入更快速，这些都不能称为这个用例的主目标。
用户为实现自己的主目标而进行操作的过程，称为用例的主场景。大部分情况下，一个用例只有一个主目标，只有一个主场景。如果主场景不明确，往往说明这个用例是上层用例（文章开头第二段有解释，忘了的回去看）。
例如：“会员登录”用例主场景包括：用户录入会员卡号、密码，登录成功这个过程。
别的处理密码输入错误、忘记密码之类的场景，不属于主场景，因为用户到这里是为了登录，输错了密码，或者忘记了密码只是一些意外情况。
主场景是实现用户主目标的过程，但未必是最常用的场景。例如：“文员进行客户档案维护”用例，录入客户信息是这个用例的主目标，是主场景，但最常用的场景却是浏览客户信息。所以，我们要注意判断。
5. 扩展场景
每一个用例，都有各种各样的使用场景，主场景只是若干种场景中的一种。主场景之外的场景，称为“扩展场景”。例如，一个简单的用例“用户登录”，主场景是用户输入用户名、密码，验证成功后进入系统。但还有别的可能，如用户密码输错了怎么办，用户忘记了密码怎么办等，这些都要有相应的处理场景，称为扩展场景。
用“用户登录”的扩展场景用例，列举2个场景进行分析，包括：密码输入错误、用户忘记密码。
扩展场景一：密码输入错误。
用户录入用户名、密码，确认登录。
系统验证用户名、密码，密码验证错误，提醒用户只允许输入三次。
用户重新输入密码。
系统验证密码，如果验证正确，则进入系统。如果验证错误，且输入已经超过三次则锁定该用户，并提醒用户账号已经被锁定，如果没有超过三次，则用户重新输入密码。
扩展场景二：用户忘记密码。
用户录入用户名、密码，确认登录。
系统验证用户名、密码，密码验证错误，系统提醒是否需要取回密码。
用户确认取回密码。
系统发送验证短信到本账号所绑定的手机。
用户提交短信验证码。
系统确认验证码正确。
用户录入新密码。
系统将当前用户的密码重置为新密码。
6. 规则
规则是指本用例用到的业务规则、逻辑算法等。有的用例逻辑简单，几乎没有什么规则；无非只是些数据的录入、保存而己，而有些用例，逻辑非常复杂，需要进行大量的运算、判断，在这种情况下，就需要整理进行运算、判断的规则。
在这里整理的规则更倾向于用户，描述用语以一般用户能理解基本要求，应当尽量避免使用太多技术化的IT语言，另外，这里也不是用户在需求调研时提供的规则的简单记录；应该有一个整理、分析、抽取、加工的过程。
总结
在互联网软件研发工作中，大家听到最多的是测试人员写的测试用例，需求用例听到的相对较少，但是需求用例也是非常重要的。由于在实际工作中，产品经理的工作内容比较繁杂，而且很多时候是多任务并行，不一定会产出像测试那么细致的测试用例文档。但是我们在思考产品功能和撰写PRD文档时，要有必要的需求用例思维，去设计和验收产品功能。
目前主流互联网公司，大多采用敏捷研发。至于产品经理是不是需要写需求用例，根据公司情况、部门要求、任务的复杂程度、自己的工作任务灵活决定。所有的工具和方法都是为了辅助我们，更好的完成工作的，不可生搬硬套而忽略了自己的实际情况。
