软件需求分析与业务建模之间的关系

软件需求分析过程中对于业务的建模是一个十分重要的流程，业务的建模决定我们项目开发的成败。

(1)业务问题的范围是参与项目的启动各方同意的。它确定了要研究的工作领域以及围绕它的相邻系统。

(2)相邻系统为工作提供数据，并从工作那里接受数据。

(3)业务事件在相邻系统中发生，通常该时间请求工作提供一项服务，另外如果工作在某个时候应该向相邻系统提供某些信息，就发生了时间触发的业务事件。

(4)工作对业务事件的响应被称为一个业务用例。 业务用例包括作出正确响应需要的所有处理和数据。

工作的范围

工作的上下范围图展示了工作与业务环境之间的关系。而要对工作进行研究，则必须包括所有受产品影响的东西。

工作的上下文范围包括了所有允许改变的东西，以及所有需要理解的东西，以便确定什么可以或应该改变。

任何工作都响应外部发生的事件，因为是在讨论拥有者的工作或业务，把这些事件成为“业务事件”

业务事件在工作范围之外发生。 通过到达的信息流，工作得知业务事件已发生。 工作包含了一个业务用例，对这个业务事件进行响应。

注意：业务用例是通过来自相邻系统的信息流来触发。

时间触发的业务事件是由某个事先确定的时间（日期）的到来所发起的。 例如，保险公司在你的保险单周年到期的一个月，给你发送一份续保通知。 对于时间触发的业务事件，通常的响应是读取以前的存储数据，处理它，并将产生的信息送到相邻系统。

业务事件和业务用例的优势

从外部看，可以明确的看到工作的范围。

系统的存在都是事前假定的。 分析者猜测自动化系统的边界应该是什么，并通过查看参与者和自动化系统交互，开始调研，而完全忽略了围绕这些交互的工作。 以产品为中心来看问题的方式，意味着你忽略了自动化系统最重要的方面：它打算改进的工作。

务事件是让工作以某种方式作出反应的事件。 业务事件可能发生在工作范围之外（外部事件），或者因为到了做某事的事件而发生（时间触发事件）。 对于外部事件，工作与外部世界（或相邻系统）的信息交流让工作知道事件已发生。 对于时间触发事件，结果总是流向外部世界的信息流。 不论哪种情况，在业务事件发生时，在上下文范围图内中至少会显示一条数据流。