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有限公司（也就是，中心实体）需要，也被移动运营商及移动商家银行实体需要时，这种区别是必要的。同时，这些实体能识别到产品的功能；因此，所有的三方都在项目范围内。
1704180622
1704180623
1704180624
1704180625
1704180626
图2-4 商业语境和Simpay语境
1704180627
1704180628
这是在斤斤计较吗？不！它帮助我们清晰地建立项目边界。这意味着我们可以从早期开始，就能避免不必要的讨论。在事后，这些区别可以看得很清楚，除了新的业务活动，为涉及需求活动的当事者确定边界。然而，这是值得研究的工作。
1704180629
1704180630
原则2：挑战你的用例目标
1704180631
1704180632
一旦你确定了范围，就可以开始确定用例和参与者。一个通常的问题是用例模型爆炸式快速增长，特别当你正在业务需求的抽象层工作的时候。很快，你将会发现你需要表达很多内容。从字面上，停留在你的用例模型的顶层以避免“700用例并发症”。如果你的用例模型正在爆炸式增长，你应该挑战你的用例粒度。对于Simpay来说，在最高抽象层，我们以大约20种主要用例作为结束。记住，一个用例传递值的一些东西给参与者；它为参与者实现一个目标。确保所有用例目标都在相同的层次上，并且对于业务建模来说所有目标都在抽象层上。
1704180633
1704180634
有一个来自Simpay语境的具体实例。支付可以立刻实现——支付授权和支付捕获同时发生，或延期实现——授权在捕获之前发生。图2-5显示了一个可能的用例图。然而，请注意用例所表现的目标并不在同一层次。商家的目标是接受支付。他必须服从管理规则，并把支付事务，分离为捕获之后的独立授权，但这可能不是他乐意的。同时，你被迫表达在请求支付授权和请求支付捕获之间的一些关系。一个简单的解决方案是把这两个用例，结合为一个称为Request Deferred Payment的用例。你以更少的用例完成，并进一步得到易于理解的用例建模。
1704180635
1704180636
1704180637
1704180638
1704180639
图2-5 不同的目标层次
1704180640
1704180641
如果在授权和捕获之间有一个长的时间间隙，那是什么呢？这你无须关心！时间间隙并不是你分隔用例的指示器，尤其是业务用例可以长期运转时。决定是否分隔用例的本质标准是它们的目标是否不同。
1704180642
1704180643
导致用例膨胀的另外一个危险，我称之为“睡莲并发症状”。当你为一个用例找到一种变化的时候，它就开始了；在Simpay例子中，它可能是支付发生的通道（例如，SMS、WAP)。你可能马上被我们例子中的多用途用例所诱惑（要求使用WAP、SMS等方式立即支付）。也可能存在更多的维数。很快，你就可以像睡莲覆盖池塘一样，覆盖你的用例图。相反，向目标挑战。如果你做些分析，将会发现目标对于所有这些用例都是相同的。把焦点集中在本质的用例上，稍后你会知道表现这些变更的更好的方法（举例来说，在用例描述的特别需求部分）。
1704180644
1704180645
同时，确定支持目标，如维护重要的业务实体，并把它们排除在外，使之独立并使用自己的图支持用例包。
1704180646
1704180647
原则3：使用需求属性决定最好的用例模型
1704180648
1704180649
需求属性包含需求信息。优先级：显示一个需求对于商业用户有多重要；迭代：表明需求分配到哪个迭代；稳定度：指出哪些需求可能遭受变更，此外还有更多的属性，但是，让我们把目光集中到上述三个属性上。请确定你在坚持不懈地为你的用例捕获这些属性，因为它们可以使过程变成更轻松。特别地，你将时常会有关于如何构建用例模型的多种选择；当你这样做时，用上述的属性定位你的用例模型。这将产生最少的重构工作，并聚焦于你的工作。
1704180650
1704180651
实际上，考虑下列的指导方针有助于你做出选择：
1704180652
1704180653
如果任何的这些指导方针违背原则2，并导致用例增加，不要应用指导方针！如果两个用例有不同的优先级，避免合并它们。
1704180654
1704180655
如果两个用例被分配到不同的迭代中，避免合并它们。如果两个用例具有不同的稳定性等级，避免合并它们。
1704180656
1704180657
不要为取得不稳定用例的模型花太多时间；这个功能可能根本上不需要改变。现在，把焦点集中在稳定用例上，以得到正确的模型。
1704180658
1704180659
记住：你如何重构用例模型将会影响其他的工作。业务用户将不得不找到适合新模型的方法，对于不同的可交付变量的追踪也将需要被更新。从一开始就正确地构建模型，也将节省其他人的时间。
1704180660
1704180661
在上面的例子中，我们坚决反对把延期和即付功能归并到一个单一用例中（如，请求支付），因为“初始Simpay开发，可以而且也会包括延迟的或直接的支付”可能很快会被产生；无论选择哪种支付机制，其他的将是以后版本的范围。这种用例反复属性的变化，导致分裂为即付请求和迟延支付请求。
1704180662