CN116466914A - 业务需求分析方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种业务需求分析方法、装置、计算机设备、存储介质和计算机程序产品，涉及计算机技术领域，可用于金融科技领域或其他相关领域。该方法包括：获取待分析业务的原始业务需求信息，根据原始业务需求信息，构建待分析业务的子业务模型；子业务模型至少包括流程模型、实体模型、产品模型和要素模型；在流程模型、实体模型、产品模型和要素模型达到预设交互状态的情况下，将以上四个子业务模型进行融合处理，得到待分析业务的候选业务模型；根据待分析业务的需求用例模型，对候选业务模型进行验证；在候选业务模型验证通过的情况下，将候选业务模型确认为待分析业务的目标业务模型。采用本方法，能够提高业务需求分析的效率。

Description

业务需求分析方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种业务需求分析方法、装置、计算机设备、存储介质和计算机程序产品。

背景技术

随着计算机软件技术的发展，出现了计算机应用系统，该系统可以作为企业业务需求分析的工具。

传统技术中，利用计算机应用系统进行企业业务需求的分析方法主要包括功能分解法、用户故事法和需求用例法，这三种方法分别从不同角度实现了对业务需求的分析。然而，目前在进行业务需求分析时，存在大量复杂重复的工作，过程比较繁琐，从而导致业务需求分析的效率较低。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高业务需求分析效率的业务需求分析方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。

第一方面，本申请提供了一种业务需求分析方法。所述方法包括：

获取待分析业务的原始业务需求信息，根据所述原始业务需求信息，构建所述待分析业务的子业务模型；所述子业务模型至少包括流程模型、实体模型、产品模型和要素模型；

在所述流程模型、所述实体模型、所述产品模型和所述要素模型达到预设交互状态的情况下，将所述流程模型、所述实体模型、所述产品模型和所述要素模型进行融合处理，得到所述待分析业务的候选业务模型；

根据所述待分析业务的需求用例模型，对所述候选业务模型进行验证；所述需求用例模型根据所述原始业务需求信息构建得到；

在所述候选业务模型验证通过的情况下，将所述候选业务模型确认为所述待分析业务的目标业务模型；所述目标业务模型用于描述所述原始业务需求信息。

在其中一个实施例中，所述将所述流程模型、所述实体模型、所述产品模型和所述要素模型进行融合处理，得到所述待分析业务的候选业务模型，包括：

将所述流程模型、所述实体模型、所述产品模型和所述要素模型进行模型对接处理，得到组合模型；所述组合模型为完整闭环链路的模型；

获取所述组合模型的反馈数据；

根据所述反馈数据对所述组合模型进行更新，得到更新后的组合模型，作为所述候选业务模型。

在其中一个实施例中，所述根据所述反馈数据对所述组合模型进行更新，得到更新后的组合模型，作为所述候选业务模型，包括：

对所述反馈数据进行预处理；

根据预处理后的反馈数据，对所述组合模型进行迭代更新，直到所述组合模型的更新次数与预设次数相同；

将最后一次更新后的组合模型，作为所述候选业务模型。

在其中一个实施例中，所述根据所述待分析业务的需求用例模型，对所述候选业务模型进行验证，包括：

获取所述候选业务模型的预设检测条件；所述预设检测条件用于检测所述候选业务模型的模型性能；

根据所述需求用例模型，验证所述候选业务模型是否满足所述预设检测条件；

在所述候选业务模型满足所述预设检测条件的情况下，确认所述候选业务模型验证通过。

在其中一个实施例中，在根据所述需求用例模型，验证所述候选业务模型是否满足所述预设检测条件之后，还包括：

在所述候选业务模型不满足所述预设检测条件的情况下，确认所述候选业务模型中不满足所述预设检测条件的目标子业务模型；

利用所述需求用例模型对所述候选业务模型中的目标子业务模型进行更新，直到更新后的候选业务模型满足所述预设检测条件。

在其中一个实施例中，所述方法还包括：

在所述原始业务需求信息更新的情况下，根据更新后的业务需求信息，从所述目标业务模型中确认出待更新的子业务模型；

根据所述更新后的业务需求信息，对所述目标业务模型中的待更新的子业务模型进行更新，得到所述目标业务模型的更新后业务模型。

在其中一个实施例中，所述方法还包括：

对所述原始业务需求信息进行分类处理，得到子原始业务需求信息；所述子原始业务需求信息至少包括流程模型信息、实体模型信息和产品模型信息；

构建与所述流程模型信息对应的模型，作为所述流程模型，构建与所述实体模型信息对应的模型，作为所述实体模型，以及构建与所述产品模型信息对应的模型，作为所述产品模型；

基于所述原始业务需求信息，构建用于补充所述流程模型、所述实体模型和所述产品模型的模型，作为所述要素模型。

第二方面，本申请还提供了一种业务需求分析装置。所述装置包括：

模型构建模块，用于获取待分析业务的原始业务需求信息，根据所述原始业务需求信息，构建所述待分析业务的子业务模型；所述子业务模型至少包括流程模型、实体模型、产品模型和要素模型；

模型融合模块，用于在所述流程模型、所述实体模型、所述产品模型和所述要素模型达到预设交互状态的情况下，将所述流程模型、所述实体模型、所述产品模型和所述要素模型进行融合处理，得到所述待分析业务的候选业务模型；

模型验证模块，用于根据所述待分析业务的需求用例模型，对所述候选业务模型进行验证；所述需求用例模型根据所述原始业务需求信息构建得到；

模型确认模块，在所述候选业务模型验证通过的情况下，将所述候选业务模型确认为所述待分析业务的目标业务模型；所述目标业务模型用于描述所述原始业务需求信息。

第三方面，本申请还提供了一种计算机设备。所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

获取待分析业务的原始业务需求信息，根据所述原始业务需求信息，构建所述待分析业务的子业务模型；所述子业务模型至少包括流程模型、实体模型、产品模型和要素模型；

在所述流程模型、所述实体模型、所述产品模型和所述要素模型达到预设交互状态的情况下，将所述流程模型、所述实体模型、所述产品模型和所述要素模型进行融合处理，得到所述待分析业务的候选业务模型；

根据所述待分析业务的需求用例模型，对所述候选业务模型进行验证；所述需求用例模型根据所述原始业务需求信息构建得到；

在所述候选业务模型验证通过的情况下，将所述候选业务模型确认为所述待分析业务的目标业务模型；所述目标业务模型用于描述所述原始业务需求信息。

第四方面，本申请还提供了一种计算机可读存储介质。所述计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

获取待分析业务的原始业务需求信息，根据所述原始业务需求信息，构建所述待分析业务的子业务模型；所述子业务模型至少包括流程模型、实体模型、产品模型和要素模型；

在所述流程模型、所述实体模型、所述产品模型和所述要素模型达到预设交互状态的情况下，将所述流程模型、所述实体模型、所述产品模型和所述要素模型进行融合处理，得到所述待分析业务的候选业务模型；

根据所述待分析业务的需求用例模型，对所述候选业务模型进行验证；所述需求用例模型根据所述原始业务需求信息构建得到；

在所述候选业务模型验证通过的情况下，将所述候选业务模型确认为所述待分析业务的目标业务模型；所述目标业务模型用于描述所述原始业务需求信息。

第五方面，本申请还提供了一种计算机程序产品。所述计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：

获取待分析业务的原始业务需求信息，根据所述原始业务需求信息，构建所述待分析业务的子业务模型；所述子业务模型至少包括流程模型、实体模型、产品模型和要素模型；

在所述流程模型、所述实体模型、所述产品模型和所述要素模型达到预设交互状态的情况下，将所述流程模型、所述实体模型、所述产品模型和所述要素模型进行融合处理，得到所述待分析业务的候选业务模型；

根据所述待分析业务的需求用例模型，对所述候选业务模型进行验证；所述需求用例模型根据所述原始业务需求信息构建得到；

在所述候选业务模型验证通过的情况下，将所述候选业务模型确认为所述待分析业务的目标业务模型；所述目标业务模型用于描述所述原始业务需求信息。

上述业务需求分析方法、装置、计算机设备、存储介质和计算机程序产品，通过获取待分析业务的原始业务需求信息，根据原始业务需求信息，构建待分析业务的子业务模型，子业务模型至少包括流程模型、实体模型、产品模型和要素模型；在流程模型、实体模型、产品模型和要素模型达到预设交互状态的情况下，将流程模型、实体模型、产品模型和要素模型进行融合处理，得到待分析业务的候选业务模型；再根据待分析业务的需求用例模型，对候选业务模型进行验证；在候选业务模型验证通过的情况下，将候选业务模型确认为待分析业务的目标业务模型。这样，先获取待分析业务的原始业务需求信息，以便后续根据原始业务需求信息有针对性地构建流程模型、实体模型、产品模型和要素模型，作为待分析业务的子业务模型；在流程模型、实体模型、产品模型和要素模型达到预设交互状态的情况下，将流程模型、实体模型、产品模型和要素模型进行融合处理，得到待分析业务的候选业务模型，从而有效地将四个不同的子业务模型融合形成候选业务模型，有利于提高业务需求分析的全面性与完整性；再根据待分析业务的需求用例模型，对候选业务模型进行验证，可以对候选业务模型的模型性能进行准确的评估与检验；最后，在候选业务模型验证通过的情况下，将候选业务模型确认为待分析业务的目标业务模型，从而有效地筛选出符合验证标准的目标业务模型；即采用业务需求分析方法对待分析业务进行业务需求分析，将业务需求分析过程应用业务架构方法转化为业务建模过程，有效避免了大量复杂重复的工作，有利于快速准确地得出业务需求分析结果，从而提高了业务需求分析的效率。

附图说明

图1为一个实施例中业务需求分析方法的流程示意图；

图2为一个实施例中业务架构组成部分的示意图；

图3为一个实施例中业务信息之间相互关联的示意图；

图4为一个实施例中业务资源形成关系的示意图；

图5为一个实施例中各子业务模型的模型关系示意图；

图6为另一个实施例中业务需求分析方法的流程示意图；

图7为又一个实施例中业务需求分析方法的流程示意图；

图8为一个实施例中业务需求分析装置中各模块的功能视图；

图9为一个实施例中业务需求分析装置与三方系统交互情况的示意图；

图10为再一个实施例中业务需求分析方法的流程示意图；

图11为一个实施例中业务需求分析装置的结构框图；

图12为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

在一个实施例中，如图1所示，提供了一种业务需求分析方法，本实施例以该方法应用于终端进行举例说明，可以理解的是，该方法也可以应用于服务器，还可以应用于包括终端和服务器的系统，并通过终端和服务器之间的交互实现。其中，终端可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑等；服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。本实施例中，该方法包括以下步骤：

步骤S101，获取待分析业务的原始业务需求信息，根据原始业务需求信息，构建待分析业务的子业务模型；子业务模型至少包括流程模型、实体模型、产品模型和要素模型。

其中，待分析业务是指待进行业务需求分析的业务，比如金融业务、企业业务等。

其中，原始业务需求是指组织或客户的高层目标，业务需求通常来自项目投资人、购买产品的客户和产品策划部门等，其描述了一个组织为什么要开发一个系统，也就是说，这个组织希望实现什么目的。

其中，子业务模型是业务模型的一个组成单元，而业务模型是对业务问题的定义，提供解决业务问题的基本方法。

其中，流程模型是描述企业业务流程，专注于业务处理逻辑，是创造价值的过程。

其中，实体模型是企业的关键资源，体现业务本质和实体特征。

其中，产品模型是基于企业战略能力，描述企业价值交付框架，专注于对客户、市场的分析，根据价值定位设计交付价值的方式。

其中，要素模型是描述企业完成价值交付的关键要素，一般包括客户、渠道以及合作方，它是对流程模型、实体模型、产品模型的补充。

具体地，终端接收针对待分析业务的业务需求分析请求，根据该业务需求分析请求，获取待分析业务的原始业务需求信息，基于原始业务需求信息，通过修改已有模型或新增模型的方式，分别得到待分析业务的流程模型、实体模型、产品模型和要素模型四个子业务模型。

举例说明，终端获取待分析业务的当前业务架构、当前实体模型和当前产品模型，根据当前业务架构构建新流程模型，得到目标流程模型；根据原始业务需求信息修改当前实体模型，得到目标实体模型；根据原始业务需求信息修改当前产品模型，得到目标产品模型；根据目标流程模型、目标实体模型和目标产品模型，补充构建目标要素模型。

需要说明的是，企业架构是定义所有构成企业的不同元素，以及这些元素怎样相互关联，它从企业战略规划出发呈现业务战略和互联网技术战略，包括业务架构、应用架构、数据架构、技术架构；而业务架构是企业架构的基础，为支撑企业业务目标而定义的一套运作管理体系的结构化描述，描述各级组织日常业务运作、模块化和层次化的业务能力结构，为应用架构、数据架构、技术架构提供指引。

进一步地，如图2所示，本申请提出的分析方法所基于的业务架构，是承接企业战略、完整描述企业业务形态、业务能力、价值交付的框架方法，业务架构由三部分组成，分别描述了业务架构的不同方面；其具体包括“三纵三横一扩展”，三纵是业务领域、业务组件、业务对象，是业务架构的高阶形态，三横是流程模型、产品模型、实体模型，是业务架构的落地方法，一扩展是要素模型，是对价值交付的要素补充。业务领域规定了业务价值交付的业务域，反映的是对外服务的能力，业务组件是企业内部能力的体现，业务对象是企业的关键资源，三者之间的关系如图3所示。参考图4，三者需依靠业务模型进行落地，即依托流程模型实现对业务流程的建模，形成抽象内聚的流程模型，包括价值流、活动、任务，依托产品模型实现对价值交付的方式的定义，形成灵活配置的基础产品，包括产品条件、产品组件、基础产品，依托实体模型实现对关键业务资源的定义，形成边界清晰的业务实体，包括业务实体、实体属性。而要素模型是对流程模型、实体模型、产品模型的补充，流程模型和实体模型在抽象建模时将具有个性特征的产品、渠道、合作方、用户等价值要素去掉，产品模型对产品要素进行了补充，要素模型对其他如渠道、合作方、用户等要素进行了补充，最终形成完成业务架构模型框架，上述四个子业务模型的模型关系具体如图5所示。

步骤S102，在流程模型、实体模型、产品模型和要素模型达到预设交互状态的情况下，将流程模型、实体模型、产品模型和要素模型进行融合处理，得到待分析业务的候选业务模型。

其中，预设交互状态是指流程模型使用的实体模型准确无误，没有出现遗漏，产品模型有流程模型支撑，实体模型能够实现对产品条件进行存储，要素模型能够与流程模型对接实现对产品模型的价值交付。

其中，融合处理是指实现模型对接，从而得到构成完整闭环链路的组合模型。

具体地，终端识别流程模型、实体模型、产品模型和要素模型的模型状态，判断这四个子业务模型是否达到预设交互状态，在其达到预设交互状态的情况下，对四个子业务模型进行融合处理；在对子业务模型融合处理完成之后，得到完整闭环链路的候选业务模型。

步骤S103，根据待分析业务的需求用例模型，对候选业务模型进行验证；需求用例模型根据原始业务需求信息构建得到。

其中，需求用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。需求用例是贯穿整个系统开发的一条主线，同一个需求用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。

具体地，终端根据原始业务需求信息，同步开展需求用例建模，得到待分析业务的需求用例模型，并用该需求用例模型对候选业务模型进行验证，得到验证结果。

步骤S104，在候选业务模型验证通过的情况下，将候选业务模型确认为待分析业务的目标业务模型；目标业务模型用于描述原始业务需求信息。

其中，目标业务模型是指将要正式发布的业务模型，其会被用于移交开发人员进行技术实现。

具体地，终端获取候选业务模型的验证结果，判断该候选业务模型是否通过验证，在其验证通过的情况下，将候选业务模型确认为待分析业务的目标业务模型。

上述业务需求分析方法中，通过获取待分析业务的原始业务需求信息，根据原始业务需求信息，构建待分析业务的子业务模型，子业务模型至少包括流程模型、实体模型、产品模型和要素模型；在流程模型、实体模型、产品模型和要素模型达到预设交互状态的情况下，将流程模型、实体模型、产品模型和要素模型进行融合处理，得到待分析业务的候选业务模型；再根据待分析业务的需求用例模型，对候选业务模型进行验证；在候选业务模型验证通过的情况下，将候选业务模型确认为待分析业务的目标业务模型。这样，先获取待分析业务的原始业务需求信息，以便后续根据原始业务需求信息有针对性地构建流程模型、实体模型、产品模型和要素模型，作为待分析业务的子业务模型；在流程模型、实体模型、产品模型和要素模型达到预设交互状态的情况下，将流程模型、实体模型、产品模型和要素模型进行融合处理，得到待分析业务的候选业务模型，从而有效地将四个不同的子业务模型融合形成候选业务模型，有利于提高业务需求分析的全面性与完整性；再根据待分析业务的需求用例模型，对候选业务模型进行验证，可以对候选业务模型的模型性能进行准确的评估与检验；最后，在候选业务模型验证通过的情况下，将候选业务模型确认为待分析业务的目标业务模型，从而有效地筛选出符合验证标准的目标业务模型；即采用业务需求分析方法对待分析业务进行业务需求分析，将业务需求分析过程应用业务架构方法转化为业务建模过程，有效避免了大量复杂重复的工作，有利于快速准确地得出业务需求分析结果，从而提高了业务需求分析的效率。

在一个实施例中，上述步骤S102中，将流程模型、实体模型、产品模型和要素模型进行融合处理，得到待分析业务的候选业务模型，具体包括如下内容：将流程模型、实体模型、产品模型和要素模型进行模型对接处理，得到组合模型；组合模型为完整闭环链路的模型；获取组合模型的反馈数据；根据反馈数据对组合模型进行更新，得到更新后的组合模型，作为候选业务模型。

其中，组合模型是指形成业务流程使用实体资源交付产品价值的完整闭环链路的模型。

其中，组合模型的反馈数据是指经过组合模型处理得到的历史输出数据。

具体地，终端将流程模型、实体模型、产品模型和要素模型进行模型对接处理，在模型对接成功的情况下，得到组合模型；再获取并分析针对组合模型的反馈数据，筛选出其中有效的反馈数据；根据其中有效的反馈数据，对组合模型进行模型参数的更新，得到更新后的组合模型，并将其作为候选业务模型。

本实施例中，通过将流程模型、实体模型、产品模型和要素模型进行模型对接处理，得到组合模型；获取组合模型的反馈数据；根据反馈数据对组合模型进行更新，得到更新后的组合模型，作为候选业务模型。从而有效地将四个现有的子业务模型融合构建形成一个组合模型，并通过最新的反馈数据对组合模型进行实时的更新和修正，有利于得到更准确的组合模型。

在一个实施例中，上一个实施例中，根据反馈数据对组合模型进行更新，得到更新后的组合模型，作为候选业务模型，具体包括如下内容：对反馈数据进行预处理；根据预处理后的反馈数据，对组合模型进行迭代更新，直到组合模型的更新次数与预设次数相同；将最后一次更新后的组合模型，作为候选业务模型。

其中，预处理指的是对反馈数据进行数据清洗、数据融合和数据检测等操作。

其中，迭代更新是指重复更新过程的活动，其目的通常是为了逼近所需目标或结果。每一次对过程的重复称为一次“迭代”，而每一次迭代得到的结果会作为下一次迭代的初始值。

具体地，终端对获取得到的反馈数据进行预处理；根据预处理后的反馈数据，对组合模型进行迭代更新，同时记录模型更新的次数，直到组合模型的更新次数与预设次数相同；获取最近一次更新后得到组合模型，并将其作为候选业务模型。

举例说明，终端对反馈数据进行数据清洗、去噪、融合等预处理操作；根据预处理后的反馈数据，对组合模型进行迭代更新，同时记录模型更新的次数，直到组合模型的更新次数达到预设次数五次；获取第五次更新后得到组合模型，并将其作为候选业务模型。

本实施例中，通过对反馈数据进行预处理；根据预处理后的反馈数据，对组合模型进行迭代更新，直到组合模型的更新次数与预设次数相同；将最后一次更新后的组合模型，作为候选业务模型；从而通过多次迭代更新组合模型准确地得到候选业务模型。

在一个实施例中，上述步骤S103中，根据待分析业务的需求用例模型，对候选业务模型进行验证，具体包括如下内容：获取候选业务模型的预设检测条件；预设检测条件用于检测候选业务模型的模型性能；根据需求用例模型，验证候选业务模型是否满足预设检测条件；在候选业务模型满足预设检测条件的情况下，确认候选业务模型验证通过。

其中，预设检测条件用于评判候选业务模型的模型性能是否符合标准，具体包括：模型完整性，满足原始需求；模型全面性，不遗漏不重复；模型复用性，能复用不新增；业务内聚性，模型边界清晰，业务内聚；模型可实现，现有技术手段能够满足；模型融合性，从业务视角出发进行需求融合。

具体地，终端获取候选业务模型的预设检测条件，解析预设检测条件的具体检测标准；基于解析得到的具体检测标准，根据需求用例模型，验证候选业务模型是否满足预设检测条件；在候选业务模型满足预设检测条件的情况下，确认候选业务模型验证通过，并将该候选业务模型作为待分析业务的目标业务模型。

本实施例中，通过获取候选业务模型的预设检测条件；根据需求用例模型，验证候选业务模型是否满足预设检测条件；在候选业务模型满足预设检测条件的情况下，确认候选业务模型验证通过；从而根据需求用例模型以及预设检测条件，有针对性地对候选业务模型的模型性能进行验证，有利于提高筛选得到的目标业务模型的准确性。

在一个实施例中，在根据需求用例模型，验证候选业务模型是否满足预设检测条件之后，还包括：在候选业务模型不满足预设检测条件的情况下，确认候选业务模型中不满足预设检测条件的目标子业务模型；利用需求用例模型对候选业务模型中的目标子业务模型进行更新，直到更新后的候选业务模型满足预设检测条件。

其中，目标子业务模型是指在流程模型、实体模型、产品模型和要素模型四个子业务模型中，不满足预设检测条件的一个或多个子业务模型。

具体地，终端在候选业务模型不满足预设检测条件的情况下，从候选业务模型中检测并筛选出不满足预设检测条件的目标子业务模型，利用需求用例模型对该目标子业务模型进行修正与更改，直到更正后的目标子业务模型满足预设检测条件，同时便可得到满足预设检测条件的候选业务模型。

举例说明，终端在候选业务模型不满足预设检测条件的情况下，从候选业务模型中检测并筛选出流程模型不满足预设检测条件，利用需求用例模型对该流程模型进行修正与更改，直到更正后的流程模型满足预设检测条件，同时便可得到满足预设检测条件的候选业务模型。

本实施例中，通过在候选业务模型不满足预设检测条件的情况下，确认候选业务模型中不满足预设检测条件的目标子业务模型；利用需求用例模型对候选业务模型中的目标子业务模型进行更新，直到更新后的候选业务模型满足预设检测条件；从而快速准确地筛选出不满足预设检测条件的目标子业务模型，并利用需求用例模型对该目标子业务模型进行更新，有利于提高更新后的候选业务模型的准确性。

在一个实施例中，该业务需求分析还包括如下内容：在原始业务需求信息更新的情况下，根据更新后的业务需求信息，从目标业务模型中确认出待更新的子业务模型；根据更新后的业务需求信息，对目标业务模型中的待更新的子业务模型进行更新，得到目标业务模型的更新后业务模型。

其中，待更新的子业务模型是指与原始业务需求信息更新的部分，相对应的子业务模型。

具体地，终端在原始业务需求信息更新的情况下，识别出业务需求信息中更新的部分，根据该更新的部分，从目标业务模型中确认出与更新的部分相对应的子业务模型，作为待更新的子业务模型，其余子业务模型保持不变；根据更新后的业务需求信息，对待更新的子业务模型进行更新，得到目标业务模型的更新后业务模型。

举例说明，终端在原始业务需求信息更新的情况下，识别出业务需求信息中更新的部分，根据该更新的部分，将实体模型确认为与更新的部分相对应的子业务模型；根据更新后的业务需求信息，对该实体模型进行更新，其余子业务模型保持不变，得到目标业务模型的更新后业务模型。

本实施例中，通过在原始业务需求信息更新的情况下，根据更新后的业务需求信息，从目标业务模型中确认出待更新的子业务模型；根据更新后的业务需求信息，对目标业务模型中的待更新的子业务模型进行更新，得到目标业务模型的更新后业务模型；这样灵活地根据更新后的业务需求信息，有针对性地修改子业务模型，从而高效准确地得到的目标业务模型的更新后业务模型。

在一个实施例中，上述步骤S101中，根据原始业务需求信息，构建待分析业务的子业务模型，具体包括如下内容：对原始业务需求信息进行分类处理，得到子原始业务需求信息；子原始业务需求信息至少包括流程模型信息、实体模型信息和产品模型信息；构建与流程模型信息对应的模型，作为流程模型，构建与实体模型信息对应的模型，作为实体模型，以及构建与产品模型信息对应的模型，作为产品模型；基于原始业务需求信息，构建用于补充流程模型、实体模型和产品模型的模型，作为要素模型。

其中，子原始业务需求信息是原始业务需求信息的一个组成部分，各个子原始业务需求信息与各个子业务模型一一对应。

具体地，终端对原始业务需求信息进行识别、筛选和分类，得到目标数量的子原始业务需求信息，分别为：流程模型信息、实体模型信息和产品模型信息；通过修改已有模型或新增模型的方式，构建与流程模型信息对应的模型，作为流程模型，构建与实体模型信息对应的模型，作为实体模型，以及构建与产品模型信息对应的模型，作为产品模型；基于原始业务需求信息，识别并补充出现遗漏的业务需求信息，生成要素模型信息，再根据要素模型信息构建用于补充流程模型、实体模型和产品模型的模型，作为要素模型。

本实施例中，通过对原始业务需求信息进行分类处理，得到子原始业务需求信息；构建与流程模型信息对应的模型，作为流程模型，构建与实体模型信息对应的模型，作为实体模型，以及构建与产品模型信息对应的模型，作为产品模型；基于原始业务需求信息，构建用于补充流程模型、实体模型和产品模型的模型，作为要素模型；这样先对原始业务需求信息进行分类处理，得到子原始业务需求信息，再分别针对各个子原始业务需求信息构建对应的子业务模型，最后构建要素模型用于补充其他子业务模型，从而有效地提高了模型构建的准确性、完整性和全面性。

在一个实施例中，如图6所示，提供了另一种业务需求分析方法，具体包括以下步骤：

步骤S601，获取待分析业务的原始业务需求信息，根据原始业务需求信息，构建待分析业务的子业务模型；子业务模型至少包括流程模型、实体模型、产品模型和要素模型。

步骤S602，将流程模型、实体模型、产品模型和要素模型进行模型对接处理，得到组合模型；组合模型为完整闭环链路的模型。

步骤S603，获取组合模型的反馈数据，对反馈数据进行预处理。

步骤S604，根据预处理后的反馈数据，对组合模型进行迭代更新，直到组合模型的更新次数与预设次数相同；将最后一次更新后的组合模型，作为候选业务模型。

步骤S605，获取候选业务模型的预设检测条件；预设检测条件用于检测候选业务模型的模型性能；根据需求用例模型，验证候选业务模型是否满足预设检测条件。

步骤S606，在候选业务模型满足预设检测条件的情况下，确认候选业务模型验证通过。

步骤S607，在候选业务模型不满足预设检测条件的情况下，确认候选业务模型中不满足预设检测条件的目标子业务模型；利用需求用例模型对候选业务模型中的目标子业务模型进行更新，直到更新后的候选业务模型满足预设检测条件。

步骤S608，在候选业务模型验证通过的情况下，将候选业务模型确认为待分析业务的目标业务模型；目标业务模型用于描述原始业务需求信息。

步骤S609，在原始业务需求信息更新的情况下，根据更新后的业务需求信息，从目标业务模型中确认出待更新的子业务模型；根据更新后的业务需求信息，对目标业务模型中的待更新的子业务模型进行更新，得到目标业务模型的更新后业务模型。

上述业务需求分析方法，可以达到以下技术效果：

(1)将四个子业务模型融合构建形成一个组合模型，并通过最新的反馈数据对组合模型进行实时的更新和修正，有利于得到更准确的组合模型。然后，获取候选业务模型的预设检测条件；根据需求用例模型，验证候选业务模型是否满足预设检测条件；在候选业务模型满足预设检测条件的情况下，确认候选业务模型验证通过；从而根据需求用例模型以及预设检测条件，有针对性地对候选业务模型的模型性能进行验证，有利于提高筛选得到的目标业务模型的准确性。

(2)在候选业务模型不满足预设检测条件的情况下，确认候选业务模型中不满足预设检测条件的目标子业务模型；利用需求用例模型对候选业务模型中的目标子业务模型进行更新，直到更新后的候选业务模型满足预设检测条件；从而快速准确地筛选出不满足预设检测条件的目标子业务模型，并利用需求用例模型对该目标子业务模型进行更新，有利于提高更新后的候选业务模型的准确性。

(3)在原始业务需求信息更新的情况下，根据更新后的业务需求信息，从目标业务模型中确认出待更新的子业务模型；根据更新后的业务需求信息，对目标业务模型中的待更新的子业务模型进行更新，得到目标业务模型的更新后业务模型；这样灵活地根据更新后的业务需求信息，有针对性地修改子业务模型，从而高效准确地得到的目标业务模型的更新后业务模型。

(4)获取目标业务模型或更新后业务模型的模型参数信息；对模型参数信息进行数据汇总处理，得到模型参数信息集，作为待分析业务的业务需求分析结果信息；从而根据模型参数信息，准确地得到待分析业务的业务需求分析结果信息。即采用业务需求分析方法对待分析业务进行业务需求分析，将业务需求分析过程应用业务架构方法转化为业务建模过程，有效避免了大量复杂重复的工作，有利于快速准确地得出业务需求分析结果，从而提高了业务需求分析的效率。

为了更清晰阐明本申请实施例提供的业务需求分析方法，以下以一个具体的实施例对该业务需求分析方法进行具体说明。在一个实施例中，如图7所示，本申请提供了又一种业务需求分析方法，具体是基于业务架构来进行业务需求分析；该方法的创新点是将业务需求分析过程应用业务架构方法转化为业务建模过程；同时，该方法使用业务模型统一了业务需求到技术实现的一致性，围绕业务模型，向上完整描述业务需求，向下落地技术实现，保证了业务与技术的链路的统一。具体包括以下步骤：

步骤1：依据当前业务架构，从原始需求中提炼预设流程模型(修改已有模型或新增模型)，明确归属业务领域，使用任务组件完成对业务逻辑描述。

步骤2：依据当前实体模型，从原始需求中提炼预设业务实体(修改已有模型或新增模型)，定义业务实体及其属性，完整描述原始需求中的业务信息。

步骤3：分析当前产品模型，定义原始需求中涉及的产品信息，预设基础产品、产品组件和产品条件，初步定义形成可售产品，完整描述原始需求交付价值的方式，为要求模型建模提供输入。

步骤4：根据原始需求价值交付情况，分析价值交付依赖的渠道，价值交付面向的客户，以及协作完成交付所需的合作方，补充预设要素模型。

步骤5：将预设的流程模型、实体模型、产品模型、要素模型进行对接，形成业务流程使用实体资源交付产品价值的完整闭环链路，不断精粹原始需求提炼的四个模型，最终形成预发布模型。

步骤6：同步开展需求用例建模，依据业务架构分析，形成细化整合的需求用例，补充业务架构模型细节，包括执行步骤、技术要求、风险控制和安全要求等。

步骤7：针对预发布业务模型，结合用例模型，开展需求评审，在完成需求评审之后，正式发布业务模型。

步骤8：将业务模型移交开发人员进行技术实现。

进一步地，本申请还提供了与该业务需求分析方法相对应的实现装置，其中分析方法是核心，实现装置依赖分析方法，是分析方法的技术实现，主要用来保障分析方法的有效开展。具体而言，本申请提出的基于业务架构的业务需求分析方法实现装置，是B/S(Browser/Server Architecture，浏览器和服务器架构)架构的应用系统，主要功能包括项目数据同步、原始需求管理、业务架构建模、业务需求评审、业务模型移交等模块，功能视图如图8所示。

此外，系统的原始需求管理模型完成原始需求记录、发布以及评价功能，用户使用该模块进行原始需求收集，原始需求发布后，用户在业务架构建模模块使用业务架构方法开始进行业务建模，输出流程模型、实体模型、要素模型、产品模型等业务模型，在建模过程中可使用建模工作台进行建模草稿，完成建模后，使用需求评审功能对业务模型进行评审，评审通过后，正式发布业务模型，可以在需求移交模块出发业务模型移交，将业务模型下发给下游系统使用。

本申请提出的基于业务架构的业务需求分析方法实现装置与三方系统的交互情况如图9所示，其中需求分析系统上游系统为项目管理系统，从该系统同步项目信息，包括项目基本信息、项目成员信息、项目版本信息，下游系统为测试管理系统和研发管理系统，主要向这两个系统同步基于业务架构开展的业务需求分析所发布的业务模型，测试管理系统依据移交的业务模型制定测试方案和编写测试用例，研发管理系统依据移交的业务模型编写总体方案和详细设计，两个系统使用业务模型完成功能开发及测试验收；本申请提出的基于业务架构的业务需求分析方法实现装置主要的工作流程如图10所示。

上述实施例带来的有益效果如下：(1)提供了企业视角开展需求分析，能够解决业务需求分散、竖井式重复的问题，可以据此建设业务中台，为应用解耦和服务复用提供了可能；(2)使用业务架构方法，开展业务建模，有效约束了业务需求分析维度，以结构化、关系式的模型代替语义化需求描述，提升了业务需求的质量；(3)基于业务架构方法提供的统一语言，业务方开展需求分析完成业务建模，可以直接传达给技术方进行实现，降低了沟通成本，提高了技术快速反应业务变化的能力。

应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的业务需求分析方法的业务需求分析装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个业务需求分析装置实施例中的具体限定可以参见上文中对于业务需求分析方法的限定，在此不再赘述。

在一个实施例中，如图11所示，提供了一种业务需求分析装置，包括：模型构建模块1101、模型融合模块1102、模型验证模块1103和模型确认模块1104，其中：

模型构建模块1101，用于获取待分析业务的原始业务需求信息，根据原始业务需求信息，构建待分析业务的子业务模型；子业务模型至少包括流程模型、实体模型、产品模型和要素模型；

模型融合模块1102，用于在流程模型、实体模型、产品模型和要素模型达到预设交互状态的情况下，将流程模型、实体模型、产品模型和要素模型进行融合处理，得到待分析业务的候选业务模型；

模型验证模块1103，用于根据待分析业务的需求用例模型，对候选业务模型进行验证；需求用例模型根据原始业务需求信息构建得到；

模型确认模块1104，在候选业务模型验证通过的情况下，将候选业务模型确认为待分析业务的目标业务模型；目标业务模型用于描述原始业务需求信息。

在一个实施例中，模型融合模块1102，还用于将流程模型、实体模型、产品模型和要素模型进行模型对接处理，得到组合模型；组合模型为完整闭环链路的模型；获取组合模型的反馈数据；根据反馈数据对组合模型进行更新，得到更新后的组合模型，作为候选业务模型。

在一个实施例中，模型融合模块1102，还用于对反馈数据进行预处理；根据预处理后的反馈数据，对组合模型进行迭代更新，直到组合模型的更新次数与预设次数相同；将最后一次更新后的组合模型，作为候选业务模型。

在一个实施例中，模型验证模块1103，还用于获取候选业务模型的预设检测条件；预设检测条件用于检测候选业务模型的模型性能；根据需求用例模型，验证候选业务模型是否满足预设检测条件；在候选业务模型满足预设检测条件的情况下，确认候选业务模型验证通过。

在一个实施例中，模型验证模块1103，还用于在候选业务模型不满足预设检测条件的情况下，确认候选业务模型中不满足预设检测条件的目标子业务模型；利用需求用例模型对候选业务模型中的目标子业务模型进行更新，直到更新后的候选业务模型满足预设检测条件。

在一个实施例中，业务需求分析装置还包括模型更新模块，用于在原始业务需求信息更新的情况下，根据更新后的业务需求信息，从目标业务模型中确认出待更新的子业务模型；根据更新后的业务需求信息，对目标业务模型中的待更新的子业务模型进行更新，得到目标业务模型的更新后业务模型。

在一个实施例中，模型构建模块1101，还用于对原始业务需求信息进行分类处理，得到子原始业务需求信息；子原始业务需求信息至少包括流程模型信息、实体模型信息和产品模型信息；构建与流程模型信息对应的模型，作为流程模型，构建与实体模型信息对应的模型，作为实体模型，以及构建与产品模型信息对应的模型，作为产品模型；基于原始业务需求信息，构建用于补充流程模型、实体模型和产品模型的模型，作为要素模型。

上述业务需求分析装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图12所示。该计算机设备包括处理器、存储器、输入/输出接口、通信接口、显示单元和输入装置。其中，处理器、存储器和输入/输出接口通过系统总线连接，通信接口、显示单元和输入装置通过输入/输出接口连接到系统总线。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的输入/输出接口用于处理器与外部设备之间交换信息。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、移动蜂窝网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种业务需求分析方法。该计算机设备的显示单元用于形成视觉可见的画面，可以是显示屏、投影装置或虚拟现实成像装置。显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图12中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：

获取待分析业务的原始业务需求信息，根据原始业务需求信息，构建待分析业务的子业务模型；子业务模型至少包括流程模型、实体模型、产品模型和要素模型；

在流程模型、实体模型、产品模型和要素模型达到预设交互状态的情况下，将流程模型、实体模型、产品模型和要素模型进行融合处理，得到待分析业务的候选业务模型；

根据待分析业务的需求用例模型，对候选业务模型进行验证；需求用例模型根据原始业务需求信息构建得到；

在候选业务模型验证通过的情况下，将候选业务模型确认为待分析业务的目标业务模型。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：将流程模型、实体模型、产品模型和要素模型进行模型对接处理，得到组合模型；组合模型为完整闭环链路的模型；获取组合模型的反馈数据；根据反馈数据对组合模型进行更新，得到更新后的组合模型，作为候选业务模型。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：对反馈数据进行预处理；根据预处理后的反馈数据，对组合模型进行迭代更新，直到组合模型的更新次数与预设次数相同；将最后一次更新后的组合模型，作为候选业务模型。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：获取候选业务模型的预设检测条件；预设检测条件用于检测候选业务模型的模型性能；根据需求用例模型，验证候选业务模型是否满足预设检测条件；在候选业务模型满足预设检测条件的情况下，确认候选业务模型验证通过。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：在候选业务模型不满足预设检测条件的情况下，确认候选业务模型中不满足预设检测条件的目标子业务模型；利用需求用例模型对候选业务模型中的目标子业务模型进行更新，直到更新后的候选业务模型满足预设检测条件。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：在原始业务需求信息更新的情况下，根据更新后的业务需求信息，从目标业务模型中确认出待更新的子业务模型；根据更新后的业务需求信息，对目标业务模型中的待更新的子业务模型进行更新，得到目标业务模型的更新后业务模型。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：对原始业务需求信息进行分类处理，得到子原始业务需求信息；子原始业务需求信息至少包括流程模型信息、实体模型信息和产品模型信息；构建与流程模型信息对应的模型，作为流程模型，构建与实体模型信息对应的模型，作为实体模型，以及构建与产品模型信息对应的模型，作为产品模型；基于原始业务需求信息，构建用于补充流程模型、实体模型和产品模型的模型，作为要素模型。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (11)

1.一种业务需求分析方法，其特征在于，所述方法包括：

获取待分析业务的原始业务需求信息，根据所述原始业务需求信息，构建所述待分析业务的子业务模型；所述子业务模型至少包括流程模型、实体模型、产品模型和要素模型；

在所述流程模型、所述实体模型、所述产品模型和所述要素模型达到预设交互状态的情况下，将所述流程模型、所述实体模型、所述产品模型和所述要素模型进行融合处理，得到所述待分析业务的候选业务模型；

根据所述待分析业务的需求用例模型，对所述候选业务模型进行验证；所述需求用例模型根据所述原始业务需求信息构建得到；

在所述候选业务模型验证通过的情况下，将所述候选业务模型确认为所述待分析业务的目标业务模型；所述目标业务模型用于描述所述原始业务需求信息。

2.根据权利要求1所述的方法，其特征在于，所述将所述流程模型、所述实体模型、所述产品模型和所述要素模型进行融合处理，得到所述待分析业务的候选业务模型，包括：

将所述流程模型、所述实体模型、所述产品模型和所述要素模型进行模型对接处理，得到组合模型；所述组合模型为完整闭环链路的模型；

获取所述组合模型的反馈数据；

根据所述反馈数据对所述组合模型进行更新，得到更新后的组合模型，作为所述候选业务模型。

3.根据权利要求2所述的方法，其特征在于，所述根据所述反馈数据对所述组合模型进行更新，得到更新后的组合模型，作为所述候选业务模型，包括：

对所述反馈数据进行预处理；

根据预处理后的反馈数据，对所述组合模型进行迭代更新，直到所述组合模型的更新次数与预设次数相同；

将最后一次更新后的组合模型，作为所述候选业务模型。

4.根据权利要求1所述的方法，其特征在于，所述根据所述待分析业务的需求用例模型，对所述候选业务模型进行验证，包括：

获取所述候选业务模型的预设检测条件；所述预设检测条件用于检测所述候选业务模型的模型性能；

根据所述需求用例模型，验证所述候选业务模型是否满足所述预设检测条件；

在所述候选业务模型满足所述预设检测条件的情况下，确认所述候选业务模型验证通过。

5.根据权利要求4所述的方法，其特征在于，在根据所述需求用例模型，验证所述候选业务模型是否满足所述预设检测条件之后，还包括：

在所述候选业务模型不满足所述预设检测条件的情况下，确认所述候选业务模型中不满足所述预设检测条件的目标子业务模型；

利用所述需求用例模型对所述候选业务模型中的目标子业务模型进行更新，直到更新后的候选业务模型满足所述预设检测条件。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述原始业务需求信息更新的情况下，根据更新后的业务需求信息，从所述目标业务模型中确认出待更新的子业务模型；

根据所述更新后的业务需求信息，对所述目标业务模型中的待更新的子业务模型进行更新，得到所述目标业务模型的更新后业务模型。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述根据所述原始业务需求信息，构建所述待分析业务的子业务模型，包括：

对所述原始业务需求信息进行分类处理，得到子原始业务需求信息；所述子原始业务需求信息至少包括流程模型信息、实体模型信息和产品模型信息；

构建与所述流程模型信息对应的模型，作为所述流程模型，构建与所述实体模型信息对应的模型，作为所述实体模型，以及构建与所述产品模型信息对应的模型，作为所述产品模型；

基于所述原始业务需求信息，构建用于补充所述流程模型、所述实体模型和所述产品模型的模型，作为所述要素模型。

8.一种业务需求分析装置，其特征在于，所述装置包括：

模型构建模块，用于获取待分析业务的原始业务需求信息，根据所述原始业务需求信息，构建所述待分析业务的子业务模型；所述子业务模型至少包括流程模型、实体模型、产品模型和要素模型；

模型融合模块，用于在所述流程模型、所述实体模型、所述产品模型和所述要素模型达到预设交互状态的情况下，将所述流程模型、所述实体模型、所述产品模型和所述要素模型进行融合处理，得到所述待分析业务的候选业务模型；

模型验证模块，用于根据所述待分析业务的需求用例模型，对所述候选业务模型进行验证；所述需求用例模型根据所述原始业务需求信息构建得到；

模型确认模块，在所述候选业务模型验证通过的情况下，将所述候选业务模型确认为所述待分析业务的目标业务模型；所述目标业务模型用于描述所述原始业务需求信息。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述的方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。

11.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。