zhijie435

    2.团队没有能力实现用例驱动
      如果开发团队在设计与测试时，根本不依照用例细节进行，那用例就只是个摆设，花瓶。
      解决方法：对设计、测试人员进行用例驱动的培训，如果事不可为就干脆放弃，怎么省事怎么做。 

    3.在用例中描述系统内部工作
      经典错误，开发人员把用例当作设计文档来写，如“系统将销售信息写入数据库”，实际上应该写的是“系统记录销售”。
      解决方法：站在客户的角度，把系统视为黑盒，删除所有内部设计描述。

   4.在用例中描述界面
      另一个经典错误，不说了。

    5.在用例中越出系统边界描述整个业务流程
      要建立的系统只是整个业务流程里的一部，善良的需求人员为了大家清楚来龙去脉，将系统外的处理步骤也写进了用例的情景。
      如：
      1.用户去营业厅开户
      2.用户拨号接入
      实际上去营业厅开户不属于宽带接入认证系统的职责。
      解决方法：开户的描述应该放到用例的前置条件中。前置与后置条件是说明系统边界外的业务流程的好地方。 

  6.过多的用例，让人晕菜
      国外的惯例，一个用例一般有半个以上人月的开发量。
      解决方法：
      1.CRUD型的用例可以合并成一个管理用例，以四个主场景分别表达。
      2."老板问：你每天做什么阿?"，"我每天登陆系统"。这就是用例没有提供足够价值的明显标志。
      3.用例中的每一个步骤，其实都可以写成一个独立的用例，分 or  不分？
      4.用例的打包组织是一门艺术。

    7.过多的扩展事件和异常事件流，让人晕菜
      即使是受过训练的程序员，2a, 3b1看多了也要晕掉，记住阅读者是人而不是机器。    
      解决方法：
      1.如果逻辑不多，可以一句话讲完，不影响主场景的，不建议新起一个事件流。
      2.可以使用活动图来辅助说明。在RSM7.0的模版里，每个用例都会带上一个活动图。

    8.过多的关系，继续让人晕菜
     “不要花一个月的时间去讨论应该include还是extend”。大家对include, extend and generalize都不熟悉，那就干脆都不要用了。   

参考材料：
    《编写有效用例--Wriging Effective Use Case》Corkburn 2001，大家现在使用的用例模版都是他创下来的，此书无可替代。
    《用例模式与蓝图--Use Cases Patterns and Blueprints》我觉得比另一本名字相近的《Patterns for Effective Use Cases》要实用一些。