需求和用例的误区

      往往貌似简单的东西里面别有洞天，用例就是这样一个东东，这两天给客户做需求和用例相关的培训及咨询，发现有一些比较共通的误区，结合以前遇到过的一些问题，整理了一些要点，记录在此，权当是抛砖引玉了

椭圆!=用例
    很多人认为用例就是那个椭圆，其实大错！我想Ivar Jacobson博士“发明”这个椭圆的时候只是想表述“用例”是个具有封闭性特征的对象，仅此而已。而用例的关键是在这个椭圆边界的内部。有些需求文档在粘上用例图后，简单的用一些概述性的文字就了事了，这是远远不够的。通常情况下需要以下这些条目才能有效的描述一个用例内部的内容：概述、基本路径、备选路径、前置条件、后置条件、扩展点、特殊需求、辅助说明等，对于界面交互的功能性需求，字段说明和屏幕模拟设计都是对需求非常有效的辅助说明手段，而对于内部流程相对复杂的用例，一个活动图也不失为一个有效的表述手段。

用例技术是手段而不是目的
      很多人这需求建模的时候脑子里面始终忘不了的还是那个椭圆以及和这个椭圆相关的诸多概念，诸如关联、依赖、包含、扩展等等，这难免有些本末倒置，因为需求分析的目的不是用例而是需求。用例只是获取需求的一种手段，用例的精髓在于通过对业务模型的有效分解和规格化表达有效的获取和描述需求。明白了这一点就能很好理解用例在需求获取过程中的作用——仅仅是一个方法而已，本质上和一个锤子或钳子没什么区别，而工具的使用一切都是为了满足需要，而不是满足某一种标准，谁说锤子只能竖着锤而不能横着敲？

用例不是万能的
    事实上，并不是所有的需求都是适合用用例来描述的，比如眼前这个客户，其产品系列中有一个应用是一个类似与IDE界面的图形化设计工具（有点像VS.Net的Form设计界面），最初，SA还是尝试用用例来获取该应用的需求，但很快就发现，由于边界的模糊和路径极度的交叉，用用例来表述需求几乎是一件不可能完成的任务。当我们在周例会上讨论这个问题时，我的答案非常简单，用例比较适合于功能性的业务系统，而其作为一种方法，毫无疑问只有在合适的时候才应该被采用，不合适的时候我们尽可以将他抛弃

 如何与客户沟通需求（用例）
    曾经有一个兄弟提过一个问题，说他在和客户确认需求的时候，因为提交给用户的需求规格书上充满了那“该死的椭圆”，使他不得不费了半天的功夫向客户解释什么是用例，从Jacobson讲到RUP，结果到最后那个客户（还是位小姐）瞪着两只大眼睛，怯生生的说：“我本来对你写的东西还似懂非懂的，现在彻底糊涂了！”我们这位兄弟当场郁闷疯了。
    其实我们这位客户小姐真的很无辜，她一个对软件的认识仅仅停留在Word和 QQ的行政管理人员，你让她要搞明白什么是用例实在是勉为其难。所以当我们把充满了“该死的椭圆”的需求文档提交给客户的时候，未必要告诉他那个椭圆的学术名字，而仅仅将小人和椭圆解释为“谁”要“干什么”就可以了。这是最自然的解释，用户也最容易理解。最后我们的兄弟改变策略，如法炮制，果然不爽。