问题时间：2014/12/23
老丹(376***002) 16:52:16 请教大家一个问题，老潘软件方法中的这个例子，这里面的实现是通过打电话的方式完成下单过程 老丹(376***002) 16:53:03 那么如果提供第二种下单方式，客户在线填写，那么"寄快递"这个业务用例当如何处理？ 老丹(376***002) 16:53:54 要不要加一个业务用例？如果不要，那我怎么表述这两种下单方式的不同呢？ 潘加宇 16:55:44 加一张业务序列图，把不同的场景画出来 老丹(376***002) 16:57:36 那如果后线的收费也有多种实现方式呢，包括这一业务的其他环节都可能有两种以上的实现 老丹(376***002) 16:58:02 那这个场景序列图会变得非常多 老丹(376***002) 16:58:29 因为每一个环节的不同组合会形成许多的业务场景 老丹(376***002) 17:00:04 比如下单分为电话下单和网上下单，收线分为当面收取和在线付款，那就会有"电话下单-当面付款"，"电话下单-在线付款"、"网上下单-当面付款"、"网上下单-在线付款"四种实际业务场景了 潘加宇 17:00:04 画出典型的场景就可以 潘加宇 17:00:42 不要怕漏掉 老丹(376***002) 17:00:55 这还只是两个环节有不同的实现，实际还有很多环节有没的实现 潘加宇 17:00:58 找出最值得改进的场景，先改进。 潘加宇 17:01:34 "这还只是两个环节有不同的实现，实际还有很多环节有没的实现" --何止啊，去调研非洲的，美国的，中东的快递公司，还可以发现更多的场景 老丹(376***002) 17:01:50 那这些展现出来就没法引伸出后面的系统用例啊 老丹(376***002) 17:02:08 对啊，所以我现在非常困惑 老丹(376***002) 17:02:17 不知道怎样处理才好 潘加宇 17:02:25 需求就是做减法，找到最值得改进的场景里最值得改进的改进点，推导出最重要的需求，这才是需求 潘加宇 17:04:08 参见《软件方法》第2章： 可能有的人会想，哎呀，要是我们只关注"大兴中医院"，那"协和医院"的需求是不是漏掉了？问题是，"大兴中医院"想要的都还没有满足，去想"协和医院"干什么？认为需求"漏掉"的想法是幼稚的。需求是一口深井，永远做不完。只要您愿意，可以满世界去调研所有医院，甚至不用调研，拍脑袋就可以得出上万条需求。关键是需求的排序，老大和愿景就是排序的首要依据。 老丹(376***002) 17:04:32 那还是以为这个为例，如果主要场景是网上下单，另一种情况电话下单用的少，但是实际也公发生，如果不描述出这个问题，就不考虑这一方面的实现了 潘加宇 17:04:43 先做一个 潘加宇 17:04:56 每个时间点，只做最重要的一个 老丹(376***002) 17:05:44 先做一个是可以的，那我做完了第一个，过一段时间后开始做第二个的时候，这第二个怎么融入到现有的模型中来呢？还是多画一个场景图吗？ 潘加宇 17:06:42 做第二个和做第一个是一样的，都是在当前现状上改进 老丹(376***002) 17:08:13 可不是要替换原来的网上下单啊，只是为用户多提供一个选择 潘加宇 17:08:16 可以会画另一张序列图，也可能还继续在当前序列图上寻找第二个最重要的改进点，也可能寻找第二个值得改进的业务用例，看你改完第一个改进点后，愿景目标有没有达到了 老丹(376***002) 17:10:25 其实这不涉及到另一个纠结我的问题，如果是用两个不同的序列图去描述一个用例，那用例本身也有一个文字上的描述的（这个应该只有一份），那这样的话文字的描述和场景的描述就对不上了 潘加宇 17:11:32 用例可以有多个场景，用多张序列图来描述 潘加宇 17:11:44 我上面讲的你理解了吗
