基于用例的需求管理框架

首先，让我们仔细研究一下用例的定义：
一个用例抽象了目标系统在现实中将执行的一组场景（每个场景由一系列动作组成）；这些场景会产生一个对某个Actor[/i]有价值的[/i]、可观测的结果;[/i]

在这个定义中，我们强调了两件事情：一、用例是被从现实的场景中抽象出来的，而不是被随便发明出来的；二、每个用例（场景）应能提供完整的商业价值。在未来的博文里会介绍这两条会如何帮助我们避免对用例的误用。

用例的优势在于它天生是黑盒的，它用自然语言抽象了用户和目标系统的交互，避免了混入分析、设计和实现细节，以保证用例可以被不懂具体技术的业务及测试人员所真正理解。同时，需求分析员又可以方便地通过用例分析（use case analysis）（即用分析类来试图在理想方式下实现用例），将需求体系精华成分析模型。在这一过程中，需求分析员可以更进一步地完善基于用例的需求体系，而不必担心分析模型会污染需求，从而实现需求与分析的分离及有效互动。

最后，我们必须指出，基于用例的需求管理体系中不仅仅包含用例，它还应该包括涉众请求，特性列表，前景文档，补充规约，词汇表等等。

用例其实是Ivar在许多年前发明的老技术了，现在被很多人所采用，而被更多人误用，下面的文章让我们看看一些对用例的典型的误解和误用。

用例是一个门槛很低的技术，任何人都可以随便画几个小人和几个椭圆，然后向全世界宣称我在用用例进行需求建模了，但是好像也没有真正解决我的问题。在这种情况下，用例技术很可能被误用了。在对用例不同类型的误用之中，最严重、最普遍的莫过于利用用例来进行功能分解了。刚在为了偷懒，想找张现成的错误使用用例的例子，结果找的了2001年Kurt写的在这方面的文章以及最近一位老兄在CSDN上给出的翻译（已经收藏在我的网摘里）。Kurt对这个问题的阐述已经相当清楚了，我也就不多写了，大家去看我的网摘或原文吧！

最近在与用户的沟通过程中，发现用户经常会认为用例是一种基于图形描述或UML的方法，从而质疑用例是否能够有足够的描述能力，或者用例是否易于被业务人员理解。其实，这是对用例的另一种典型的误解。

在用例模型中，的确会用到一些UML的图符（一个小人代表Actor，一个椭圆代表Use Case，等等），但这些图符是非常容易理解的。而且用例的主要信息是在需求规约当中，用例模型传递的信息可能只占所有相关需求信息的5%。

所以，我建议，大家可以粗略地认为用例与UML基本无关，它主要是一种基于文本的结构化地书写需求的方式。

用例的粒度问题一直是困扰着需求分析员的常见问题，对于这个问题，抱歉，没有银弹，我只能给出一些解决这个问题的基本原则：
1. 控制用例的总体数量[/b]：一般来说，一个相当复杂的系统的用例数量可能在30-50个之间，如果一个系统的用例数量大大超过了这一范围，那就该看看是不是陷入了功能分解的误区；
2. 高内聚、低耦合：[/b]用例是一种结构化写作需求的技术，用例是被从现实的场景中抽象出来的。如果这些场景有紧密的联系（高内聚），那用用例技术来组织它们则可以复用这些场景中的步骤描述，从而达到事倍功半的效果；
3. 写写看:[/b]很多时候在初步规划用例模型的阶段，有时很难判断一个用例的粒度是否合适，不要执迷于一次获得一个完美的用例模型和用例粒度。不妨先得出一个初稿，然后写写用例，看看是不是符合高内聚、低耦合的原则，实际上在写用例的过程中，用例模型往往是需要不断进行调整的；
4. 避免功能分解：[/b]功能分解是正确使用用例技术的最大敌人，很多用例粒度的讨论其实都是功能分解的思想在作怪。

目前大多数用户的开发都是对现有系统的升级和改造，在这样的情况下还能使用用例技术吗？很幸运答案是肯定的，你可以按照以下步骤进行：
1. 确定系统边界：通过标识Actor来定义系统边界；
2. 重构用例模型：简要地捕获和描述现有系统的用例模型；
3. 扩展用例模型补充用例规约：根据系统的升级和改造要求，增加新的用例或对已有用例进行扩展；在对现有用例进行扩展之前，则需要补充用例的基本事件流和涉及到的备选流，在以它们为基础来对描述需要的新行为；

这样，就可以在对现有系统的改造过程中，逐步地重构整个系统的用例模型和用例描述。

作为总结，可以记住这样两句话：
1、Login往往不是一个好的用例；
2、用例是不会互相调用的；

英文原文：
http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/WhyUseCasesAreNotFunctionsDec00.pdf

中文翻译：
http://blog.csdn.net/soaringbird/archive/2007/03/28/1544093.aspx

为什么用例不是“功能”？

by Kurt Bittner
General Manager
Rational Unified Process Business Unit

多数人从用例开始就走入了迷途，也许是用例图和数据流图的相似性导致人们把用例定义为简单的功能或者菜单项。不论原因是什么，这都是新手最容易犯的错误。



图 1 错误的方式：用例是菜单项或者功能
这幅图有什么错误？用最简单的定义，我倾向于把用例看作是关于使用系统作某些有用的事情的方式的故事。利用这个定义，是不是所有的“用例”都是独立的有用的呢？
答案当然是不是，在这个例子中，用例表示了系统需要做的所有的事情，但是他们也描述了用户需要通过系统去做的一件单独的事情：定购。所有保留的元素都是这一个用例的备选支流，它们是在定购时可能发生的步骤。在只做一件有用的事情的地方，只应该有一个用例。图1就是一个功能分解的例子，或者“四轮马车”格式的例子――一个参与者在中间，周围是一圈用例。
这是一个常见的问题，为什么人们会陷入这个陷阱呢？我们有一个有对定购的内在需要，并且在不存在的地方如果我们需要那么就利用它。在功能分解的情况下，我们有一种自然倾向把问题分解为越来越小的块。有一种天真的想法那就是把用例分解为越来越小的单位会简化问题。这种理解是完全错误的。当我们分解用例时，实际上会把问题复杂化。

问题在这里

用例的目的是描述某人某物如何使用系统来完成对他们有价值的事情，它描述了系统在概念层次上做什么，使我们足够理解系统以便决定系统是否要做恰当的事。用例是我们能够形成一个系统的概念模型。
再看看图1，现在问你自己，如果我从来没有定购过，我想通过系统查询定单的状态吗？这是不太可能的。或者如果我从来没有定购过，我想变更订单吗？不，也许不。通常这些东西只有当我订购过的时候才对我有用。然而，为了系统能够允许我订购，这些都是必要的。
把系统分解为越来越小的用例模糊了系统的真实目的，极端情况下，我们将以得到一堆隔绝的行为的细致末节而告终。结果我们不能说明系统做什么。这就像看到一辆被拆解为零件的汽车，或许你会说这是辆汽车，你也知道零件们是有用的，但是你确实不能说明他们如何组装在一起。
当使用用例的时候，记住用例是考虑整个系统的一种方式，并且要组织成可管理的功能块，这些功能块完成一些有价值的事情。为了得到正确的用例集合，问你自己一个问题：“参与者实际上想使用系统做什么？”
如果你在想图1的改进后的版本是什么样的，图2展示了改进后的版本。



图 2一种更好，更加简单的方法: 合并功能以反映对参与者的真正价值
这一个用例包含了以前的图中所分解为用例的所有“功能”。你也许会问为什么这样做比较好，答案很简单：它关注于客户想要系统提供的价值，而不是我们在系统内部如何细分和构造的。如果把所有的功能分解成单独的用例，你将迫使客户（为系统付钱的人）把分解过的用例装配成一件对他们有意义的东西，以便理解系统所描述的是不是他们所想要的（即他们想为之付钱的）。

关注价值

很多小用例是常见的问题，尤其是在一个习惯于功能分解的团队中，他们的用例名称读起来就象是一个系统所执行的功能的列表，如“输入订单”、“审查订单”、“取消订单”、“履行订单”，这起先听起来也不是很坏，但不仅仅这些。即使对于一个小规模的订购系统，用例列表也很容易达到上百个，如果谁走到了这一步，他们不久就会淹死在用例的海洋中，尤其是当系统规模确实比较大时，在这种情况下，你最终也许会有几百个，甚至上前个用例。

这么做有什么错呢？

这些用例的价值将会被错过。用例的唯一目的是为参与者产生价值。在一定层次上能够输入订单也是某种有价值的事情，但是，如果这些订单从来不被履行，那还有价值吗？也许没有吧。
怎样输入订单、修改订单以及取消订单等等，所有这些事情都是与客户真正想要做的事情有关的，那就是接受订购的货物。这些活动对公司想要的事情是必须的，那就是收到货款。

这种看起来是支离破碎的没有任何明显关系的功能集合的另一个问题是导致难以使用的系统。很多系统跟这个很类似，它们只是一堆杂乱的特性。记住，用例帮助我们关注与什么是真正重要的，也就是具有真正价值的事物，并且使我们能够围绕那些元素来定义系统。用例不要是系统按照功能分解的蓝图。

举例

考虑一个你在互联网上用过的一个电子商务系统，当你登录这个站点的时候，你的目标可能是查找产品相关的信息、选择要购买的产品、安排支付及送货约定。在做这些事的过程当中，你可能会改变主意、输入错误的信息以至不得不修改它、改变邮递或送货地址，以及其他的一些东西。如果这个网站不允许你通过一种吸引人的方式来找到并订购产品，你也许不会完成你的订购，更不用说再次来到这个网站。

当建造一个系统时，始终要记住用例的核心定义：关于采用某种方式使用系统来做有价值的事情的故事。如果你能够实施这个定义，展示用户希望通过系统获得的价值，然后创建反映这些价值的用例的时候，你的系统将会更好地满足用户的期望。

原文地址：Why Use Cases Are Not "Functions"