基于业务描述语言BDL的需求方法论

业务需求

需求重要吗？业务需求重要吗？

为什么重要？它有多重要？

需求的切入点在哪里？

业务架构与业务需求之间是什么关系？

业务需求与软件需求之间又是什么关系？

软件需求与软件设计之间是什么关系？

设计与实现、实现与应用系统之间又是什么关系？

可以做到所需即所得吗？

……

说到需求我们爱恨交加，说到需求我们有很多话题。

1. 概述
   1. 1 基本概念

为了后面讨论方便，首先明确几个基本概念。

• 业务事项（Business Matter）

任何一个企业它在开展业务的过程中，就需要做一些“事”，这些事可能由客户触发，也可能由内部触发（例如盘点库存、统计报表），也可能由外部关联机构或系统触发，有的书上称之为“事件”，但“事件”一词有其特殊含义（通常都有点意外，而企业的这些事都不是意外），因此这里统一称之为业务事项。

一个业务事项它通常需要几个岗位的人各司其职的完成，极个别事项可能会由一个岗位的人完成。

• 行为主体（Actor）

这些业务事项必须有人（也可能是其他系统或装置）去处理，处理这些事项的人称之为行为主体，亦可称为角色。

• 行为（Action）

行为主体在处理某项业务时所作的活动或作业，称之为行为。

• 活动（Action）

行为中判断、观察、填制表单、票证等不直接记录和变更业务状态的行为，称之为活动。

• 作业（Opration）

行为中记录、变更、删除业务状态的行为，称之为作业，有时也称为操作。

• 岗位（Position）

岗位是组织架构中的重要组成部分，它既是行为主体的容器，又是业务事项的容器。行为主体在业务领域必然归属某岗位（一人多岗的情况是存在的），行为主体在处理某岗位的一个事项时，表示他在这个业务中扮演了一个角色。

• IT架构

企业架构包含：业务架构、应用架构、数据架构、技术架构；为叙述简单，我们有时称应用架构+数据架构+技术架构为IT架构。

• 软件需求

需求通常分为业务需求、用户需求、系统需求；我们称用户需求+系统需求为软件需求。

• 业务描述语言（BDL）

本文提出的用于清晰、一致地描述业务事项的形式化语言的统称。它由三个子语言组成（BML、BPL、BOL）。

• 业务事项语言（BML）

用于清晰、一致的定义业务事项的形式化语言。

业务事项通常是一个流程，由不同岗位执行某些业务过程或作业完成。

它退化的情况可以是只执行一个过程或作业。

它是针对这个业务事项的制度定义，与后面两个语言结合，可以精准的定义数字化的企业制度。

• 业务过程语言（BPL）

用于清晰、一致的定义业务过程的形式化语言。

它通常是一个简单的过程，需要依据具体的业务制度，通过执行几个不同的业务操作完成。它配合BML，定义各业务事项共享的细粒度的具体业务过程。

• 业务作业语言（BOL）

用于清晰、一致的定义业务作业逻辑的形式化语言。

作业是业务事项的核心操作，涉及核心的专业知识和企业制度，例如如何记账、管理产品、管理客户以及合约等。

     1.2  导致应用系统现状的根源

这里我们用数学的方法推导一下业务需求的重要性，看看能否发现问题的根源。

首先引入一个广义过程函数的概念：

     y = f(x, α)

x：代表一个输入，例如业务架构。

f：代表一个过程，x通过该过程会得到y。

α：代表参与这个过程的人以及环境等影响过程和结果的因素总和，称为参与因子。

过程函数是热力学中的一个概念，表达了热力学系统从一个初始状态到另一个状态，与过程和路径有关，存在诸多不确定性。

这里只是借用这个概念，推导一下业务架构、业务需求、软件需求……应用系统之间的关系。

基于这种不确定性的函数讨论有意义吗？有意义，我们希望引入此概念达到如下三个目的：

1. 从形式上给出相互之间的关系。
2. 尽管有不确定因素，但我们努力找出稳定不变的东西，这会给我们重要指引。
3. 真理。尽管每个过程输出的结果都可能不确定，但在这众多的结果中必然存在一个最好的，我们称之为真理，因为我们相信它存在，而让我们为之努力。

首先，我们认为业务架构是需求的需求，当然业务架构又是因企业战略、愿景而生，这里我们聚焦在企业的业务本身，从业务架构开始。

    公式1： 业务需求 = f1(业务架构，α1)

    公式2： 软件需求 = f2(业务需求，α2)

    公式3： 软件设计 = f3(软件需求，α3)

    公式4： 软件开发 = f4(软件设计，α4)

    公式5： 应用系统 = f5(软件开发，α5)

据此我们得到：

公式6：