作者：张克强 作者微博：张克强-敏捷307
RUP尽管对于业务对象建模进行了具体的说明，但其本身并没有把业务对象建模（领域模型）、业务用例作为必须的工件。Rational系方法把业务用例作为需求规格说明（SRS）前的推荐工件。在《编写有效用例》中，业务用例被放在非常次要的位置，前面提到云朵和风筝时，科伯恩并没有清晰的指出这是业务用例，相反的还是在系统范围内讨论用例。
并且科伯恩还指出了2大“坏消息”。
Dean Leffinwell, Don Widrig所著《软件需求管理用例方法》第2版中的一个小节：何时使用业务建模：业务建模不是我们对每一个软件project工作的推荐。当应用环境是复杂并且横跨多领域。并且很多人员直接參与到系统使用，业务建模带来最大价值。
比方，假设你在一个既有通讯交换器上加入一个补充功能，你没有必要考虑业务建模。还有一方面。假设你要为GoodAreUs建设订单入口系统，那么进行业务建模为支持问题分析带来优点。
附加说明，《软件需求管理用例方法》书中前文是採用业务用例来进行业务建模的，这与RUP是一样的，此书总共502页，业务建模章节占了8页。
在Frank Armour和Granville Miller的《高级用例建模卷Ⅰ:软件系统》一书中，没有提及业务用例。有意思的是。提出了“发现概念层次的系统用例”，而且与科伯恩利用目标帮助识别用例的方法联系起来了。
这与《编写有效用例》事实上是一样的观点，《编写有效用例》在前面说明不同目标的用例，并没有提到业务用例，所分析范围事实上是在系统范围内，恰是符合此书提出的“概念层次的系统用例”。
在KurtBittner，Ian Spence《用例建模》（出版社 清华大学出版社。出版时间 2003-5-1）中。全书相同没有提及业务用例，其提出描写叙述问题领域和环境的关键概念是必需的，有三种形态：1，简单的文本词汇表；2，正式的领域模型。3，带有图片说明领域模型的文本词汇表。从其说明能够看出。正式的领域模型包含业务用例。
Doug Rosenberg / Kendall Scott 的《UML用例驱动对象建模》（出版社: 清华大学出版社
出版年: 2003-7-1），也即是著名的ICONIX方法，全书相同没有提到业务用例。
高焕堂编著的《USE CASE入门与实例》（2008年出版)全书没有提到业务用例。
徐峰的《软件需求最佳实践》（ 出版社: 电子工业出版社 出版年: 2008）使用其他方式进行业务流程分析，没有提到业务用例。
邱郁惠著的《系统分析师UML用例实战》（2010年出版）是一本用例分析入门书，全书没有提到业务用例。
谭云杰的《大象Thinking in UML》第2版，全书有526页，书中前后花费了17页来说明了业务用例。当中提到“并非全部的软件须要从业务用例建模開始”。其17页中的将近一页来是用来说明使用和不使用业务用例模型的理由，核心内容与Dean Leffinwell, Don Widrig所著《软件需求管理用例方法》中的“何时使用业务建模”是一致的。
在某本我不愿意提起书名但口气超大的书中，花了前面的131页来谈业务建模，而后面的需求分析占据101页。是众多用例类书的特例。
在最新的Use-Case 2.0中。业务用例在后半段被提到了一次，重点放在了引入Use-Case Slice。
通过以上，能够清楚的看到，业务用例在用例分析中的位置：1，没必要的。2。可被替代的。
就笔者亲身经历而言。除了在RUP材料与及Rational兴许文章中看到较好的业务用例之外，就没有在实际使用中看到过合乎RUP的业务用例。在笔者亲自參与的项目中，都是直接採用用例（系统用例）。而在处理复杂而且不熟悉的业务时，绘制流程图、活动图等等来作为理解业务的载体。
很多其它相关文章
需求用例分析之中的一个：异常流需求用例分析之二：级别设置
需求用例分析之三：补充规约
需求用例分析之四：业务规则