CN116700677A - 用于软件开发中需求建模的流程建模系统 - Google Patents

Abstract

本发明提供了一种用于软件开发中需求建模的流程建模系统，所述流程建模系统包括：业务架构构建模块，获取目标企业的业务领域，构建与所述业务领域关联的业务架构，包括业务领域、干系人、业务对象、业务组件；流程建模模块，基于所述业务架构进行流程建模，包括业务领域分析、价值流分析、活动分析和任务分析。本发明的流程建模系统形成了具有良好可视化、引导性操作的工具，辅助客户在该工具的指引操作下，实现企业顶层战略的规划，并且逐级分解，逐层落实，转化成可执行的企业级、结构化、层次化的业务流程模型，解决了需求管理难度大、需求成果物保鲜困难的问题。

Description

用于软件开发中需求建模的流程建模系统

技术领域

本发明涉及软件设计技术领域，特别是一种用于软件开发中需求建模的流程建模系统。

背景技术

需求分析，是软件生命周期中一个重要的阶段。在可行性研究之后，确定了最基础的软件开发目标以及涉及到的业务范围。然后对所涉及的业务需求进行详细的分析，通过分析来确定最终的软件交付标准，同时也可以作为测试的校验文档来确定最终的产品完成度。更重要的一点是：避免需求分析中出现的错误溢出和延后，可以极大避免在后续开发及测试过程才发现问题、而进行修正所带来的系列关联处理而付出时间和成本成倍增加的代价。

传统的需求分析流程，通常划分为5个阶段：收集需求阶段，厂商原型培训阶段，访谈阶段，编制阶段，评审阶段。

收集需求阶段：收集需求是为实现目标而确定，记录并管理相关方的需求的过程。需要做到尽可能全面的收集需求，不管需求是否能够实现。收集需求由客户来收集，需求来源主要是竞品、系统现状、历史需求等。厂商原型培训阶段：该阶段需要由厂商做系统原型的培训，重点讲解目前厂商系统所具备的能力需求。访谈阶段：该阶段主要做厂商系统原型具备的需求和客户需求的差异分析，访谈期间由客户和厂商需求人员，针对需求差异做进一步的分析，形成提纲、问题清单，一一确认，最终得到需求清单。编制阶段：该阶段按照需求分析的结论，编写模板，确定需求主题。评审阶段：该阶段需要对需求清单做多次的评审修订，最终得到终版需求清单，并由客户签署确认。但是，传统的需求分析流程具有以下缺陷：

1、缺乏体系性的工艺方法论支撑，无法体现从客户诉求到高阶需求、再到中阶粗粒度需求、再分解到详细业务规则，逐层细化和推导的过程。

2、存在收集的需求过于零散，分析工艺和方法不成体系，对需求提出方和需求实施方的专业人员经验和素质要求过高、依赖过度等典型问题或现象。

3、需求分析阶段，一般采用线下文档整理评审意见等，文档更新、意见汇总效率低，协同性差，且容易出现纰漏。

4、业务与技术人员语言不统一或者一句话需求，会导致业务人员和技术人员对需求的理解不一致，出现理解偏差。

5、需求没有创新工具去管理，无法追根溯源，项目中的需求变更管理一直是一个痛点问题。

发明内容

鉴于上述问题，本发明提出一种克服上述问题或者至少部分地解决上述问题的用于软件开发中需求建模的流程建模系统。

本发明主要应用于金融科技领域的需求分析阶段，基于企业的业务架构，从企业级银行价值链和业务价值创造的视角出发，以便将企业的战略能力需求和管理需求逐级分解，该阶段在本发明中被称为流程建模阶段，其依次由业务领域、价值流、活动、任务构成，各级环环相扣、逐层落实，转化成可执行的企业级、结构化、层次化的业务流程模型，最终实现企业的战略目标，完成企业的价值交付。

本发明提供了一种用于软件开发中需求建模的流程建模系统，所述流程建模系统包括：

业务架构构建模块，获取目标企业的业务领域，构建与所述业务领域关联的业务架构，包括业务领域、干系人、业务对象、业务组件；

流程建模模块，基于所述业务架构进行流程建模，包括业务领域分析、价值流分析、活动分析和任务分析；所述任务是单一角色执行的步骤集合；所述活动是由事件触发，干系人之间的交互过程；所述价值流是业务领域内的价值创造过程，包含一组活动；所述业务领域由一组包含计划、执行、监督的活动组成，使用业务组件提供的任务，提供对外服务的能力。

可选地，所述业务对象是企业业务的核心资源，是资源的结构化体现，用于指导应用系统落地时，用户执行用例相关操作时，所创建、存取和更新、删除等的一组业务概念；所述业务组件为关联各所述业务对象的功能组件；所述业务领域为所述目标企业为客户和企业内部提供的需求服务，体现企业的高阶价值需求以及整体价值创造过程。

可选地，业务架构构建模块还用于：基于所述目标企业的价值链的视角定义业务领域；

根据业务活动和操作的业务对象定义干系人；预设活动与业务事件对接以定义业务对象；按照角色和业务目的划分业务并定义业务组件。

可选地，所述流程建模进行业务领域分析包括：业务领域定义、干系人定义、业务对象定义、业务组件定义、识别干系人、定义业务事件、预设活动。

可选地，所述流程建模进行价值流分析包括：划分价值流阶段，对基于价值链分析的业务价值进行价值阶段分析；归纳价值流节点，根据对业务领域定义和理解，将活动归纳为价值流节点；绘制价值流图，依据价值流图绘制标准，绘制预设活动的完整价值流图。

可选地，所述流程建模进行活动分析包括：预设活动与业务事件对接，分析活动清单、业务事件清单，建立业务事件与活动的映射关系；对接分析，分析预设活动与业务事件对接成果；活动优化，据预设活动与业务事件对接分析成果，明确活动的定义；识别业务场景，基于业务事件以及变量因子的不同取值的组合，识别出不同的业务场景。

可选地，所述变量因子包括客户、产品、渠道、合作方或者其他自定义变量因子。

可选地，所述流程建模进行任务分析包括：识别工作事项，活动分析完成后，以活动为单位，识别活动下具体的处理事项；任务划分定义，在活动下罗列的工作事项基础上，把工作事项进行归纳，划分任务；绘制工作流图，将活动下识别的任务以图形的形式表达，展示业务的处理流程；任务标准化，将业务领域下识别的任务，以企业级业务组件视角，进一步规范统一；识别输入输出，根据任务的职责定义，识别出任务核心的输入输出属性。

本发明基于企业的业务架构，承接企业高阶的顶层战略目标，完成需求从高阶到详细的逐层细化和推导；同时系统中的动名词库、交易码、数据字典等的设计，解决了传统的需求分析面临的业务与技术人员语言不统一，团队协同性差等问题。工艺平台承接流程建模工艺，形成了具有良好可视化，引导性操作的工具，辅助客户在该工具的指引操作下，实现企业顶层战略的规划，并且逐级分解，逐层落实，转化成可执行的企业级、结构化、层次化的业务流程模型，解决了需求管理难度大、需求成果物保鲜困难的问题，进一步促进业技融合，最终实现企业的战略目标，完成企业的价值交付。对比传统的需求分析方法，“工艺方法论+工艺工具”的方式能够更好地去做应用系统建设中的需求分析环节的流程建模。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

根据下文结合附图对本发明具体实施例的详细描述，本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明中业务架构的内容框架示意图；

图2为本发明中业务架构的内部组成关系示意图；

图3为本发明中流程建模工序概览图；

图4为本发明中业务领域定义的界面示意图；

图5为本发明中业务领域定义交付物示例的示意图（业务领域全景图）；

图6为本发明中业务领域定义交付物示例的示意图（业务领域清单）；

图7为本发明中干系人定义的界面示意图；

图8为本发明中干系人定义交付物示例的示意图；

图9为本发明中业务对象定义的界面示意图；

图10为本发明中业务对象定义交付物示例的示意图；

图11为本发明中业务组件定义的界面示意图；

图12为本发明中业务组件定义交付物示例的示意图；

图13为本发明中识别干系人的界面示意图；

图14为本发明中识别干系人交付物示例的示意图；

图15为本发明中定义业务事件的界面示意图；

图16为本发明中定义业务事件交付物示例的示意图；

图17为本发明中预设活动的界面示意图；

图18为本发明中预设活动交付物示例的示意图；

图19为本发明中价值流分析的界面示意图；

图20为本发明中价值流分析交付物示例的示意图；

图21为本发明中预设活动与业务事件对接的界面示意图；

图22为本发明中预设活动与业务事件对接交付物示例的示意图；

图23为本发明中对接分析的界面示意图；

图24为本发明中对接分析交付物示例的示意图；

图25为本发明中活动优化的界面示意图；

图26为本发明中活动优化交付物示例的示意图；

图27为本发明中识别业务场景的界面示意图；

图28为本发明中识别业务场景交付物示例的示意图；

图29为本发明中识别工作事项的界面示意图；

图30为本发明中识别工作事项交付物示例的示意图；

图31为本发明中任务划分定义的界面示意图；

图32为本发明中任务划分定义交付物示例的示意图；

图33为本发明中绘制工作流图的界面示意图；

图34为本发明中绘制工作流图交付物示例的示意图；

图35为本发明中任务标准化的界面示意图；

图36为本发明中任务标准化交付物示例的示意图；

图37为本发明中识别输入输出的界面示意图；

图38为本发明中识别输入输出交付物示例的示意图。

具体实施方式

下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。

本发明实施例采用“工艺方法论+工艺工具”的方式来设计软件，包括需求建模（R）、分析建模（A）、设计建模（D）、实现建模（C）四个阶段，简称雷达客（RADC）工艺。在需求建模阶段，设计梳理业务架构，构建流程业务模型和产品业务模型，标准化描述业务需求。本发明实施例重点描述需求建模中的流程建模。流程建模，需基于业务架构规划开展，以便承接企业既定的业务战略，助力企业实现业务需求结构化管理、技术和业务的转型，以及推动业技融合。RADC工艺方法论实现从战略目标到业务需求再到IT实施的一体化，其中，通过以流程建模为基础的业务模型来表达业务需求，战略能力需求和管理需求将被转化成可执行的企业级、结构化、层次化业务模型。工艺工具承接RADC工艺方法论，进一步将其思想使用工具进行体现，命名为RADC工艺平台-流程建模。本发明实施例主要适用于项目建设阶段，对需求的拆解、分析和管理。本发明主要是基于企业业务架构，去实现业务模型阶段的流程建模功能。

本发明提供了一种用于软件开发中需求建模的流程建模系统，所述流程建模系统包括：业务架构构建模块和流程建模模块。业务架构构建模块，获取目标企业的业务领域，构建与所述业务领域关联的业务架构，包括业务领域、干系人、业务对象、业务组件。本实施例的流程建模系统可以应用于如银行、金融机构或是其他类型的企业作为目标企业时进行软件开发时使用，目标企业的业务领域、业务架构等信息可以根据目标企业的实际需要获取建立。

流程建模模块，基于所述业务架构进行流程建模，包括业务领域分析、价值流分析、活动分析和任务分析；所述任务是单一角色执行的步骤集合；所述活动是由事件触发，干系人之间的交互过程；所述价值流是业务领域内的价值创造过程，包含一组活动；所述业务领域由一组包含计划、执行、监督的活动组成，使用业务组件提供的任务，提供对外服务的能力。

在实施例中，业务架构工艺主要包含定义业务领域、干系人、业务对象、业务组件，流程建模工艺主要包含业务领域分析、价值流分析、活动分析、任务分析等四个阶段，每个阶段包含若干个更详细的工序，每个工序基于一定前序输入、执行后产生的输出成果。

流程模型是业务模型的组成部分，针对特定业务领域开展流程建模工作。以企业级业务视角自顶向下，本发明实施例的流程模型共分为四级。第一级为业务领域，第二级为价值流，第三级为活动，第四级为任务。第一级到第三级反映了企业为客户创造价值所涉及的端到端的活动，重点回答了做什么的问题；第三级到第四级反映了企业内部为实现价值而努力的过程，重点回答了怎么做的问题。各层级环环相扣、逐层落实，最终实现企业的战略目标，完成价值交付。

图1示出了本发明实施例的业务架构的内容框架示意图，业务架构，是企业以自顶向下的视角进行顶层设计的一部分。向上承接企业的战略、高阶的价值需求，向下指导业务建模的边界划分、流程驱动、涉及的业务概念等。在软件开发的需求建模可以包括流程建模和产品建模，其需基于业务架构规划开展，以便承接行内既定的业务战略；业务架构与两个建模之间存在引用、交叉和依赖关系。

图2示出了本发明实施例的业务架构的内部组成关系示意图，本实施例中，业务架构可以包括业务领域、业务组件、干系人、业务对象。业务领域：关于服务客户，从业务服务流程视角来实现客户诉求、创造价值和收入来源；需要利用业务组件的内部能力。业务组件：关注于内部能力，从降本增效的视角来考量提高复用度、创新能力、办理效率，以节省成本；需要服务于业务领域，同时集成整合一组业务对象的所提供的更小粒度的能力。业务对象：是较小粒度的、具有相似性的一组业务资源的集合，通常被业务组件的一组流程所串接形成可交付给客户的能力，在发明实施例中，业务对象是更小粒度的行为能力、被包含与业务组件中。业务领域是满足客户诉求的一种外部能力体现，而业务组件是企业具备的内部能力，业务对象反应业务本质，是业务的核心资源，其三者直接的关系是业务领域利用业务组件，业务组件负责业务对象。可选地，所述业务对象是企业业务的核心资源，是资源的结构化体现，用于指导应用系统落地时，用户执行用例相关操作时，所创建、存取和更新、删除等的一组业务概念；所述业务组件为关联各所述业务对象的功能组件；所述业务领域为所述目标企业为客户和企业内部提供的需求服务，体现企业的高阶价值需求以及整体价值创造过程。

可选地，业务架构构建模块还用于：基于所述目标企业的价值链的视角定义业务领域；根据业务活动和操作的业务对象定义干系人；预设活动与业务事件对接以定义业务对象；按照角色和业务目的划分业务并定义业务组件。

流程建模是一套企业级方法体系，通过本实施例的系统以企业（如银行）和客户视角将业务需求结构化、标准化、规范化，可以有效支持快速业务创新，支撑企业级战略目标的实现，提供业务能力与流程的相关需求供应用分析使用。本实施例的流程建模系统，是以企业视角自顶向下依次按照领域划分，价值流构建，活动划分，任务识别四个层级构建企业级业务模型。各个层级环环相扣，逐层落实，最终实现企业级战略目标，完成最终价值的实现和交互。图3示出了本发明实施例的流程建模工序概览图。流程建模阶段工序成果物清单如表1所示。

一、业务领域分析

业务领域是业务架构的主要组成部分，包含一组活动。活动涉及计划、执行、监督等价值流阶段，使用业务组件提供的任务，提供对外服务的能力。

领域分析的主要工序包括：工序1业务领域定义；工序2干系人定义；工序3业务对象定义；工序4业务组件定义；工序5识别干系人；工序6定义业务事件；工序7预设活动。

工序1：业务领域定义

（1）工艺方法

基于业务材料、定义业务领域及识别出的预设活动，考虑是否要对业务领域进行调整，并最终确定业务领域定义，绘制出业务领域全景视图。

业务领域名称：企业级唯一，通常以名词命名，能够涵盖和抽象本领域的所有职责、功能范围；目的（P）：对外（客户）的价值和对内（银行）的价值，一般写对客户有什么好处，对银行业务、管理分析等方面的好处。同时含提升点，为后续的建模、优化提供方向；定义（D）：描述领域做什么，包括领域的核心活动；范围（S）：涉及的客户、涉及的产品、投放的渠道、涉及的介质等；包括：重点描述突出本领域的核心活动或特色的CPCP，强调领域特征；不包括：描述本领域与其他领域的边界，不包括的内容需要指明所属领域。

（2）工艺工具

体现企业整体价值创造的过程，包括一组计划、执行、监督的活动组成，需从客户角度和银行角度分析价值。如图4所示。

（3）交付物示例，如图5~图6所示。

工序2：干系人定义

（1）工艺方法

确定业务领域的上下文背景关系的首要工作是根据业务领域的边界，识别银行外部对本业务领域提出要求的外部干系人。领域的主管部门，以及为本领域提供赋能支持及具体操作的部门，为内部干系人。干系人一般为组织、外部人群的统称等，而不具体为某个自然人或内部某类岗位、角色等。

（2）工艺工具

定义企业外部对银行提出要求的外部干系人，定义提供赋能、支持的部门的内部干系人。如图7所示。

（3）交付物示例，如图8所示。

工序3：业务对象定义

（1）工艺方法

业务对象是企业业务的核心资源，业务建模的目的是提升企业的核心竞争力。业务对象是资源的结构化体现，一个业务对象至少包含命名、定义、属性（需求阶段识别），以及行为、关联关系及约束条件（分析阶段识别）。

业务对象用于指导应用系统落地时，用户执行用例相关操作时，所创建、存取和更新、删除等的一组业务概念。业务对象通常有状态、可保存的、也是可持久化的，业务对象是包含属性和行为的模型。在业务流程中流转，是企业的内部资源，实现业务资源的整合；是反应业务本质的、一组关联的业务资源的集合；遵循高内聚松耦合的原则，没有重复没有缺失。

关键属性：对象相关的特性，用于描述业务对象、实例化后具有唯一性；

主要行为：使得业务对象自我演进和自治、无外部依赖和协同的行为能力，是从过程式、转变为自我演进的微服务的关键业务考量；

关联关系：与其他业务对象的关系，实际上也是一种协同、约束，可以用来判断业务的紧密程度，便于扩展与演进。

（2）工艺工具

基于业务流程，梳理出银行内部的业务资源，并对业务资源进行整合形成业务对象。业务对象反应了业务本质，是银行业务的核心资源，通常有状态、可保存、也可持久化，遵循高内聚松耦合的原则，对象之间不交叉重叠。如图9所示。

（3）交付物示例，如图10所示。

工序4：业务组件定义

（1）工艺方法

业务组件自上而下看是实现业务领域的一组业务能力，具有明确的业务含义和交付价值的业务能力；自下而上看是由一组高内聚、松耦合的任务组成。

业务组件是一个可以独立部署的单元，相应的任务对业务对象担当责任，对业务对象起到保护作用，保证了更高的数据质量，同时控制复杂程度，所以说业务组件不仅提供了整合的资源及结构，而且围绕业务对象提供了可复用的能力。业务组件不同于技术组件，业务组件更关注业务功能和业务流程。

（2）工艺工具

将企业的业务功能或业务能力进行模块化封装，形成业务组件，以构建专业化“功能模块“，其可以独立运行和部署。如图11所示。

（3）交付物示例，如图12所示。

工序5：识别干系人

（1）工艺方法

干系人是参与业务事件的个体和组织。本工序在业务架构阶段定义的企业级干系人的基础上，识别哪些干系人为本业务领域的利益相关方。

1）识别干系人时，可再次进行业务领域解读，根据现有的组织结构以及对业务的理解，明确范围边界。

2）基于业务架构阶段定义的干系人，识别本业务领域适用的内、外部干系人。

3）将识别的本领域干系人，关联到本领域，以便进一步定义本领域的业务事件。

（2）工艺工具

识别本领域的外部干系人和内部干系人。如图13所示。

（3）交付物示例，如图14所示。

工序6：定义业务事件

（1）工艺方法

根据内外部干系人对业务领域的行为或要求识别业务事件，为预设活动工序做准备。

1）事件名称: 事件名称以动词开头、且以动词+名词/名词短语构成。

2）事件类型：一般分为外部事件、条件事件、时间事件三种。

3）事件范围：起点和终点：起点即该事件的初始动作，终点即该事件的最后动作。一般以客户提出申请为事件起点，以银行办理完成并通知个人客户为事件终点。典型业务场景：遵循上述原则尽可能根据业务知识覆盖所有业务场景。

4）原交易码：罗列现有交易系统涉及该业务事件的交易码与交易名称。

（2）工艺工具

触发活动的业务事件的定义，业务事件由干系人触发，银行需要以活动流程来应对，包括外部事件、时间事件、条件事件。如图15所示。

（3）交付物示例，如图16所示。

工序7：预设活动

（1）工艺方法

基于企业视角，在全行范围内梳理本业务领域的业务活动，识别需要哪些业务流程支撑业务的开展。

1）根据业务资料、行业经验及银行业务价值链，梳理定义业务领域下的所有业务流程并罗列预设活动，活动应覆盖计划、执行、监督三个阶段的内容。

2）预设活动时，不考虑流程颗粒度，先识别，后续与事件对接时整合或调整。

3）活动尽量不体现CPCP的差异，如果差异较大，考虑拆分活动。

4）活动以“动词+名词” 结构命名，每个活动有特定的业务目的，以满足干系人的期望。

5）活动在不同业务领域间不能重复。

6）预设活动时，通过说明、描述、包括、不包括进一步描述活动的职责和边界：

活动说明：活动是由于什么目的而存在的。可以从多个角度来说明，如客户、产品、渠道、合作方，详细说明活动实现了哪些流程，产生了哪些价值，对活动动名词的充分解释，实现了什么功能。活动描述：一般以起点和终点的方式描述，体现业务价值。活动的包括与不包括：一般对容易与其他活动或领域混淆的内容进行说明。

（2）工艺工具

由内部事件或外部事件触发的，为满足特定业务目的，与干系人之间的交互过程。是银行应对所发生的内外部事件所启动的满足或应对事件中干系人诉求的流程。如图17所示。

（3）交付物示例，如图18所示。

二、价值流分析

价值流从客户和银行视角串接本业务领域内的各阶段活动，体现了企业级的价值链和价值创建过程。活动按照计划、执行、监督三个阶段进行编排，将活动归纳到价值流节点、节点归属到价值流阶段，形成价值流。

工序1：价值流分析

（1）工艺方法

1）分析价值流阶段：该工序需要对基于价值链分析的业务价值进行价值阶段分析。

按计划、执行、监督三个阶段，考虑业务本质，识别该业务领域下的价值流节点。计划：包含业务策略、规划、制度、研究、计划等内容。执行：包含业务处理的相关流程。监督：包括风险监控、业务评估、报表、监管、对账、司法管控等内容。

2）归纳价值流节点：该工序在划分出的价值流阶段基础上，进一步划分出价值流节点。根据对业务领域定义和理解，将活动归纳为价值流节点。归纳时，要对相关活动进行一定程度的抽象，基于业务价值进行概括。同时，每个价值流节点粒度应尽量保持一致，并保证价值流的完整性，确保价值创造的各个重要环节都能在价值流中体现。

价值流节点有一定的先后顺序，在排列顺序时应体现出价值创造的过程。可通过实体关系图辅助形成正确的价值流向，参考业务对象的先后关系来帮助确定价值流节点的顺序。

3）绘制价值流图：依据价值流图绘制标准，绘制预设活动的完整价值流图。

根据活动归纳和抽象价值流节点，并对价值流节点进行定义和描述，绘制三级活动结构图，即价值流图。

（2）工艺工具

定义在业务领域内的价值产生过程，包含一组活动，为确保价值创造的完整性。如图19所示。

（3）交付物示例，如图20所示。

三、活动分析

活动是由内部事件或外部事件触发的，为满足特定业务目的，与干系人之间的交互过程。

活动向上实现客户及银行价值，提升客户体验；向下根据不同的业务场景，将相关的任务依照顺序串接在一起，完成干系人的诉求。活动分析的主要工序包括：工序1预设活动与业务事件对接；工序2对接分析；工序3活动优化；工序4识别业务场景。

工序1：预设活动与业务事件对接

（1）工艺方法

分析活动清单、业务事件清单，建立业务事件与活动的映射关系，表示活动被业务事件触发。

1）将业务事件与预设活动进行对接，形成对应关系。

2）业务事件和预设活动是多对多的关系。

3）一个业务事件或预设活动只能归属一个业务领域。

（2）工艺工具

将业务事件和预设活动对接，识别、调整、补充未对接成功的事件或活动，以确保预设活动或事件的准确。如图21a~21b所示。

（3）交付物示例，如图22所示。

工序2：对接分析

（1）工艺方法

分析预设活动与业务事件对接成果，确保成果的准确性和完整性。

1）检查对应关系的正确性、合理性；

2）针对未对接的业务事件或预设活动，重新分析；

3）再次对接并调整未对应上的业务事件或预设活动。

（2）工艺工具

对未被关联的事件和活动进行分析，确保每个事件和活动都被关联上。如图23所示。

（3）交付物示例，如图24所示。

工序3：活动优化

（1）工艺方法

依据预设活动与业务事件对接分析成果，明确活动的定义。

1）活动是端到端的交互活动，时间上是连续的，不能中断。

2）活动名称：标准化动词+名词或名词短语，全领域唯一。

3）活动说明：

描述活动是由于什么目的而存在；一般从客户、产品、渠道、合作方等多个角度来详细说明活动实现了哪些流程，产生了哪些价值，对活动动名词进行充分地解释。

4）活动范围：

应包括起点和终点，要体现业务价值；包括的内容主要为容易与其他活动或领域混淆的，本活动的范围；不包括的内容主要为易混淆的其他领域或活动的范围、需要明确领域名称或活动名称。

（2）工艺工具

对已识别的活动，完善其要素内容，如定义、描述、包括、不包括等，以清晰、准确表述活动。如图23所示。

（3）交付物示例，如图26所示。

工序4：识别业务场景

（1）工艺方法

结合现有业务以及未来业务规划情况，明确业务事件下具体包括哪些业务场景，然后基于业务事件与变量因子，识别不同的业务场景。

1）事件是客户的诉求，抽离了变量因子，可以因为变量因子（CPCP）的取值不同，组合产生不同的业务场景。比如，“开立个人活期账户”事件因柜面渠道、网络渠道、自助渠道的不同，产生“网络渠道开立电子账户”、“柜面渠道/自助渠道开立个人活期账户”、“柜面渠道批量开立个人活期账户”三个不同的业务场景。

2）若变量因子的不同取值所触发的场景相同，则应被认为是同一场景。比如，变量因子为渠道时，柜面渠道和自助渠道开立个人活期账户的内部处理流程基本一致的，因此，他们属于同一个业务场景。

3）每个事件可以触发一个或多个场景。

（2）工艺工具

基于业务事件以及变量因子(cpcp)的不同取值的组合，识别出不同的业务场景。如图27所示。

（3）交付物示例，如图28所示。

四、任务分析

任务是由单一角色所执行的、时间上连续不间断发生的、具备明确的业务目的的工作事项的集合，为活动流程提供了基本的处理能力。

任务向上是组成业务组件的基本要素，是形成活动的基本单元；任务向下包含一组连续的工作事项，体现了最小粒度的服务能力（即一个独立的不能细分的服务能力）。任务分析的主要工序包括：工序1识别工作事项；工序2任务划分定义；工序3绘制工作流图；工序4任务标准化；工序5识别输入输出。

工序1：识别工作事项

（1）工艺方法

活动分析完成后，以活动为单位，识别活动下具体的处理事项。

1）工作事项一般从事项名称、所属活动、角色、依赖事项、描述、来源等方面进行识别：工作事项相互独立，彼此排斥，领域内唯一，即尽量穷举，但彼此间不重合不交叉。工作事项对应的角色应保证标准化命名。角色与工作流图泳道的角色名称对应，保持统一。工作事项的重点是讲清楚需要实现什么业务目的。如果通过工作事项名称简单易懂，若不能准确表达业务需求的范围，可在描述中进行说明，进而保证后续应用实施准确承接业务需求。

2）工作事项识别时，注意：工作事项不跨业务组件；工作事项只涉及单个业务对象或几个业务关系紧密的业务对象。比如，“维护个人存款介质状态”活动下有“检查挂失证件信息”、“检查挂失机构”、“检查挂失介质状态”事项。因“证件”、“机构”、“介质”这几个业务对象关系不紧密，故一般拆分成三个工作事项，而“网点”和“柜员”这两个业务对象联系比较紧密，故将检查网点服务资格和检查柜员服务资格合并为一个工作事项“检查网点及柜员服务资格”。

（2）工艺工具

根据业务需求、生产现状、监管要求等，基于活动，搜集工作事项，为后续的任务划分做好准备。同一活动下的工作事项彼此独立且排斥，内容不能重叠。如图29所示。

（3）交付物示例，如图30所示。

工序2：任务划分定义

（1）工艺方法

任务是业务组件的组成部分，而任务是由一个或多个工作事项构成的。该工序在活动下罗列的工作事项基础上，把工作事项进行归纳，划分任务。

1）任务的名称为动词+名称结构，全领域唯一。

2）任务的工作事项必须是一个角色所连续执行的。比如，“检查个人存款协议维护合法性”这个任务，包含的工作事项（“检查归属机构”、“检查通兑级别”、“检查账户状态”、“检查账户付息状态”、“检查介质状态”、“检查钱包子账户状态”、“检查钱包子账户介质状态”、“支付方式验证”）必须是同个角色（柜员）连续执行的，而不是柜员做了前两项，后几项由授权柜员或主管操作。

3）任务具有明确的业务目的。比如，“检查个人存款协议维护合法性”是为了规避冒名办理业务以及跨行违规操作的风险。

4）任务有明确的输出，包括信息创建或更新，比如，“终止个人存款产品协议”这个任务执行后，会更新协议状态；以及信息查询结果输出，比如“识别客户身份信息”结果为“通过”或“不通过”。

5）一个任务只能归属于一个业务组件。

6）任务应尽量能被不同的活动复用。

7）关联度高的几个工作事项应包含在一个任务中，便于活动使用。比如，前文列举的工作事项“检查归属机构”、“检查通兑级别”、“检查账户状态”、“检查账户付息状态”、“检查介质状态”、“检查钱包子账户状态”、“检查钱包子账户介质状态”、“支付方式验证”都是针对存款协议维护合法性进行的一系列检查，故将这些事项都整合为一个任务-“检查个人存款协议维护合法性”。

（2）工艺工具

对所罗列的事项划分为任务，要求任务是同一角色连续执行的工作事项的集合，任务具有明确的业务目的和业务价值的产出。如图31所示。

（3）交付物示例，如图32所示。

工序3：绘制工作流图

（1）工艺方法

工作流图将活动下识别的任务以图形的形式表达，展示业务的处理流程。

1）任务在执行过程中与外部干系人有交互且后续流程需依赖其反馈结果时，绘制外部泳道。

2）工作流图以最长的流为主流程绘制。工作流图网关流转，以最长的流为主流；相对短的流为分支流。

3）绘制工作流图时，流程不能返回。在完成当前工作后，流程只能向前不能向后，只能往下一个任务链接；若当前工作流程中断无法往前执行，则结束活动。

4）一个活动的活动工作流图只有一个，物理工作流图是在活动工作流图的基础上结合业务场景绘制的，一般存在多个。

（2）工艺工具

绘制基于任务的活动工作流图，以展示业务目的（客户诉求）的实现过程。如图33所示。

（3）交付物示例，如图34所示。

工序4：任务标准化

（1）工艺方法

任务标准化将业务领域下识别的任务，以企业级业务组件视角，进一步规范统一。

1）企业级标准化：根据各业务领域的任务清单，以企业级视角识别领域内可进行标准化的任务，并确定企业级标准化任务的责任归属。

2）工作流和任务完善：任务标准化之后，需修改和完善标准化任务相关的建模交付，更新、完善工作流图。

3）任务正确性原则：

任务的名称必须是“动词+名词或名词短语”的形式；

动词要符合动词标准，名称或名词短语需具有明确的业务含义；

在未做企业级标准化前，任务名称的名词或名词短语应体现本业务领域的业务含义，比如：配发个人存款介质。

4）任务标准性原则：

尽管同一任务允许在工作流中多次出现，但是任务名称及其含义必须唯一、标准化。避免出现任务同名不同义或者同义不同名的情况。任务可以被不同角色执行。在工作流程图等模型资产中，任务是允许多次重复出现，被多个角色所执行的。

5）任务完整性原则：

任务所包含的属性要完整，即：描述、范围、输入、输出、角色、业务对象等。

（2）工艺工具

挑选任务，逐步完成在领域内及跨领域（企业级）的任务标准化并确认该任务的责任归属，要求任务符合正确性、唯一性、完整性原则。如图35所示。

（3）交付物示例，如图36所示。

工序5：识别输入输出

（1）工艺方法

根据任务的职责定义，识别出任务核心的输入输出属性。

1）识别任务的输入：输入是执行任务的前提，在满足条件的情况才能触发任务。在识别输入信息时需考虑是否必输及其校验规则，如字段合法性校验等。

2）识别任务的输出：输出是任务执行后的结果，决定后续任务的路径和产出。识别输出时，需标注导致不同分支输出的数据来源，明确该字段出自哪个工作事项。比如，“维护介质认证信息”任务中“介质认证方式”字段的输出决定“介质密码”是否需要录入，因此，“介质认证方式”该字段需要标注。

（2）工艺工具

输入是执行任务的前提，在满足条件的情况才能触发任务；输出是任务执行后的结果，决定后续任务的路径和产出。如图37所示。

（3）交付物示例，如图38所示。

本发明从企业级价值链和业务价值创造的视角出发，流程建模结合实际需求梳理业务流程，并通过差异化封装变量因子（client客户、product产品、channel渠道、partner合作方，后简称CPCP），识别一系列可复用的标准化任务，运用企业级标准进行规范和整合，打破部门壁垒，形成企业级、标准化的流程模型，提升端到端的业务流程服务效率。与传统的业务需求相比，流程建模是业务需求的一种新的表达方式，它通过结构化、标准化的语言描述业务过程，搭建了战略能力实现和应用开发的桥梁。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：在本发明的精神和原则之内，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案脱离本发明的保护范围。

Claims (8)

1.一种用于软件开发中需求建模的流程建模系统，其特征在于，所述流程建模系统包括：

业务架构构建模块，获取目标企业的业务领域，构建与所述业务领域关联的业务架构，包括业务领域、干系人、业务对象、业务组件；

流程建模模块，基于所述业务架构进行流程建模，包括业务领域分析、价值流分析、活动分析和任务分析；所述任务是单一角色执行的步骤集合；所述活动是由事件触发，干系人之间的交互过程；所述价值流是业务领域内的价值创造过程，包含一组活动；所述业务领域由一组包含计划、执行、监督的活动组成，使用业务组件提供的任务，提供对外服务的能力。

2.根据权利要求1所述的系统，其特征在于，所述业务对象是企业业务的核心资源，是资源的结构化体现，用于指导应用系统落地时，用户执行用例相关操作时，所创建、存取和更新、删除的一组业务概念；

所述业务组件为关联各所述业务对象的功能组件；

所述业务领域为所述目标企业为客户和企业内部提供的需求服务，体现企业的高阶价值需求以及整体价值创造过程。

3.根据权利要求1所述的系统，其特征在于，业务架构构建模块还用于：

基于所述目标企业的价值链的视角定义业务领域；

根据业务活动和操作的业务对象定义干系人；

预设活动与业务事件对接以定义业务对象；

按照角色和业务目的划分业务并定义业务组件。

4.根据权利要求1所述的系统，其特征在于，所述流程建模进行业务领域分析包括：业务领域定义、干系人定义、业务对象定义、业务组件定义、识别干系人、定义业务事件、预设活动。

5.根据权利要求1所述的系统，其特征在于，所述流程建模进行价值流分析包括：

划分价值流阶段，对基于价值链分析的业务价值进行价值阶段分析；

归纳价值流节点，根据对业务领域定义和理解，将活动归纳为价值流节点；

绘制价值流图，依据价值流图绘制标准，绘制预设活动的完整价值流图。

6.根据权利要求1所述的系统，其特征在于，所述流程建模进行活动分析包括：

预设活动与业务事件对接，分析活动清单、业务事件清单，建立业务事件与活动的映射关系；

对接分析，分析预设活动与业务事件对接成果；

活动优化，据预设活动与业务事件对接分析成果，明确活动的定义；

识别业务场景，基于业务事件以及变量因子的不同取值的组合，识别出不同的业务场景。

7.根据权利要求6所述的方法，其特征在于，所述变量因子包括客户、产品、渠道、合作方。

8.根据权利要求1所述的系统，其特征在于，所述流程建模进行任务分析包括：

识别工作事项，活动分析完成后，以活动为单位，识别活动下具体的处理事项；

任务划分定义，在活动下罗列的工作事项基础上，把工作事项进行归纳，划分任务；

绘制工作流图，将活动下识别的任务以图形的形式表达，展示业务的处理流程；

任务标准化，将业务领域下识别的任务，以企业级业务组件视角，进一步规范统一；

识别输入输出，根据任务的职责定义，识别出任务核心的输入输出属性。