针对每个业务事件，有一个预先计划的对它的响应，被称为“业务用例（BUC）”。业务用例总是包处理过程的含一些可识别的过程，一些被存取的数据，产生一些输出，发送一些消息，或是这些事情的组合。换言之，业务用例就是一个功能单元。这种单元是编写功能需求和非功能需求的基础。
可以把一个业务用例的工作隔离开来，因为它的处理和其他业务用例基本上没有联系，BUC之间唯一的重叠是它们存储的数据。每个业务用例的相对隔离，这意味着可以找到一些利益相关者，他们是这部分工作的专家，他们可以准确并详尽地描述这部分工作。他们也可以描述业务用例，利益相关者了解业务时间，他们可以告诉你，组织机构如何响应所有的业务事件。
工作对业务事件的响应是连续的处理过程，直到所有的任务已经完成，所有的数据已取得或存储为止。可以将响应想象成处理过程和相关存储数据形成的链条。注意，围绕处理过程的是数据存储和相邻系统。
我们应该跳出到外部环境，在组织机构的外部寻找，顾客和供应商是怎么响应的工作的，这样才能在理解客户期望的工作的成果的基础上，构建业务用例，从而推动设计出最佳的，支持工作的产品。
关于业务用例的描述
我们强调，业务用例的描述，需要基于组织或个体想完成什么，他的期望和预期的结果是什么。如描述“将CD中的音乐放到MP3播放器中”，而不能描述成“转录CD并转换为MP3格式”
关于业务用例（BUC）和产品用例（PUC）
BUC中由自动化系统处理的部分就是产品用例（PUC）。有时候PUC的功能最后就是BUC的功能（你决定自动化所有的东西），但是通常功能的某个部分不会成为PUC，你决定这个任务最好由人完成，所以这就是结果：导出了PUC。它不是在需求调研开始时假定的，而是分析了工作后不小心得出的结论。从BUC导出PUC，你找到了更有用的产品，它对拥有者的价值贡献更大。
有时，出于技术上的原因，可能选择用几个产品用例来实现一个业务用例。或许你希望计算机内部的工作划分成更小的部分。或许有机会复用一些产品用例，它们是以前为产品的其他部分或其他产品开发的。或许不同类型的利益相关者只关注业务用例的某个部分。
产品用例的选择在某种程度上是由技术考虑驱动的。但是，如果产品要让预期用户认可并认为有用，那么它的PUC必须基于最初的业务事件，必须能追溯到业务用例。
网友评论