来自Rational Edge：这篇文章基于Simpay，一个通过移动电话操作的支付系统，的业务需求工程项目的经验，大致描绘了关于捕获业务需求的七个实用原则。

假定你已经有需求工程规范的一些经验，而且你突然面对一个包括多个公司，并跨越不同商业领域的重大业务需求方案。开始在你的心里出现问题：用例是否会在这个项目中使用？我应如何决定用例粒度的正确层次？我应如何构建用例模型？我必须裁剪标准的 IBM® Rational Unified Process 或 RUP以达到交付标准吗？这篇文章提供Alpheus，一位国际性的IT顾问，如何在Simpay（一个可共同操作的手持电话支付系统）组织需求工程项目¹中应对这些问题。它提取我们在项目中所学到的，成为七个实用的原则，它将举例说明你怎样在你自己的业务需求计划中取得成功。

该论述假定读者对需求工程，使用用例及对RUP的基本协议，有很好的理解。

Simpay 是关于开发联合现在分段的手持电话支付市场的、能共同操作支付的全新架构的第一步²。图 1 显示业务上下文的概观。Simpay 占领这上下文的中心位置，使用开放的接口，来整合手持电话商业要求者（代表多个零售商及[或] 内容供应者）和手持电话操作者（代表并认证最终客户），成为在线金融交易。Simpay 为支付认证，结算并解决手持电话操作者与手持电话商业要求者之间的资金流，提供服务。³

图 1: Simpay 商业上下文概观

业务需求过程被嵌入到一个把支付解决方案（如Simpay 产品）转变进入市场的大型过程中。产品展现了一个使用手动或自动过程的、从头建造的、新业务。由于预算必须控制得恰到好处，因此决定延期实现确切的自动化过程，直到业务已经被建模。

整体项目及商业特性可以摘要为：

• 多公司（Orange，Telef a M es，T-Mobile和Vodafone）
• 重视规模方面（支持约二亿八千万客户）
• 拥有虚拟团队的多国公司
• 持有名誉方面的潜在影响
• 覆盖多重专家领域（举例来说，无线通通讯，财政服务）
• 规则加强器，拥有多种不同的法律约束

这些特性表达了许多关于建立所有企业涉众、共同的、一致的业务需求集合的重要性和可见性。

我们介绍一个与RUP⁴ 结合的过程，跨越Simpay从商业想法到产品部署的项目生命周期。我们把活动和交付产物映射到 RUP的四个阶段（初始，精化，构建和产品化）及它们各自的里程碑。RUP 活动和交付产物最初剪裁为软件开发过程，然而项目已经有一个非常宽泛的范围（举例来说，一个交付产物是新公司的建立，如Simpay Ltd.）。然而，活动和交付产物有时大幅度地偏离 RUP 。而且，这个与 RUP最佳实践相反的进程，并不是可重复的。⁵ 然而，许多个别交付产物在重复的/增量的基础上产生，提供早期的评审，验证和质量保证，以及偶尔依靠早期的活动启动。

当我们想要在业务层次上捕获需求，而不指定特定交付产物是手动的或自动的，我们使用 RUP 业务建模规范作为我们的参考规范，并用需求工程的一些元素进行强化。对于我们定制的交付产物结构，参见文章的补充内容。

实践原则
下面，我们将讨论由我们的经验总结的实践原则。他们将会帮助你：

• 为你的业务需求寻找正确的边界（原则 1：得到正确范围）
• 适当结构化你的用例模型（原则 2：向你的用例目标和原则挑战； 原则3：使用需求属性决定最好的用例模型）
• 进一步详细说明你的业务需求（原则 4：分而治之：通过业务参与者分解）
• 适当描述你的业务用例（原则 5：用例描述：阐明“ 是什么”，而不是“如何做”）
• 连接你的业务用例,避免冗余，并确认你的需求（原则 6：提出域模型和原则7：使用实体的生命周期）

原则 1：确定正确范围
需求管理的目标是为了确定正确范围。边界在哪里呢？谁在里面而谁在外面呢？这是更高层次的抽象，更为重要的。在范围方面很小的变化，就可能会带来与企业所有者相关，将要开展的工作，及项目运行的最后期限的重大影响。

让我们回顾图 1，这次把它当作一个市场视图。⁶ 这个视图显示购买（购物相互作用）和付款相互作用；它也显示Simpay作为支付中介。现在，比较图1与图2。除了使用不同的记号（UML）之外，图 2 显示两个不同的语境。上面一个是具有销售功能的商人的语境，它在购买商品用例中表现。下面的一个是 Simpay 拥有的支付功能，用请求支付用例表现。⁷

如果你认真地看，你将会看到这个特征把Simpay从市场视图分为两个部分：Simpay 产品和和 Simpay 有限公司。当我们发现 Simpay 产品不仅仅Simpay有限公司（也就是，中心实体）需要，也被移动操作者、及移动商家要求者实体需要时，这种区别是必要的。同时，这些实体识别到产品的功能；因此，所有的三方都在项目范围内。

这是在斤斤计较吗？不！它帮助我们清晰地建立项目边界。这意谓着我们可以从早期开始，就能避免不必要的讨论。在事后，这些区别可以看得很清楚，除了新的业务活动，为涉及到需求活动的当事者确定边界。然而，这是值得研究的工作。

图 2: 商业语境和 Simpay 语境

原则 2: 挑战你的用例目标
一旦你确定了你的范围，你可以开始确定用例和参与者。一个通常的问题是用例模型爆炸式快速增长，特别当你正在业务需求的抽象层工作的时候。很快的，你将会发现你需要表达很多内容。从字面上，停留在你的用例模型的顶层以避免“700 用例并发症”。如果你的用例模型正在爆炸式增长，你应该挑战你的用例粒度。对于 Simpay来说，在最高抽象层，我们以大约二十种主要用例作为结束。记住，一个用例传递值的一些东西给参与者；它为参与者实现一个目标。确保所有用例目标都在相同的层次上，并且对于业务建模来说所有目标都在抽象层上。

有一个来自 Simpay 语境的具体实例。支付可以立刻实现——支付授权⁸ 和支付捕获⁹ 同时发生，或延期实现——授权在捕获之前发生。图 3 显示了一个可能的用例图。然而，请注意用例所表现的目标并不在同一层次。商家的目标是接受支付。他必须服从管理规则，并把支付事务，分离为捕获之后的独立授权，这可能不是他乐意的。同时，你被迫表达在请求支付授权和请求支付捕获之间的一些关系。一个简单的解决方案是把这两个用例，结合为一个称为Request Deferred Payment的用例。¹⁰ 你以更少的用例完成，并进一步得到易于理解的用例建模。

如果在授权和捕获之间有一个长的时间间隙，那是什么呢？这你无须关心！时间间隙并不是你分隔用例的指示器；尤其是业务用例可以是长期运转的。决定是否分隔用例的本质标准是他们的目标是否不同。

导致用例膨胀的另外一个危险是我称之为“睡莲并发症状”。当你为一个用例找到一种变化的时候，它就开始了；在 Simpay 例子中，它可能是支付发生的通道（例如，SMS，WAP）。你可能马上被我们例子中的多用途用例所诱惑（要求使用WAP，SMS等方式立即支付）。也可能存在更多的维数。很快地，你就可以像睡莲覆盖池塘一样，覆盖你的用例图。相反地，向目标挑战。如果你做些分析，你将会发现目标对于所有这些用例都是相同的。把焦点集中在本质的用例上，稍后你会知道表现这些变更的更好的方法（举例来说，在用例描述的特别需求部分）

同时, 当你确定支持目标，如维护重要的业务实体，把它们排除在外，使之独立并使用自己的图支持用例包。

图 3：不同的目标层次

原则 3：使用需求属性决定最好的用例模型
需求属性包含需求信息。优先级：显示一个需求 对于 商业用户有多重要。迭代：表明需求分配到哪个迭代。稳定度：指出哪些需求可能遭受变更。还有更多的属性，但是，让我们把目光集中到上述三个属性上。请确定你在坚持不懈地为你的用例捕获这些属性。为什么呢？因为他们可以使你的过程变成更轻松。特别地，你将时常会有关于如何构建用例模型¹¹的多种选择；当你这样做时，用上述的属性定位你的用例模型。这将产生最少的重构工作，并聚焦于你的工作。

实际上，考虑下列的指导方针以决定你的选择：

1. 如果任何的这些指导方针违背原则2，并导致用例增加，不要应用指导方针！
2. 如果两个用例有不同的优先级，避免合并它们。
3. 如果两个用例被分配到不同的迭代中，避免合并它们。
4. 如果两个用例具有不同的稳定性等级，避免合并它们。
5. 不要为取得不稳定用例的模型花太多时间；这个功能可能根本上不需要改变。现在，把焦点集中在稳定用例上，以得到正确的模型。

记住：你如何重构用例模型将会影响其它的工作。业务用户将不得不找到适合新模型的方法，对于不同的可交付变量的追踪也将需要被更新。从一开始就正确地构建模型，也将节省其他人的时间。

在上面的例子中，我们坚决反对把延期和即付功能，归并到一个单一用例中（如，请求支付），因为“初始Simpay开发，可以而且也会包括延迟的或直接的支付”可能很快会被产生；无论选择哪种支付机制，其它的将是以后版本的范围。这种用例反复属性的变化，导致分裂为即付请求和迟延支付请求。

原则 4：分解和规则 – 通过业务参与者分解
现在你有一个结构良好并可以理解的业务用例模型。接下来你要往哪里去呢？一件重要的事情是 不要 把功能分解到你的用例模型中；即，不要把你的用例打破成较小的部分。这样的部分将会变成孤立的，违反用例步骤的最重要的优点之一：在参与者的目标语境中呈现需求。相反地，答案是递归地在当前语境中，基于用例步骤重新应用。

让我们回过头看看图 3。底部的 Simpay 产品语境显示由Simpay 有限公司，移动操作者和移动商业要求者实现的Simpay 产品。这些实体的 RUP 术语是 业务参与者 。这些业务参与者合作完成 Simpay 产品功能。一个，二个，或所有的业务参与者都参与每个 Simpay 产品用例。通过这一信息，你可以为每个业务参与者（由Simpay产品语境分配的）产生一个语境。每个语境由下面二者建立：(1)通过业务参与者划分用例，和(2)从现有的业务参与者派生出新的参与者。这个过程在图 4 中举例说明，它为移动操作者显示了一个实例结果。带有两段用例和一个新参与者（Simpay 有限公司）的新的移动操作者语境已经由更高抽象层派生出来。现在你能分开控制（相互调用）新的语境。¹²

这与功能分解有什么不同吗？是的！取替在Simpay 产品语境（不是由参与者目标激发的）创建孤立的部分的是，你已经用新参与者表现的精确目标，创建了更小的域。看看移动操作者语境的结果。明显地，Simpay 有限公司代表移动业务需求方（依次代表贸易商）做这些事情。然而，移动操作者的领域是自我包含的；它不需要了解Simpay 有限公司参与者做什么。相反地，功能分解方式将把用例分解成许多部分：获得商业细节；进行外汇交易；授权支付；捕获支付。哪种方式更适合管理方案范围呢？

图 4: 业务参与者划分。 点击这里放大。

原则 5: 用例描述：陈述“是什么”，而非“如何做”
很幸运；我们拥有感兴趣的业务代表，他们很快地就适应了用例方式，和有能力的技术队伍，他们的目标是把需求自动翻译成科技规范。然而，如同它被生成一样，业务代表尽可能地由状态激发，而且科技队伍对于强加于他们之上的不必要的限制因素感到不安。用例通过描述产品做什么来展现需求，以达到参与者的目标。“ 做什么 ”和“ 如何做 ”间的产品活动是人们特别是全球性的分布化团队不太清楚的一些事情，误解是正常的。这里有四种类型的指导方针可以帮助我们避免这些错误：

1. 特定的自然语言表达有技术内涵。（举例来说，回路）。如果你使用这些表达，确定他们在作为技术设计建议时不会被误解。
2. 业务用例描述商业流；它们决定谁是信息的来源，以及谁是目标。它们没有暗示流的技术实现。没有明确定义信息是否要推或拉，信息交换是批量的或在线的，是否要使用缓存。这样的技术性的决断主要关联到非功能需求。确定人们理解业务用例中的词，例如联系、请求，不要为基本的技术交流基础设施暗示技术约束。
3. 争取涉及参与者及产品间的简单交流模式。尝试遵照同步请求/响应¹³ 沟通模型。这暗示一个请求的响应在用例描述持续情况下，或者被接收，或者不被接收（举例来说，在超时的情况下）。当用例已经在它的描述中继续前进时，它不可能接受响应。请求的表达是充分的，并且它简化了描述。应强调的是，它并不暗示同一模型的技术性实现。
4. 当你为用例步骤编号时，人们通常认为你正在下令应该如何完成功能。¹⁴ 然而，用例步骤的顺序通常仅仅关系到参与者的下一个交互。当在这样一组步骤的特定顺序被托管时，请习惯于跟随明确的状态。

交流这些指导方针是重要的。对于 Simpay 来说，我们在产品概述文档（见页面边栏）捕获它们。在RUP中最适合做这件事的地方是用例模型，指导方针文档。更为重要的是，如果你正工作于定制的过程之中，要有一个试验。选取一个用例，并努力与整个队伍前进一致，这样每个人都会对你将如何生成事务及管理期望，感到满意。

原则 6：提出域模型
在 RUP 中一个域模型（见图 5）被定义为：在域的语境中捕获最重要类型的对象。域模型是业务分析模型的一个子集，业务分析模型包含描述业务参与者（见原则4）和业务实体如何获得用例功能的业务用例实现。域模型很有用，即使你不提出业务用例实现。它通过为你的用例描述提供具有精确含义的通用词汇术语，来连接你的各个用例。域模型确保相同的术语指向相同的业务实体。正好也捕获如下类型的需求：

• 业务实体和它们的多样性之间的联系（举例来说，一个移动用户使用一个或多个移动电话）
• 限制因素（举例来说，一个支付不能够超过一个特定的数值）和推导规则（举例来说，利息计算），尤其当这些不仅仅与一个用例相关时

结构化你的域模型文档，为这一信息（见到图 5）加入占位符。在我的经验中，业务用户对这些细微改进的形式感到相当满意，而且它为你提高稳定性和完全性检验：

• 所有的业务实体及它们的属性是否都已经定义？
• 你是否已经捕获了所有的联系？
• 所有涉及的业务实体是否至少在一个用例中？
• 所有涉及的业务实体是否都存在于域模型的用例中？

当创造域模型的时候，除了根据常识和你的读者偏好之外，你能使用下列的指导方针：

1. 使用图帮助描述，尤其是显示业务实体间的彼此联系。
2. 宁愿冗余的泛化；否则，你可以从你的业务用户那里要求。
3. 对于简单的关系类型使用属性；否则，你将会使你的图混乱。
4. 当属性的类型会明显避免制造困惑时，忽略它们。
5. 如果识别符（比如用户ID）与商业无关，忽略它们。
6. 只有当参与者名字有助于澄清语境的时候，才使用它们。否则，意味着把业务实体作为参与者命名，以避免弄乱你的图。
7. 产生相关条目的简单导航技巧。域模型将会时常被用于查找信息。对于 Simpay来说，我们使用IBM Rational Rose为域模型捕获信息，使用IBM Rational SoDa来产生简单的导航文档。

一个域模型如何与一个术语表相关联？一个术语表定义了项目中使用的重要术语。以这个定义为基础，一个域模型是术语表中术语的一个子集。但要避免冗余：在术语表或域模型中定义一个条目，但是不要在两者里面都下定义。通常，当你知道更多关于你的商业域时，术语从术语表转移到域模型。然而，你的术语表对于那些不存在于业务实体中的术语，仍然是有用的交付产物内容。

图 5：域模型图和相关文本。 点击这里放大。

原则 7: 使用实体生命周期
实体生命周期在商业规范中未得到充分利用，但是，一个好的解决方案是可用的：UML状态图。 你为什么要使用这些，以及它们如何关联到用例？业务实体（举例来说，一个移动使用者）通常有跨用例的生命周期。一个在状态之间的用例过渡（通常是不同的，状态图给一个统一视图，它关于你的重要业务实体在哪里，如何被操纵。图 6 显示一个关于移动使用者业务实体的例子。转变表现了维护移动用户的用例¹⁵ ，并在不同状态间转化它。

作为一个分析师，你也可以使用状态图保持你的需求集的一致性和完整性。我的业务实体是如何成为实物的呢？我是否已经错过了一个重要的状态？我是否已经描述我的用例中支持的所有转变的所有状态？我是否错过了影响转变的特别条件？

限定最重要的业务对象的生命周期，而在你的文档中描写所有状态。你的用例将以正确定义的域模型术语，描述涉及的这些状态，在保持可读性的情况下，把歧义从你的规范中排除。一个用例描述（涉及到图 6 所示的实例）会如下被看到：

4. 移动操作者确认移动用户并未被禁止。

这种禁止状态 指明了移动用户所处的状态，并为状态展现了一个非常精确的定义。依赖参数选择，你可以使用格式来强调文本中的状态。

生命周期最好作为由业务实体定义（如图5所示）耦合的附录，置于域模型中。你能够使用IBM Rational Rose来维护状态图并文档化状态，而且你也可以使用IBM Rational SoDa 产生易于操纵的文档。

采用这种方式，当你把实体生命周期置于业务用户之前时，你可以就像技师¹⁶ 一样，在没有做出需求时，平衡使用它们的好处。

一个对于未来的调查：通过模型驱动架构，¹⁷ 你将会独立于一个特定的平台，受益于预先指定的精确性态。除此之外，可运行的 UML 将会使你可以在你开始着手不惜代价的细分你的需求之前，确认你前面的模型。

图 6：状态图：手机用户 -- 生命周期

总结
用例是捕获业务需求的一个优秀的方法。只要你定义适当的抽象层，以支持可理解及可追踪的全部细节，他们就可以通过大的项目很好地伸缩。仅仅增加用例的数目并不起作用。确认你的需求的业务用户，会对基于用例的方法感到非常舒服。关于这种方法，精心描述你的自动化业务用例，让技术需求的技术团队通常更容易被接受。

因此，如果你被分配了一个复杂的业务需求项目，不要绝望。通过应用用例方法于需求工程，一个由可靠的开发过程及本文中呈现的原则，细化支持的方法，你就能克服许多挑战，并使方案成功。正如我所做的，你甚至可能已经发现，它是一个令人满意的实践。

感谢
我很感谢在 Simpay 中的人们，因为他们在本文中描述的方法中所承担的工作。特别是Tim Jones，Simon Richards，Martin Rugfelt 和 Jim Wadsworth。特别感谢我的同事Martin Elliffe提供了有帮助的说明及建议。

脚注
¹在这该文章中，我使用需求工程，作为业务需求工程一个简称。

²本文所用的例子来源于宽泛的Simpay语境。一些已经被简化了，仅仅用来论证要点和要求的观察保密性。因此，请读者不要把这些例子，理解为真实的Simpay活动。

³更多关于 Simpay 商业模型的细节，见 www.simpay.com。

⁴更多关于 RUP 的细节，见 Philippe Kruchten的《The Rational Unified Process. 》，Addison-Wesley，2000及 http://www-306.ibm.com/software/awdtools/rup/index.html。

⁵非迭代交付的主要障碍是，IT解决方案和它的操作者是由第三方转包，并通过一组法律合同集成到整个过程的事实。一个迭代过程会在这些法律合同中增加重要的复杂性。

⁶尽管不是与RUP关联的标准4+1 视图的一部分，但这一视图是基本的。在最后，你不得不出售你的产品。

⁷两个语境有很明显的关系。作为在商业语境中购买产品用例的一部分，商业触发器支付请求使用 Simpay 语境中的例子。

⁸商人确定手机使用者能支付和为他储备的货币。

⁹商人请求应支付给他的金额。

¹⁰实际上，你甚至可以更进一步考虑，并有一个独立的支付请求用例：我们的确决定反对它。理由是范围管理, 但是继续向下看。

¹¹我不在这里讨论扩大并包括联系。以我的经验，最好在你的业务用例模型中避免这些联系。

¹²在《 The Object Advantage》（Addison-Wesley，1995，第173页），E.A. Jacobsen 介绍了一个算法，用于映射一个业务用例模型到一个系统用例模型。这里使用一个类似的算法，把一个业务用例模型映射到不同语境中的另一个业务用例模型。

¹³在确定的环境中，你可能有一个不存在响应的请求。如果响应没有业务含义，这与被提议及将被使用的模型完全一致。

¹⁴相反地，我强烈建议你使用一个有细密纹理的编号样式，作为用例描述。它允许你改良一致性、完整性检查及参照。

¹⁵如果一个用例在多种状态间转换为业务实体。你可以转换为备选流或一组步骤（举例来说，使用标签或你用例描述的数字记号）。

¹⁶让我强调一下，它们可能看起来象技师，但是它们不是技师，因为它们仅仅书写商业决策的文档。

¹⁷更多关于模式驱动架构的细节，参见 http://www.omg.org/mda 和 Behrens，Richards的《 StateLator in Advanced Information Systems Engineering》，Springer，2000。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  

关于作者 Thomas Behrens 是Alpheus（www.alpheus.com）的技术总监和需求工程市场方面的头。他宣传在建立解决方案之前，需要了解并定义它，主要在技术驱动环境中。他在电讯和财务服务领域已经领导了大量的需求项目。由于作为 IBM Rational Rose的首批用户之一，他对于IBM Rational工具和这种训练的相关过程非常专业。他在软件工业中作为不同的角色有14年的经验。Thomas 是一个认证 IBM 讲师。他从德国慕尼黑的陆海空三军大学获得计算机科学的学位。