看看System Use Case的例子，“从数据库中查询低库存的”它太小了，容易跟需求的实现细节混淆。对比一下，作为System Use Case，“仓库管理”就太大了，它不能实现作为没有大的分支的行为的单一线索的原则，并且从系统的观点来说，它很难说明成功的目标，但它可以做为一个好的Business Use Case，对于配件部门来说，它可以定义“仓库管理”这一成功的目标（可能是根据库存调整、配件验收、成本操作等）。
这些Business Use Case的好处是它们能用于区分其它的Use Cases，就如：“仓库管理”可用于组织这些用于实际管理仓库的Use Cases。
Use Cases的正式定义
Use Case：特殊行为者（Actor）的价值的量化结果的提交
正如前面所说的，Actors可以是人也可以是正在设计的系统与之交互的外部系统，一个Use Case要求有一个量化的结果，从单个线索的需要提交。做为量化结果的组成，目标要么成功要么失败，没有其它的情况。
达到主要Actor的目标定义为成功，结果没有迎合主要Actor的目标定义为失败，不同的情节显示了成功或失败的途径。
Use Cases的说明
Use Cases的好处是一些情节能用不同程度的正规化的文字说明。每个情节涉及Use Cases中单一的途径，细节是条件组。
不正规的文本描述也能使用，不过当条件较多和可能失败的情况下它们很难跟随下去。开始试图理解需求时，不正规的叙述风格也是非常有用的，然而随着Use Cases的进展，使用更加正规的机制去说明Use Cases才是有用的。
下面是客户对Use Case“下定单”的粗略概略：
“确定客户，找出需要的并且仓库里还有的物品并检查客户信用额是否够用”
结构化叙述的格式已经被证明是非常有效的。这个格式所做的事是描述每一个情节的行为者：目标语句对的顺序。在这个顺序中，每一个行为者：目标的语句对都假设前一个的目标是成功的，右面是一个简单的范例：
Use Cases认为我们正在设计的系统是一个单一的黑盒，根本没有任何内部结构被记录下来，并且它被认为是一个情节产生的目的及对应单一的行为者（Actor）。这些Use Cases没有表示任何关于系统内部的东东，只是表示系统将达到什么样的目标及由什么（人或其它系统）操作和负责。
文章来源于领测软件测试网 https://www.ltesting.net/
