每个人的个性、经验和经受的锻炼不同，每个开发组织都有其特有的人员、历史和文化;

　　不同的项目有不同的需要;

　　不同的编写团队需要不同程度的规范和严格度;

　　在组织中使用公共的编写形式有助于交流;

　　在同一个项目上使用不同的模板不是一个好主意;

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

　　3.4 TowTireReview(评审)

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

　　原因：

　　对于验证和确认编写及内容来说，评审是必要的;

　　涉众在用例上有一种既得利益;

　　使每个人参与编写过程非常昂贵、麻烦并且缓慢;

　　如果仅由一个小的编写组进行评审，不会考虑所有涉众的利益;

　　评审可能是昂贵的、乏味的、耗时的。

　　所以：

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

　　3.5 QuittingTime

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

　　原因：

　　忽视重要需求的巨大恐惧使构建人员和涉众延长了需求收集活动;

　　大多数人可以用一种合理的模糊性工作，即不言自明;

　　详细讲述谎言并不能使他们更为精确;

　　所以：

　　在用例完整并且符合参与者的需要后，停止开发用例;

　　用例模型完整性的检验：完整、可读、逻辑上正确、对开发人员足够详细。

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

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

　　设计人员是否能够实现这些用例?

　　3.6 WriterLicense

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