连载：面向对象葵花宝典：思想、技巧与实践（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？
所以，采用用例方法分析需求的时候，我们都是采用纯文本来描述需求的，而不会采用用例图来分析需求