Iterative Requirements-Driven Business Process Modeling and Verification with Large Language Models

Abstract

Contemporary business process modeling lacks a systematic framework for converting unstructured requirements into structured models. Traditional manual approaches fail to support integrated lifecycle management from requirements elicitation to iterative model refinement. The gap severely limits the efficiency and accuracy of the alignment between requirements and business process modeling and often leads to costly rework and implementation errors in complex software projects. Therefore, this paper aims to establish a coherent modeling framework from requirements extraction to business process model verification. The framework maintains the traceability and consistency of the unstructured requirements through three tasks: (1) automatic generation of a structured requirements model from textual input to a set of designed prompts of hyperparameter-optimized large language models (LLMs); (2) establishment of a modeling routine to handle the iterative requirements via two sets of formalized mapping rules, a merging algorithm, and a toolkit; (3) detection of the obtained CBPMN model by a static flow error verification algorithm and reachability verification using CPN tools 4.0. A total of 15 sets of comparative experiments with three state-of-the-art automated modeling approaches demonstrate the superiority of our method in generating higher-quality requirements models, while an additional case study with two-step verification proves its validity.

1. Introduction

A business process, defined as a series of interrelated activities within or between organizations, is fundamental to organizational value creation: precise business process models enable data-driven optimization and iterative improvement to meet evolving customer demands [1]. However, a persistent methodological challenge lies in the significant semantic gap between informal stakeholder needs and formal verifiable process specifications, which often leads to information loss and deviation during model construction [2]. This gap is rooted in the traditional labor-intensive paradigm of requirements engineering, which struggles with the ambiguity of natural language and the dynamic nature of business requirements [3].

The confirmation of requirements is not as simple as generating a conceptual model from a prepared document; it involves a complete framework containing requirements collection and modeling, an execution carrier for the requirements structure, verification of the execution model, and a systematic approach that integrates all of these components. However, an efficient professional modeling method comes from long-term learning, logical sorting, and accumulation of knowledge in a certain field, which hinders the automation of the general construction of complex requirements in business process modeling [4,5]. Meanwhile, changing markets impose consequent requirements for incremental improvements to the business process model [6]. Therefore, researchers are looking for solutions to construct an iterative process model with complexity and relative stability to address the dynamic changes in requirements.

Studies to bridge this gap have evolved along two primary directions. On the one hand, agile and iterative methodologies focus on enhancing the adaptability of business process models to changing requirements [7,8,9,10,11]. While effective in keeping up with requirements evolution, these approaches typically presuppose the existence of an initial correct model, offering limited guidance on its systematic derivation from ambiguous initial requirements. On the other hand, general requirements engineering (RE) advances provide powerful domain-agnostic patterns for requirements handling and formal specifications, but the automated synthesis of executable business process models imposes unique constraints. These include the need to explicitly capture multidimensional perspectives, hierarchical decomposition, complex execution semantics, and the integration of multiple stakeholder views into a single, logically coherent, and executable workflow model [12]. Existing LLM-for-RE approaches, while proficient in generating isolated artefacts like UML class diagrams or code snippets, often lack the domain-specific formalization mechanism to guarantee the structural integrity, behavioral consistency, and executability of synthesized business process models. Conversely, dedicated formalized process modeling approaches, such as BPMN or Petri nets, offer the necessary semantic precision but are disconnected from integrating automation and requirements-driven synthesis.

In response to this trend, the Problem Frames (PFs) method proposed by Mickle Jackson focuses on the interaction between a system and its environment, modeling software based on realistic requirements [13]. The PFs method divides the system into three parts: requirements, the problem domain (PD), and the machine domain. Requirements and the PD are linked by requirement phenomena, while the PD and the machine domain are connected by shared phenomena, as shown in Figure 1.

Figure 1. Problem diagram in the problem frames method.

Requirements are derived from reality and depicted by context diagrams. The PD and machine domain, collectively called “the domain,” are split into internal behavior and external phenomena. Internal behavior refers to the domain’s structure and actions, whereas external phenomena represent the direct interface that selectively transmits information. Shared phenomena occur at the interface between the problem and machine domains, while requirement phenomena link the problem domain with requirements [14].

However, the weakness of PFs is that both the analysis process and the decomposition process of the problem need to be completed manually, which calls for expert experience and the accumulation of knowledge in specific fields. Meanwhile, large language models trained with large amounts of data and corpuses can generally understand human language to a certain extent and output answers depending on the quality of prompts. Therefore, in order to reduce the burden of both the providers and analysts in the process of requirements acquisition, this paper combines PFs with prompt engineering, introducing multiple agents with their own roles to replace the work of requirements providers and analysts. Then, the obtained requirements models are transformed into a set of business process models through transformation rules with matrix computations. The business process model is verified through three layers of verification and simulated by the corresponding colored Petri net (CPN).

Therefore, a pivotal challenge has evolved: the key issue is no longer the automation of requirements elicitation but rather the absence of a formal theoretical bridge that must connect the acquired requirements with executable process models. To construct this bridge, an effective integrated framework must encompass three key capabilities: (1) providing a well-defined requirements model to serve as a consistent target structure for semi-automated parsing tools; (2) establishing a set of formal mapping and transformation rules to ensure semantic fidelity throughout the chain from the requirements model to business process models and further to executable models; and (3) incorporating model integration and verification algorithms to maintain correctness in complex multi-source requirements scenarios.

To address the three challenges above, this study proposes an integrated framework centered on a formal requirement analysis model, combining prompt engineering with formal methods. The specific research objectives are as follows:

(1)

To design a structured problem frames-based model (PFM) and automate the generation of its instances from natural language text using optimized LLM prompt strategies.

(2)

To verify the feasibility and semantic consistency of PFM by establishing formal mapping rules to a requirement business process model (RBPMN) and an executable colored Petri net (CPN) model.

(3)

To ensure the logical correctness of the integrated models by developing algorithms to merge multiple RBPMN models and to detect flow errors in the resulting collaboration BPMN (CBPMN) model.

The remainder of this paper is structured as follows. Section 2 reviews the related work in requirements acquisition and business process modeling. Section 3 introduces the problem frames model (PFM) and formally defines the requirement business process modeling notation (RBPMN), collaboration business process modeling notation (CBPMN), and colored Petri net (CPN) models, collectively forming the PRBC modeling approach. Section 4 proposes an iterative business process modeling methodology, detailing a three-stage process of requirement collection and modeling, mapping requirements to business process models, and model verification and iteration. Section 5 evaluates the quality of prompts for requirements modeling and illustrates the end-to-end modeling process—from natural language requirements to an executable business process model—using a case study of a car-hailing system. Finally, Section 6 concludes the paper and outlines directions for future research.

2. Related Work

To support the business process modeling of iterative requirements, there are three aspects that are worth exploring: requirement elicitation, requirement modeling, and business process modeling and simulation [15].

Requirements elicitation is the process of abstracting and arranging requirement elements from the natural language requirement descriptions using various tools, while LLMs and natural language processing (NLP) have a strong relationship with the automation of requirement elicitation. As a bridge between requirements engineering and process management, business process modeling should conquer the high-fidelity transformation challenge from requirements to business process models, while the advent of LLMs introduces a possible solution for efficient process modeling.

Traditional requirements modeling typically involves manual requirements analysis, where requirements are gathered through questionnaires, interviews, comment analysis, and other methods. After multiple rounds of discussions among user representatives, software project leaders, review experts, and domain experts, requirement descriptions are finalized into formalized models [16,17]. In terms of requirements elicitation, most frameworks incorporate advanced techniques such as machine learning, prompt engineering, as well as NLP, transforming complex requirements into formalized models. For instance, Ruan et al. presented an automated framework that incorporates zero-shot learning based on GPT 3.5 by designing an appropriate prompt to extract a requirement model from requirement texts by employing composition rules [18]. Similarly, Liu et al. created a domain-specific modeling language, constrained natural language input via grammar rules, and established an automatic transformation mechanism to map textual requirements to a state machine model [19]. Additionally, Yilmaz Uygun et al. proposed a Local GPT Q&A retrieval solution aimed at simplifying the requirements analysis process [20].

However, the existing methods face significant limitations. The reliance on rigid syntactic rules, as demonstrated in the work of Liu et al., restricts flexibility in handling vague or evolving requirements. Additionally, document-based modeling approaches often suffer from cross-language semantic inconsistencies, a problem exacerbated by temporal and regional variations that undermine the accuracy of the requirements.

After requirement elicitation, a formalized requirement model is necessary to provide sufficient conditions for business process simulation and verification, thereby improving the quality and efficiency of software performance testing [21]. Focusing on the application development driven by machine learning, Yang et al. [22] developed a metamodel framework based on state machine extensions to enable hierarchical expression and constraint verification of complex system requirements by enhancing UML modeling capabilities. In the field of model-driven systems engineering, P. Gu et al. [23] created an automated requirement link tracking mechanism that integrates the SysML modeling language with formal verification technology, forming a comprehensive solution that covers the entire requirements lifecycle. Additionally, to lower the barrier to formal verification for system engineers, V. Besnard et al. [24] proposed an approach that interprets UML state machines as executable observer automata for model-checking and runtime monitoring. They evaluated the method on multiple case studies, demonstrating through a cruise-control system example that it produces verification results consistent with traditional LTL checking, monitoring the overhead scaling linearly. Research in requirements modeling shows that formalized requirement models promote the development of requirements engineering from the aspects of machine learning system modeling, requirements traceability management, and formal verification [25].

As for formalizing business process models and their simulation and verification, Flavio Corradini et al. proposed BProVe, a novel verification method combining both standard model checking techniques and statistical model checking techniques for BPMN collaborations, to address the state–space explosion problem in BPMN [26]. Similarly, C. Dechsupa Chanon et al. presented a formal definition for BPMN and mapped the decomposed process models to CPN models through partitioned functions, enabling executable tests via CPN models [27]. Additionally, Long Cheng et al. mined dependencies among tasks from event logs by combining various graph structure models to build a mixed process model [28]; however, the semantics of some activities in the business process models obtained through the above method of Cheng remained unclear. For the semantic specification and formalization of BPMN, Flavio Corradini et al. defined the execution semantics of BPMN elements and proposed that a formal BPMN model should satisfy three important properties, namely, well-formability, safety, and soundness [29].

In the field of business process modeling from the requirements perspective, activities such as requirements elicitation, requirements modeling, and formal business process transformation are often confined to their respective research fields. For instance, large language models are commonly used in requirements elicitation and analysis, and BPMN, CPN, and other modeling standards are used in business process modeling and verification. This separation hinders the ability to achieve consistent business process modeling that seamlessly spans the transformation from requirements to business processes [30,31,32].

This paper aims to bridge the gap between static business process modeling frameworks for requirements and the implementation of dynamic evolution verification technologies applied to business process modeling for iterative requirements.

3. PRBC Modeling Approach

Before introducing the problem framework business process iterative modeling method, we present a PRBC modeling approach to establish a set of interconvertible models from requirements to a business process executable model.

3.1. PFM Model, RBPMN Model, CBPMN Model, and Model Formalization

To build a complete and consistent business process model from the requirement level, we need to specify its languages and the formalism needed for the definition.

To make the transformation process more clearly understood from the requirements to business process models, we define the PFM model, a refined formalized model based on the problem diagram concept of problem frames. The PFM model is proposed for analysts to draw out details before the business process models are built. The common elements of the PFM model are shown in Table 1. As shown in Definition 1, the core subset of BPMN elements is divided into six groups: the requirements set (Re), the requirement phenomenon (RPh), the shared phenomenon (SPh), the problem domain (PD), the variables set (V), and the relationships among them (${\mathrm{f}}_{\mathrm{M}}$).

Table 1. Common elements in PFM.

PFM Model Elements
Re		V
RPh		SPh
PD
${\mathrm{f}}_{\mathrm{M}}$

Definition 1. 

Problem frames model (PFM):

A problem frames model is a tuple, in which

$$\mathrm{P}\mathrm{F}\mathrm{M}=(\mathrm{R}\mathrm{e},\mathrm{P}\mathrm{D},\mathrm{R}\mathrm{P}\mathrm{h},\mathrm{S}\mathrm{P}\mathrm{h},\mathrm{V},{\mathrm{f}}_{\mathrm{M}}),$$

(1)

where

(1)

The PFM is a problem frames model composed of at least one sub-problem model ${\mathrm{P}\mathrm{F}\mathrm{M}}_{\mathrm{i}}$. Each sub-problem model contains one requirement; the relationship between ${\mathrm{P}\mathrm{F}\mathrm{M}}_{\mathrm{i}} and {\mathrm{P}\mathrm{F}\mathrm{M}}_{\mathrm{j}}$ can be described by $f_{R\left(ij\right)}$,

$${\mathrm{P}\mathrm{F}\mathrm{M}}_{\mathrm{i}}=({\mathrm{R}\mathrm{e}}_{\mathrm{i}},{\mathrm{P}\mathrm{D}}_{\mathrm{S}},{\mathrm{R}\mathrm{P}\mathrm{h}}_{\mathrm{S}},{\mathrm{S}\mathrm{P}\mathrm{h}}_{\mathrm{S}},{\mathrm{V}}_{\mathrm{S}},{{\mathrm{f}}_{\mathrm{M}}}_{\mathrm{S}}), X_S\subseteq X, \mathrm{X}=\mathrm{P}\mathrm{D},\mathrm{R}\mathrm{P}\mathrm{h},\mathrm{S}\mathrm{P}\mathrm{h},\mathrm{V},{\mathrm{f}}_{\mathrm{M}};$$

(2)

$$\mathrm{P}\mathrm{F}\mathrm{M}={\sum }_{\mathrm{i}=1}^{\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}\left(\mathrm{R}\mathrm{e}\right)}{\mathrm{P}\mathrm{F}\mathrm{M}}_{\mathrm{i}}\cup {\sum }_{\mathrm{j}=\mathrm{i}+1}^{\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}\left(\mathrm{R}\mathrm{e}\right)}{f}_{R\left(ij\right)}.$$

Additionally, since the problem frame does not involve the specific realization of software programming and mechanics, the machine domain will be omitted in the modeling process.

(2)

The PD is the finite set of problem domains, most of which are presented in the form of entities and their interrelations; the number of PD is no less than one:

$$\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}\left(\mathrm{P}\mathrm{D}\right)\ge 1.$$

(3)

(3)

The SPh is the shared phenomenon between PDs, represented by data item DI. DI is an infinite set denoting the type of data,${ \forall \mathrm{s}\mathrm{p}\mathrm{h}}_{\mathrm{i}}\in \mathrm{S}\mathrm{P}\mathrm{h},\exists {\mathrm{D}\mathrm{I}}_{\mathrm{S}}\subseteq \mathrm{D}\mathrm{I},\mathrm{s}\mathrm{t}:{\mathrm{s}\mathrm{p}\mathrm{h}}_{\mathrm{i}}={\mathrm{D}\mathrm{I}}_{\mathrm{S}}$

(4)

The RPh is the requirement phenomenon, decomposing the requirements expectations into a series of task list. The sequence series of RPh in and among PDs are shown as a partially ordered set $\mathrm{Q}$, $\mathrm{Q}=\mathrm{R}\mathrm{P}\mathrm{h}\times \dots \times \mathrm{R}\mathrm{P}\mathrm{h}$, and for $\forall \mathrm{i}\ne \mathrm{j}, q_{ij}={\mathrm{r}\mathrm{p}\mathrm{h}}_{\mathrm{i}}\times \dots \times {\mathrm{r}\mathrm{p}\mathrm{h}}_{\mathrm{j}}\in \mathrm{Q},d\left(q_{ij}\right)$ is the type of $q_{ij}$ in the directed acyclic relationship set Q of RPh; while ${\mathrm{r}\mathrm{p}\mathrm{h}}_{\mathrm{i}}\in q_x, {\mathrm{r}\mathrm{p}\mathrm{h}}_{\mathrm{j}}\in q_y and \{q_x, q_y\}\subseteq Q$

$${d(q}_{ij})=\left\{\begin{array}{c}parallel, if for \forall q_x\subset q\in Q, q_y\subset q;\\ exclusive, if for \forall q_x\subseteq q\in Q, q_y\not\subset q ;\\ sequential, if {\mathrm{r}\mathrm{p}\mathrm{h}}_{\mathrm{i}} \prec {\mathrm{r}\mathrm{p}\mathrm{h}}_{\mathrm{j}};\\ 0, otherwise.\end{array}\right.$$

For the relation between ${\mathrm{P}\mathrm{F}\mathrm{M}}_{\mathrm{i}}$ and ${\mathrm{P}\mathrm{F}\mathrm{M}}_{\mathrm{j}}$, $Q_x={\complement }_{Q_i\cup Q_j}( Q_i\cap Q_j)$, $\{Q_i,Q_j\}\subseteq Q$, and $Q_k\subset {PFM}_k (k=i,j$),

$$\mathrm{d}{f}_{R\left(ij\right)}=\left\{\begin{array}{c}1, if Q_i\cap Q_x\ne \varnothing \ne Q_j\cap Q_x, and (Q_i\cap Q_x)\cup (Q_j\cap Q_x)\subseteq Q;\\ 1, if {\varnothing \ne (Q}_x\cap Q_i)\subseteq Q, and (Q_x\cap Q_j)\cap Q=\varnothing ;\\ 1, if \forall q_x\in Q_i,q_y\in Q_j, q_x\prec q_y;\\ 0, otherwise.\end{array}\right.$$

(5)

Re is the requirement set, which is a union of requirements; the set Re can be described as a vector composed of requirements in sub-problems:

$$\mathrm{R}\mathrm{e}=({\mathrm{R}\mathrm{e}}_1,{\mathrm{R}\mathrm{e}}_2, \dots , {\mathrm{R}\mathrm{e}}_{\mathrm{m}}), m=card\left(Re\right).$$

(4)

(6)

${\mathrm{f}}_{\mathrm{M}}$ indicates a set of mapping functions, ${\mathrm{f}}_{\mathrm{M}}=\{{\mathrm{f}}_{\mathrm{R}\mathrm{P}},{\mathrm{f}}_{\mathrm{P}\mathrm{R}\mathrm{h}},{\mathrm{f}}_{\mathrm{R}\mathrm{h}\mathrm{S}},{\mathrm{f}}_{\mathrm{S}\mathrm{h}\mathrm{V}}$}, where ${\mathrm{f}}_{\mathrm{R}\mathrm{P}}$ denotes the mapping function indicating the requirement executor link from Re to the related PD, ${\mathrm{f}}_{\mathrm{R}\mathrm{P}}:\mathrm{R}\mathrm{e}\to \mathrm{P}\mathrm{D}$; ${\mathrm{f}}_{\mathrm{P}\mathrm{R}\mathrm{h}}$ denotes the mapping function indicating a task list relationship from the set of PD to RPh, ${\mathrm{f}}_{\mathrm{P}\mathrm{R}\mathrm{h}}:\mathrm{P}\mathrm{D}\to \mathrm{R}\mathrm{P}\mathrm{h}$; ${\mathrm{f}}_{\mathrm{R}\mathrm{h}\mathrm{S}}$ denotes the mapping function indicating the data item of every task list, ${\mathrm{f}}_{\mathrm{R}\mathrm{h}\mathrm{S}}:\mathrm{R}\mathrm{P}\mathrm{h}\to \mathrm{S}\mathrm{P}$h; ${\mathrm{f}}_{\mathrm{S}\mathrm{h}\mathrm{V}}$ denotes the mapping function indicating the variables of data items in SPh, ${\mathrm{f}}_{\mathrm{S}\mathrm{h}\mathrm{V}}:\mathrm{S}\mathrm{P}\mathrm{h}\to \mathrm{V}$.

(7)

V is a finite set of variables that denotes the data terms in SPh; for ${\mathrm{s}\mathrm{p}\mathrm{h}}_{\mathrm{i}}\in \mathrm{S}\mathrm{P}\mathrm{h},$there is one and only one ${\mathrm{D}\mathrm{I}}_{\mathrm{S}}\subseteq V$, st: $\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}{[V}_x]={\mathrm{D}\mathrm{I}}_{\mathrm{S}}$.

An example of a sub-problem model in the PFM model is shown in Figure 2.

Figure 2. An example of one sub-problem model ${\mathrm{P}\mathrm{F}\mathrm{M}}_1$ in PFM model.

Business process modeling notation (BPMN) contains the top five most frequently used elements in a business process meta-model [33], including events, data, activities, pools and lanes, and sequence flows. Next, this section presents the RBPMN model and the CBPMN model as the execution carrier of the requirements analysis model PFM. The CBPMN model consists of a set of RBPMN models in accordance with the BPMN 2.0 standard [34]. The relationships between PFM, RBPMN, and CBPMN will be established in Section 4.2.

Definition 2. 

RBPMN model.

The RBPMN model is a piece of mapping converted directly from a sub-problem model ${PFM}_i$ of the PFM model, which can be denoted as a tuple, RBPMN = (E, PL, D, M, In, A, F), where

(1)

E is the set of events, in which

$$\mathrm{E}=E_S\cup { E}_M\cup E_E,$$

(5)

$$\mathrm{E}=\left\{{\mathrm{e}}_{\mathrm{i}}\right\},\mathrm{i}=(1,\dots ,\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}(\mathrm{E}\left)\right).$$

(6)

① $E_S$ indicates the set of start events,

$$\forall e_s\in E_S,\left|in\left(e_s\right)\right|=0\wedge \left|out\left(e_s\right)\right|=1.$$

(7)

②${ E}_M$ indicates the set of intermediate events,

$$\forall e_m\in E_M,\left|in\left(e_m\right)\right|=1\wedge \left|out\left(e_m\right)\right|=1.$$

(8)

③ $E_E$ indicates the set of end events,

$$\forall e_e\in E_E,\left|in\left(e_e\right)\right|=1\wedge \left|out\left(e_e\right)\right|=0.$$

(9)

④ There are also other types of event classifications, but all the events in RBPMN can be divided by the location; that is, the event set E consists of a starting event set, an intermediate event set, and an ending event set, which can be written as

$$E=(E_S\cup E_M\cup E_E)\wedge E_S\cap E_M\cap E_E=\varnothing .$$

(10)

(2)

PL represents a set of pools and lanes, while a lane refers to the different individuals contained in a pool, and there is at least one pool in a lane,

$${\mathrm{P}\mathrm{L}}_{\mathrm{k}}\in \mathrm{P}\mathrm{L},\mathrm{k}=(1,\dots ,\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}(\mathrm{P}\mathrm{L}\left)\right),$$

(11)

$$\mathrm{L}\subseteq \mathrm{P}\mathrm{L} \& \mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}\left(\mathrm{L}\right)\ge 1.$$

(12)

(3)

D is a set of data that indicates information transfer in a pool,

$$\mathrm{D}=\left\{{\mathrm{d}}_{\mathrm{i}}\right\},$$

(13)

$$\mathrm{i}=(0,\dots ,\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}(\mathrm{D}\left)\right).$$

(14)

(4)

M is a set of messages that indicates information transfer between or among pools,

$$\mathrm{M}=\left\{{\mathrm{m}}_{\mathrm{i}}\right\},$$

(15)

$$\mathrm{i}=(0,\dots ,\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}(\mathrm{M}\left)\right).$$

(16)

(5)

In is a set of functions, $In:\mathrm{v}\mathrm{a}\mathrm{r}\mathrm{i}\mathrm{a}\mathrm{b}\mathrm{l}\mathrm{e}\mathrm{s}\to \mathrm{v}\mathrm{a}\mathrm{l}\mathrm{u}\mathrm{e}$, and its expression is as follows:

$$In\left(\mathrm{a}\right)=c,$$

(17)

which means “$variable$ a values c”, and c belongs to data types.

$$a\in (D\cup M),$$

(18)

$$D\cap M=\varnothing .$$

(19)

(6)

A represents a finite set of activities,

$$A=\{a_1,a_2,\dots \},\forall a_i\in \mathrm{A},a_i=({\mathrm{a}}_{name},{\mathrm{a}}_{\mathrm{a}\mathrm{t}\mathrm{t}\mathrm{i}\mathrm{b}},a_{\mathrm{o}\mathrm{p}\mathrm{e}\mathrm{r}}).$$

(20)

$a_{name}$ represents the unique identifier of the activities$, {\mathrm{a}}_{\mathrm{a}\mathrm{t}\mathrm{t}\mathrm{i}\mathrm{b}}$ indicates the attribution of the activity, and $a_{\mathrm{o}\mathrm{p}\mathrm{e}\mathrm{r}}$ indicates what the activity does to the related information, $a_{\mathrm{o}\mathrm{p}\mathrm{e}\mathrm{r}}:{In}_v\left(\mathrm{a}\right)\to {In\prime }_v\left(\mathrm{a}\right)$; while the value of In is changed,

$$a_{\mathrm{o}\mathrm{p}\mathrm{e}\mathrm{r}}=\mathrm{\varnothing }.$$

(21)

(7)

F stands for the connected arc set, and

$$\mathrm{F}\subseteq \left(\right(\mathrm{E}\cup \mathrm{A}\cup \mathrm{D}\cup \mathrm{M})\times (\mathrm{E}\cup \mathrm{A}\cup \mathrm{D}\cup \mathrm{M}\left)\right)\cup (\mathrm{P}\mathrm{L}\times (\mathrm{E}\cup \mathrm{A}\cup \mathrm{D}\cup \mathrm{M}\left)\right).$$

(22)

${\mathrm{F}}_{\mathrm{C}}$ represents the control flow arc set, ${\mathrm{F}}_{\mathrm{C}}:\left\{\mathrm{E}\cup \mathrm{A}\right\}\to \left\{\mathrm{E}\cup \mathrm{A}\right\}; {\mathrm{F}}_{\mathrm{D}}$ denotes the data stream arc set, ${\mathrm{F}}_{\mathrm{D}}:(\mathrm{D}\cup \mathrm{M})\to (\mathrm{E}\cup \mathrm{A})$; $f_{PN}$:$\mathrm{P}\mathrm{L}\to (\mathrm{E}\cup \mathrm{A}\cup \mathrm{D}\cup \mathrm{M})$ stands for the containing relationships between $\mathrm{P}\mathrm{L}$ and flow element; and

$$\mathrm{F}={\mathrm{F}}_{\mathrm{C}}\cup {\mathrm{F}}_{\mathrm{D}}\cup f_{PN},$$

(23)

$${\mathrm{F}}_{\mathrm{C}}\cap {\mathrm{F}}_{\mathrm{D}}=\varnothing =f_{PN}\cap ({\mathrm{F}}_{\mathrm{C}}\cup {\mathrm{F}}_{\mathrm{D}}).$$

(24)

Definition 3. 

BPMN collaboration model (CBPMN):

The BPMN collaboration model is a tuple, in which

$$\mathrm{C}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}=(\mathrm{G},f_C,R{BPMN}_M),$$

(25)

where

(1)

${RBPMN}_M$ represents an RBPMN model, ${RBPMN}_M=({\mathrm{E}}_{\mathrm{R}\mathrm{M}},{\mathrm{P}\mathrm{L}}_{\mathrm{M}},{\mathrm{D}}_{\mathrm{M}},{\mathrm{M}}_{\mathrm{M}},{\mathrm{I}\mathrm{n}}_{\mathrm{M}},{\mathrm{A}}_{\mathrm{M}},{\mathrm{F}}_{\mathrm{M}})$, ${\mathrm{F}}_{\mathrm{M}}={\mathrm{F}}_{\mathrm{C}\mathrm{M}}\cup {\mathrm{F}}_{\mathrm{D}\mathrm{M}}\cup f_{PNM}$, and ${RBPMN}_{MS}$ is the subset of the ${RBPMN}_M$ model.

(2)

G is a set of gateways,

$$G=(G_{PF}\cup G_{PC}\cup G_{XF}\cup G_{XC}),$$

(26)

$$(G_{P\text{\_}}\cap G_{X\text{\_}}=\varnothing ),$$

(27)

$$(G_{-F}\cap G_{-C}=\varnothing ),$$

(28)

where $G_{P\text{\_}}$ denotes the set of parallel gateways, $G_{X\text{\_}}$ denotes the set of exclusive gateways.

① $G_{-F}$ denotes the set of divergent control flow gateways,

$$\forall g\in G_{-\mathrm{F}},\left|in\left(g\right)\right|=1\wedge \left|out\left(g\right)\right|>1.$$

(29)

② $G_{-C}$ denotes the set of convergent control flow gateways,

$$\forall g\in G_{-\mathrm{C}},\left|in\left(g\right)\right|>1\wedge \left|out\left(g\right)\right|=1.$$

(30)

(3)

$f_C$ represents a set of mapping functions in CBPMN, in which

$$f_C=\{f_{Rs},f_{GT}\},$$

(31)

where

① $f_{Rs}$ indicates the traceable mapping from set ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{S}}$ to ${RBPMN}_M$, $f_{Rs}:({\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{S}}\times { f}_R)\to {RBPMN}_M$, where ${RBPMN}_S$ is a set of ${RBPMN}_S$ models, ${ f}_R$ is a vector denoting the relationship from ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_i$ to ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_j$ in ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{S}}$, ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{S}}=\{{\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_1,{\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_2,\dots ,{\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{card\left({RBPMN}_S\right)}\}$, and${ f}_R:({\mathrm{P}\mathrm{F}\mathrm{M}}_{\mathrm{S}}\times f_M\times { f}_{R\left(ij\right)})\to {RBPMN}_{\mathrm{S}}$.

② $f_{GT}=\{f_{GT1}, f_{GT2}, \dots , f_{GTm}\}$ represents the gateway pattern, containing the selection of flow direction and the diversion conditions (divergent or convergent and parallel or exclusive type of gateway). Every element of $f_{GT}$ is composed of a two-tuple $f_{GTi}=\left(direction, condition\right)$, where the direction illustrates the change in the flow number, and condition indicates the conditional marking function to choose the next node; $f_{GT}:G\to \{PF, PC, XF, XC\}$.

The CPN model is an executable model for sequential and concurrent systems. As an advanced Petri net, it has mathematical characteristics like reachability and liveness, permitting rigorous quantitative analysis, while its graphical expression makes it easy to understand, and it can model and simulate the system with an initial state; therefore, the CPN model is often used for checking whether the business process model design meets the expected requirements.

Definition 4. 

Colored Petri Net [35]:

A CPN model is a tuple,

$$\mathrm{C}\mathrm{P}\mathrm{N}=(\mathrm{P},\mathrm{T},\mathrm{A}\mathrm{r}\mathrm{c},\sum ,\mathrm{V},f,\mathrm{I}),$$

(32)

where

(1)

P is a finite set of places, which possess a kind of resource and tokens in a data warehouse waiting for the signal to “move”.

(2)

T is a finite set of transitions, which indicate a change in state or the occurrence of an event:

$$P\cap T\ne \varnothing .$$

(33)

(3)

Arc is a finite set of directed arcs,

$$\mathrm{P}\cap \mathrm{A}\mathrm{r}\mathrm{c}=\mathrm{A}\mathrm{r}\mathrm{c}\cap \mathrm{T}=\mathrm{Ø}.$$

(34)

(4)

$f_E$ is an arc expression function, and $f_E:\mathrm{A}\mathrm{r}\mathrm{c}\to expression$, written as $f_E\left(\mathrm{a}\mathrm{r}\mathrm{c}\right)$, and

$$\forall \mathrm{a}\mathrm{r}\mathrm{c}\in \mathrm{A}\mathrm{r}\mathrm{c}: \mathrm{T}\mathrm{y}\mathrm{p}\mathrm{e}\left(f_E\right(\mathrm{a}\mathrm{r}\mathrm{c}\left)\right)={\mathrm{C}\left(\mathrm{p}\left(\mathrm{a}\mathrm{r}\mathrm{c}\right)\right)}_{\mathrm{m}\mathrm{s}}\wedge \mathrm{T}\mathrm{y}\mathrm{p}\mathrm{e}\left(\mathrm{V}\mathrm{a}\mathrm{r}\right(f_E\left(\mathrm{a}\mathrm{r}\mathrm{c}\right)\left)\right)\subseteq \sum ).$$

(35)

(5)

∑ is a finite nonempty set of colors, V is a finite set of type variables, and for $\forall v\in V, \mathrm{T}\mathrm{y}\mathrm{p}\mathrm{e}\left[\mathrm{v}\right]\in \sum$.

(6)

$f$ represents a set of mapping functions,

$$f=(f_{CC}, f_G, I).$$

(36)

① $f_{CC}$ represents a colored function set that divides places into color set ∑, according to the classification of resources in the simulation,${ f}_{CC}:P\to \sum \mathrm{s}\mathrm{s}$, where $\sum \mathrm{s}\mathrm{s}$ is a finite subset of $\sum$/

② $f_G$:T→Expr,$f_G$ is the guard function of transition set T, Expr denotes an expression of variables, and

$$\text{∀}\mathrm{t}\text{∈}\mathrm{T}: \mathrm{Type}(f_G\left(\mathrm{arc}\right))=\mathrm{Bool}\wedge \mathrm{Type}(\mathrm{Var}\left(f_G\right(\mathrm{t}\left)\right))\subseteq \sum ,$$

(37)

$$\mathrm{Bool} = \{\mathrm{true}, \mathrm{false}\}.$$

(38)

(7)

With regard to an identifier set,$\mathrm{I}:\mathrm{P}\to expression$, the original state defined by user as required is called the initial identifier ${\mathrm{I}}_0$, and

$$\forall \mathrm{p}\in \mathrm{P},\mathrm{a}\mathrm{r}\mathrm{c}\in \mathrm{A}\mathrm{r}\mathrm{c}: \mathrm{T}\mathrm{y}\mathrm{p}\mathrm{e}\left(\mathrm{I}\left(\mathrm{p}\right)=f_{CC}\left(\mathrm{p}\right)\right)={f_{CC}\left(\mathrm{p}\left(\mathrm{a}\mathrm{r}\mathrm{c}\right)\right)}_{\mathrm{m}\mathrm{s}}\wedge \mathrm{V}\mathrm{a}\mathrm{r}\left(\mathrm{I}\left(\mathrm{p}\right)\right)=\mathrm{\varnothing }.$$

(39)

3.2. PRBC Modeling Framework

The PRBC modeling framework is proposed as shown in Figure 3. This framework is a process of stepwise refinement modeling method, according to the mapping rules and relationship matrices between the PFM model and the business process models.

Figure 3. PRBC modeling framework.

In the problem frames concepts, requirements are classified as a set of phenomena, containing desired relationships, behaviors, events, states, or values in the human mind [13]. To emphasize the system’s relevance to the real world, the first step of iterative business process modeling is to capture the requirement description called the “world model” (which is a “mirror” of the real world compressing common sense into the human mind) and to arrange these phenomena into a requirement model. Every requirement description can be regarded as a fragment of the whole requirement set, and the elements in the problem diagram can be regarded as a sketch of a PFM model.

In the requirement extracting process, to achieve accurate requirement extraction, it is necessary to capture the entities and their relationship in the world model. The world model is a mirror mapping the real world in a human brain [36]. Jay Wright Forrester regarded “the image of the world around us” as a model in our head [37]. “Nobody in his head images all the world, government, or country”; most of the time, people just “select concepts and relationships” and “use those to represent the real system,” which means the world model contains all the entities and relationships relevant to the system under construction. The problem frame depicts the world model through a problem diagram and context frame. Therefore, the PRBC modeling method utilizes LLMs to chat with people to collect dynamic changes in requirements, and PFM models represent the established requirements, while the LLMs extract enough information from the chatting records. Thus, the practical requirements of the real world are mapped onto a series of PFM models, and by a specific mapping function from PFM to RBPMN, the business process structures will catch the constantly changing requirements. The RBPMN model set will be transformed into a CBPMN model after the merging algorithm. As long as the detection of certain properties in the corresponding CPN model simulation is conducted, the CBPMN model can be regarded as a qualified business process model of the initial requirement description.

4. Business Process Iterative Modeling Method

This section describes the business process modeling method. This process consists of three subsections: the collecting and modeling method of requirements, mapping the requirements to business process models, and iterating the method when requirements evolve.

4.1. Requirements’ Collecting and Modeling

As shown in Figure 4, the requirement provider receives a change M from the business environment in flux; the change accumulates into intellectual cognition and then builds the inner world model in the owner’s mind. The large language models (LLMs) will communicate with the requirement provider to extract the necessary information for modeling and convert the requirement description (RD) into requirement details through the interaction of two external modules (Information Extracting and Retrieval) and the internal reasoning module. The obtained model rudiment, called requirement details, will be delivered to the requirement inspector to estimate the quality; then, the inspector will test the output model and determine whether to give feedback to the provider or to confirm the contents as the final outputs in this bout. If the requirement provider receives a piece of feedback, a new change M’ will be imported, and a new cycle will start to build the incremental model.

Figure 4. Requirement collecting and modeling process.

The main part of the requirement modeling paradigm can be generalized as the following three modules: (i) the external function module composed of information extracting and retrieval, which can be respectively instantiated by the Standford CoreNLP and BM25 retrieval algorithm; (ii) the dialogue module based on the generative capability of LLMs, mediated by prompt input in Table 2 and prompt output in Table 3 and (iii) the reasoning module leveraging the generation ability of zero-shot and few-shot Chain-of-Thought (CoT) of LLMs, accomplished through the prompt decomposition shown in Table 4.

Table 2. The prompt template of input.

Composition	Contents
Role	You are a chatbot; your responsibility is to communicate with the requirement provider and arrange the received messages as the requirement description.
Goal	Your target is to collect all the requirement fragments from the dialogue and categorize the paragraph into <5> types of phrases according to the paradigm of <5> layers in <PFM> model.
Skills	To collect the information required in the decomposition template, you need the ability to extract information from the phrase through a tokenizer.
Workflow	First, you need to check which type of phrase is absent in present model corresponding to the <5> layers in <PFM> paradigm; then, from the top to the bottom ask questions of the constructing layer in turn and refine phrases on the basis of the answer messages. Finally, transfer the obtained phrases set to the role modeler.
Output format	The <X set> relates to phrases set <X-D>, containing phrases: <X-D text>.

Table 3. The prompt template of output.

Composition	Contents
Role	You are a model trimmer; your responsibility is to verify and arrange all the layer sets of <PFM> model under construction as a numbered PFM model.
Goal	Your target is to verify the recorded layer sets of PFM, send the wrong generation back to PFM paradigm modeler, organize all the correct recorded layer sets of the numbered PFM model, and transmit the qualified PFM model to the requirement inspector.
Skills	To verify and organize the constitution of <PFM> model, you need to be familiar with the <PFM> model, have the ability to recognize the correct element in PFM, and send the wrong element back to the PFM paradigm modeler to get a revised one.
Workflow	$\mathrm{First}, \mathrm{a} \mathrm{PFM} \mathrm{model} \mathrm{is} \mathrm{composed} \mathrm{of} \mathrm{more} \mathrm{than} \mathrm{one} \mathrm{sub}\text{-}\mathrm{problem} \mathrm{set}, \mathrm{which} \mathrm{means} \mathrm{the} \mathrm{corresponding} \mathrm{amount} \mathrm{of} \mathrm{Re} \mathrm{set} \mathrm{elements} \mathrm{will} \mathrm{more} \mathrm{than} \mathrm{one}. \mathrm{Then}, \mathrm{the} \mathrm{number} \mathrm{of} \mathrm{PD} \mathrm{elements} \mathrm{for} \mathrm{every} {\mathrm{R}\mathrm{e}}_{\mathrm{i}}$ will be more than one. Third, check the linked ${\mathrm{f}}_{\mathrm{P}\mathrm{R}\mathrm{h}},{\mathrm{f}}_{\mathrm{R}\mathrm{h}\mathrm{S}},{\mathrm{f}}_{\mathrm{S}\mathrm{h}\mathrm{V}}$ amount, to ensure their numbers conform to the three proportions: (1) $\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}({\mathrm{R}\mathrm{P}\mathrm{h})}_{\mathrm{i}}:\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}({\mathrm{P}\mathrm{D}}_{\mathrm{i}})=\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}({{\mathrm{f}}_{\mathrm{P}\mathrm{R}\mathrm{h}}}_{\mathrm{i}})>2;$ (2) $\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}({\mathrm{S}\mathrm{P}\mathrm{h})}_{\mathrm{j}}:\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}({\mathrm{R}\mathrm{P}\mathrm{h}}_{\mathrm{j}})=\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}({{\mathrm{f}}_{\mathrm{R}\mathrm{h}\mathrm{S}}}_{\mathrm{j}})\ge 2\mathrm{x},\mathrm{x}\in \mathrm{Z}$; (3) $\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}({\mathrm{V})}_{\mathrm{q}}:\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}({\mathrm{S}\mathrm{P}\mathrm{h}}_{\mathrm{j}})=\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}({{\mathrm{f}}_{\mathrm{R}\mathrm{h}\mathrm{S}}}_{\mathrm{q}})=1$.
Output format	$\mathrm{The} <\mathrm{number} \mathrm{k}> \mathrm{PFM} \mathrm{model} \mathrm{is} \mathrm{composed} \mathrm{of} <\mathrm{i}> \mathrm{sub}\text{-}\mathrm{problem} \mathrm{models}; \mathrm{every} \mathrm{construction} \mathrm{in} \mathrm{the} \mathrm{sub}\text{-}\mathrm{problem} \mathrm{model} {\mathrm{P}\mathrm{F}\mathrm{M}}_{\mathrm{i}}$$\mathrm{will} \mathrm{be} \mathrm{displayed} \mathrm{from} \mathrm{Re} \mathrm{set} \mathrm{to} \mathrm{V} \mathrm{set} \mathrm{in} \mathrm{turn} \mathrm{in} \mathrm{the} \mathrm{form} \mathrm{of} \mathrm{the} \mathrm{following}: <\mathrm{X} \mathrm{set}> \mathrm{are} <{\mathrm{X}}_1,{\mathrm{X}}_2\dots >$. $\mathrm{The} <\mathrm{relations} \mathrm{from} <\mathrm{X}> \mathrm{to} \mathrm{next} \mathrm{layer} <\mathrm{Y}>> \mathrm{are} <<{\mathrm{X}}_1$$><Y_1, \dots >,$<${\mathrm{X}}_2$$><Y_i, \dots$>, …>. $\mathrm{For} \mathrm{the} \mathrm{Re} \mathrm{set} \mathrm{and} \mathrm{RPh} \mathrm{set}, \mathrm{the} <\mathrm{relations} \mathrm{among} \mathrm{layer} <\mathrm{X}>> \mathrm{can} \mathrm{be} \mathrm{represented} \mathrm{as} \mathrm{follows}: <\mathrm{Parallel}><(X_1, X_2), \dots >$, <Exclusive><($X_3, X_4$), …>, <Sequential><( , ), …>, <0><( , ),…>. For the relations between the layer <RPh> set and the <SPh> set, the $<\mathrm{contents} \mathrm{of} \mathrm{X} \mathrm{relations} \mathrm{with} \mathrm{another} \mathrm{layer}> \mathrm{will} \mathrm{be} \mathrm{attached} \mathrm{with} \mathrm{a} \mathrm{weight} \mathrm{matrix}, \mathrm{shown} \mathrm{as} \mathrm{below}: <\mathrm{d}> <{\mathrm{R}\mathrm{P}\mathrm{h}}_{\mathrm{i}},{\mathrm{S}\mathrm{P}\mathrm{h}}_{\mathrm{j}}>$. d = −$1, 0, 1, \mathrm{while} {\mathrm{R}\mathrm{P}\mathrm{h}}_{\mathrm{i}}$$\mathrm{and} {\mathrm{S}\mathrm{P}\mathrm{h}}_{\mathrm{j}}$$\mathrm{are} \mathrm{uncorrelated}, \mathrm{d} \mathrm{equals} 0; \mathrm{d} \mathrm{equals} 1, \mathrm{while} \mathrm{there} \mathrm{is} \mathrm{a} \mathrm{relation} \mathrm{between} {\mathrm{R}\mathrm{P}\mathrm{h}}_{\mathrm{i}}$$\mathrm{and} {\mathrm{S}\mathrm{P}\mathrm{h}}_{\mathrm{j}}$; otherwise, d equals −1.

Table 4. The prompt template for decomposition.

Composition	Contents
Role	You are a <PFM> paradigm modeler; your responsibility is to receive the phrases sets, retrieve the sets in available repository to get the relevant description, and then reasoning to get the elements of model and the relationships among them.
Goal	Your target is to build the <PFM> model, containing the elements in every layer and the relations among the layers and within layers.
Skills	To build the <PFM> model, you need the ability to find paragraphs corresponding to the objective phrases set by the retriever system, to choose entities as model elements by the natural language processing tool, and construct the relationships between them via LLMs generating zero-shot reasoning chain of thoughts.
Workflow	First, you need to search for the top 15 paragraphs most closely related to <RD> through an applicable retrieval strategy. Second, the entities will be selected into the <PD> set and will be checked by the requirement provider. Third, the authenticated <PD> set will be combined with <RD>, serving as the reasoning basis of <Re> set. Then, execute a retrieve-and-reason loop until the last layer <V> set of <PFM> is built. Finally, transmit every layer set and the relation set between and among them to the role model trimmer.
Output format	The layer i, set <X> of PFM model is as follows: <X content>. The relations between layer <X> and the layer upper stair are as follows: <contents of X relations with another layer>. The relations among layer <X> are as follows: <contents of relations among <X> set>.

After the role modeler accomplishes the transmission to the role trimmer, the requirement details are sufficient for verification and adjustment for the PFM model. To check the practicability of the PFM model, three hierarchies of verification should be taken: the element checking related to structure logic in the PFM model, the rationality verification of the static flow in the CBPMN model, and the executable verification of it.

With the aim of promising the traceability of the original business requirements, a PFM model should abide by certain “rules” represented by increments in the PFM model. The “rules” are summarized from the regularity of the PFM model and the industry common sense in the inspector’s mind; the former is accomplished by the output prompt, while the latter will be discussed in the next section.

4.2. Mapping Requirements to Business Process Models

The PFM architecture links business requirements and their increment to detailed business process implementation elements, which can be transmitted into the CBPMN model through the mapping function $\psi$, shown in Table 5.

Table 5. Rules mapping PFM model elements onto RBPMN modules.

$\mathbf{Mapping} \mathbf{Function} \mathit{\psi }$	Model Elements
Expression	Diagram
Rule 1 (Traceability 1, $f_R\cup f_M$): $\forall {Re}_i\in {PFM}_i,\exists {\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{i}}$, and $f_{Rx}\subseteq f_R$, such that $f_{Rx}:({PFM}_i\times f_M\times f_{Rx})\to {\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{i}}$.
Rule 2 (Problem domain, $PD$): $PD\stackrel{\psi }{\to }\mathrm{P}\mathrm{L}$, if ${\mathrm{p}\mathrm{d}}_1$ is connected with ${\mathrm{p}\mathrm{d}}_2$ through the phenomenon, then $({\mathrm{p}\mathrm{d}}_1, {\mathrm{p}\mathrm{d}}_2)\stackrel{\psi }{\to }(\mathrm{L}1,\mathrm{L}2)$, where $PD={\mathrm{p}\mathrm{d}}_1\cup {\mathrm{p}\mathrm{d}}_2$, and $\mathrm{P}\mathrm{L}=\mathrm{L}1\cup \mathrm{L}2$.
Rule 3 (Requirement phenomenon, $\mathrm{R}\mathrm{P}\mathrm{h}$): $RPh\stackrel{\psi }{\to }(\mathrm{A},\mathrm{E})$.
Rule 4 (Partially ordered set, $Q$): $Q\stackrel{\psi }{\to }({\mathrm{F}}_{\mathrm{C}},d(Q\left)\right)$, where $d\left(q_{ij}\right)\in$$\{parallel, exclusive, sequential, none\}$, and $d\left(Q_{kl}\right)=d(N_k\times N_l)\subseteq d\left(Q\right)$, $N_k=[n_{ks}, \dots ,n_{ke}]$, $N_l=[n_{ls}, \dots ,n_{le}]$, and $({\mathrm{N}}_{\mathrm{k}}\cup N_l)\subset (A, E)$.
Rule 5 (Data item of task list, ${\mathrm{f}}_{\mathrm{R}\mathrm{h}\mathrm{S}}$): ${\mathrm{f}}_{\mathrm{R}\mathrm{h}\mathrm{S}}\stackrel{\psi }{\to }{\mathrm{F}}_{\mathrm{D}}$, and set ${\mathrm{f}}_{\mathrm{R}\mathrm{h}\mathrm{S}}$ is mapped onto the data stream arc set ${\mathrm{F}}_{\mathrm{D}}$.
Rule 6 (Shared phenomenon, $\mathrm{S}\mathrm{P}\mathrm{h}$): $\mathrm{S}\mathrm{P}\mathrm{h}\stackrel{\psi }{\to }(\mathrm{D},\mathrm{M})$, and set $\mathrm{S}\mathrm{P}\mathrm{h}$ is mapped onto the D and M set.
Rule 7 (Variables of data items, ${\mathrm{f}}_{\mathrm{S}\mathrm{h}\mathrm{V}}$): ${\mathrm{f}}_{\mathrm{S}\mathrm{h}\mathrm{V}}\stackrel{\psi }{\to }\mathrm{I}\mathrm{n}$, and set ${\mathrm{f}}_{\mathrm{S}\mathrm{h}\mathrm{V}}$ is mapped onto the information set $\mathrm{I}\mathrm{n}$.
Rule 8 (Variables, $\mathrm{V}$): $\mathrm{V}\stackrel{\psi }{\to }\left\{\mathrm{v}\mathrm{a}\mathrm{r}\mathrm{i}\mathrm{a}\mathrm{b}\mathrm{l}\mathrm{e}\mathrm{s}\right\}$, and set V is mapped onto the variables in set In.

The transformation rules between those models are based on semantics.

In order to propagate the requirements, the union of the PFM models is transformed into RBPMN models, complying with a series of relevant matrix calculation rules. According to the construction of the PFM models, the relationship matrix can be defined as follows:

$M_{XY}=\mathrm{v}\mathrm{a}\mathrm{l}\mathrm{u}\mathrm{e}\left({\mathrm{X}}^{\mathrm{T}}\mathrm{Y}\right)$, $m_{ij}=\mathrm{v}\mathrm{a}\mathrm{l}\mathrm{u}\mathrm{e}\left(x_i{y}_i\right)$, the vector $\mathrm{X}=(x_1, x_2, \dots , x_n)$, and $\mathrm{X} \mathrm{a}\mathrm{n}\mathrm{d} \mathrm{Y} \mathrm{r}\mathrm{e}\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{t} \mathrm{s}\mathrm{e}\mathrm{t} \mathrm{R}\mathrm{e},\mathrm{P}\mathrm{D},\mathrm{R}\mathrm{P}\mathrm{h},\mathrm{S}\mathrm{P}\mathrm{h},\mathrm{o}\mathrm{r} \mathrm{V}$;

$$m_{ij}=\left\{\begin{array}{c}1, if x_i and y_i has an connection \\ 0, otherwise\end{array}\right..$$

Thus, the requirements will be transformed into different layer sets through the following calculation matrices, where card(Re) = m, card(PD) = n, card(RPh) = p, card(SPh) = q, and card(V) = k:

$$\left\{\begin{array}{c}{M}_{RP(m\times n)}=value({{Re}^T}_{m\times 1}\cdot {PD}_{1\times n})\\ M_{RRh(m\times p)}=M_{RP(m\times n)}\times M_{PRh(n\times p)}\\ M_{RSh(m\times q)}=M_{RRh(m\times p)}\times M_{RhS(p\times q)}\\ M_{RV(m\times k)}= M_{RSh(m\times q)}\times M_{ShV(q\times k)}\end{array}\right..$$

That is to say, an inspector can obtain the corresponding RBPMN net modules through the calculation matrices:

$$\left\{\begin{array}{c}{PL}^T=\psi (M_{RP}\cdot {PD}^T)\\ {(A,E)}^T=\psi (M_{RRh}\cdot {RPh}^T)\\ {(D,M)}^T=\psi (M_{RSh}\cdot {SPh}^T)\\ {variables}^T=\psi (M_{RV}\cdot V^T)\end{array}\right..$$

In order to implement the rationality verification of the static flow in the CBPMN model, all the RBPMN modules transmitted by calculation matrices will be first merged into a CBPMN model through Algorithm 1.

Algorithm 1. ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{S}}$ Net Module Merging Algorithm

Input: ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_S=\{{\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_1,{\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_2,\dots ,{\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{card\left({RBPMN}_S\right)}\};$

${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_i=({\mathrm{E}}_{\mathrm{i}},{\mathrm{P}\mathrm{L}}_{\mathrm{i}},{\mathrm{D}}_{\mathrm{i}},{\mathrm{M}}_{\mathrm{i}},{\mathrm{I}}_{\mathrm{i}},{\mathrm{A}}_{\mathrm{i}},{\mathrm{F}}_{\mathrm{i}});$ ${\mathrm{F}}_{\mathrm{i}}={\mathrm{F}\mathrm{c}}_{\mathrm{i}}\cup {\mathrm{F}}_{\mathrm{D}\mathrm{i}}\cup {\mathrm{f}}_{\mathrm{P}\mathrm{N}\mathrm{i}}$;

d$\left(Q\right)$; $f_{R\left(ij\right)}\to$ {1, 0}; ${d(q}_{ij})\to \{parallel, exclusive, sequential, none\}$

Output$: \mathrm{C}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}=(\mathrm{G}, f_C, {RBPMN}_M)$

(1) Initialize

1. $\mathrm{G}\leftarrow \mathrm{\varnothing },f_C\leftarrow \mathrm{\varnothing };{RBPMN}_M=({\mathrm{E}}_{\mathrm{R}\mathrm{M}},{\mathrm{P}\mathrm{L}}_{\mathrm{M}},{\mathrm{D}}_{\mathrm{M}},{\mathrm{M}}_{\mathrm{M}},{\mathrm{I}}_{\mathrm{M}},{\mathrm{A}}_{\mathrm{M}},{\mathrm{F}}_{\mathrm{M}})$, ${\mathrm{F}}_{\mathrm{M}}$=${\mathrm{F}\mathrm{c}}_{\mathrm{M}}\cup {\mathrm{F}}_{\mathrm{D}\mathrm{M}}\cup {\mathrm{f}}_{\mathrm{P}\mathrm{N}\mathrm{M}}$;

2. ${\mathrm{E}}_{\mathrm{R}\mathrm{M}}\leftarrow \mathrm{\varnothing },{\mathrm{P}\mathrm{L}}_{\mathrm{M}}\leftarrow \mathrm{\varnothing },{\mathrm{D}}_{\mathrm{M}}\leftarrow \mathrm{\varnothing },{\mathrm{M}}_{\mathrm{M}}\leftarrow \mathrm{\varnothing },{\mathrm{I}}_{\mathrm{M}}\leftarrow \mathrm{\varnothing },{\mathrm{A}}_{\mathrm{M}}\leftarrow \mathrm{\varnothing },{\mathrm{F}}_{\mathrm{M}}\leftarrow \mathrm{\varnothing }$; 3. i = 1;

(2) Merging

4. for $(;i<=card({RBPMN}_S);i++;)$ #O(m)

5. for (j = i − 1; j > 0; j--)        #O(m)

6.  if ${df}_{R\left(ij\right)}$ = 0 then #O(n+$c_1$p+$c_2$q+$c_3$k+${\displaystyle \frac{1}{2}}{c}_1{c}_2\mathrm{p}\mathrm{q}$+${\displaystyle \frac{1}{2}}{c}_2{c}_3\mathrm{q}\mathrm{k}$)

7.   ${\mathrm{E}}_{\mathrm{R}\mathrm{M}}\leftarrow {\mathrm{E}}_{\mathrm{R}\mathrm{M}}\cup {\mathrm{E}}_{\mathrm{i}}$; ${\mathrm{P}\mathrm{L}}_{\mathrm{M}}\leftarrow {\mathrm{P}\mathrm{L}}_{\mathrm{M}}\cup {\mathrm{P}\mathrm{L}}_{\mathrm{i}};{\mathrm{D}}_{\mathrm{M}}\leftarrow {\mathrm{D}}_{\mathrm{M}}\cup {\mathrm{D}}_{\mathrm{i}};{\mathrm{M}}_{\mathrm{M}}\leftarrow {{\mathrm{M}}_{\mathrm{M}}\cup \mathrm{M}}_{\mathrm{i}};$

${\mathrm{I}}_{\mathrm{M}}\leftarrow {\mathrm{I}}_{\mathrm{M}}\cup {\mathrm{I}}_{\mathrm{i}};{\mathrm{A}}_{\mathrm{M}}\leftarrow {\mathrm{A}}_{\mathrm{M}}\cup {\mathrm{A}}_{\mathrm{i}};{\mathrm{F}}_{\mathrm{M}}\leftarrow {\mathrm{F}}_{\mathrm{M}}\cup {\mathrm{F}}_{\mathrm{i}}$;

8.  end if

9.   if ${df}_{R\left(ij\right)}$=1 then

10.   ${\mathrm{E}}_{\mathrm{R}\mathrm{M}}\leftarrow {\mathrm{E}}_{\mathrm{M}}\cup {\mathrm{E}}_{\mathrm{i}}$; ${\mathrm{P}\mathrm{L}}_{\mathrm{M}}\leftarrow {\mathrm{P}\mathrm{L}}_{\mathrm{M}}\cup {\mathrm{P}\mathrm{L}}_{\mathrm{i}};{\mathrm{D}}_{\mathrm{M}}\leftarrow {\mathrm{D}}_{\mathrm{M}}\cup {\mathrm{D}}_{\mathrm{i}};{\mathrm{M}}_{\mathrm{M}}\leftarrow {{\mathrm{M}}_{\mathrm{M}}\cup \mathrm{M}}_{\mathrm{i}};$

11.    ${\mathrm{I}}_{\mathrm{M}}\leftarrow {\mathrm{I}}_{\mathrm{M}}\cup {\mathrm{I}}_{\mathrm{i}};{\mathrm{A}}_{\mathrm{M}}\leftarrow {\mathrm{A}}_{\mathrm{M}}\cup {\mathrm{A}}_{\mathrm{i}};$ ${\mathrm{F}}_{\mathrm{D}\mathrm{M}}\leftarrow {\mathrm{F}}_{\mathrm{D}\mathrm{M}}\cup {\mathrm{F}}_{\mathrm{D}\mathrm{i}}$; ${\mathrm{f}}_{\mathrm{P}\mathrm{N}\mathrm{M}}\leftarrow {\mathrm{f}}_{\mathrm{P}\mathrm{N}\mathrm{M}}\cup {\mathrm{f}}_{\mathrm{P}\mathrm{N}\mathrm{i}}$;

12.    for(k = 0; k<card(${\mathrm{F}\mathrm{c}}_{\mathrm{i}})$; k++;)   #O(log p)

13.    for(l = 0; k<card(${\mathrm{F}\mathrm{c}}_{\mathrm{j}})$; l++;)  #O(log p)

14.     Retrieve all ${\mathrm{N}}_{\mathrm{k}}$ and ${\mathrm{N}}_{\mathrm{l}}$,

15.     ${\mathrm{n}}_{\mathrm{k}\mathrm{s}1}=[{\mathrm{N}}_{\mathrm{k}}\cap {\complement }_{{\mathrm{N}}_{\mathrm{k}}\cup N_l}({\mathrm{N}}_{\mathrm{k}}\cap N_l\left)\right]$.first, ${\mathrm{n}}_{\mathrm{k}\mathrm{e}1}=[{\mathrm{N}}_{\mathrm{k}}\cap {\complement }_{{\mathrm{N}}_{\mathrm{k}}\cup N_l}({\mathrm{N}}_{\mathrm{k}}\cap N_l\left)\right]$.last;

16.     ${\mathrm{n}}_{\mathrm{l}\mathrm{s}2}=[{\mathrm{N}}_{\mathrm{l}}\cap {\complement }_{{\mathrm{N}}_{\mathrm{k}}\cup N_l}({\mathrm{N}}_{\mathrm{k}}\cap N_l\left)\right]$.first, ${\mathrm{n}}_{\mathrm{l}\mathrm{e}2}=[{\mathrm{N}}_{\mathrm{l}}\cap {\complement }_{{\mathrm{N}}_{\mathrm{k}}\cup N_l}({\mathrm{N}}_{\mathrm{k}}\cap N_l\left)\right]$.last;

17.     ${\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{s}}=$ [predecessor[${\mathrm{N}}_{\mathrm{k}}\cap {\complement }_{{\mathrm{N}}_{\mathrm{k}}\cup N_l}({\mathrm{N}}_{\mathrm{k}}\cap N_l)$, ${\mathrm{N}}_{\mathrm{l}}\cap {\complement }_{{\mathrm{N}}_{\mathrm{k}}\cup N_l}({\mathrm{N}}_{\mathrm{k}}\cap N_l)$]].last;

18.     ${\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{e}}=$ [successor[${\mathrm{N}}_{\mathrm{k}}\cap {\complement }_{{\mathrm{N}}_{\mathrm{k}}\cup N_l}({\mathrm{N}}_{\mathrm{k}}\cap N_l)$, ${\mathrm{N}}_{\mathrm{l}}\cap {\complement }_{{\mathrm{N}}_{\mathrm{k}}\cup N_l}({\mathrm{N}}_{\mathrm{k}}\cap N_l)$]].first;

19.     if $\mathrm{d}\left({\mathrm{Q}}_{\mathrm{k}\mathrm{l}}\right)=\mathrm{“}\mathrm{p}\mathrm{a}\mathrm{r}\mathrm{a}\mathrm{l}\mathrm{l}\mathrm{e}\mathrm{l}\mathrm{”}$ then

20.       $\mathrm{G}\leftarrow \mathrm{G}\cup {\mathrm{G}}_{\mathrm{P}\mathrm{F}\left(\mathrm{k}\mathrm{l}\right)}\cup {\mathrm{G}}_{\mathrm{P}\mathrm{C}\left(\mathrm{k}\mathrm{l}\right)}$;

21.       ${\mathrm{F}\mathrm{c}}_{\mathrm{M}}\leftarrow {\mathrm{F}\mathrm{c}}_{\mathrm{M}}\cup ({\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{s}},{\mathrm{G}}_{\mathrm{P}\mathrm{F}\left(\mathrm{k}\mathrm{l}\right)})\cup ({\mathrm{G}}_{\mathrm{P}\mathrm{F}\left(\mathrm{k}\mathrm{l}\right)},{\mathrm{n}}_{\mathrm{k}\mathrm{s}1})\cup ({\mathrm{G}}_{\mathrm{P}\mathrm{F}\left(\mathrm{k}\mathrm{l}\right)},{\mathrm{n}}_{\mathrm{l}\mathrm{s}2})$

$\cup ({\mathrm{n}}_{\mathrm{k}\mathrm{e}1},{\mathrm{G}}_{\mathrm{P}\mathrm{C}\left(\mathrm{k}\mathrm{l}\right)})\cup ({\mathrm{n}}_{\mathrm{l}\mathrm{e}2},{\mathrm{G}}_{\mathrm{P}\mathrm{C}\left(\mathrm{k}\mathrm{l}\right)})\cup ({\mathrm{G}}_{\mathrm{P}\mathrm{C}\left(\mathrm{k}\mathrm{l}\right)},{\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{e}});$

22.       ${\mathrm{F}\mathrm{c}}_{\mathrm{M}}\leftarrow {\complement }_{{\mathrm{F}\mathrm{c}}_{\mathrm{M}}}\left(\right({\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{s}},{\mathrm{n}}_{\mathrm{k}\mathrm{s}1})\cup ({\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{s}},{\mathrm{n}}_{\mathrm{l}\mathrm{s}2})\cup ({\mathrm{n}}_{\mathrm{k}\mathrm{e}1},{\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{e}})\cup ({\mathrm{n}}_{\mathrm{l}\mathrm{e}2},{\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{e}}\left)\right)$;

23.     end if

24.     if $\mathrm{d}\left({\mathrm{Q}}_{\mathrm{k}\mathrm{l}}\right)=\mathrm{“}\mathrm{e}\mathrm{x}\mathrm{c}\mathrm{l}\mathrm{u}\mathrm{s}\mathrm{i}\mathrm{v}\mathrm{e}\mathrm{”}$ then

25.       $\mathrm{G}\leftarrow \mathrm{G}\cup {\mathrm{G}}_{\mathrm{X}\mathrm{F}\left(\mathrm{k}\mathrm{l}\right)}\cup {\mathrm{G}}_{\mathrm{X}\mathrm{C}\left(\mathrm{k}\mathrm{l}\right)}$;

26.       ${\mathrm{F}\mathrm{c}}_{\mathrm{M}}\leftarrow {\mathrm{F}\mathrm{c}}_{\mathrm{M}}\cup ({\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{s}},{\mathrm{G}}_{\mathrm{X}\mathrm{F}\left(\mathrm{k}\mathrm{l}\right)})\cup ({\mathrm{G}}_{\mathrm{X}\mathrm{F}\left(\mathrm{k}\mathrm{l}\right)},{\mathrm{n}}_{\mathrm{k}\mathrm{s}1})\cup ({\mathrm{G}}_{\mathrm{X}\mathrm{F}\left(\mathrm{k}\mathrm{l}\right)},{\mathrm{n}}_{\mathrm{l}\mathrm{s}2})$

$\cup ({\mathrm{n}}_{\mathrm{k}\mathrm{e}1},{\mathrm{G}}_{\mathrm{P}\mathrm{C}\left(\mathrm{k}\mathrm{l}\right)})\cup ({\mathrm{n}}_{\mathrm{l}\mathrm{e}2},{\mathrm{G}}_{\mathrm{P}\mathrm{C}\left(\mathrm{k}\mathrm{l}\right)})\cup ({\mathrm{G}}_{\mathrm{P}\mathrm{C}\left(\mathrm{k}\mathrm{l}\right)},{\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{e}});$

27.       ${\mathrm{F}\mathrm{c}}_{\mathrm{M}}\leftarrow {\complement }_{{\mathrm{F}\mathrm{c}}_{\mathrm{M}}}\left(\right({\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{s}},{\mathrm{n}}_{\mathrm{k}\mathrm{s}1})\cup ({\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{s}},{\mathrm{n}}_{\mathrm{l}\mathrm{s}2})\cup ({\mathrm{n}}_{\mathrm{k}\mathrm{e}1},{\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{e}})\cup ({\mathrm{n}}_{\mathrm{l}\mathrm{e}2},{\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{e}}\left)\right)$;

28.     end if

29.     if $\mathrm{d}\left({\mathrm{Q}}_{\mathrm{k}\mathrm{l}}\right)=\mathrm{“}\mathrm{s}\mathrm{e}\mathrm{q}\mathrm{u}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{i}\mathrm{a}\mathrm{l}\mathrm{”}$ then

30.       $\mathrm{G}\leftarrow \mathrm{G}\cup \mathrm{\varnothing };$

31.       ${\mathrm{F}\mathrm{c}}_{\mathrm{M}}\leftarrow {\mathrm{F}\mathrm{c}}_{\mathrm{M}}\cup ({\mathrm{n}}_{\mathrm{k}\mathrm{e}1},{\mathrm{n}}_{\mathrm{l}\mathrm{s}2})$;

32.     end if

33.     end do

34.    end do

35.  end if

36. end do

37. end do

Algorithm 1 merges a set of RBPMN models ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{S}}$ into a CBPMN model. Lines 1–3 deal with CBPMN model initialization; Lines 4–37 illustrate the detailed method of merging; the first and second for loops (lines 4–37) list all the models in ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{S}}$ and combine them from ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_1 \mathrm{t}\mathrm{o} {\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}\left({\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{S}}\right)}$. The first “if” from lines 6 to 8, merges ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{i}}$ into CBPMN when there are no relations between them, and the second “if” from lines 9 to 35, merges ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{i}}$ into CBPMN when ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{i}}$ is related to the previous CBPMN. Lines 14 to 18 retrieve the node sets A and E and find six special kinds of nodes: the first node ${\mathrm{n}}_{\mathrm{k}\mathrm{s}1}$ in sequence ${\mathrm{N}}_{\mathrm{k}}$ excludes the common parts of ${\mathrm{N}}_{\mathrm{k}}$ and ${\mathrm{N}}_{\mathrm{l}}$, the last node ${\mathrm{n}}_{\mathrm{k}\mathrm{e}1}$ in sequence ${\mathrm{N}}_{\mathrm{k}}$ excludes the common parts of ${\mathrm{N}}_{\mathrm{k}}$ and ${\mathrm{N}}_{\mathrm{l}}$, the first node ${\mathrm{n}}_{\mathrm{l}\mathrm{s}2}$ in sequence ${\mathrm{N}}_{\mathrm{l}}$ excludes the common parts of ${\mathrm{N}}_{\mathrm{k}}$ and ${\mathrm{N}}_{\mathrm{l}}$, the last node ${\mathrm{n}}_{\mathrm{l}\mathrm{e}2}$ in sequence ${\mathrm{N}}_{\mathrm{l}}$ excludes the common parts of ${\mathrm{N}}_{\mathrm{k}}$ and ${\mathrm{N}}_{\mathrm{l}}$, the last node ${\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{s}}$ of the common parts of ${\mathrm{N}}_{\mathrm{k}}$ and ${\mathrm{N}}_{\mathrm{l}}$ before their different parts, and the first node ${\mathrm{n}}_{\mathrm{k}\mathrm{l}\mathrm{e}}$ of the common parts of ${\mathrm{N}}_{\mathrm{k}}$ and ${\mathrm{N}}_{\mathrm{l}}$ after their different parts. Lines 19 to 32 discuss three conditions of $\mathrm{d}\left(\mathrm{Q}\right)$, in order to assign the value to gateway set G and control flow set ${\mathrm{F}\mathrm{c}}_{\mathrm{M}}$. The theoretical time complexity of Algorithm 1 is decided by the nested loop structures in lines 4–5 and lines 12–13; thus, the theoretical time complexity of Algorithm 1 is $\mathrm{O}\left({\mathrm{m}}^2{(\mathrm{l}\mathrm{o}\mathrm{g} \mathrm{p})}^2\right)$, where m stands for the cardinality of ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{S}}$, and p stands for the cardinality of the N set.

As can be seen in Table 6, when the number of nodes exceeds 100,000, the run time of the algorithm significantly increases. This indicates that the algorithm is suitable for large-scale (${10}^2~{10}^4$) and part of huge-scale (${10}^4$~${10}^5$) business processes, but for even larger huge-scale (${10}^5$~${10}^6)$ business processes with more than 100,000, nodes, optimization or the use of approximate algorithms may be necessary.

Table 6. Theoretical time complexity analysis of Algorithm 1.

Node Cardinality ($\left|\mathbf{m}\right|;\left|\mathbf{p}\right|$)	Theoretical Operation Count $\mathbf{O}({\mathbf{m}}^2{(\mathbf{l}\mathbf{o}\mathbf{g} \mathbf{p})}^2)$	Estimated Running Time (Assume O (100,000,000) = 1 s)
(100; 100)	490,000	0.0049 s
(10,000; 10,000)	100,000,000	16 s
(100,000; 100,000)	250,000,000,000	42 min

4.3. Model Verification and Iteration of Incremental Requirement

After executing Algorithm 1, the requirement inspector will get an untested CBPMN model; thus, the obtained CBPMN model will be verified through two procedures. One is the static flow checking in Algorithm 2. Static flow checking will detect the flow in the CBPMN model to confirm whether there is any isolated node in the directed acyclic graph of CBPMN.

Algorithm 2 will recognize all the isolated nodes and redundant nodes in the obtained CBPMN model. Lines 2–3 retrieve all the nodes and calculate the in-degree and out-degree of each node; lines 5–12 traverse all the classifications to get the isolated nodes, invalid start nodes, and invalid end nodes; lines 13–27 divide the selected nodes into different classifications, and lines 28–29 output all node errors.

Following the steps above, the requirement collector obtains the fundamental CBPMN model from Table 5 and gains the corresponding CPN model according to Table 7: the mapping rules of the model CBPMN transforming into the CPN model are listed in Table 7. Then, the multiple turns of dialogue transfer the incremental requirement up to date. Thus, the next subsection will elaborate on the method of handling the incremental task and adding requirements to the business process that was already built.

Table 7. CBPMN model elements mapping onto CPN net modules rules.

$\mathbf{Mapping} \mathbf{Rule} \mathit{\varphi }$	Model Elements
Expression	Diagram
Rule 1.1 (Parallel gateway, $G_{P\text{\_}}$): $\forall G_{P\text{\_}}=(g_{PF}, g_{PC})$, $G_{P\text{\_}}\stackrel{\varphi }{\to }T$, where $\mathrm{T}=({\mathrm{t}}_1,{\mathrm{t}}_2)$.
Rule 1.2 (Exclusive gateway, $G_{X\text{\_}}$): $\forall G_{X\text{\_}}=(g_{XF}, g_{XC})$, $G_{X\text{\_}}\stackrel{\varphi }{\to }\{T, p\}$, where $\mathrm{T}=({\mathrm{t}}_1,{\mathrm{t}}_2)$.
Rule 2.1 (Traceable mapping 2, $f_{Rs}$): $\forall {Re}_i,\exists f_{Rsi}:\{{\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{i}}\times { f}_{Ri}\}\to {RBPMN}_{Mi})$, such that every ${RBPMN}_{Mi}$ related to ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{i}}$ in ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{S}}$ will find a subset ${CPN}_{Si}$ in the CPN model; in other words, $\forall {Re}_i,\exists f_{R\left(ij\right)}\in f_{Ri}\subseteq f_{Rsi},$s.t. ${\mathrm{R}\mathrm{B}\mathrm{P}\mathrm{M}\mathrm{N}}_{\mathrm{M}\mathrm{i}}\stackrel{\varphi }{\to }{CPN}_{Si}$.
Rule 2.2 (Gateway pattern, $f_{GT}$): $\forall f_{GT}=\left(direction, condition\right)$, $f_{GT}\stackrel{\varphi }{\to }(Arc, f_E)$.
Rule 3.1 (Data flow elements, (${\mathrm{D}}_{\mathrm{M}}$,${\mathrm{M}}_{\mathrm{M}}$,${\mathrm{I}\mathrm{n}}_{\mathrm{M}}$,${\mathrm{F}}_{\mathrm{D}\mathrm{M}}$)): (${\mathrm{D}}_{\mathrm{M}}$, ${\mathrm{M}}_{\mathrm{M}}$, ${\mathrm{I}\mathrm{n}}_{\mathrm{M}}$, ${\mathrm{F}}_{\mathrm{D}\mathrm{M}}$)$\stackrel{\varphi }{\to }(P, \mathrm{C},\sum ,\mathrm{A}\mathrm{r}\mathrm{c})$.
Rule 3.2 (Control flow elements, (${\mathrm{A}}_{\mathrm{M}}$,${\mathrm{E}}_{\mathrm{R}\mathrm{M}}$,${\mathrm{F}}_{\mathrm{C}\mathrm{M}}$)): (${\mathrm{A}}_{\mathrm{M}}$,${\mathrm{E}}_{\mathrm{R}\mathrm{M}}$,${\mathrm{F}}_{\mathrm{C}\mathrm{M}}$)$\stackrel{\varphi }{\to }(P, \mathrm{T},f_G,\mathrm{A}\mathrm{r}\mathrm{c})$, where ${\mathrm{E}}_{\mathrm{R}\mathrm{M}}=E_{MS}\cup { E}_{MM}\cup E_{ME}$, and $(E_{MS},E_{ME})\stackrel{\varphi }{\to }P$, $({\mathrm{A}}_{\mathrm{M}},{ E}_{MM})\stackrel{\varphi }{\to }T$.

Algorithm 2. CBPMN Net Modules Checking Algorithm

Input: $CBPMN=(\mathrm{G},f_C,{RBPMN}_M);$

${RBPMN}_M=({\mathrm{E}}_{\mathrm{R}\mathrm{M}},{\mathrm{P}\mathrm{L}}_{\mathrm{M}},{\mathrm{D}}_{\mathrm{M}},{\mathrm{M}}_{\mathrm{M}},{\mathrm{I}}_{\mathrm{M}},{\mathrm{A}}_{\mathrm{M}},{\mathrm{F}}_{\mathrm{M}}),{\mathrm{F}}_{\mathrm{M}}={\mathrm{F}\mathrm{c}}_{\mathrm{M}}\cup {\mathrm{F}}_{\mathrm{D}\mathrm{M}}\cup {\mathrm{f}}_{\mathrm{P}\mathrm{N}\mathrm{M}};$

Output: All flow errors

(1) Initialize

1. $\mathrm{missing}.\mathrm{node}\leftarrow \mathrm{\varnothing }$;

2. Retrieve all nodes in CBPMN,

3. Calculate the in_degree(x) and out_degree(x) of E, A, D, M and G.

4. $\mathrm{isolated}\text{\_}\mathrm{nodes}\leftarrow \mathrm{\varnothing }$$, \mathrm{invalid}\text{\_}\mathrm{start}\text{\_}\mathrm{nodes}\leftarrow \mathrm{\varnothing }$$, \mathrm{invalid}\text{\_}\mathrm{end}\text{\_}\mathrm{nodes}\leftarrow \mathrm{\varnothing }$,

$\hspace{1em} \mathrm{redundant}\text{\_}\mathrm{start}\text{\_}\mathrm{E}\leftarrow \mathrm{\varnothing }$$, \mathrm{redundant}\text{\_}\mathrm{end}\text{\_}\mathrm{E}\leftarrow \mathrm{\varnothing }$;

(2) verification

5. for each node x in X do

6. $\hspace{1em} \mathrm{if} \mathrm{i}\mathrm{n}\text{\_}\mathrm{d}\mathrm{e}\mathrm{g}\mathrm{r}\mathrm{e}\mathrm{e}\left(\mathrm{x}\right)==0$ and out_degree(x)$==0$ then

7. $\hspace{1em}\hspace{1em} \mathrm{isolated}\text{\_}\mathrm{nodes}\leftarrow \mathrm{i}\mathrm{s}\mathrm{o}\mathrm{l}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{d}\text{\_}\mathrm{n}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{s}\cup \left\{\mathrm{x}\right\}$;

8. $\hspace{1em} \mathrm{if} \mathrm{i}\mathrm{n}\text{\_}\mathrm{d}\mathrm{e}\mathrm{g}\mathrm{r}\mathrm{e}\mathrm{e}\left(\mathrm{x}\right)==0$$\mathrm{and} \mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\left(\mathrm{x}\right)= ! \mathrm{E}$ then

9. $\hspace{1em}\hspace{1em} \mathrm{invalid}\text{\_}\mathrm{start}\text{\_}\mathrm{nodes}\leftarrow$$\mathrm{invalid}\text{\_}\mathrm{start}\text{\_}\mathrm{nodes}\cup \left\{\mathrm{x}\right\}$;

10. $\hspace{1em}\mathrm{if} \mathrm{o}\mathrm{u}\mathrm{t}\text{\_}\mathrm{d}\mathrm{e}\mathrm{g}\mathrm{r}\mathrm{e}\mathrm{e}\left(\mathrm{x}\right)==0$$\mathrm{and} \mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\left(\mathrm{x}\right)= ! \mathrm{E}$ then

11. $\hspace{1em}\hspace{1em}\mathrm{invalid}\text{\_}\mathrm{end}\text{\_}\mathrm{nodes}\leftarrow$$\mathrm{invalid}\text{\_}\mathrm{end}\text{\_}\mathrm{nodes}\cup \left\{\mathrm{x}\right\}$;

12. end for

13. for each PL do

14. $\hspace{1em} \mathrm{if} \mathrm{i}\mathrm{n}\text{\_}\mathrm{d}\mathrm{e}\mathrm{g}\mathrm{r}\mathrm{e}\mathrm{e}\left(\mathrm{x}\right)==0$ then

15. $\hspace{1em}\hspace{1em} \mathrm{start}\text{\_}\mathrm{nodes}\leftarrow$$\mathrm{start}\text{\_}\mathrm{nodes} \cup \left\{\mathrm{x}\right\}$; //Find all start nodes in PL

16. $\hspace{1em} \mathrm{if} \mathrm{o}\mathrm{u}\mathrm{t}\text{\_}\mathrm{d}\mathrm{e}\mathrm{g}\mathrm{r}\mathrm{e}\mathrm{e}\left(\mathrm{x}\right)==0$ then

17. $\hspace{1em}\hspace{1em} \mathrm{end}\text{\_}\mathrm{nodes}\leftarrow$$\mathrm{end}\text{\_}\mathrm{nodes} \cup \left\{\mathrm{x}\right\}$; //Find all end nodes in PL

18.   if PL has no sub-L then

19. $\hspace{1em}\hspace{1em}\hspace{1em}\mathrm{if} E\cap \mathrm{s}\mathrm{t}\mathrm{a}\mathrm{r}\mathrm{t}\text{\_}\mathrm{n}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{s}=\mathrm{\varnothing }$ then

20. $\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\mathrm{missing}.\mathrm{node}\leftarrow \mathrm{m}\mathrm{i}\mathrm{s}\mathrm{s}\mathrm{i}\mathrm{n}\mathrm{g}.\mathrm{n}\mathrm{o}\mathrm{d}\mathrm{e}\cup \{"{\mathrm{E}}_{\mathrm{S}} \mathrm{f}\mathrm{o}\mathrm{r} \mathrm{P}\mathrm{L}"\}$

21. $\hspace{1em}\hspace{1em}\hspace{1em}\mathrm{if} E\cap \mathrm{e}\mathrm{n}\mathrm{d}\text{\_}\mathrm{n}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{s}=\mathrm{\varnothing }$ then

22. $\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\mathrm{missing}.\mathrm{node}\leftarrow \mathrm{m}\mathrm{i}\mathrm{s}\mathrm{s}\mathrm{i}\mathrm{n}\mathrm{g}.\mathrm{n}\mathrm{o}\mathrm{d}\mathrm{e}\cup \{"{\mathrm{E}}_{\mathrm{E}} \mathrm{f}\mathrm{o}\mathrm{r} \mathrm{P}\mathrm{L}"\}$

23. $\hspace{1em} \mathrm{if} \mathrm{count}({\mathrm{E}}_{\mathrm{S}}\cap \mathrm{s}\mathrm{t}\mathrm{a}\mathrm{r}\mathrm{t}\text{\_}\mathrm{n}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{s})>\mathrm{c}\mathrm{o}\mathrm{u}\mathrm{n}\mathrm{t}(\mathrm{L}.\mathrm{P}\mathrm{L})$ then

24. $\hspace{1em}\hspace{1em}\hspace{1em} \mathrm{redundant}\text{\_}\mathrm{start}\text{\_}\mathrm{E}\leftarrow \mathrm{r}\mathrm{e}\mathrm{d}\mathrm{u}\mathrm{n}\mathrm{d}\mathrm{a}\mathrm{n}\mathrm{t}\text{\_}\mathrm{s}\mathrm{t}\mathrm{a}\mathrm{r}\mathrm{t}\text{\_}\mathrm{E}\cup \left\{{\mathrm{E}}_{\mathrm{S}}\right\}$;

25. $\hspace{1em} \mathrm{if} \mathrm{count}({\mathrm{E}}_{\mathrm{E}}\cap \mathrm{e}\mathrm{n}\mathrm{d}\text{\_}\mathrm{n}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{s})>\mathrm{c}\mathrm{o}\mathrm{u}\mathrm{n}\mathrm{t}(\mathrm{L}.\mathrm{P}\mathrm{L})$ then

26. $\hspace{1em}\hspace{1em}\hspace{1em} \mathrm{redundant}\text{\_}\mathrm{end}\text{\_}\mathrm{E}\leftarrow \mathrm{r}\mathrm{e}\mathrm{d}\mathrm{u}\mathrm{n}\mathrm{d}\mathrm{a}\mathrm{n}\mathrm{t}\text{\_}\mathrm{e}\mathrm{n}\mathrm{d}\text{\_}\mathrm{E}\cup \left\{{\mathrm{E}}_{\mathrm{E}}\right\}$;

27. end for

28. Print all isolated_nodes, invalid_start_nodes, invalid_end_nodes;

29. Print all redundant_start_E, redundant_end_E;

Whether the CBPMN model fulfills the original requirements can be detected by checking the condition of the target input and output modules in the CPN model. Thus, according to the traceability of the PRBC modeling approach, to verify the realizability of requirements, the reachability of CPN shall be tested.

Definition 5. 

Reachability of CPN Model

Let $CPN=(P,T,Arc,\sum ,V,f,I)$ be a CPN model. If there exists a t∈ T such that $I_0$ [t > $I_x$, then $I_x$ is said to be directly reachable from $I_0$. If there exists a sequence of transitions $t_1$, $t_2$, …, $t_k$ and a sequence of identifiers $I_1$, $I_2$, …, $I_k$ such that $I_1$ [$t_1$ > $I_2$[$t_2$ > … > $I_{k-1}$[$t_k$ > $I_k$, then $I_k$ is said to be reachable from $I_1$. “$I_0$[t > $I_x$” means that identifier “$I_0$“ will change to $I_x$ after transition t is fired.

If an arbitrary ${\mathrm{I}}_{\mathrm{x}}$ belonging to the set I of CPN is reachable from the initial identifier ${\mathrm{I}}_0$, then the reachability of CPN meets the standard, and the corresponding CBPMN model is executable.

When addressing a complex problem involving many nodes, the overall requirement description is always divided into several modules or function points, and each part is analyzed and designed separately. The PRBC modeling approach allows the incremental improvement of requirements and helps to accelerate the requirement modeling process. By leveraging human–computer collaboration, the requirements can be optimized continuously. As outlined in Figure 5, the requirement increment will be transformed into PFM models through the prompts provided in Table 2, Table 3 and Table 4; then, the new set of PFM models will be altered into a RBPMN model set. Subsequently, Algorithm 1 takes this RBPMN set and the previous CBPMN model as its input (where the previous CBPMN is assigned as the initial value in Lines 1–2) to generate a new CBPMN model through merging. The following verification results of Algorithm 2 and CPN simulation will decide the inspector’s choice for the new CBPMN model to get feedback or a confirmation.

Figure 5. Business process iterative modeling method.

5. Experimental Design and Case Study

This paper proposes the PRBC, a modeling and verification framework for business process models under the requirement perspective. Compared with other methods, this method can generate a higher quality BPMN model through chatting with the requirement provider. To prove this conclusion, two research questions were delivered with a corresponding case study to demonstrate the validity of the PRBC.

Research question 1: How does the quality of the PFM model generated by the PRBC in the requirement modeling process compare to other methods? In Section 5.2, we calculate three indices of the generated PFM models utilizing the PRBC method on five cases and conduct comparative experiments with three other automated methods.

Research question 2: Can the PRBC method convert the requirements description in dialogue into a complete CBPMN model that meets the reachability standard in definition 5? Question 2 aims to prove the validity of the generated CBPMN. In Section 5.3, we built an online car-hailing CBPMN model through a set of tools that automate the generation of the model and verification.

Before the case study, Section 5.1 will introduce the configuration settings in the experiments.

5.1. Configuration Settings in the Experiments

(1)

Cases used for experiments. Five publicly available cases were adopted as a raw data set for evaluating the quality of the requirement modeling part in PRBC. The five cases are the Automated Teller Machine (ATM) [38], Data Set Searching System (DSSS) [39], Elevator System (ES) [40], SmartNet System (SNS) [41], and CamperPlus (CPs) [42]. Each case is composed of a detailed requirement description and a standardized requirement model. In addition, for research question 2, an actual application system based on the comprehensive requirement of a car-hailing system [43,44,45] is chosen as the research case for modeling and verification.

(2)

Baseline method. This paper employed three automated modeling approaches as the baseline method to compare with the PRBC; the three methods are introduced as follows:

(1)

The GSD [38] method generates a sequence diagram by defining NLP rules extracting actors, senders, and receivers from processed natural language;

(2)

The AEPD [46] method generates a problem diagram through function modules entity extractor, relation predictor, and element assembler;

(3)

The TtMT [47] method adjusts the operation in natural language processing while extracting and selecting information and generates models conforming to the SysML standard, such as a class diagram from input textual requirements.

(3)

Configuration settings of models and algorithm in the PRBC framework.

The technical implementation routine is shown in Figure 6. This paper uses two open-source LLMs, DeepSeek-V3 for chatting and Deepseek-R1 for model reasoning. DeepSeek-V3 supports the dialogue module and can generate responses according to prompts in Table 2 and Table 4; the chatting records will be transformed into JSON format and sent to an NLP module named Stanford NLP, which can be invoked through Python 3.14 after the Stanford CoreNLP Python interface is installed; the keywords will be sorted by algorithm BM25, which is available for download at https://github.com/xhluca/bm25s (accessed 1 December 2024), and the selected phrases and keywords will be packed together and sent to Deepseek-R1, which integrates a web searching function to build the PFM model according to the prompts in Table 3 and Table 4. The generated PFM model will be validated by JSON Schema and sent to Plant Text to implement the visualization of the PFM model. The mapping function $\psi$ will transform PFM to RBPMN models through a JSON2BPMN converter (accessed on 12 September 2024, from https://github.com/taoxiaotao6/bpmn_converter), while the BPMN editor (accessed on 12 December 2024, from https://bpmn.io/toolkit/bPMn-js/) can export BPMN diagrams and the corresponding XML format. The PNML is an XML-based markup language, which uses tags to describe the data. Thus, based on the mapping function ϕ and a BPMN2CPN script, the CBPMN can be transformed to a CPN model through Java 8.

Figure 6. PRBC technical realization process.

5.2. Requirement Modeling Quality Evaluation

In order to evaluate the quality of the requirement model PFM generated by the LLMs and prompts in Section 4.1, this experiment chooses to compare the PRBC with three advanced requirements automatic modeling methods introduced in Section 5.1 (2) on five publicly available cases in Section 5.1 (1), and it calculates the accuracy, recall, and F1 value of the requirements’ modeling elements generated from the requirements’ description of the provider.

(1)

Experiment procedure: The experiment starts by tuning two hyperparameters (the temperature and the max tokens) in DeepSeek-V3 and Deepseek-R1. With the prompt templates from Table 2, Table 3 and Table 4, the chat module asks the provider questions, according to the model elements and collects answers to construct the requirement models. As for the other three methods, we maintain the infrastructure of prompts and change the model elements marked by the symbol “<>”. To keep the initial input information amount at the same quantity level, the requirement description of every case is simplified to a document, the provider will answer the questions according to the same document, and the number of interaction rounds between the provider and chat module is capped at 10. The record of dialogue will be divided into pieces related to different PFM model elements through two external function modules, the information extracting module through the ranking and retrieving module, and the processed package will be processed in Deepseek-R1 to generate the model in JSON format.

(2)

Index chosen and calculation formula: Due to the difference among the output formats of the methods mentioned above, this paper selects the precision, recall, and F1-score as the evaluation metrics to guarantee the equity in the experiment.

$$\mathrm{P}\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{i}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n}={\displaystyle \frac{\mathrm{N}\mathrm{u}\mathrm{m}\mathrm{b}\mathrm{e}\mathrm{r} \mathrm{o}\mathrm{f} \mathrm{c}\mathrm{o}\mathrm{r}\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{t} \mathrm{e}\mathrm{l}\mathrm{e}\mathrm{m}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{s} \mathrm{i}\mathrm{n} \mathrm{t}\mathrm{h}\mathrm{e} \mathrm{g}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{d} \mathrm{m}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{l}}{\mathrm{T}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l} \mathrm{e}\mathrm{l}\mathrm{e}\mathrm{m}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{s} \mathrm{n}\mathrm{u}\mathrm{m}\mathrm{b}\mathrm{e}\mathrm{r} \mathrm{o}\mathrm{f} \mathrm{t}\mathrm{h}\mathrm{e} \mathrm{g}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{d} \mathrm{m}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{l}}},$$

(40)

$$\mathrm{R}\mathrm{e}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{l}={\displaystyle \frac{\mathrm{N}\mathrm{u}\mathrm{m}\mathrm{b}\mathrm{e}\mathrm{r} \mathrm{o}\mathrm{f} \mathrm{c}\mathrm{o}\mathrm{r}\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{t} \mathrm{e}\mathrm{l}\mathrm{e}\mathrm{m}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{s} \mathrm{i}\mathrm{n} \mathrm{t}\mathrm{h}\mathrm{e} \mathrm{g}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{d} \mathrm{m}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{l}}{\mathrm{T}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l} \mathrm{e}\mathrm{l}\mathrm{e}\mathrm{m}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{s} \mathrm{n}\mathrm{u}\mathrm{m}\mathrm{b}\mathrm{e}\mathrm{r} \mathrm{o}\mathrm{f} \mathrm{t}\mathrm{h}\mathrm{e} \mathrm{s}\mathrm{t}\mathrm{a}\mathrm{n}\mathrm{d}\mathrm{a}\mathrm{r}\mathrm{d} \mathrm{m}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{l}}},$$

(41)

$$\mathrm{F}1=2{\displaystyle \frac{\mathrm{P}\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{i}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n} \mathrm{R}\mathrm{e}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{l}}{\mathrm{P}\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{i}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n}+\mathrm{R}\mathrm{e}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{l}}}.$$

(42)

(3)

Hyperparameter tuning: While keeping the prompt templates, case sets, the chatting and reasoning LLMs, and the input information quantity constant, we performed hyperparameter tuning manually for the temperature over the range of (0, 1) and max_tokens over the range of (500, 4000). The experiment finds that the best temperature of Deepseek-R1 is 0.5m and the max_tokens is 2048 tokens. When the two hyperparameters are set to the above value, the calculation results of the three indices for the requirement models generated by the PRBC and three other methods are shown in Table 8.

Table 8. Evaluation results between PRBC and other methods on modeling quality.

	Case Name	ATM	SNS	CPs	ES	DSSS
Method name
PRBC	Recall	82.1%	72.8%	87.1%	81.6%	82.1%
	Precision	92.5%	90.5%	81.5%	78.5%	84.5%
	F1-score	87.0%	80.7%	84.2%	80.0%	83.3%
GSD	Recall	83.3%	72.1%	56.9%	78.4%	82.5%
	Precision	55.6%	82.6%	69.8%	63.0%	72.0%
	F1-score	66.7%	77.0%	62.7%	69.9%	76.9%
AEPD	Recall	75.0%	71.8%	72.0%	80.6%	67.0%
	Precision	69.1%	67.1%	82.1%	67.1%	46.1%
	F1-score	71.9%	69.7%	76.7%	73.2%	54.6%
TtMT	Recall	58.3%	52.7%	59.4%	49.3%	68.3%
	Precision	56.4%	35.4%	61.1%	66.7%	75.1%
	F1-score	57.3%	42.3%	60.2%	56.7%	71.5%

(4)

Results analysis: The three indices are calculated by invoking Scikit-learn via Python. As can be seen in Table 8, except for yielding comparable results to the GSD method on the ATM case, the PRBC achieved higher performance on the recall value over other methods; similarly, apart from achieving comparable results to the AEPD method on the CP case, the PRBC markedly outperforms other baseline methods. Additionally, the PRBC demonstrates superior performance over other methods on the F1-score, maintaining an improvement difference value over 3% (at least). Thus, across multiple cases, the PRBC establishes a clear and consistent advantage over the baseline, as evidenced by its results in all three key metrics.

(5)

Statistical significance: The permutation test is conducted to assess the uncertainty of results in Table 8. The p-value is 0.049.

(6)

Impacts of dialogue length: To explore how the method performs in longer dialogue, the DSSS case was chosen for the experiment, with the number of dialogue rounds ranging from 5 to 30. The benchmark system uses only the original history, and the enhanced memory system uses external memory. It can be clearly seen from Figure 7 that the two curves of the benchmark system show a significant and continuous decline, while the enhanced system is significantly more gradual. That indicates the context loss impacts the model consistency over the text length.

Figure 7. Performance trends in long conversation.

5.3. Verification of the Business Process Model

This section will represent the modeling process of a CBPMN model, as well as the rationality verification of the static flow and the executable verification of it through a car-hailing system case.

(1)

Case introduction: With the rise of private car ownership, online car-hailing has emerged as a mainstream option for transportation. It is now common to use mobile apps and high-speed networks to benefit from this convenience. Given its prevalence as a ride-hailing platform, this paper employs an example based on the Didi Chuxing system to demonstrate the feasibility of our approach.

(2)

Case modeling: The requirements description of car-hailing was put into the LLMs through the dialogue; then, the LLMs generated the PFM model description according to the output format, which is partially shown in Table 9. This can be transformed into a PFM diagram through tool Plant Text, shown in Figure 8a,b.

Table 9. Partial output result of car-hailing system requirement model.

The 0000 PFM model is composed of 4 sub-problem models; the sub-problem models will be displayed in turn. 1. PFM-1 Re: <hailing> PD: <Driver>, <Passenger>, <Hailing system>; RPh: <Order>, <Find Driver>, <Send Order>, <Car Confirm>, <Rush to Order> SPh: <Personal preference>, <Order info>, <Driver info> <Order list>, <Car info>, <Send signal>; V: <cartype,Slocation,Glocation,PassengerID>, <orderID,Slocation,Glocation,PassengerID>, <Dlocation,Order status,Car ID>, <orderIDlist,Slocation,Glocation,PassengerID>, … f-RP: <[hailing][Driver,Hailing system, Passenger$]$>; f-PRh: <[Passenger][Order], [Hailing system][Find Driver,Send Order,Car Confirm], [Driver][Rush to Order]>; f-RhS: <[Order][Personal preference,Order info], [Find Driver][Order info,Driver info],…; f-ShV: <[Personal preference][cartype,Slocation,Glocation,PassengerID], …;For Re set, f-R can be represented as follows: [Parallel][0$]$, [Exclusive][($\mathrm{O}\mathrm{r}\mathrm{d}\mathrm{e}\mathrm{r} \mathrm{r}\mathrm{e}\mathrm{s}\mathrm{p}\mathrm{o}\mathrm{n}\mathrm{d},0$), …], [Sequential][(Order, Trip confirmation), …], [0][(Order, Rush to order),…]; For RPh set, Q can be represented as follows: (Order, Trip confirmation),…; For relations between layer RPh set and SPh set, the f-RhS will be attached with an weight matrix, shown as below: [d] <RPh-i,SPh-i,>. d = −1, 0, 1; d<Order, Personal preference>=−1; d<Order, Order info> = 1,…; 2. PFM-2 Re: <riding> PD: <Driver>, <Passenger>, <Hailing system>; RPh: <Trip confirmation>, <Ride on>, <Car confirm>, <External communication>, <Order respond>…; Requirement reference: <hailing to passenger>, <hailing to information storage >, …; SPh: <Request>, <Car info>, <Rush result>, <Tel>, <Routine info>; V: <orderID,Slocation>, <orderID,DriverID,Dlocation,PassengerID>, <OrderID, pair result>, <orderID,PassengerID,Slocation,Alocation,Price>; f-RP: <[riding][Driver,Hailing system, Passenger$]$>; f-PRh: <[Passenger][Trip confirmation, Ride on], [Hailing system][Car Conform,External communication], [Driver][Order respond,Carry passenger,Arrive confirm]>; f-RhS: <[Trip confirmation][Request,Car info], [Ride on][0], …; f-ShV: <[Personal preference][cartype,Slocation,Glocation,PassengerID], …>; …

Figure 8. (a) The PFM model of the car-hailing system. (b). The residue PFM model of the car-hailing system.

(3)

Rationale verification of static flow: The element set of PFM was converted into the corresponding RBPMN models in Figure 9, according to the mapping rules shown in Table 5. Then, the four RBPMN set groups were combined according to Algorithm 1, and the output model is shown in Figure 10. The result of Algorithm 2 illustrated that there are two isolated nodes (“Ride on” and “Carry passenger”) in the hailing system CBPMN model.

Figure 9. The RBPMN models corresponding to PFM models. (a) The hailing RBPMN model; (b) the riding RBPMN model; (c) the payment RBPMN model; (d) the order reject RBPMN model.

Figure 10. The complete CBPMN model of the hailing system.

(4)

The executable verification: Following the mapping rule $\varphi$ in Table 7, we converted the requirement description of the car-hailing system into an executable CPN model. Next, the obtained CPN model was verified by checking the reachability and liveness through CPN Tools 4.0. From the condition of the simulation, we find that there is no dead transition, dead lock, live lock, or dead markings in the CPN model, which can be proven by the state–space report shown in Table 10. Based on the simulation result shown in Figure 11, the operation path and results of the model met the requirements of the initial problem diagram and PFM model.

Table 10. State–space report of the car-hailing system CPN model.

Statistics	Liveness Properties
State Space Nodes: 12,954 Arcs: 42,068 Secs: 0 Status: Full Scc Graph Nodes: 12,954 Arcs: 42,068 Secs: 1 Boundedness Properties	Dead Markings None Dead Transition Instances None Live Transition Instances None Fairness Properties
Home Properties	No infinite occurrence sequences.
Home Markings None

Figure 11. The simulation model of the car-hailing system in CPN tools.

Therefore, after the analysis of the simulation result and the observation of the actual operation process, it is demonstrated that the business process iterative modeling approach is effective.

6. Conclusions

The lack of systematic iterative requirement modeling methods and tools hampers business process modeling. To address this: (1) we propose a framework of iterative business process modeling to integrate the tools from the requirement model establishment to business process model execution and to bridge the gap between requirement elicitation and business process modeling and verification; (2) we present a requirement model based on the automatic language processing ability of large language models to reduce the labor; (3) we verify the feasibility and usability of the proposed method by experiments of simulation and verification; (4) we put forward two algorithms, one for generating the CBPMN model from the RBPMN model set and another for verification of the newly generated CBPMN model.

The iterative requirement modeling method embraces the concept of continuous integration, effectively combining requirements analysis, design, simulation, and verification to create a comprehensive business process modeling routine. This approach addresses the inflexibility and rigidity often encountered in verification within traditional business process modeling and requirements verification.

In this paper, due to the space constraints and thematic considerations, the formal consistency of verification has not been discussed. Additionally, the behavior verification methods and standards of requirements will be investigated in the follow-up study.