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