1.用例的本质上是一种功能分解技术。

2.用例的读者：

　　1)最终用户或业务专家；2)程序员；

3.用例的编写者：

　　1)至少一位具有编程背景的人，以获得描述所要求的准确和精度；

　　2)至少一位熟知业务规则的人；

　　3)至少一位熟知在实际中如何使用系统的人；

　　创建小的用例编写团队(smallWritingTeam)。

　　原因：用例要求具有不同观点和专业知识的人编写。

　　　　　但是将一大组人聚集在一起是困难的，理论上，在用例上投入的人越多，就能越快的完成用例编写工作；实际上，大的团队会变得低效。因为，大型编写团队势必会通过集体讨论的形式开发用例，添加许多不必要的特性。

　　所以：一个由2或3人组成的团队足够小，容易交流和达成一致。

　　　　　可以使用几个smallWritingTeam，但应当制定一位用例设计师，以保证所有的用例与愿景一致。最终的目的是使过程保持在可管理的状态，大的团队将在管理上投入更多的精力。

4.用例的开发过程：

　　1)首先开发用例的概述是有益的。完成概述用例后，随着对系统的了解的增多，不断提高用例的精度。避免一开始就陷入用例编写的细节，失去重点，无法描述所有可能的扩展条件。而到了用例编写后期，在了解系统后又必须进行大量的修改。

　　2)理解系统的行为可能会花掉大量时间，拖延的成本是昂贵的，要尽快完成用例的编写；对需求进行分析后，需求很可能会发生变化，需求错误的成本是昂贵的。以一种迭代的，宽度优先的方式开发用例，每次迭代都会提高用例集的准确性和精度：

　　　　1>从简单的东西开始，如一个参与者/用例列表；

　　　　2>简要描述用例主场景，即高层用例，以包含用例的主要范围；

　　　　3>扩展摘要的子集，并填充细节；

　　　　4>评审并调整；

　　3)在同一个项目上使用不同的模板不是一个好主意。不同的项目需要不同程度的形式化，不同的编写团队需要不同程度的规范和严格度，每个人对模板都有不同的偏好。在组织中使用公共的编写形式有助于交流，根据项目相关的风险性，项目特点，和所涉及到的人员选择用例的编写格式，并在该项目的开发过程中组织内部使用。

　　4)分批次的评审用例

　　原因：许多人都可能需要评审用例，这是一件昂贵耗时的事情。对于验证和确认编写及内容来说，评审是必要的。涉众在用例上有一种既得利益，但是每个人参与编写过程非常昂贵，麻烦并且缓慢；如果仅由一个小的编写组进行评审，就不会考虑所有涉众的利益；评审可能是昂贵的、乏味的、耗时的。

　　所以，两种类型评审：一是由较小的内部小组进行的评审，可能需呀重复进行很多次；二是由整个团队进行的评审，可能只进行一次。

　　5)适度停止用例开发工作

　　忽视重要需求的巨大恐惧使构建人员和涉众延长了需求收集活动，开发一个超出了涉众和开发人员需要的用例模型不仅浪费资源，而且会拖延项目进度。大多数人可以用一种合理的模糊性工作，即不言自明，详细讲述谎言并不能使他们更为精确。在用例完整并且符合参与者的需要后，就需要停止开发用例。

　　用例模型完整性的检验：

　　　　1)完整、可读、逻辑上正确、对开发人员足够详细。

　　　　2)是否识别了所有的参与者和目标并将其编成了文档?

　　　　3)客户及其代表是否承认用例集是完整的，而且每个用例都是可读的和正确的?

【tool】有效的用例编写规则