使用用例探索需求――一次解决需求问题的对话

think 著

本文根据录音整理改编。对话时间为2004年5月。隐去具体环境人物，尽量保持原汁原味。虽然不完美，甚至很乱很狼狈，但这样的东西是真实的、管用的。UMLChina把“聚焦最后一公里”作为一个目标，就是要抛弃“精心设计的案例”这种方式。

一些解释性的补充说明用补注的方式在括号中说明。

D――开发人员

U――UMLChina专家

D：这个用例文档你看着写得怎么样，给提提意见？

U：我看了。但是我想先不说这个用例文档，你先回答我一个问题：为什么要开发这个系统？

D：这是一个基于web的类似工作流的系统。现在企业里面的各种MIS应用越来越复杂，用户使用这些MIS系统的时候会出现各种问题，需要MIS部门的工程师解决。通过这样一个系统避免用户的请求没有人去负责，提高处理的效率，合理配置人员，对工作的情况有一个报告，有多少已经处理，有多少没处理等等。

U：好，我们来看看，你刚才说的就是系统的愿景（Vision）。这里要提醒你的地方是，你说的这几个愿景目标，能够有办法度量吗？比如你说“提高处理效率”，那么现在的效率情况如何，平均一个请求需要多长时间解决？上了这样一个系统，希望能缩短到多少才算系统没有白上？等等。这些客户或者你们老板心里有没有数？这个可以回去考虑一下。

（注：有关愿景的重要性，参见《有效用例模式》的SharedClearVision模式，Philippe Kruchten曾说，“如果仅允许设计一份文档、模型或工件来支撑项目，我会选择愿景文档”。）

U：这个系统涉及到哪些人，他们对系统有什么希望？

D：可能有这么几种人，第1种是用户，也就是使用MIS遇到问题的企业员工。这个系统主要就是为这些人服务的（注：是吗？难道没有这个系统，用户的问题就不解决了吗？），他们希望能通过一个友好的界面把请求提出来，提出来以后还能跟踪处理情况，觉得不满意的时候还能找到处理的人，让他把进度加快。第2种就是处理这些请求的MIS部门工程师，他们希望这些请求能够有分类地发到他们手里，例如负责处理email问题的工程师，不应该有打印机的问题发到他那里去。而且分配的任务是比较清楚的，要给我一个清楚的任务列表。我每天一上班打开机器，我的任务就出现在我的面前，优先级也很明确。这样，就能使自己更有效率地去处理用户的问题。第3种就是部门经理了，希望能通过系统掌握工作量，某个时间段的工作量，例如4月份，接到多少和IT有关的求助请求以及工程师对请求的响应情况。比如说提出了100条，谁完成了多少条，还有多少条没完成，完成这些东西消耗了工程师的多少时间，由此产生了多少成本，希望对部门的工作量有好的统计报告产生出来，让他能够通过这些统计分析来调整部门内部的工作流程或资源配置。给你的是和MIS工程师相关的用例，用例技术刚刚尝试使用，可能有些地方写得不是很规范……

U：规范不规范倒不要紧，关键是有没有写出有价值的东西，捕获了该捕获的信息。我们现在一个一个来看具体问题更好一点。比如2.6.2这个，“查看任务管理员发送的用户请求和其他信息”。任务管理员是谁，是系统上马以后设想的一个角色吗？

D：系统上马以后，工程师里面有分工。其中有1-2个工程师担任任务管理员的角色。这个角色怎么定义的呢？就是说一个用户提出一个请求，用户可能不知道他是属于哪一类的问题，email还是操作系统还是应用软件，提出问题以后，首先就到了任务管理员这个地方。任务管理员根据请求的性质转给相应的MIS工程师去处理。任务管理员就是起到一个类似接线员的作用。

U：好。你现在假设了一个流程，流程里所有的任务要通过任务管理员派发。也隐含了一个系统需求，任务管理员使用系统来派发任务。这里面就要和客户一起考证、一起思考了。为什么要有这个用例，没有这个用例妨碍不妨碍刚才提到的愿景目标：提高效率，透明度，明确责任。设置任务管理员这个执行者并给他一个用例“分配任务”是否合理？能不能系统自己智能分配，或者让用户自己挑工程师？这些都是可以讨论的。每提出一个用例，都需要思考它是否有存在的理由。这样才能防止需求的蔓延，计算机可以做这个，可以做那个，需求不知不觉中蔓延，这些需求是要钱的，而且无价值的“需求”和真正的需求混在一起，会影响真正需求的实现。（注：类似这样的事您一定也见过。一个人事系统，开发人员先花大量的时间去研究权限分配，RBAC什么的，最后没有时间去搞真正的业务，解决那些真正让职员头痛的问题，其实那个系统的用户很少，就算是用钥匙锁办公室的门也能实现权限管理。）如果没有经过考证，引进了一个用例，这个用例有可能还排在比较优先的级别，到最后才发现这个用例可有可无，这时很多时间都浪费掉了。写用例之前的第一步实际上是要论证这个用例存在的必要性。依据就是现实业务和系统的愿景。

D：这些问题要好好考虑一下……

U：现在先假设这个用例“查看任务管理员发送的用户请求和其他信息”的存在没有问题。我们来看看用例的内容。名称长一点，不过一开始长一点没事。（注：随着需求工作的进行，对系统的理解逐渐深刻，可能会有更好的名称）操作者（注：执行者，Actor）也可以，描述也无所谓。前置条件，这里应该是系统能够判断的一个状态，不能判断的前置后置条件是没有意义的。例如，这里的“任务管理员将用户请求分解并发送给相关MIS工程师”这个是可以判断的。后置条件有问题，这里写“MIS工程师查看任务管理员发送的用户请求和其他信息”，后置条件是用例结束之后系统的状态。前置条件是说开始时怎么样，后置条件是说结束时怎么样，应该尽量用“已××××”这种描述状态的语句来表述。好，现在起点终点定了，那么中间的路怎么走呢，这不是MIS工程师一个人就能决定的。我现在说一个通俗的例子，取钱。周末我想到楼下超市去买东西，会先看看家里的抽屉有没有现金，如果有，就拿一些出来到楼下超市买东西，如果没有，我就会拿上卡，到楼下取款机去取钱，这里就存在问题，为什么同样是取钱，家里的抽屉没有找我要卡要密码（注：如果读者您是气管炎，则是例外），楼下的取款机找我要卡要密码？而且很可能抽屉里的钱就是我昨天在取款机那里取的啊！找取款机取钱的用例写得象抽屉或者找抽屉取钱的用例写得象取款机行不行？这里就涉及到用例的下一个内容：涉众利益。假设MIS工程师在“查看任务管理员发送的用户请求和其他信息”的时候，有哪些人会关心这个过程。或者说他搞砸了或者乱搞，谁会担心可能会损害他的直接利益？从这些利益出发，才能推导出下面的路径、步骤、补充约束。我们来用一下幻灯片里的“醉酒法”（注：指UMLChina训练用的一个幻灯片，http://www.umlchina.net/training/umlchina_2.pdf），要是MIS工程师喝得醉醺醺的在做这个事情，谁会担心自己的直接利益受损？为什么他会担心？

（注：关于用例，Ivar Jacobson的定义是：用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。Alistair Cockburn进一步发展了用例思想，正如《编写有效用例》开篇所言，用例是什么？用例是涉众之间就系统行为达成的契约。笔者尝试把它补充一下，作为用例的进阶定义：用例是涉众之间就系统行为达成的契约，以执行者为达成特定目标和系统交互的方式演绎。笔者认为：只有在这个层次上理解用例，才能发挥出用例的最大价值。有关用例的历史，不妨看看《程序员》2004年5月的《用例：十年风雨》）

D：我觉得部门经理会担心。

U：担心什么呢？

D：（沉吟）……我分配给他的任务，他做不了，就把它接受下来了。或者是他能做，却把它拒绝了。如果他做不了，就把它接受下来了，任务管理员就会认为这个任务已经有人负责了，就不会去管它了。而这个人可能接下来之后就不去做它。这会导致用户的请求迟迟得不到响应。用户不会去抱怨某个MIS工程师，他只会去抱怨MIS部门，“反应给你们部门这么久，我还是不能打印”，这种抱怨多了，老板对MIS部门的经理肯定会有意见，认为他不称职，可能会处分他或撤了他的职。

U：好。经理――希望MIS工程师不要乱接受，确认能做才接受。那么，MIS工程师呢？

D：他也希望系统能帮他把把关，看看他能不能搞定。

U：这里我插一句：涉众的利益我们不能假设，只能去问涉众自己。也许他希望接得越多越好，能不能搞定再说。这种情况也不是不可能啊，如果公司的规章是按接的活多少发钱的话。因为一个问题能不能解决，谁也说不准。比如打印机坏了，我说我行，那可能性也大约就99%，说绝对能搞定估计是没有的。要去调查，把这些真正的利益关系搞清楚。

D：还有用户，看到他喝得醉醺醺的，会担心自己的请求能不能得到及时解决。

U：从这些利益就可以推出一些系统的需求了。为满足部门经理的利益，系统可能需要提供一种帮助判断MIS工程师能否搞定一个任务的价值，当然，可能不是这个用例的内容，可能是“任务管理员à分配任务”这个用例里面的内容。例如：在“任务管理员à分配任务”里面，可能需要一个步骤，系统告知任务管理员以前谁解决过类似问题作为参考。

D：任务管理员希望责任要清楚，透明一点，因为他和用户接触，用户看到问题迟迟未解决，会责怪他。

U：针对这个利益，就有必要让用户及时知道任务已经被分配给谁，这样他就不会怪任务管理员。这就是新的需求，可能也是在“任务管理员à分配任务”里面加一个步骤，通知用户（主动的），或者保存分配的细节，让用户及时跟踪。这就是探索需求的思考方法。

D：这里我有一个问题，我这个用例的格式是从一本《软件需求》的书上摘下来的，这样格式会不会有问题。

U：格式无所谓。当然有一些形式上的原则，但这个问题好解决。难解决的问题在于，可能你的用例写得规规整整，但内容不对。用例值不值得存在，值不值得花钱去做它，根据是业务和愿景。格式本身只是代表了用例应该有哪些内容，通过充填这些内容强迫需求工程师去思考。

U：下面我们来看看一般流程（基本路径），第1句，任务管理员把任务分配给MIS工程师。实际上这一句不应该属于这个用例，用例就像一份合同，它声明了只要满足前置条件，按照里面的路径步骤走，就能到达后置条件。这几个字不应该属于这份“合同”。任务管理员à把任务分配给MIS工程师可能是另一份合同，里面也会有步骤。另外半句，系统提示MIS工程师。这个也可能是另外一个用例，这里面涉及到提示的方式，是MIS工程师登录以后提示还是每隔一段时间自动提示还是二者兼有。

D：第一句是不是一定是执行者的动作？

U：是的。而且后面步骤的主语也只能是执行者或者系统。因为这份合同是通过执行者和系统交互的细节来演绎的。（补注：针对的是描述需求的系统用例。）

D：如果这里是自动产生提示，执行者应该是什么？

U：“时间――检查未查看任务”。（补注：时间，不是系统时钟，时间执行者在外面，系统时钟是实现时间引发用例的一种设计机制，如果用面向对象方法来设计，它是一个边界类对象的成分。）其实这个“系统提示有任务”的步骤可以出现在多个用例中。登录的时候提示，就可以出现在“MIS工程师à登录”用例中，在线的时候一分配就提示，就会出现在“任务管理员à分配任务”用例中。

U：我们看第二句，“MIS工程师查看任务列表，任务列表以明显的方式显示”，实际上这一句和用例的名字一样，但是步骤写的应该是为了达到用例目标，执行者和系统的动作。这些动作按照回合制书写：

所以要把这一步改成一个动作，“MIS工程师请求查看任务列表”，中间没有验证、改变，但需要系统的回应，“系统显示任务列表”，这样，就把责任区分开来，请求是MIS工程师的责任，不请求要怪MIS工程师，显示是系统的责任，请求了不显示要怪系统。下面的“以明显的方式”几个字，这几个字不象需求，因为这几个字是不可验证的。明显是相对不明显而言，这和个人体验、环境等很多因素有关。这里就有必要找MIS工程师问清楚，什么是明显。这可以看做一条涉众利益，但需要具体的需求来体现。

D：我想可能是用某种方式表示出来，比如，“某些字段用黑体显示”，这种是不是需求，怎么表示。

U：这可以看作绑定到这一步的一个约束，你甚至可以让涉众把他想要的“明显的”方式描述清楚，比如要声音？颜色？界面布局。可以让他把布局画出来作为一条约束绑定到“系统显示任务列表”这一句。但这两句需求要分开。前一句是功能需求（系统做什么），后一句是设计约束。稳定性不同，后者绑在前者之上，比前者易变。这里的关键是要和MIS工程师交谈，弄清楚明显的真正含义。刚才说的声音、字体、颜色什么的约束，也许并不一定是这样，也许MIS工程师的要求是某些显示字段，该出来的出来，不该出来的隐藏，这个就叫明显了。这种情况下，这条需求就属于“字段列表”补充到“系统显示任务列表”中。

（

注：用例的内容有以下这些：

用例编号：用例名

执行者

前置条件

后置条件

涉众利益

基本路径

1…..××××

2……××××

扩展

2a.××××：

2a1….×××××

字段列表

业务规则

非功能需求

设计约束

）

D：我怎么区分设计和设计约束？例如刚才的“用黑体显示”。

U：需求的意思是如果系统做出来不满足它，某些涉众的正当权益就会受损害。如果涉众已经明确提出要用“黑体显示”，这是需求，因为系统如果不满足这一点，就违反了涉众的这个意思。如果涉众只是要求“某些字段要和其他字段在显示格式上区分开”，那么“用黑体显示”就是一种设计，由界面设计人员根据自己的知识和经验来为涉众选择的一种解决方案。

（补注：经常有人会问，使用了用例文档以后，怎么感觉那么细，这是不是设计呢。其实原因只是以前的需求做得不过关，漏了很多需求而已。设计指的是用什么平台、语言、架构来实现需求。涉众提出“用黑体”、“通过××协议与支撑系统通讯”，“购物满1000元获得VIP资格”，这是需求，不管用什么语言平台架构，都要满足这一点。还经常有人问，怎样和客户讨论设计？答案是你没有必要和客户讨论设计，你想要和客户讨论的多半也不是设计，只是做需求的时候没做好，一些利益、业务规则、概念关系没有搞清楚，拖到设计阶段出现问题了才不得不和客户交流。）

（补注：这里又引出我见到的另一种理解偏差，“反正需求是不能一次弄清楚的，这是为什么要迭代开发的原因。所以我们要敏捷，不用太认真去做需求（甚至分析设计），先编码再说”。这里我采用一个比喻：治病。要治好一种稍为复杂的病，医生不能也不应一开始就定好所有的治疗方案细节，而是要“拥抱变化”，根据上一个疗程的治疗效果来调整下一个疗程的治疗方案。虽然承认“这个病不能只用一个疗程就治好”的事实，但是医生在每一个疗程都需要根据现有情况尽心尽力。敏捷是积极的行动，不是偷懒的理由。）

U：下一句“MIS工程师点击任务列表”。这句话也有问题。暗示了MIS工程师用了某种“点击”的设备来工作，比如鼠标、触模屏。MIS工程师的目的可能是“选定某个任务”，不管他以任何方式选定，能满足他的要求就行。即使MIS工程师明确提出要用鼠标，也不能出现在这里，因为这是两类不同的需求。

D：这是不是意味着用例要写得尽可能抽象一些？

U：不，不是这个意思。我们经常看到有人讨论用例应该写得多细，用例的“粒度”应该多大的问题，实际上这些讨论是没有意义的。用例或者说需求不是面团，要怎么捏就怎么捏。这里面实际上就是四个字“实事求是”，用例是一种实事求是的技术，反映出“真正想要的是什么”。“选定某个任务”和“点击某个任务”之间，哪一个是需求，要去和MIS工程师交流，得到真实的答案。也许他们真的有需求，希望通过“点击”来锻炼手指呢？这个时候，“点击”就是需求。所以，不是“尽可能抽象”，也不是“尽可能具体”，而是“尽可能真实”，用例就是引导你一步步去探索真实需求的技术。

下一句“系统显示任务详细信息”，这一句可以，但紧接着的后半句“详细信息包括请求者…”可以分离到后面的字段列表栏目，一方面可以保持路径步骤的可读性，另一方面，“系统显示任务详细信息”及“该显示的详细信息有……”是稳定性不同的需求，前者比后者稳定。那么现在我们在路径里有四步：1. MIS工程师请求查看任务。2. 系统显示新到达任务。3. MIS工程师选择一个任务。4. 系统显示任务详细信息。这四步就完成了一个查看的目的。

D：那我应该是把查看作为一个用例来写，还是和接受任务合在一起写？

U：这里的根据是，光是查看，是否为MIS工程师提供了一个完整的价值。这就要和MIS工程师交流，问他：你认为光是这么看一看算是完成了一个事情吗？（就像你到取款机那里不是为了插卡输密码一样）或者是不是可以回答老板，“老板，我今天的成绩是看了100个任务…”。细节上加起来是一样的，例如到取款机取钱的用例，也可以在输完密码后砍断变成两个用例，里面也有路径步骤，问题在于我们和取款机交互的目的是为了取钱。

U：下面我们来看扩展。扩展就是步骤里出现的分支或失败，而且系统要处理这种意外或失败。第一个你写的是“超时”，从上面来看不属于这个用例的范围，没有哪一步能引申出这个扩展点。这里可能隐含着一个时间引发的用例。寻找扩展点要从步骤来看，看每一步有没有可能失败，而且这种失败是系统要处理的――因为这才是系统的需求，用例文档里写的都是需求――例如MIS工程师心脏病发作，停电等，是这个要开发的系统无法也不应该去处理的。第2步，“系统显示新到达任务”，这里可能就有一种例外情况，没有新到达任务。这时系统怎么处理或者干脆就结束用例。你看看那几步还有没有什么地方会有扩展？

D：好像没有了。

U：那好。现在我们的路径步骤写完了。接下来就要为这些路径步骤补上一些约束。包括字段列表、业务规则、非功能需求、设计约束。例如，“系统显示新到达任务”，该显示哪些信息？什么叫“新到达任务”？根据什么判断规则？有没有性能上的需求？你需要把这些调查清楚，补上去。

U：这个时候再回头看看涉众利益。MIS工程师希望系统能帮他把把关，帮他判断他能不能搞定。这个利益这个用例能体现吗？

D：系统可以把以前类似问题的解决方案列出来给MIS工程师看。

U：这就有必要添加一个步骤，“系统显示类似任务的解决方案”。还有用户，他希望MIS工程师不要搞错，信息要透明。我们看看这个用例里能不能体现。

D：“不要搞错”这个利益可以体现在刚刚增加的那个步骤上。

U：“透明”这个利益能不能体现呢。

D：可以。我们可以把谁查看了、什么时候查看的记录下来，让用户知道。

U：那么应该添加一条需求，作为步骤出现，“系统保存查看的细节”，外加一条字段列表的补充说明，“需保存的细节包括MIS工程师、时间、任务”。再看看部门经理，希望能接就接，不能接不要乱接。这个利益能体现吗？

D：这个用例没有接任务的内容，不好体现，应该在“接受任务”里面体现。但是部门经理希望一个任务被分配给MIS工程师以后，MIS工程师能尽快查看并做出判断接还是不接。

U：这个用例第一步就已经是请求查看了，所以这个利益也不是体现在这里，但可能会体现在“时间à提醒有新任务没看”这个用例里面，例如提醒时间设得短一些，提醒方式强烈一些。但是要注意这又有可能和MIS工程师的利益相抵触，你不断地强烈提醒他，可能他正需要时间思考来解决一个难题，这实际上对他形成了干扰。这就需要MIS工程师和部门经理之间有一个妥协，要去问清楚，这是需求工程师的工作。怎么妥协，包身工式的公司和人性化管理的公司是不一样的。总之，一切需求的来源是涉众，这个项目涉及到的人，包括用户，也包括我们开发人员自己。

D：谢谢你的讲解。有没有什么好书可以推荐？

U：温伯格的《探索需求》马上就要出版了，你可以买来看看，里面有很多有用的技术。

D：我现在看一本陆丽娜翻译的《软件需求》。

U：我知道，机械工业那本。

D：对，我那个用例模板也是从那本书上来的，我看那书上和你说的好像有些地方不太一样。

U：没有本质上的不同，思想都是一致的。目前来说，用例是帮助贯彻这些思想的一个比较好的利器。至于模板什么的无所谓的，只要你能把该捕获的需求写出来，写在草纸上都可以。

D：书里面没有提到涉众利益。

U：我看看，比如说57页，第7章，寻找客户的需求，这里面的用户类、寻找用户代表，还有谁做出决策，不就是我们说的涉众吗，书里面翻译成风险承担者的就是。他可能没有写在模板上，但是你要知道这些是需求的来源，不能猫在办公室里“写用例”，编需求。而且也要让涉众来验证。69页那里也描述了我们刚才说的那些需求的类别。这本书没有强求你一定要使用用例这种方式来组织它们，但用例技术确实能【强迫】你去思考这些问题。

笔者为首席专家。1999年创建UMLChina，潜心研究UML/UP相关技术的应用。这些年，笔者已经上门为50多家企业提供关于用例驱动的面向对象分析设计技术的指导。