（18） – 用例分析
最后更新于：2022-04-01 07:29:21
## 连载：面向对象葵花宝典：思想、技巧与实践（18） - 用例分析
很多人在分析需求的时候，采用的是东扯葫芦西扯瓢的方式，列出了很多的需求点，但当你看完后，你还是不知道到底要干嘛！！ ---- 写在前面
用例，英文名称Use Case，英文和中文都是很好理解，因为大家都这么用，我们暂且不去追究名称上的问题，只要知道“用例是用来描述需求的流程”，即：**描述5W1H中的How**。
看起来用例应该很好写，因为用例是描述需求的流程的，而需求的流程一般都是客户根据自己的业务总结出来，然后告诉我们的。我们只要将客户描述的内容记录下来即可，既简单又轻松！
但现实与理想总是有差距的，你可能会遇到一个对业务并不十分熟悉的客户，又或者和你交流的人员是客户的临时工，还有可能和你交流的人马上要休婚假了，他巴不得赶快了结这个无聊的事。。。。。。总之，各种各样的情况都可能出现，就是完美的情况不会出现！
这种情况下，我们如何才能做到完善的分析呢？我们怎么知道我们的分析是否正确，是否有遗漏，是否足够了？
一般的情况下，公司里负责需求分析得人员都是资深的员工，对领域、对系统有一定的积累和经验，即使面对这些情况，也可以通过自己的经验来弥补。
但对于一个菜鸟，遇到这种情况应该怎么办呢？难道菜鸟就不能做需求分析了么？
别慌，菜鸟虽然没有经验，但只要掌握正确的方法，一样可以做出很好的需求分析，这就是我总结的用例三部曲方法，又或叫做NEA方法。
我总结出的用例方法三段法（NEA方法）：
1） 正常处理（Normal）：通过和客户沟通，分析需求的正常流程；
2） 异常处理（Exception）：在正常处理流程的步骤上，分析每一步的各种异常情况和对应的处理；
3） 替代处理（Alternative）：在正常处理流程的步骤上，分析每一步是否有其它替代方法，以及替代方法如何做；
经过这简单三步后，How可以说分析得八九不离十了。
### 【用例的具体写法】
前面我们学习了518需求分析方法，而一个完整的用例，正好体现了518需求分析方法中涉及的内容。
一个完整的用例应该包含如下几个部分：
【用例名称】
一般情况下，用例的名称即需求的名称。
【场景】
场景即用例发生的环境，正好对应5W中的3个W：Who、Where、When
【用例描述】
描述详细的用例内容，对应5W中的What和How，即用户应该怎样做，以及每个步骤中的输出。但并不要求每个步骤都一定有输出，可以有也可以没有，也可以有多个。
【用例价值】
描述用例对应的客户价值，对应5W中的Why。
【约束和限制】
即整个需求流程中相关的约束和限制条件，对应518方法中的8C。
我们来看一个简单的样例：POS机。
**【第一步：正常处理】**
|
【用例名称】
买单
【场景】
Who：顾客、收银员
Where：商店的收银台
When：营业时间
【用例描述】
1. 顾客携带选择好的商品到收银台；
2. 收银员逐一扫描商品条形码，系统根据条形码查询商品信息；
3. 扫描完毕，系统显示商品总额，收银员告诉顾客商品总额；
4. 顾客将钱交给收银员；
5. 收银员清点钱数，输入收到的款额，系统给出找零的数目；
6. 收银员将找零的钱还给顾客，并打印小票；
7. 买单完成，顾客携带商品和小票离开；
【用例价值】
顾客买完单以后，就可以携带商品离开，而超市也将得到收入；
【约束和限制】
1. POS机必须符合国标XXX；
2. 键盘使用中文，因为收银员都是中国人；
3. 一次买单数额不能超过99999RMB；
4. POS机要非常稳定，至少一天内不要出现故障；
**【第二步：异常处理】**
在第一步的基础上，我们增加相关步骤的异常情况说明和处理，例如如下的黑体字：
【用例名称】
买单
【场景】
Who：顾客、收银员
Where：商店的收银台
When：营业时间
【用例描述】
1. 顾客携带选择好的商品到收银台；
（这一步没有异常）
2. 收银员逐一扫描商品条形码，系统根据条形码查询商品信息；
2.1 扫描仪坏了，必须支持手工输入条形码；
2.2 **商品的条形码无法扫描，必须支持手工输入条形码；**
2.3 **条形码能够扫描，但查询不到信息，需要收银员和顾客沟通，放弃购买此产品**
3. 扫描完毕，系统显示商品总额，收银员告诉顾客商品总额；
（这一步没有异常）
4. 顾客将钱交给收银员；
4.1 **顾客的钱不够，顾客和收银员沟通，删除某商品**；
4.2 **顾客的钱不够，顾客和收银员沟通，删除某类商品中的一个或几个（例如买了5包烟，去掉两包）**
4.3 **顾客觉得某个商品价格太高，要求删除某商品；**
5. 收银员清点钱数，输入收到的款额，系统给出找零的数目；
（这一步没有异常）
6. 收银员将找零的钱还给顾客，并打印小票；
7. 买单完成，顾客携带商品和小票离开；
【用例价值】
顾客买完单以后，就可以携带商品离开，而超市也将得到收入；
【约束和限制】
1. POS机必须符合国标XXX；
2. 键盘使用中文，因为收银员都是中国人；
3. 一次买单数额不能超过99999RMB；
4. POS机要非常稳定，至少一天内不要出现故障；
有的人可能会认为第3、第5、第6步都应该有异常，例如系统坏了应该怎么处理。
但实际上我们没有必要这么写，因为用例分析的目的是为了详细分析为了实现客户价值，系统应该怎么做，如果系统本身都坏了，这个就不是用例关注的内容了。
需要注意的是：用例分析中的“异常”是指流程的异常情况，而不包含系统本身的的异常。
**【第三步：替代处理】**
在第二步的基础上，我们增加替代处理。即：有的步骤可以换一种方式来实现。例如如下用例中的付款方式，可以有信用卡支付、会员卡支付、购物卡支付等。
【用例名称】
买单
【场景】
Who：顾客、收银员
Where：商店的收银台
When：营业时间
【用例描述】
1. 顾客携带选择好的商品到收银台；
（这一步没有异常）
2. 收银员逐一扫描商品条形码，系统根据条形码查询商品信息；
2.1 扫描仪坏了，必须支持手工输入条形码；
2.2 商品的条形码无法扫描，必须支持手工输入条形码；
2.3 条形码能够扫描，但查询不到信息，需要收银员和顾客沟通，放弃购买此产品
3. 扫描完毕，系统显示商品总额，收银员告诉顾客商品总额；
（这一步没有异常）
4. 顾客将钱交给收银员；
4.1 顾客的钱不够，顾客和收银员沟通，删除某商品；
4.2 顾客的钱不够，顾客和收银员沟通，删除某类商品中的一个或几个（例如买了5包烟，去掉两包）
4.3 顾客觉得某个商品价格太高，要求删除某商品；
4-A：**顾客使用信用卡支付**
4-A.1 信用卡支付流程（请读者自行思考完善，可以写在这里，如果太多，也可以另外写一个子用例）
4-B：**顾客使用购物卡支付**
4-B.1 购物卡支付流程
4-C：**顾客使用会员卡积分支付**
4-C.1 会员卡积分支付流程
5. 收银员清点钱数，输入收到的款额，系统给出找零的数目；
（这一步没有异常）
6. 收银员将找零的钱还给顾客，并打印小票；
7. 买单完成，顾客携带商品和小票离开；
【用例价值】
顾客买完单以后，就可以携带商品离开，而超市也将得到收入；
【约束和限制】
1. POS机必须符合国标XXX；
2. 键盘使用中文，因为收银员都是中国人；
3. 一次买单数额不能超过99999RMB；
4. POS机要非常稳定，至少一天内不要出现故障；
经过上面步步为营，逐步细化和求精，我们已经得到了一个比较完善的需求了，这个过程中并没有高深的技巧，也没有涉及需要丰富的经验。
有的读者可能会有疑问：我怎么知道第4步有那些异常、那些替代方案呢？
其实很简单：问你的客户！客户是最清楚了，但如果你不问，嘿嘿，客户倒不一定会告诉你：）
但只要我们掌握了NEA用例分析方法，即使客户忘记了，或者没有意识到，我们也会将需求挖出来，这样需求就不会遗漏。
### 【要画图么？】
大家可以看到，我们在前面进行用例分析的时候，并没有看到任何图，而是纯文本！
对于那些UML狂热分子来说，这可能是难以接受的，怎么能没有图呢？UML中的用例图不就是用来分析需求的么？
我们当然不怀疑UML的权威性，但任何东西都有局限性，UML也不例外。UML的局限就在于UML是一个建模的语言，就像汉语、英语一样，只是一种表达形式，而不是一种分析和创作方式。
比如说你会汉语，但并不代表你就能写小说，你会画UML用例图，但并不代表你就能做需求分析。相反，必须是有了需求和用例之后，才有用例图，说白了，用例图是用例的图形化描述，但是它并不能取代用例。
除了UML本身的局限性外，还有另外一个更重要的原因：用例是客户和公司关于产品的一个共同认识！一般情况下，市场人员和客户沟通交流，了解客户的需求，然后和客户一一确认，最后形成需求文档。在这个过程中，主要是客户和市场人员参与，而没有研发的人员参与。
对于客户来说，他肯定是以自然语言，而不会用UML来描述需求；对于市场人员来说也一样，他可能对UML一窍不通，甚至他以前可能都是卖医疗器械，甚至有可能是狗皮膏药的，他还管你什么软件工程，什么UML？
所以，采用用例方法分析需求的时候，我们都是采用纯文本来描述需求的，而不会采用用例图来分析需求