用例规约要细致到万无一失吗？

网友的来信：

 谭先生，您好！
      最近在拜读您的大作《大象》，收益良多，正是我在寻找的一份有正在将uml运用于实际场景过程的好教材。在阅读中，我反复回顾并结合了我在实践中的一些积累。有一个关于用例规约的小问题想请教下。
      先介绍下问题的背景，我从事的产品以web界面为主，业务逻辑本身并不十分复杂，产品设计人员产出物为 用例规约和原型demo，开发即开始进行相应的表设计，开发，没有做到您提的三个层级建模的过程（这样的人才和资源要求比较高）。（呵呵，我想这是国内很多公司的做法吧:-D）。
      问题就产生于这样的产品开发流程中，到了产品的深入开发以及测试阶段，开发、测试、产品设计人员往往会对于一些用例规约的模糊地带产生比较多的分歧，诸如，用例中是否应该包含ui的信息，比如怎么交互，使用什么控件，反馈信息应该如何。另外，用例规约对于一些实现层面的异常流程的处理的说明如果缺失话，往往会造成争持，而作为用例产出者的产品设计人员也往往很委屈，觉得无法做到"事无巨细"。
      关于这样的问题，个人理解，归结到底，就是用例的细腻程度应该如何？望谭先生不吝赐教！
      另，还在学习中，如有疑问的产生还希望得到您的继续指教，非常感谢！

我的回复：

     你好。用例当中有关于UI设计的内容，在RUP当中称为用例示意板。在实际操作当中往往用界面原型进行描述，如您的产品以WEB为主，那么使用静态html配合用例规约就是比较适合的方法。在你所描述的情况当中，交互信息、异常情况是应当尽量考虑清楚的，但是不论如何仔细，永远都不可能做到事事具备。如果花费过于大的精力去描述用例的各个方面，把争持认为是用例规约没有描述清楚，很容易走入过度设计的死胡同。我不相信谁能够保证把用例规约写到没有万一的地步，那不符合软件规律。

   所以，我们要接受现实，不是用例规约出了问题，而是实施方法出了问题。用例不仅是分析人员的事，也是测试人员的事，也是开发人员的事。在实施上，他们都应当参与进来，而不是等待分析员的结果。在决定一个用例规约的时候，测试人员就应当能够产生测试用例，对于模糊地带，在讨论用例的过程当中来进行澄清。RUP之所以使用迭代的开发方法，就是要在每一个迭代时重新审视、修改用例规约，让各方都参与进来，把模糊地带搞清楚。

   请告诉你的同事们，用例规约的责任不仅仅是产品设计人员的事，也是开发，测试的事，他们也是责任者而不仅仅是使用者和旁观者。争执是不可避免的，但是争执如果发生在用例讨论过程当中而不是产品开发和测试时，争执就是好事情而不是委屈了。

最后再做一点补充：

在一个敏捷的团队里，一个用例就相当于一个work item，或者一个task，或者一个userstory，不论叫什么名字，这个用例是由整个团队来维护的讨论的，不同职责的成员关心它的不同部分，但大家讨论的是同一个用例。在迭代的过程中，这些讨论被不断的深入，一个一个的模糊地带被不断的澄清，大家对同一个问题越来越清楚。当必要的改变发生时，大家分别负责改变自己的部分。最后，需求部分、分析部分、设计部分、代码、测试用例、测试代码、测试结果、缺陷纪录、变更纪录....所有围绕用例产生的东西都成为了用例的一个组成部分。

可见，用例规约不是一开始就事无巨细的。这位网友的问题其实是在软件过程中产生的，非常普遍，方法好讲，解决起来并不容易。关键是要建立一个自驱动的团队，大家都意识到用例是所有人的，软件过程是迭代的而不是瀑布的，这样，用例驱动的意义才能够体现出来。