如果批任务要比一个复杂的用例还要大，那么它应该还有不止一个目标，因此该工作可以分解成更多的用例，每一个用例都能够服务于至少一个投资者的利益。这种机理能够适用于任何用例，这些用例要比实际上还要复杂许多(见于表2)。如果您不能找到一个好的原因，去分解一个批任务，您可以转化成图 1 中提到的“补充性效果”类型。club.mypm.net

　　非常复杂的用例项目经理博客

　　一些作家看到了用例点方法中的困难之处，因为在8个业务的复杂用例与16个业务之间，没有什么不同之处。在我们的经验中，由超过12个业务组成的用例，能够满足不止一个目标。所以，它们是问题性用例模型的标志。换句话说，如果您拥有超过12个业务的用例，那么考虑一个新的用例就是值得的。service.mypm.net

　　在项目的早期阶段计算用例业务bbs.mypm.net

　　在写下所有的用例配置后，计算业务就变得简单起来。另一方面，估算是在项目的早期进行预测的。在这里，您只有用例模型，以及每一个用例的简单介绍。为了展望组成用例的流程，以及涉及到的用例事务，您需要经验的帮助。如果您没有这个经验，不要犹豫去咨询拥有类似系统和背景工作经验的同事。通过创建如表 2 所示 的扩展单来开始，并填入展望的事务。这将会形成管理用例范围的基础，您就能解释哪些用例需要比用户预料的那样更多的事务。项目管理培训

　　结论项目管理者联盟

　　为了对软件性能估算应用用力点方法，对它的基本组成有良好的了解是十分重要的。用例业务的概念是这样一种成分，它最好与一个环形路线结合，从用户启动的刺激源到系统的反应都是如此。如果系统等待进一步的刺激源的话，业务就算完成了。talent.mypm.net

　　与这个概念结合，我们需要对怎样以及什么时候计算业务作出一些建议。它更像是一种艺术，而不是一门科学，与常识和经验一起应用这些推荐，可与帮助您作出更有效的努力，并评价项目早期的成本。club.mypm.net

　　参考文献pmp.mypm.net

　　[1] Jacobson,Ivar 等，Object-Oriented Software Engineering. A Use Case Driven Approach, 修订版，Addison-Wesley 1993.项目管理者联盟