老丹(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
我上面讲的你理解了吗