1704180572
假定你已经有需求工程规范的一些经验，而且你突然面对一个包括多个公司，并跨越不同商业领域的重大业务需求方案时，心里一定会想：用例是否会在这个项目中使用？我应如何决定用例粒度的正确层次？我应如何构建用例模型？我必须裁剪标准的IBM Rational Unified Process或RUP以达到交付标准吗？这篇文章提供者Alpheus（一位国际性的IT顾问）就如何在Simpay（一个可共同操作的手持电话支付系统）组织需求工程项目中应对这些问题进行了深刻地思考。他总结了我们在项目中所学的知识，成为七个实用的原则，他将举例说明你怎样在你自己的业务需求计划中取得成功。
1704180573
1704180574
该论述假定读者对需求工程、使用用例及对RUP的基本协议都有很好的理解。
1704180575
1704180576
图2-3给出了Simpay商业语境的概观。Simpay在整个系统中处中心位置，它使用开放的接口，来整合手持电话商业要求者（代表多个零售商及[或]内容供应者）和手持电话操作者（代表并认证最终客户），成为在线金融交易。Simpay为支付认证，它为手持电话操作者与手持电话商业要求者提供各种资金流相关的服务。
1704180577
1704180578
业务需求过程被嵌入到一个把支付解决方案（如Simpay产品）转变进入市场的大型过程中。产品展现了一个使用手动或自动过程的从头建造的新业务。由于预算必须控制得恰到好处，因此决定延期实现确切的自动化过程，直到业务已经被建模。
1704180579
1704180580
整体项目及商业特性可以摘要为：
1704180581
1704180582
多公司参与。
1704180583
1704180584
重视规模方面（支持约二亿八千万客户）。
1704180585
1704180586
1704180587
1704180588
1704180589
图2-3 Simpay商业语境概观
1704180590
1704180591
拥有虚拟团队的多国公司。
1704180592
1704180593
名誉方面的潜在影响。
1704180594
1704180595
覆盖多重专家领域（举例来说，无线通信、财政服务）。
1704180596
1704180597
规则加强器，拥有多种不同的法律约束。
1704180598
1704180599
这些特性表达了许多关于建立所有企业涉众、共同的、一致的业务需求集合的重要性和可见性。
1704180600
1704180601
现在，我们来介绍一个与RUP结合的过程，它跨越了Simpay从商业想法到产品部署的项目生命周期。我们把活动和交付产物映射到RUP的四个阶段（初始、精化、构建和产品化）及它们各自的里程碑。RUP活动和交付产物最初被简述为软件开发过程，即使项目已经有一个非常宽泛的范围（举例来说，一个交付产物是新公司的建立，如Simpay Ltd.），但是在执行过程中，活动和交付产物有时大幅度地偏离RUP，而且这个与RUP最佳实践相反的进程并非可重复的。许多个别交付产物在重复的/增量的基础上产生，提供了早期的评审、验证和质量保证，并且偶尔依靠早期的活动启动。
1704180602
1704180603
当我们想要在业务层次上捕获需求，而不指定特定交付产物是手动的或自动的，就可以使用RUP业务建模规范作为我们的参考规范，并用需求工程的一些元素进行强化。对于我们定制的交付产物结构，参见文章的补充内容。
1704180604
1704180605
下面，我们将讨论由我们的经验总结的实践原则。它们将会帮助你：
1704180606
1704180607
为你的业务需求寻找正确的边界（原则1：得到正确范围）。
1704180608
1704180609
适当结构化你的用例模型（原则2：向你的用例目标和原则挑战；原则3：使用需求属性决定最好的用例模型）。
1704180610
1704180611
进一步详细说明你的业务需求（原则4：分而治之：通过业务参与者分解）。适当描述你的业务用例（原则5：用例描述：阐明“是什么”，而不是“如何做”）。
1704180612
1704180613
连接你的业务用例，避免冗余，并确认你的需求（原则6：提出域模型，以及原则7：使用实体的生命周期）。
1704180614
1704180615
原则1：确定正确范围
1704180616
1704180617
需求管理的目的是为了确定正确范围。边界在哪里呢？谁在里面而谁在外面呢？这是更高层次的抽象。你要明白在范围方面很小的变化，就可能为你带来重大影响，如工作量的增加，工期的缩短等。
1704180618
1704180619
让我们回顾图2-3，这次把它当做一个市场视图。这个视图显示购买（购物相互作用）和付款的相互作用；它显示出Simpay是支付中介。现在，比较图2-3与图2-4，除了使用不同的记号(UML)之外，图2-4显示了两个不同的语境。图片上方是具有销售功能的商人的语境，它在购买商品用例中表现；图片下方是Simpay拥有的支付功能，用请求支付用例表现。
1704180620
1704180621
如果你认真地看，将会看到这个特征把Simpay从市场视图分为两个部分：Simpay产品和Simpay有限公司。我们发现当Simpay产品不仅仅被Simpay有限公司（也就是，中心实体）需要，也被移动运营商及移动商家银行实体需要时，这种区别是必要的。同时，这些实体能识别到产品的功能；因此，所有的三方都在项目范围内。