尽管这些用例的概念自从二十多年前已经生成，实际上许多软件从业者从没使用过它们或者甚至从来没有了解过他们。业务转型方法论越来越普遍，这很大程度上取决于过程规则，其实正在改变这个状况。普遍的工具比如 IBM Rational RequisitePro®(用来支持 RUP) 结合用例的生成作为需求定义过程的一部分。UML 的引入为软件描述设定了标准，已经进一步促进了用例的采用。

　　用例主要强调涉众需要这个系统交付什么，而不是描述如何实现终的结果。用例采用“黑盒”接近这个系统。 2 它应该陈述将要发生什么行为，但是并不陷入关于行为如何被实现的具体细节中。将一个用例看作是来自参与者观点导向的结果。只要结果被实现，这个参与者实际上并不真正在意这个行为是怎样执行的。因此，一个用例必须代表支持对参与者有重要价值的结果。

　　UML 将一个用例定义为“一个系统执行的一系列行为的描述，包括变量，它将生成特殊参与者所得值的可观测结果。” 3 当决定一个用例的构成时，这个“价值”的概念十分重要。如果您不想识别这个将由参与者识别的具体值，那么这个行为可能对一个用例来说不是一个很好的候选。 4

　　一个用例可以是图形的，也可以是文本的，但理论上两者都是用例。 5 用例可以创建为只读文本的格式，但是初都储存在像 Microsoft Word 这样的工具中。长期以来，在用例图中以图形的格式表示变得越来越普遍。使用 UML 和支持 RUP 的工具来构建用例模型是为常见的方法。这样的工具支持文本描述和支持图的多样性，从而更好地图解化此系统是如何被使用的。