《掌握需求过程》学习笔记3

【volere需求过程-理解需求层次】-从业务用例到产品用例

总结：

本章讲工作、事件、业务用例，产品用例，产品等概念的本质，为需求调研阶段滤清概念，提供理论基础，引导调研过程有序，稳步进行。

1. 业务事件描述了工作和外部环境的交互的过程。它是由系统，或外部组织产生的。业务事件会触发业务用例
2. 一个业务用例，可以分解为一个或多个子用例。这些子用例，有些是人工操作完成的；而有些是系统完成的，由系统完成的部分，我们称之为产品用例。

3. 本书描述的范围域概念【外部环境，工作，产品】之间的关系如下所示：

   
   范围域之间的关系

4. 活动域之间的关系如下所示：

   
   活动域之间的关系

工作
当我们说“工作”的时候，指的是完成业务的系统。这个系统包括人的任务、软件系统、机器、低科技的设备（如电话、影印机、手工文件和笔记本），实际上包括了用于生产拥有者的产品、服务和信息的所有东西。只有理解了这项工作和它的预期输出，才能知道怎样的产品对拥有者最有价值。

工作的意义
工作存在的价值，在于，它向外部世界提供服务，它应该是顾客或客户希望改进的那部分业务。为了能提供那些服务，工作必须从外界接收信息和信号，将这些输入作为原材料，将一些信息和型号送回外界，即这些东西的消费者。

外部世界
外部世界是由相邻系统代表，它们是自动化系统、人、部门、组织、以及其他向工作提出某种要求，或作出某种贡献的参与方。

你需要定义工作和外部世界之间的关系，它向外部世界提供了什么服务，而外部世界又提供了什么服务，给工作。只有梳理清楚了，你才能知道工作的范围，并进一步挖掘产品的范围。

业务事件

我们使用业务事件来划分工作，因为，我们认为，它具有很清楚的辨识度，且具有系统性。

对业务事件的响应，我们称之为业务用例（BUC）

工作要不响应外部发生的事件，要不响应时间规则自动发生的事件。当业务事件发生的时候，工作通过发起一个业务用例进行响应。

例如，你在月末为信用卡账单付款。从信用卡公司的角度来看，这是一个业务事件。信用卡公司响应这个事件的做法是：核对你的地址没有改变，然后记录下支付的日期和金额。这个响应的过程，就是业务用例。

例如你在图书馆借书了之后，到了第6周的时候，图书馆就会自动响应，发出一次提醒给你。而这个时间触发的业务事件，其实也是有前置事件的，只不过这个前置事件已经预设规则在系统里面而已。

工作和业务事件之间的关系

事件发生意味着工作和外部世界建立了联系，也因此能提供服务给外部世界，或接受外部世界提供的服务。

事件的理解

工作对业务事件的响应，让所有该在一起的东西在一起。因此，你就得到了一些内聚的部分，并让这些部分之间的接口最小化。这种划分得到了逻辑性更强的一些工作分块，以便进行详细的需求调研。因为这些部分之间的依赖关系越少，分析师就越能调研一个部分的细节而不需要知道其他部分的信息。（这段话，我的理解是，工作对业务事件的响应，就是业务用例。这些用例的出现，应该是自然而然的。它们构成了一个完整的工作，并且和外界环境之间有清晰的边界，也就是作者所说的高内聚。另外一个层面这些用例也应该是分工明确，互不相交叉打扰，也就是另一个作者没说的部分，就是低耦合）。利用这些工作流来确定业务事件。

另外，我们应该要注意事件发生的时候，进入或离开工作的数据流，分析师利用这些信息流来确定业务事件，进入或离开工作的每个信息流都是一个业务事件的结果。（书本把外部世界提供的接口，也统一成为业务时事件的一部分，我个人认为，这是一个很好的统一地组织需求的方式，它不孤立接口，因为，接口也是有故事的同学，这样，接口需求也就可以以业务的视角来看待了）。

工作和产品的关系

工作是业务层面的，依然是产品拥有者的实际工作领域。而产品则是构建辅助更好地完成工作的构件，它可以是自动化系统，或其他。

很多人在构建系统，创造产品的过程中，只以产品中心来看问题。这种做法意味着，他们忽略了自动化系统最重要的方面：它打算改进的工作。

我们在做系统调研的第一步，应该是，跳出系统，从工作层面理解系统，才能以有限的资源，创造最大价值。这样才算是构建出更好的产品。