业务需求

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

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

需求的切入点在哪里？

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

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

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

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

可以做到所需即所得吗？

……

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

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： 应用系统 = f5(f4(f3(f2(f1(业务架构,α1) ,α2) ,α3) ,α4) ,α5)

为了凸显业务需求，我们把公式6中的f1(业务架构,α1)换成业务需求，于是：

公式7：应用系统 = f5(f4(f3(f2(业务需求,α2) ,α3) ,α4) ,α5)

进而：

    公式8： 应用系统 = F（业务需求，Α）

F代表f2、f3……f5的叠加过程，Α代表,α2、α3、α4、α5的因子叠加。

公式1~5告诉了我们业务架构、业务需求、软件需求之间的关系，它告诉我们一个输入通过一个过程和参与因子，可以得到一个输出，参与因子不同时间过程不同，会导致输出结果不同，也就是说这个函数可以产生若干不同的结果，我们认为这可能的若干结果中存在一个最佳的，我们把它称为“真理”，它给我们寻求真理的动力和渴望。

我们得到了这一组形式，反映出来它们之间的函数关系，公式8告诉我们应用系统是业务需求和参与因子的函数，如果我们假设每个过程中的参与因子都是积极寻找真理的力量，我们就有理由相信，由需求可以导出真正所需的应用系统，同时我们发现过程函数也非常重要。

公式8同时告诉我们，由于过程的不确定性叠加参与因子的不确定性，我们得到一个好的应用系统就已经非常困难。

那么当我们忽略业务需求，直接从软件需求开始时，公式8变成了：

应用系统 = F（ ？，Α）

自然我们得到一个好的应用系统的机会就更渺茫了。

这就是造成应用系统现状的根源了—-- 起点模糊，差之毫厘谬以千里，结果可想而知。

• 重要结论：

如上的讨论，不是刻意强调软件过程的不确定性，尽管它是客观存在，更重要的是我们想发现那些稳定的东西，这些东西在这个过程中像基因一样稳定的传递和表达，推导说明的过程有些繁琐，我们在后面讨论，这里先给出结论：

     结论1：应用系统.重要部分 = F1（业务需求.BDL）

     结论2：应用系统.核心部分 = F2（业务需求.BDL）

注意：这里的F1、F2是简单函数，不是过程函数。

就是说，应用系统中最重要的部分可以通过简单的转换由业务需求导出，应用系统的核心部分也可以由业务需求导出。换句话说，业务需求可以导出应用系统重要的和核心的部分。更重要的结论是：

       结论3：不断发展的业务系统 = F（应用系统）+ 未信息化的业务系统

这表明按本套方法论构建的应用系统，具备一个重要的能力，业务人员通过简单可视化的方法，可以使应用系统满足业务系统的持续发展，业务人员就如同管理传统业务系统中的业务制度一样，调整应用系统中的流程和制度就可以实现业务的变更和创新，应用系统比人工系统还具备一个更大的优势，它可以忠实、精准的执行它们，免去了培训和学习过程。它表明这样的应用系统具备持续进化、发展、创新的能力，这才是业务真正需要的系统。

这个结论还表明，业务需求的变化，可以跨越软件需求、设计和开发过程，通过作用于应用系统的F就可以实现，而这个F如同原来业务制度制定一样简单、自然，甚至比那时还简单高效，这时应用系统已经与业务系统融为一体，合二为一，将为企业带来更大的价值。

这是非常重要的变化，也是本体系追求的目标和结果。

我们先记住这三个结论，带着美好的愿景，看看这一切如何达成。

       2. 如何做好业务需求

万事开头难

好的开始是成功的一半

万事开头难，但难易相成，如果我们克服不了这开头的难，必然面临后续过程的苦。

         天下皆知美之为美，斯恶矣；皆知善之为善，斯不善已。故有无相生，难易相成，长短相形，高下相倾，音声相和，前後相随。——《道德经》

      美与丑、善与恶，易与难、长与短、高与下、前与后、音与声、有与无，它们的关系都是相互对立的，同时又是相互依存的。如果不能辩证地看待它们，矛盾就不可能得到很好地解决。世人多追求前者，而厌恶后者，其结果往往求之而不得。老子向世人指明的是，求有须向无，易从难来啊。

       我们的软件工程在开头处遇到了业务需求这个难题，于是我们试图绕过去，但发现后面的过程更加艰难，更重要的是我们很难开发出一个好的应用系统；如果我们努力克服这个困难，会发现后面的事情变得越来越简单，我们更容易构建一个更优秀的应用系统，这就是难易相成。

       计算机虽然已经有八十多年的发展，但真正的企业应用还不过三十几年时间，因此还很年轻，从大的周期看，还没有真正完成一个理论、实践、再理论、再实践的过程，出现各种情况是正常的。

       计算机刚诞生时因价格昂贵，仅用于大型科学计算和军工领域，IBM创始人沃森曾说：全世界只需五台计算机。然而今天几乎每个家庭都有五台计算机，我们的手机的计算和存储能力都远超当时计算机，合久必分，分久必合，未来可能的确如沃森所言，全世界只需五台计算机——华为云、阿里云、腾讯云、雅虎云、谷歌云。那时我们的应用都放在云上，比放在自己的机房还安全，没有你的授权，任何人都无法获得你的数据，量子加密的信息无人可解。也就是说人们对计算机的认识以及其自身的发展，都在不断变化而且速度很快，企业应用软件的理论体系和方法工具也需要快速变革了。

20世纪80年代，一些懂计算机编程技术的工程师们和一些懂业务的行业专家，坐到一起要做企业应用软件，深究起来是有点不太科学的，双方你不懂我，我不懂你，那时相关的书籍也很少，可贵的是双方的热情都很高，吃苦耐劳，加班加点，昼夜奋战，搞技术的在努力学习业务，但毕竟是半路出家，又无名师指导，难以入道。遗憾的是业务人员鲜有努力学习技术的，如果有，可能会出现可喜的结果，两头发力，思想碰撞、融合，或能取得更丰富的成果。

双方隔着一条河，业务人员讲业务、讲制度、讲法规，技术人员似懂非懂，他们更关心功能、需求，需求你们就说到底要做啥吧。需求对业务人员来说也是一个新生事物，到底如何提出、如何表达也是为难。功能，功能成了双方的抓手，业务人员提出需要哪些功能，技术人员问这些功能都涉及到哪些数据，内部逻辑如何……这样面向数据和功能的工程就开始了。

我们开始需求建模，软件设计建模，做的热火朝天，很有成就感。业务人员想了解我们做的需求和设计是否如他们所愿，我们非常专业的向他们介绍数据流程图、ER图、ORM、UC图、泳道图，怕他们不明白，我们又从所有者视图、架构师视图、设计师视图、构建者视图等全方位、多视角进行介绍，但他们听了一头雾水，心生恐惧，不明白我们到底是何试图。算了，我们还是看结果吧。测试、测试，通过反复的测试我们得到了一个什么呢？得到了一个（勉强）可用的系统，不是一个可发展的系统，不是一个他们可以理解的系统，更不是他们可用驾驭的系统，技术与业务的裂痕越来越大，融合成了梦想。

这条河必须打通，我们需要建起一座桥，联通业务与需求，其实这座大桥就是业务—需求，其核心就是业务需求描述语言，这语言不仅要双方都能很容易理解，而且要与后续工程密切相关，这样应用系统才算真正实现了业务的需求，我们要充分认识到应用系统是企业业务的一部分，它属于业务世界，而不是独立王国。

建立一个怎样的业务描述语言，既能简洁直观的描述业务，又可以很好的表达需求，业务、技术双方可以通过它良好的沟通呢？ UML做了很多努力，但它好像在另一个世界，属于建模领域，用于业务描述的确勉为其难，业界做了许多努力，但效果应该说并不满意。用自然语言，当然是可以的，自然语言功能强大，表现力丰富，绝对是可以胜任的，但是自然语言，尤其是中文，一词多义，同样的词句，在不同的语境和环境，不同的语气，意思可能完全不同：

能穿多少穿多少。

冬天和夏天意思可能完全相反。

女友说：

如果你到了我还没到你就等着吧。

如果我到了你还没到你就等着吧。

“你就等着吧”在这两句中的意思应该是不同的。

因此用这样美妙、神奇的伟大语言来表达严肃、刻板的业务过程，自然是屈才了，大才不能小用，凤雏当不好县令。

我们再看看计算机语言，C语言有32个关键字，Java有53个关键字，词汇不多，但可以用它们实现应用系统，说明他们可以完整的表达业务，那么我们是不是可以用计算机语言作为业务描述语言呢？可以，但是它们面向的是机器，业务人员看它们就像看天书，同时它过于琐碎，不适合做业务描述。看来寻找一个适合的语言还的确有点困难，既然客观世界不存在，就需要我们根据业务领域的特点，发明一套适合业务描述的语言了。

计算机语言琐碎并非是它落选的主要原因，重要的是它不属于业务世界，但它证明了可行性，就是说可以有一种简单的语言来准确的表达业务，剩下的任务就是我们去研究了，当我们发现它时，还会给我们带来更多惊喜。

     2.1  企业概念模型

我们既然是做企业应用系统，就需要对企业有一个深刻的研究。

企业有千种万种，其实就算专注于一种，恐怕也很难完全研究清楚。

因此我们需要综合抽象，努力抓到其本质。

任何一个企业都有它的愿景、使命和战略，这是它的初心，企业因此诞生。

做一个企业就需要做各种各样的“事”，通过做这些事，实现社会价值，从而获得企业价值。这就是企业。

由此来看“事”是企业的核心内容。做事需要有人，就是前面提到的行为主体。为了把事做好，企业要管理，要立规章、建制度，每个“事”都要合规、合法，效率要高，风险要低。企业有许多许多“事”，因此需要机构、部门、岗位，将这些“事”科学合理的安置到位，确定什么岗位做什么事，每一个事需要那几个岗位的人分工合作完成，流程和责任都划分的很清楚。这些“事”我们称之为业务事项。通常企业都会为每个业务事项定义明确制度和流程。

这就是一个企业的概念模型，参见下图。

 

我们认真研究发现，企业这些岗位抽象的看，可以分成五大类：

• 一线业务岗位：它们通常是业务事项的起点或终点。
• 二线业务岗位：它们通常在一个业务事项中完成比较专业的处理过程，且具体操作交由三线完成。
• 三线业务岗位：它们通常完成一个业务事项的具体操作。
• 管理岗位：负责业务事项调度、人员管理、考核，有时会参与到业务事项的批准、授权等。
• 决策岗位：负责企业重大事项的决策。

由此可以发现，企业业务事项的处理，主要由前三种岗位协作完成，各司其职，而且一、二线岗位的行为主体，通常不对业务进行实质操作（改变业务状态，用计算机的术语说就是，不动库表），他们收集转发信息、编制专用凭证，并安排三线岗位的人员执行具体操作，例如：在银行业务中，客户转账是一个业务事项，它通常由一线接柜人员代客户发起，二线会计人员根据银行的具体业务制度，开出借贷凭证，可能是一借一贷，也可能多借多贷，因为某种情况下要收手续费，这些专业的工作由会计根据具体业务制度进行专业处理，然后将凭证交由三线的记账员执行具体的账务操作。这个过程可能会被多个业务事项共享，例如可能是客户通过自助终端或手机银行发起的转账，也可能是客户在购物时由电商平台发起的。

这个事实很重要，它与企业业务的五层架构也刚好吻合，我们抽象的看，企业所有事项的处理都是以这种模式进行着。这就为业务需求和业务描述语言建立了基础。

     2.2 业务需求的本质

业务需求其实包含两层含义，一个是业务，一个是需求。

虽然我们的目标是确定需求，但如果我们直接从需求入手反倒是找错了起点，会导致诸多困惑。

我们从业务入手就轻松多了，首先业务事项是客观的存在，很容易就可以罗列出来，针对每个业务事项的处理过程也是客观存在的，而且需求就在其中。

每个业务事项由那几个岗位参与，分别都做什么，企业的业务制度都会有明确的规定，用后面介绍的业务描述语言定义清楚就把业务搞清楚了，那些行为需要有计算机完成，就是需求了，这就是业务需求的本质。

当然还有非功能性需求、约束条件等，这里我们专注于业务的核心操作层面，不展开讨论这些内容。

企业做应用系统的动因是针对某些业务事项中的问题及其要达到的目标提出来的需求，我们全面了解业务事项的全景后，更有利于给出更好的解决方案，这些问题和目标亦是需求的重要部分，同样要在需求中描述和定义，目标必须是可度量的，度量标准要在需求中明确定义，以便于对方案进行量化评估。这些内容非常重要，要落实到每个业务事项的需求之中。

    2.3 业务描述语言（BDL）

我们以业务事项作为抓手，就找到了准确的切入点，把业务描述清楚，就为需求工作奠定了基础。这时问题就转换为如何清楚、准确的描述业务了，因此我们需要业务描述语言。

通过对各类业务事项的研究，经过综合分析、抽象我们发现了业务事项处理过程的基本形态：

某岗位 执行 （什么）

如果 （ 金额>X ）{

某岗位 执行过程 （什么过程）

}否则 {

某岗位 执行 （什么）

}

……

实际情况会更复杂一些，因此具体的语言会提供更丰富的关键字和表达能力，以支持各种复杂业务事项的定义。

这是一个对业务事项的全景描述，采用BML进行表达。

什么过程对应二线岗位的专业过程，采用BPL进行表达。它们按不同领域进行独立描述，因为它们可能会在不同的业务事项中被共享。

什么对应三线岗位的操作行为，采用BOL进行表达。它们也要分领域的进行独立描述，因为它们可能会在不同的业务事项中被使用，也会被BPL使用。

三个语言在不同的抽象层次上，对业务进行清晰、一致的精准表达，描述业务事项的流程、过程和处理逻辑。

BML最为重要，它从业务事项（BM）的整体视角，全面完整地定义BM的处理过程，重要的是它把业务事项处理过程中涉及的过程和作业清晰地呈现出来，为后续的软件需求和设计奠定了重要的基础，这些过程和作业，是业务领域制度、逻辑等的合理归集，为构建结构良好的应用系统给出了最佳指引。

在传统的需求过程中，编写需求是一个发明创造过程，需要“编”写出许多新东西，这个“编”导致我们制造了许多独狼怪兽。现在我们把需求定义为发现之旅，我们首先回归到业务本源，然后再界定需求，这样我们即有了更宽阔的业务视角，为设计出更好的应用系统增加了机会，同时使需求过程变得容易入手，而且更加简单。

语言通常只是工具，但BDL对于软件工程而言不止于此。

它可以成为业务制度的定制标准，配合专业的需求平台，不仅可以快速、准确、一致的定义业务过程，形成数字化的业务制度，而且可以成为行业知识管理平台，为后续业务管理和需求工程奠定坚实基础，可以极大提高企业信息化的效率和管理水平。

它可以界定需求，在表达业务的同时定义需求，后面会具体介绍。

它可以引导软件需求和设计，减少软需和设计的核心工作，从本质上提高工程效率。

它可以所需即所得，与技术平台的流程引擎和流程引擎配合，可以最大限度的降低代码的开发量，实现应用架构流程层和过程层的全数字化驱动，配合开发平台的UI配置工具，可以实现所需即所得，构建业务人员可以轻松驾驭的可发展应用系统。

这时我们发现BDL非同凡响了，它不仅提高整个工程的整体效率，而且对应用系统本身影响深远，这时我们就会真心的重视业务需求了，肯于在业务需求上下大功夫，业务需求做的越好，价值就越大，后续的工程就越简单，应用系统建设的就越好。

BDL的细节这里不做更多介绍，详细内容参考附录。

      2.4  需求工程

需求工程内容丰富，除了功能性需求还有非功能需求、约束条件等等，本篇不重点讨论，我们主要针对应用系统中最核心的部分——业务处理。

有了BDL语言，等于我们拿到了打开业务需求大门的金钥匙，但是如何开始呢？如果你使用内置方法论的需求平台，平台提供的WBS（任务分解结构）会指导你轻松上路，并能够针对每项具体任务，提供具体的工作界面，不仅可以提高效率，而且可以保证业务和需求表述的一致性，更省去了编写文档的辛劳，平台可以按不同的标准输出各种工程文档。

下面概要的介绍一下业务需求的主要步骤：

1. 业务架构梳理

基于上面的讨论，我们已经清楚要搞好业务需求，首先要把业务按业务描述语言梳理清楚，因为业务的客观性，这项工作是很容易开始的，但是我们还是不要急于进入细节，还是要系统的、结构化的展开工作。

为此我们先从企业业务架构开始，如果企业有成文的业务架构文件当然更好，没有也没关系，按下面的方法把主要的内容收集整理出来，剩下的工作就有条不紊了。

业务架构需要整理的主要内容包括：

• 企业的组织架构
• 各业务部门的岗位及岗位职责
• 各岗位包含的业务事项
• 按类收集业务名词（可以在整个过程中不断完善）

这些工作比较容易完成，下面这项工作需要花些功夫。

• 收集每个事项处理过程中都有哪些岗位参与，他们具体做什么事。

注意，这时不要陷入细节，只是了解业务事项处理过程中都会涉及到哪些岗位、哪些过程和操作，我们努力为它们起一个妥帖的名字，并分别按业务域归集，只需要一个名字就可以，目的是控制后续用BML详细描述业务事项时有一个共同的基础，这些过程和操作的名称会在BML中引用。我们要清楚这个过程中收集的未必全面和正确，没关系，它可以在后面的过程中逐步完善，这是一个迭代的过程，但要努力把这个工作做好，为后面的工作打下良好的基础，这个过程也是我们全面了解业务重要步骤。

努力做好上面的工作，为控制了整个需求奠定根基，机构、岗位、过程、操作、业务名词等都会成为后续需求定义的元数据，可以保障需求表达的一致性，避免重复和差错，提高后续各项工作的效率。

不要以为这些与开发工作无关，事实上，这时你已经在为开发而工作了，组织架构、岗位等内容可以直接导入应用系统，成为系统运行的参数，后续的许多工作都是如此，我们不会有任何浪费，前面的工作越细致，后面的工作就越轻松，这是一体化的工程。

物理的实际的组织机构和岗位的确重要，但在这个过程中，需要抽象出该企业的标准组织架构和岗位（与实际机构无关的），我们在业务描述中使用的岗位是标准岗位，而非某个具体机构的具体岗位，这才具有通用性。

1. 业务事项描述

这是业务需求中工作量较大的一块内容，但它不难，如果企业有完整的制度文档，这项工作就更容易了，即使没有也没关系，业务人员对每个业务事项都能说的很清楚，因为他们每天都在做着，当你完成这项工作后，企业的制度文档就出来了，甚至是电子化的。

根据前面梳理出来的每个业务事项，参照业务制度，找相关的业务人员，按BML的语法要求详细的描述处理过程吧，这是一个耐心细致的工作。

在描述的过程中，要谨慎的选择前面定义好的过程和操作名称，如果不存在，可以添加，但要经过总体组的评估确认。

过程中安排专人对过程和操作分别用BPL和BOL进行定义，这也是本过程中的重要工作。

上述工作完成后，要经过业务部门的评审确认，为了不分散精力，更专注的把这些至关重要的工作做好，建议不要急于讨论需求，认真的把业务搞清楚。

      2. 确定需求

终于开始做需求了，尽管这一步至关重要，但有了前面的基础，确定需求已经不再困难。

我们对每个BML中涉及到的过程和操作与业务人员落实哪些需要计算机做，哪些仍然保持人工处理就可以了。

更简单的办法直接对过程和操作进行讨论，因为它们比业务事项少很多。

如果在需求平台支持下，我们根据讨论的结果，修改对应过程和操作的类型属性（从人工调整为计算机处理或者AI），BML就自动调整好了。

至于改造工程及创新工程等不同类型，我们在2.5进行讨论。

尽管这个过程不复杂，但非常重要，它是决定待建系统的整体品质和水平最重要的过程，要认真对待。

因为在BML基础上讨论需求，我们看到的是一个个具体业务事项的全景，业务和技术人员共同商讨针对每个业务事项如何信息化，双方可以发挥各自的优势，为确定一个最佳需求打开了一个重要的窗口，多花些功夫在每个业务事项具体需求的讨论上，对构建一个优秀的系统是非常重要的。

例如，有的业务事项需要复印客户身份证件，是否可以将身份证阅读器读取的证件信息存档，就可以取消一个人工环节。

开户时需要实名认证，接柜人员要比对客户和证件，经理还要再次比对后进行授权，比较费时，可否运用人工智能，通过人脸识别自动比对身份证照片，简化这个过程。

总之，技术人员和业务人员都可以充分发挥聪明才智，把需求做的更好。

通过这样的过程，双方就成为战友了，会结下深厚友谊。

当一个超越需求的应用系统诞生时，一定会得到广泛的赞誉，这是双方共同的荣誉。

类似这样的窗口在做软件需求时还会开放，双方会再次迎来并肩作战的机会

     2.5  不同类型的工程

我们在做具体企业应用系统时，可能会遇到不同类型的复杂工程。但我们抽象的看，可以分为三大类：

1. 新建系统
2. 优改工程
3. 创新工程

其实创新可能发生前两类中，但把它单独拿出来，集中说一下，也适用于前两种。

     1. 新建系统

一张白纸好写最新最美的文字，好画最新最美的图画。用此套方法体系开展软件工程，一定能够构建出令人满意的应用系统。

      2. 优改工程

这时再分两大类，一类原系统就是采样本套体系建设，这时比较简单，因为已经运行了一个时期，流程、过程可能都已经在线进行了调整，将它们导出来，就形成了需求基线，然后在此基础上开始新的工程即可。

另一类，就是原系统用其他体系建设的。

这个企业应用系统已经存在，甚至已经经过几期建设，这时情况有些复杂，为了表达清楚再分三种情况：

      1) 小修小改

工程计划投入不足原工程的10%，建议按原来方法做，与本方法无关。

       2) 大修大改

工程计划投入超过原工程的50%，建议全面采用本套体系重新建设，会取得超出预期的成果。

否则，首先把老系统中可以作为过程和操作的部分提取出来，作为新系统可以直接使用的过程和操作使用，开始按本套方法体系开始新的工程。

在具体开发时，把他们封装成符合新系统的服务组件使用即可。

       3) 新一代工程

           同新建系统。

    3. 创新工程

      首先，尽管本套体系以业务为基础，但并不是否认创新，相反它为创新提供了更大的空间，业务需求的过程以及软需的过程会融入大量的创新要素，无论是最新的技术还是人工智能、大数据技术、前端技术、物联网技术等等，都可以在过程中合理的引入，甚至可以远远超越最初的动因，得到一个更好应用系统。

至于流程创新、制度创新、产品创新更是这套体系的礼物，可以持续的满足业务发展的诉求，这里不过多讨论。

需求讨论的是业务的基础创新，就是说企业某种新型业务需要在操作层进行创新，是过去完全没有的业务。这种情况反倒好办了，这时我们不要采用技术思维，首先要业务思维，把新业务按照业务的理念梳理好，新业务就会有新的业务事项产生，每个新的业务事项要制定业务流程和制度，这时就会发现它又进入了本套体系的轨道，完全可以按新建系统的方法执行，没什么两样，这套新业务可能会使用原系统的部分过程或操作，没关系，这样很好，新业务与原系统就良好融合了，企业本来就是一个有机整体。

        2.6 需求平台

软件工程面对企业复杂的业务系统，诸多的业务事项、过程、操作、信息、数据，以及之间错综复杂的关系，要想正确的构建满足业务及其发展要求的企业应用系统，需要经过业务需求、软件需求、软件设计、开发实现、系统测试等一系列过程，每个阶段都会产生大量的“工件”，而且它们的内部和相互之间又存在诸多关系，完全通过手工作业的确困难较大。

因此我们需要有支持整个软件过程生命周期的软件平台，以使软件生产过程信息化，进一步实现智能化，提高软件过程的效率、质量和管理水平。这里重点说一下需求平台。

目前支持需求的软件平台也有许多，但大多都是面向文档的，虽然解决了需求工程中的部分问题，但没有解决根本问题，形成的需求文档，还需要设计人员消化理解，架在需求和设计之间的鸿沟依然没有打通，更谈不上所需即所得了，因此对工程效率的贡献是微不足道的。

按本文介绍的方法体系以及业务描述语言，可以使需求过程更容易把控，需求成果对后续工程可以提供更好的指引，即使采用手工作业已经能够比传统的需求工程做的更好，但完全手工作业还是有些困难，无法充分发挥其全部效能。我们需要一个软件平台支持这个过程，把全部需求模型化、数字化表达，业务需求结束可以自动生成软件需求的框架，BML、BPL等可以直接通过开发平台转换成流程引擎和过程处理引擎所需的脚本，实现所需即所得。需求文档可以按企业所需标准自动生成，这样我们才可以最大化的提高整个工程的生产效率，降低企业建设和使用IT系统的成本。

下面概述我们对这个需求平台的基本要求：

1. 它是一个需求工程的工作平台

参与者无论是业务人员、技术人员还是管理人员都基于此平台开展具体工作。平台能够指引和帮助参与人进行工作分解、下达任务、交流讨论、参考复用、完成任务、评审确认，版本控制、变更管理、进度监控、过程评估、分析统计。

需求工程的全部工作在此平台上完成，是管理、控制、工作、讨论一体化的作业平台。

     2.支持不同需求标准和过程、可拓展的需求平台

平台管理者可以定义需求标准（包括需求架构和基础需求单元），配置管控流程；平台可以伴随需求理论、方法的进步不断发展。

支持BDL语言以及其后可能发生的版本变化。

      3. 需求成果的积累和复用

需求积累包括三大门类：

      需求标准及管控体系

这部分是需求工程理论及方法论方面的积淀，一方面可以持续引入最佳的需求工程实践，另一方面丰富的积累可以满足各类软件工程的具体需求，适合大型、中型、小型软件工程的不同诉求。

      领域知识及需求

随着使用机构的长期积累，在所涉足的各领域积累了丰富的需求，包括：工程过程、工程量、组织架构、业务体系、BDL、业务对象、业务流程、名称术语、数据字典等，都可以成为类似系统需求过程的重要参考和可复用资源。

       企业应用系统内的已有积累

当一个系统在进行升级改造时，原系统需求的许多内容可以直接继承和引用，亦可在原基础上进行优化和提升，极大地提高优改工程的效率和质量，使企业信息化建设保持连续性，持续进化和发展，满足企业发战略的长期要求。

      4. 跨越鸿沟与设计无缝对接

模型化、数字化的需求表达，可以直接对接软件需求和设计，设计与需求共享数据，大量工作可以跨越设计，实现所需即所得，极大减少设计开发工作量，全面提升软件工程生产效率。基础数据一以贯之，高度一致，从根本上解决软件工程一致性的问题，需求、设计及实现的关联及关系一目了然，跟踪管控、追本溯源系统化完成，大大降低管控成本，提高管控效率。

       5. 可全视角洞察、跟踪、分析和量化需求全过程

需求工程全过程整体可见，各环节都可以方便跟踪检查，各项工作任务均可量化分析，实际工作量真实可靠（实际工作量依据具体任务创建、修改、保存、确认等具体时间进行统计计算，精准无误）

同时，每项具体需求均包括设计、实施的系统评估工作量，当需求完成时，下一阶段的工作量评估就可精确的估算出来，为整个软件工程提高量化分析基础。

       6. 完备的全过程管理

整个需求可依据配置进行全流程管控，包括已下达、未下达、在途各项任务进行跟踪管控，工作量、已下达工作量、在途工作量、已完成工作量、实际工作量等进行统计分析、对比，对评审确认、变更、版本等关键节点进行管控，对过程进展各项数据进行统计分析，及时发现风险和问题，及时调整解决，精准决策。

      7. 可按不同标准输出需求文档

平台可以依据工程需要，选择需求标准文档输出模板，平台可以配置新模板，具体项目可以在标准模板上进行调整和增减相关内容，可以保存为客户模板供以后使用。

     8. 可按工程定义自动生成各类统计分析报告

平台定义一套标准化统计分析模板，用户可以选择使用，亦可拓展并存为客户模板。

平台根据所选择的报告模板体系，自动定时生成相关报告，供使用者查阅分析。

      9. 即支持新系统开发，亦支持优改工程

对于优化改造工程，如果老系统的需求已经在本平台中，新工程可以以此为基础，开展新系统需求工作（建议不是在原需求上修改，而是另起项目，不变的地方直接引用，需要变更的部分继承过来修改），如果老系统需求不在平台中，需要启动一个工作将原需求导入平台，已便于积累和复用。

      10.智能化管控

运用大数据分析和人工智能技术，实时监控整个需求过程，发现问题及时报告预警，动态分析各项任务执行情况，发现优劣，辅助需求工作者不断优化工作模式，提高效率，再进一步，机器人通过不断的观察学习，在某项特定领域可以帮助需求人员完成部分或全部任务，逐步提高平台智能化。

本文地址：https://blog.csdn.net/xabcdjon/article/details/107580621

如对本文有疑问， 点击进行留言回复！！