使用用例捕获业务需求

《使用用例捕获业务需求》由会员分享，可在线阅读，更多相关《使用用例捕获业务需求（12页珍藏版）》请在金锄头文库上搜索。

1、 版权所有 IBM 公司 2005商标 使用用例捕获业务需求第 1 页，共 12使用用例捕获业务需求导致区别的七个原则Thomas Behrens 首席技术官 Alpheus解决方案2005 年 2 月 15 日来自Rational Edge：这篇文章基于Simpay，一个通过移动电话操作的支付系统，的业务需求工程 项目的经验，大致描绘了关于捕获业务需求的七个实用原则。假定你已经有需求工程规范的一些经验，而且你突然面对一个包括多个公司，并跨越不同商业领域的重大业务需求方案。开始在你的心里出现问题：用例是否会在这 个项目中使用？我应如何决定用例粒度的正确层次？我应如何构建用例模型？我必须裁剪标准

2、的 IBM Rational Unified Process 或 RUP以达到交付标准吗？这篇文章提供Alpheus，一位国际性的IT顾问，如何在Simpay（一个可共同操作的手持电话支付系统）组织需求工程项目1中应对这些问题。它 提取我们在项目中所学到的，成为七个实用的原则，它将举例说明你怎样在你自己的业务需求计划 中取得成功。该论述假定读者对需求工程，使用用例及对RUP的基本协议，有很好的理解。Simpay 是关于开发联合现在分段的手持电话支付市场的、能共同操作支付的全新架构的第一步2。图 1 显示业务上下文的概观。Simpay 占领这上下文的中心位置，使用开放的接口，来整合手持电话商 业

3、要求者（代表多个零售商及或 内容供应者）和手持电话操作者（代表并认证最终客户），成为 在线金融交易。Simpay 为支付认证，结算并解决手持电话操作者与手持电话商业要求者之间的资金流，提供服务。3developerW 2 页，共 12图 1: Simpay 商业上下文概观业务需求过程被嵌入到一个把支付解决方案（如Simpay 产品）转变进入市场的大型过程中。产品展 现了一个使用手动或自动过程的、从头建造的、新业务。由于预算必须控制得恰到好处，因此决定 延期实现确切的自动化过程，直到业务已经被建模。整体项目及商业特性可以摘要为： 多公司（Orange，Telef a M es，T-Mobile和

4、Vodafone） 重视规模方面（支持约二亿八千万客户） 拥有虚拟团队的多国公司 持有名誉方面的潜在影响 覆盖多重专家领域（举例来说，无线通通讯，财政服务） 规则加强器，拥有多种不同的法律约束这些特性表达了许多关于建立所有企业涉众、共同的、一致的业务需求集合的重要性和可见性。我们介绍一个与RUP4 结合的过程，跨越Simpay从商业想法到产品部署的项目生命周期。我们把活动 和交付产物映射到 RUP的四个阶段（初始，精化，构建和产品化）及它们各自的里程碑。RUP 活动 和交付产物最初剪裁为软件开发过程，然而项目已经有一个非常宽泛的范围（举例来说，一个交付 产物是新公司的建立，如Simpay Lt

5、d.）。然而，活动和交付产物有时大幅度地偏离 RUP 。而且，这个与 RUP最佳实践相反的进程，并不是可重复的。5 然而，许多个别交付产物在重复的/增量的基础 上产生，提供早期的评审，验证和质量保证，以及偶尔依靠早期的活动启动。当我们想要在业务层次上捕获需求，而不指定特定交付产物是手动的或自动的，我们使用 RUP 业 务建模规范作为我们的参考规范，并用需求工程的一些元素进行强化。对于我们定制的交付产物结 构，参见文章的补充内容。 3 页，共 12实践原则下面，我们将讨论由我们的经验总结的实践原则。他们将会帮助你： 为你的业务需求寻找正确的边界（原则 1：得到正确范围） 适当结构化你的用例模型（

6、原则 2：向你的用例目标和原则挑战； 原则3：使用需求属性决定最 好的用例模型） 进一步详细说明你的业务需求（原则 4：分而治之：通过业务参与者分解） 适当描述你的业务用例（原则 5：用例描述：阐明“ 是什么”，而不是“如何做”） 连接你的业务用例,避免冗余，并确认你的需求（原则 6：提出域模型和原则7：使用实体的生命 周期）原则 1：确定正确范围需求管理的目的是为了确定正确范围。边界在哪里呢？谁在里面而谁在外面呢？这是更高层次的抽 象，更为重要的。在范围方面很小的变化，就可能会带来与企业所有者相关，将要开展的工作，及 项目运行的最后期限的重大影响。让我们回顾图 1，这次把它当作一个市场视图。

7、6 这个视图显示购买（购物相互作用）和付款相互作 用；它也显示Simpay作为支付中介。现在，比较图1与图2。除了使用不同的记号（UML）之外，图 2 显示两个不同的语境。上面一个是具有销售功能的商人的语境，它在购买商品用例中表现。下面的一个是 Simpay 拥有的支付功能，用请求支付用例表现。7如果你认真地看，你将会看到这个特征把Simpay从市场视图分为两个部分：Simpay 产品和和 Simpay 有限公司。当我们发现 Simpay 产品不仅仅Simpay有限公司（也就是，中心实体）需要，也被移动操 作者、及移动商家要求者实体需要时，这种区别是必要的。同时，这些实体识别到产品的功能；因

8、此，所有的三方都在项目范围内。这是在斤斤计较吗？不！它帮助我们清晰地建立项目边界。这意谓着我们可以从早期开始，就能避 免不必要的讨论。在事后，这些区别可以看得很清楚，除了新的业务活动，为涉及到需求活动的当 事者确定边界。然而，这是值得研究的工作。developerW 4 页，共 12图 2: 商业语境和 Simpay 语境原则 2: 挑战你的用例目标一旦你确定了你的范围，你可以开始确定用例和参与者。一个通常的问题是用例模型爆炸式快速增 长，特别当你正在业务需求的抽象层工作的时候。很快的，你将会发现你需要表达很多内容。从字 面上，停留在你的用例模型的顶层以避免“700 用例并发症”。如果你的用例

9、模型正在爆炸式增长，你 应该挑战你的用例粒度。对于 Simpay来说，在最高抽象层，我们以大约二十种主要用例作为结束。 记住，一个用例传递值的一些东西给参与者；它为参与者实现一个目标。确保所有用例目标都在相 同的层次上，并且对于业务建模来说所有目标都在抽象层上。有一个来自 Simpay 语境的具体实例。支付可以立刻实现支付授权8 和支付捕获9 同时发生，或 延期实现授权在捕获之前发生。图 3 显示了一个可能的用例图。然而，请注意用例所表现的 目标并不在同一层次。商家的目标是接受支付。他必须服从管理规则，并把支付事务，分离为捕获 之后的独立授权，这可能不是他乐意的。同时，你被迫表达在请求支付授权

10、和请求支付捕获之间的 一些关系。一个简单的解决方案是把这两个用例，结合为一个称为Request Deferred Payment的用例。10 你以更少的用例完成，并进一步得到易于理解的用例建模。如果在授权和捕获之间有一个长的时间间隙，那是什么呢？这你无须关心！时间间隙并不是你分隔 用例的指示器；尤其是业务用例可以是长期运转的。决定是否分隔用例的本质标准是他们的目标是 否不同。导致用例膨胀的另外一个危险是我称之为“睡莲并发症状”。当你为一个用例找到一种变化的时候， 它就开始了；在 Simpay 例子中，它可能是支付发生的通道（例如，SMS，WAP）。你可能马上被我 们例子中的多用途用例所诱惑（要

11、求使用WAP，SMS等方式立即支付）。也可能存在更多的维数。 很快地，你就可以像睡莲覆盖池塘一样，覆盖你的用例图。相反地，向目标挑战。如果你做些分 析，你将会发现目标对于所有这些用例都是相同的。把焦点集中在本质的用例上，稍后你会知道表 现这些变更的更好的方法（举例来说，在用例描述的特别需求部分） 5 页，共 12同时, 当你确定支持目标，如维护重要的业务实体，把它们排除在外，使之独立并使用自己的图支持 用例包。图 3：不同的目标层次原则 3：使用需求属性决定最好的用例模型需求属性包含需求信息。优先级：显示一个需求 对于 商业用户有多重要。迭代：表明需求分配到哪 个迭代。稳定度：指出哪些需求可能

12、遭受变更。还有更多的属性，但是，让我们把目光集中到上述 三个属性上。请确定你在坚持不懈地为你的用例捕获这些属性。为什么呢？因为他们可以使你的过程变成更轻松。特别地，你将时常会有关于如何构建用例模型11的多种选择；当你这样做时，用上 述的属性定位你的用例模型。这将产生最少的重构工作，并聚焦于你的工作。实际上，考虑下列的指导方针以决定你的选择：1. 如果任何的这些指导方针违背原则2，并导致用例增加，不要应用指导方针！ 2. 如果两个用例有不同的优先级，避免合并它们。 3. 如果两个用例被分配到不同的迭代中，避免合并它们。 4. 如果两个用例具有不同的稳定性等级，避免合并它们。 5. 不要为取得不稳

13、定用例的模型花太多时间；这个功能可能根本上不需要改变。现在，把焦点集 中在稳定用例上，以得到正确的模型。记住：你如何重构用例模型将会影响其它的工作。业务用户将不得不找到适合新模型的方法，对于 不同的可交付变量的追踪也将需要被更新。从一开始就正确地构建模型，也将节省其他人的时间。在上面的例子中，我们坚决反对把延期和即付功能，归并到一个单一用例中（如，请求支付），因 为“初始Simpay开发，可以而且也会包括延迟的或直接的支付”可能很快会被产生；无论选择哪种支 付机制，其它的将是以后版本的范围。这种用例反复属性的变化，导致分裂为即付请求和迟延支付 请求。developerW 6 页，共 12原则

14、4：分解和规则 通过业务参与者分解现在你有一个结构良好并可以理解的业务用例模型。接下来你要往哪里去呢？一件重要的事情是 不 要 把功能分解到你的用例模型中；即，不要把你的用例打破成较小的部分。这样的部分将会变成孤 立的，违反用例步骤的最重要的优点之一：在参与者的目标语境中呈现需求。相反地，答案是递归 地在当前语境中，基于用例步骤重新应用。让我们回过头看看图 3。底部的 Simpay 产品语境显示由Simpay 有限公司，移动操作者和移动商业要 求者实现的Simpay 产品。这些实体的 RUP 术语是 业务参与者 。这些业务参与者合作完成 Simpay 产 品功能。一个，二个，或所有的业务参与者

15、都参与每个 Simpay 产品用例。通过这一信息，你可以为 每个业务参与者（由Simpay产品语境分配的）产生一个语境。每个语境由下面二者建立：(1)通过业 务参与者划分用例，和(2)从现有的业务参与者派生出新的参与者。这个过程在图 4 中举例说明，它 为移动操作者显示了一个实例结果。带有两段用例和一个新参与者（Simpay 有限公司）的新的移动操作者语境已经由更高抽象层派生出来。现在你能分开控制（相互调用）新的语境。12这与功能分解有什么不同吗？是的！取替在Simpay 产品语境（不是由参与者目标激发的）创建孤立 的部分的是，你已经用新参与者表现的精确目标，创建了更小的域。看看移动操作者语境的结果。 明显地，Simpay 有限公司代表移动业务需求方（依次代表贸易商）做这些事情。然而，移动操作者 的领域是自我包含的；它不需要了解Simpay 有限公司参与者做什么。相反地，功能分解方式将把用 例分解成许多部分：获得商业细节；进行外汇交易；授权支付；捕获支付。哪种方式更适合管理方 案范围呢？图 4: 业务参与者划分。 点击这里放大。 7 页，共 12原则 5: 用例