第三章 过程 

    编写好的用例是极其个性化的，每个人都有他自己的风格，每个组织都有根据自己的文化和业务需要做事情的方式，因此，没有创建用例

的通用过程。

    3.1 BreadthBeforeDepth

    原因：

    需求收集是一个发现过程，用例编写是一个迭代过程；
    人们很早就开始编写用例的细节；
    人们浪费了精力或陷入了太多的细节，通常都会失去重点，无法描述所有可能的扩展条件；
    从早期获得概述是有益的；
    最初编写的细节越多，在了解系统后必须进行的改变也就越多；

    所以：

    通过首先开发用例的概述来保存精力，然后逐步增加细节，并行开发一组相关用例。

    完成概述用例后，随着对系统了解的增多，不断提高用例精度，避免突然开发完所有用例或一次只开发一个用例的倾向。

    3.2 SpiralDevelopment（螺旋式开发）

    原因：

    理解系统的行为可能会花掉大量时间，要求渐进式分析；
    拖延是昂贵的。要尽快完成用例的编写；
    对需求进行分析后，需求很可能会发生变化；
    需求成本的错误是昂贵的；

    所以：

    以一种迭代的，宽度优先的方式开发用例，每次迭代都会提高用例集的准确性和精度。

    基本过程：

    从简单的东西开始，如一个参与者/用例列表；
    简要描述用力主场景，即高层用例，以包含用例的主要范围；
    扩展摘要的子集，并填充细节；
    评审并调整；

    3.3 MultipleForms

    不同的项目需要不同程度的形式化，每个人对模板都有不同的偏好，要求每个人都使用相同的用例模板只会起到相反的作用。

    原因：

    每个人的个性、经验和经受的锻炼不同，每个开发组织都有其特有的人员、历史和文化；
    不同的项目有不同的需要；
    不同的编写团队需要不同程度的规范和严格度；
    在组织中使用公共的编写形式有助于交流；
    在同一个项目上使用不同的模板不是一个好主意；

    因此：根据项目相关的风险性、项目特点，和所涉及到的人员选择用例的编写格式，并在该项目的开发过程中的组织内部使用。

    3.4 TowTireReview（评审）

    许多人都可能需要评审用例，这是一件昂贵耗时的事情。

    原因：

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

    所以：

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

次。

    3.5 QuittingTime

    开发一个超出了涉众和开发人员需要的用例模型不仅浪费资源，而且会拖延项目进度。

    原因：

    忽视重要需求的巨大恐惧使构建人员和涉众延长了需求收集活动；
    大多数人可以用一种合理的模糊性工作，即不言自明；
    详细讲述谎言并不能使他们更为精确；

    所以：

    在用例完整并且符合参与者的需要后，停止开发用例；
    用例模型完整性的检验：完整、可读、逻辑上正确、对开发人员足够详细。
    是否识别了所有的参与者和目标并将其编成了文档？
    客户及其代表是否承认用例集是完整的，而且每个用例都是可读的和正确的？
    设计人员是否能够实现这些用例？

    3.6 WriterLicense

    小的格式差别并不重要，解决了所有系统问题后，及时还存在一些格式问题，也可以停止编写。