Business demand confirmation method and system based on cloud platform

Abstract

The present invention provides a business demand confirmation method and system based on a cloud platform, which relates to the technical field of cloud platforms, including building a business process engine on a cloud platform according to business scenarios and business rules, visually modeling business demands through the business process engine, and generating a standardized business demand model; deploying a demand verification service on the cloud platform, and automatically verifying the formally expressed business demand logic through a formal verification method of control flow analysis or data flow analysis in combination with the business domain ontology model, and generating a demand verification report; judging whether there is a semantic contradiction or a logical loophole in the business demand logic according to the demand verification report, and when a semantic contradiction or a logical loophole is detected, the business demand logic that fails the verification is corrected in combination with the business domain ontology model. Deploy a demand collaboration service on the cloud platform, and publish the corrected business demand logic in the form of a standardized interface for subscription by collaborating parties.

Description

Technical Field

[0001] The present invention relates to cloud platform technology, and in particular to a method and system for confirming business requirements based on a cloud platform. Background Art

[0002] Traditional business requirement confirmation mainly relies on manual methods, such as obtaining requirement information through face-to-face communication with customers and document analysis. This method is time-consuming and labor-intensive, and is prone to problems such as missing requirements and misunderstandings, making it difficult to meet the increasingly complex requirements of software system development.

[0003] In recent years, the rise of cloud computing technology has provided new ideas and means for business demand confirmation. Moving the demand management process to the cloud platform and taking advantage of the cloud platform's massive storage, high-performance computing, and elastic expansion can significantly improve the efficiency and quality of demand information collection, processing, and analysis. At present, academia and industry have begun to explore the practice of demand engineering supported by cloud platforms, and some representative research results and application cases have emerged.

[0004] Among them, domestic and foreign scholars have proposed a variety of cloud-based demand acquisition methods. Liu et al. designed a collaborative demand acquisition cloud platform that supports multi-role participation in demand negotiation and decision-making. Chen et al. developed a demand crowdsourcing cloud system that uses a crowdsourcing model to collect multi-source heterogeneous user needs. Hosseini et al. proposed a cloud-based demand priority calculation method that automatically prioritizes demand through a machine learning algorithm. These studies have expanded the application of cloud platforms in demand acquisition, but they mainly focus on the collection and expression of demand, and lack systematic guidance for the subsequent demand confirmation process. Summary of the invention

[0005] The embodiments of the present invention provide a method and system for confirming business requirements based on a cloud platform, which can solve the problems in the prior art.

[0006] According to a first aspect of the embodiments of the present invention,

[0007] Provides a cloud platform-based business requirements confirmation method, including:

[0008] According to business scenarios and business rules, a business process engine is built on the cloud platform, and business requirements are visually modeled through the business process engine to generate a standardized business requirement model; based on the business requirement model, a demand management microservice is deployed on the cloud platform, and the business requirement model is intelligently parsed through the demand management microservice to extract key information of business requirements and generate a structured demand description document;

[0009] Use natural language processing technology to perform semantic analysis on the demand description document, establish a business domain ontology model through knowledge graph construction technology, map the unstructured text in the demand description document to the concept nodes in the business domain ontology model, and formally represent the business demand logic; deploy the demand verification service on the cloud platform, and automatically verify the formally represented business demand logic through the formal verification method of control flow analysis or data flow analysis in combination with the business domain ontology model to generate a demand verification report;

[0010] Based on the demand verification report, determine whether there are semantic contradictions or logical loopholes in the business demand logic. When semantic contradictions or logical loopholes are detected, correct the business demand logic that fails the verification in combination with the business domain ontology model; deploy the demand collaboration service on the cloud platform, and publish the corrected business demand logic in the form of a standardized interface for subscription by collaborating parties.

[0011] In an optional embodiment,

[0012] According to business scenarios and business rules, a business process engine is built on the cloud platform. Business requirements are visualized and modeled through the business process engine to generate a standardized business requirement model including:

[0013] Build a business process engine on the cloud platform and complete the deployment of the business process engine through the services provided by the cloud platform according to the scale and complexity of the business scenario; define process modeling elements in the business process engine and design a graphical interface for process modeling; introduce a rule management module into the business process engine to achieve decoupling of business rules and business processes;

[0014] Using the visual modeling function provided by the business process engine, identify the elements involved in business requirements and build a business domain model; abstract the business activities in business requirements into task nodes, use connecting lines to define the execution order and dependency relationships between business activities, introduce gateway nodes to implement branching and merging of business activities, and embed business rules into corresponding task nodes;

[0015] According to the process modeling standard, each node and connection line in the business domain model is labeled with type and attribute configuration, and the business rules are mapped and bound to the task nodes through the interface of the rule engine to generate a standardized business demand model.

[0016] In an optional embodiment,

[0017] Based on the business demand model, a demand management microservice is deployed on the cloud platform. The business demand model is intelligently parsed by the demand management microservice to extract key business demand information and generate a structured demand description document including:

[0018] A demand management microservice architecture is built on the cloud platform. The demand management microservice architecture adopts a design mode of front-end and back-end separation, and divides the core service modules into demand metadata management module, demand document generation module, demand change management module and demand tracking and analysis module.

[0019] The demand metadata management module is responsible for storing and managing the metadata in the business demand model; the demand document generation module is responsible for automatically generating structured demand description documents based on the business demand model; the demand change management module is responsible for processing demand change requests and evaluating the impact of the change; the demand tracking and analysis module is responsible for recording the life cycle status of the demand and analyzing the progress and quality of the demand implementation;

[0020] Utilize the PaaS service provided by the cloud platform, encapsulate the demand management microservice architecture into a standardized deployment unit through containerization technology, and use container orchestration tools to achieve automated deployment, orchestration, and scheduling of microservices. At the same time, combine the monitoring and log services of the cloud platform to conduct real-time monitoring and early warning of the operating status and performance indicators of the standardized deployment units.

[0021] The unstructured text description information in the business demand model is preprocessed through the demand management microservice architecture in the cloud platform, and the key terms and concepts in the business demand are standardized and semantically disambiguated by constructing a demand domain ontology and dictionary. Then, the key entities, attributes and relationships in the business demand description are identified using semantic role labeling technology, and a semantic dependency graph corresponding to the business demand is constructed.

[0022] Based on the semantic dependency graph, rule-based and learning-based methods are used to further extract and organize business requirements to generate structured requirement description documents; the rule-based method uses predefined templates and rule matching to extract key elements of goals, processes, data, and constraints in business requirements, and the learning-based method uses deep learning models to automatically learn and extract patterns and features of business requirement elements from large-scale requirement corpora, ultimately achieving information extraction and structured representation of the business requirement model.

[0023] In an optional embodiment,

[0024] Deploy the requirement verification service on the cloud platform, and automatically verify the formalized business requirement logic by using the formal verification method of control flow analysis or data flow analysis combined with the business domain ontology model. Generate a requirement verification report including:

[0025] Deploy a requirement verification service on the cloud platform. The requirement verification service includes two core components: a formalization engine and a reasoning engine. The formalization engine is responsible for converting structured business requirements into formalized requirement specifications, and the reasoning engine is responsible for automated verification and problem detection of formalized requirement specifications.

[0026] Convert the extracted structured process requirements into a Petri net model, map the process activities into transitions, map the process data and states into places, and map the sequential relationships between activities into directed arcs by defining mapping rules. Then use the Petri net analysis technology to verify the control flow of the generated Petri net model, check the abnormal states of deadlock and livelock by building a reachable graph, verify the completeness and termination of the process by calculating invariants, check the consistency and certainty of the process by analyzing conflicts and concurrency relationships, and generate counterexample paths and repair suggestions for the detected problems.

[0027] The extracted structured requirement description document is converted into a data flow diagram model. By defining mapping rules, the data objects in the requirements are mapped into data elements, and the data processing activities are mapped into processing processes. Then, the generated data flow diagram model is verified using abstract interpretation technology to generate a requirement verification report.

[0028] In an optional embodiment,

[0029] The method further comprises:

[0030] Construct a business domain ontology model for requirement verification, use ontology description language and ontology development tools to build a general requirement verification ontology framework, instantiate and expand the ontology for specific business domains, design semantic reasoning rules based on the business domain ontology model, check whether the key terms in the requirement statement are clearly defined in the ontology by defining concept matching rules, and check whether the attribute assignment in the requirement statement meets the data type and value range restrictions in the ontology by defining attribute constraint rules;

[0031] The semantic reasoning engine is used to perform semantic verification on the formally expressed requirement statements. The semantic consistency between the requirement statements and the domain ontology is automatically checked through the logical reasoning algorithm. The semantic defects and errors in the requirement statements are inferred, and intuitive problem descriptions and modification suggestions are generated for the detected semantic problems.

[0032] In an optional embodiment,

[0033] According to the requirement verification report, judging whether there is a semantic contradiction or a logical loophole in the business requirement logic, and when a semantic contradiction or a logical loophole is detected, correcting the business requirement logic that fails the verification in combination with the business domain ontology model includes:

[0034] Convert the process model containing process deadlock defects into a Petri net representation, and use the formal semantics of Petri nets to explicitly model process activities, resources, and control flow relationships;

[0035] Based on the Petri net model, the reachability graph analysis is performed to identify the deadlock state in the Petri net by searching for the termination node in the reachability graph. The termination node indicates that there is no migration that can be triggered in the current state.

[0036] For each deadlock state, a corresponding deadlock dependency graph is generated. The nodes in the deadlock dependency graph represent the resources and migrations that cause the deadlock, and the edges represent the resource application and occupancy dependencies. The deadlock dependency graph describes the resource constraints that form the deadlock loop.

[0037] Run the minimum cut algorithm on the deadlock dependency graph to find the resource dependency edge set that can cut off the deadlock loop and minimize the modification cost. The minimum cut algorithm ensures that the adjustment to the original process structure is minimized while breaking the deadlock.

[0038] Generate a process modification plan based on the minimum cost edge set, and automatically recommend specific modification operations such as adjusting the resource application sequence, increasing resource capacity, and inserting a synchronization mechanism by combining the semantic information of process activity resources and expert modification rules;

[0039] The deadlock reachability of the process modification plan is re-verified based on Petri nets to ensure that the process modification plan effectively eliminates the deadlock and does not introduce new defects.

[0040] According to a second aspect of the embodiments of the present invention,

[0041] Provide a cloud-based business requirements confirmation system, including:

[0042] The first unit is used to build a business process engine on the cloud platform according to business scenarios and business rules, and to perform visual modeling of business requirements through the business process engine to generate a standardized business requirement model; based on the business requirement model, a demand management microservice is deployed on the cloud platform, and the business requirement model is intelligently parsed through the demand management microservice to extract key information of business requirements and generate a structured demand description document;

[0043] The second unit is used to perform semantic analysis on the demand description document using natural language processing technology, establish a business domain ontology model through knowledge graph construction technology, map the unstructured text in the demand description document to the concept nodes in the business domain ontology model, and formally represent the business demand logic; deploy the demand verification service on the cloud platform, and automatically verify the formally represented business demand logic through the formal verification method of control flow analysis or data flow analysis in combination with the business domain ontology model to generate a demand verification report;

[0044] The third unit is used to determine whether there is a semantic contradiction or logical loophole in the business demand logic based on the demand verification report. When a semantic contradiction or logical loophole is detected, the business demand logic that fails the verification is corrected in combination with the business domain ontology model; the demand collaboration service is deployed on the cloud platform, and the corrected business demand logic is published in the form of a standardized interface for subscription by the collaborating parties.

[0045] According to a third aspect of the embodiments of the present invention,

[0046] An electronic device is provided, comprising:

[0047] processor;

[0048] a memory for storing processor-executable instructions;

[0049] The processor is configured to call the instructions stored in the memory to execute the aforementioned method.

[0050] According to a fourth aspect of the embodiments of the present invention,

[0051] A computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the aforementioned method is implemented.

[0052] The traditional rule management method is to hard-code business rules in the process, which leads to tight coupling between rules and processes and high maintenance costs. To this end, this method introduces an independent rule management module in the business process engine to decouple business rules from business processes. This application proposes a business demand visualization modeling method based on a cloud platform. By building a business process engine in a cloud environment and using the visualization modeling and rule management capabilities of the process engine, unstructured business requirements are converted into structured process models and rule definitions, thereby providing a formal representation method for demand confirmation.

[0053] Through demand preprocessing, ontology and dictionary construction, semantic role labeling, rule-based and learning-based information extraction, etc., structured and standardized demand descriptions are extracted from unstructured demand texts, providing a solid foundation for subsequent demand confirmation, design and development. At the same time, with the elastic scaling and microservice architecture of the cloud platform, the system has good concurrent processing capabilities and scalability, and can efficiently cope with large-scale and rapidly changing demand scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 A schematic diagram of a process of confirming a business requirement based on a cloud platform according to an embodiment of the present invention;

[0055] Figure 2 It is a structural diagram of a business demand confirmation system based on a cloud platform according to an embodiment of the present invention. DETAILED DESCRIPTION

[0056] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0057] The technical solution of the present invention is described in detail with specific embodiments below. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0058] Figure 1 FIG. 1 is a flow chart of a method for confirming business requirements based on a cloud platform according to an embodiment of the present invention. Figure 1 As shown, the method includes:

[0059] S101. According to the business scenarios and business rules, a business process engine is built on the cloud platform, and business requirements are visually modeled through the business process engine to generate a standardized business requirement model; based on the business requirement model, a demand management microservice is deployed on the cloud platform, and the business requirement model is intelligently parsed through the demand management microservice to extract key information of business requirements and generate a structured demand description document;

[0060] S102. Perform semantic analysis on the demand description document using natural language processing technology, establish a business domain ontology model using knowledge graph construction technology, map the unstructured text in the demand description document to the concept nodes in the business domain ontology model, and formally represent the business demand logic; deploy a demand verification service on the cloud platform, and automatically verify the formally represented business demand logic through formal verification methods such as control flow analysis or data flow analysis in combination with the business domain ontology model, and generate a demand verification report;

[0061] S103. Based on the demand verification report, determine whether there are semantic contradictions or logical loopholes in the business demand logic. When semantic contradictions or logical loopholes are detected, correct the business demand logic that fails the verification in combination with the business domain ontology model; deploy the demand collaboration service on the cloud platform, and publish the corrected business demand logic in the form of a standardized interface for the collaborating parties to subscribe to.

[0062] In an optional embodiment,

[0063] According to business scenarios and business rules, a business process engine is built on the cloud platform. Business requirements are visualized and modeled through the business process engine to generate a standardized business requirement model including:

[0064] Build a business process engine on the cloud platform and complete the deployment of the business process engine through the services provided by the cloud platform according to the scale and complexity of the business scenario; define process modeling elements in the business process engine and design a graphical interface for process modeling; introduce a rule management module into the business process engine to achieve decoupling of business rules and business processes;

[0065] Using the visual modeling function provided by the business process engine, identify the elements involved in business requirements and build a business domain model; abstract the business activities in business requirements into task nodes, use connecting lines to define the execution order and dependency relationships between business activities, introduce gateway nodes to implement branching and merging of business activities, and embed business rules into corresponding task nodes;

[0066] According to the process modeling standard, each node and connection line in the business domain model is labeled with type and attribute configuration, and the business rules are mapped and bound to the task nodes through the interface of the rule engine to generate a standardized business demand model.

[0067] Exemplarily, this application proposes a business demand visualization modeling method based on a cloud platform. By building a business process engine in a cloud environment and utilizing the visualization modeling capabilities and rule management mechanisms provided by the process engine, business demands are converted into standardized business demand models, providing a basis for subsequent demand confirmation.

[0068] First, according to the scale and complexity of the business scenario, a business process engine is built on the cloud platform. The business process engine is a process management middleware running in the cloud environment that can support the modeling, deployment, execution and monitoring of business processes. This method selects the open source Activiti as the business process engine and uses the PaaS service provided by the cloud platform to complete the deployment of Activiti. The specific steps are as follows:

[0069] Create a Java Web runtime environment on the cloud platform and select the appropriate JDK version (such as JDK1.8) and Servlet container (such as Tomcat9).

[0070] Upload the Activiti WAR package to the cloud environment and complete the deployment and initialization of Activiti through the Web container.

[0071] Configure the data source of Activiti to point to the relational database service (such as MySQL) provided by the cloud platform to store metadata such as process definitions and process instances.

[0072] Bind the domain name to the service address of Activiti so that it can be accessed through the Internet.

[0073] After the above steps, a business process engine based on the cloud platform has been built. Next, it is necessary to define process modeling elements and graphical interfaces in the business process engine. Activiti provides a set of process modeling elements based on the BPMN2.0 standard, including task nodes, gateway nodes, event nodes, connecting lines, etc. Based on this, this method designs a set of elements suitable for business demand modeling, among which,

[0074] Business subjects can include organizations, roles or personnel involved in business needs, and are the executors of process tasks, such as customers, salespeople, auditors, etc.

[0075] Business objects can include data entities involved in business needs, such as orders, contracts, invoices, etc., which usually correspond to the domain model of the system.

[0076] Business activities can include a specific operation or task in business requirements and are the basic unit of the process model, such as filling out an order, reviewing a contract, etc.

[0077] Activity dependencies can include defining execution dependencies between business activities, which can be sequential, parallel, selective or cyclic, etc.

[0078] Business rules can include the execution conditions or decision logic of business activities, expressed in the form of IF-THEN. For example: IF the order amount > 10,000 THEN the supervisor needs to approve it.

[0079] At the same time, this method also develops a set of Web-based graphical process modeling interfaces that support process design by dragging and dropping. On the left side of the interface is the modeling element panel, which contains various types of nodes and connecting lines; in the middle is the canvas area, which is used to draw the flow chart; on the right side is the property configuration area, which is used to set the properties of the element.

[0080] In addition to process modeling, business rule management is also an important part of business demand confirmation. The traditional rule management method is to hard-code business rules in the process, which leads to tight coupling between rules and processes and high maintenance costs. To this end, this method introduces an independent rule management module in the business process engine to decouple business rules from business processes. Specifically, the Drools rule engine is used to store and execute business rules, and the rule content is defined through rule files (such as drl files). The rule files are referenced through rule task nodes in the process model. In this way, when the business rules change, only the rule files need to be modified instead of the process definition, which improves the flexibility and maintainability of the system.

[0081] With the support of the business process engine, the visual modeling of business requirements can begin. The starting point of modeling is to identify the key elements involved in business requirements and build a business domain model. The specific steps are as follows:

[0082] Extract stakeholder information from the business requirement document, identify various business entities, and present them in the form of swimlanes in the process modeling interface.

[0083] Analyze the core business objects and attributes in business requirements, extract entity classes, and establish entity relationship diagrams (ER diagrams) as the data basis for process models.

[0084] Perform functional decomposition of business requirements, identify key business activities, and represent them in the form of task nodes in the process modeling interface.

[0085] Analyze the execution logic and constraints between business activities, use connection lines (SequenceFlow) to define the flow between activity nodes, and use gateway nodes (Gateway) to implement process modes such as branching, merging, and looping. Common gateway types include: Exclusive Gateway, Parallel Gateway, Inclusive Gateway, etc.

[0086] Sort out the business rules in business requirements, express them in natural language or decision tables, and save them as independent rule files.

[0087] In the process model, business rules are embedded into the corresponding task nodes in the form of rule tasks (BusinessRuleTask). The rule task calls the API of the rule engine and passes the current process variables to the rule engine for matching and execution.

[0088] Through the above steps, the main body of the business demand model has been constructed. Next, the model needs to be improved and optimized, including:

[0089] Label the types of task nodes, gateway nodes, etc. in the process model, and set the attributes of the task executor, form, permission, etc. Define the input / output data of the task node and map it to the entity attributes in the ER diagram. Refine the branch conditions of the gateway node to ensure the integrity and correctness of the process. You can use expressions (such as UEL expressions) or scripts (such as Groovy scripts) to write branch conditions. Extract repeated or similar process fragments and define them as subprocesses to improve the reusability of the process model. Test and verify the process model through the simulation execution (Simulation) function provided by the process engine to discover and fix process defects.

[0090] After multiple rounds of iterative optimization, the business requirements model is finalized. The main artifacts generated in this stage are: process definition files (such as BPMN2.0 XML files), rule definition files (such as Drools drl files), ER model files, etc. These artifacts are stored in the warehouse of the business process engine for subsequent requirements confirmation and development.

[0091] The following example uses the order processing process of an online retail system to demonstrate the process of visual modeling of business requirements. The main business entities involved in this process are: customers, sales staff, warehouse managers, financial staff, etc. The core business objects are: orders, goods, inventory, invoices, etc. Business activities include: creating orders, reviewing orders, arranging shipments, issuing invoices, confirming receipts, etc. Business rules include: orders greater than 5,000 yuan require approval from the sales manager; VIP customer orders are shipped first; the invoice amount is consistent with the actual payment amount of the order, etc.

[0092] Based on these analyses, in the process modeling interface, first create four lanes to represent four types of business entities. Then, add corresponding task nodes in the lanes, such as the "Create Order" task in the Customer Lane and the "Review Order" task in the Salesperson Lane. Next, use connecting lines to define the order relationship and branch logic between tasks. For the order review link, set up an inclusive gateway, which is divided into two branches: "Amount Review" and "VIP Review", and then merge into the subsequent "Arrange Shipment" task. After the "Create Invoice" task, embed a rule task to check whether the invoice amount is consistent with the order amount. Finally, configure the attributes of each task node and gateway node, and define the task form, executor, input / output data, branch conditions, etc.

[0093] Through visual modeling, the business requirements of the order processing process are presented in a clear and intuitive way, laying the foundation for the next step of demand confirmation. Business personnel can intuitively understand business requirements through flowcharts, and developers can also quickly understand business logic based on process definitions, reducing communication costs and understanding deviations.

[0094] This application proposes a business demand visualization modeling method based on a cloud platform. By building a business process engine in a cloud environment and using the visualization modeling and rule management capabilities of the process engine, unstructured business requirements are converted into structured process models and rule definitions, thereby providing a formal representation method for demand confirmation. The advantages of this method are:

[0095] (1) By utilizing the elastic resources of the cloud platform, the cost of building and maintaining the business process engine is reduced.

[0096] (2) The use of graphical process modeling makes the expression of business requirements more intuitive and easy to understand, which is conducive to promoting understanding and communication between business personnel and technical personnel.

[0097] (3) The introduction of an independent rule engine decouples business rules from business processes, improving the flexibility and maintainability of the system.

[0098] (4) The process model and rule definition are standardized and structured, and can serve as the basic artifacts for requirement confirmation and also provide input for subsequent system design and implementation.

[0099] In an optional embodiment,

[0100] Based on the business demand model, a demand management microservice is deployed on the cloud platform. The business demand model is intelligently parsed by the demand management microservice to extract key business demand information and generate a structured demand description document including:

[0101] A demand management microservice architecture is built on the cloud platform. The demand management microservice architecture adopts a design mode of front-end and back-end separation, and divides the core service modules into demand metadata management module, demand document generation module, demand change management module and demand tracking and analysis module.

[0102] The demand metadata management module is responsible for storing and managing the metadata in the business demand model; the demand document generation module is responsible for automatically generating structured demand description documents based on the business demand model; the demand change management module is responsible for processing demand change requests and evaluating the impact of the change; the demand tracking and analysis module is responsible for recording the life cycle status of the demand and analyzing the progress and quality of the demand implementation;

[0103] Utilize the PaaS service provided by the cloud platform, encapsulate the demand management microservice architecture into a standardized deployment unit through containerization technology, and use container orchestration tools to achieve automated deployment, orchestration, and scheduling of microservices. At the same time, combine the monitoring and log services of the cloud platform to conduct real-time monitoring and early warning of the operating status and performance indicators of the standardized deployment units.

[0104] The unstructured text description information in the business demand model is preprocessed through the demand management microservice architecture in the cloud platform, and the key terms and concepts in the business demand are standardized and semantically disambiguated by constructing a demand domain ontology and dictionary. Then, the key entities, attributes and relationships in the business demand description are identified using semantic role labeling technology, and a semantic dependency graph corresponding to the business demand is constructed.

[0105] Based on the semantic dependency graph, rule-based and learning-based methods are used to further extract and organize business requirements to generate structured requirement description documents; the rule-based method uses predefined templates and rule matching to extract key elements of goals, processes, data, and constraints in business requirements, and the learning-based method uses deep learning models to automatically learn and extract patterns and features of business requirement elements from large-scale requirement corpora, ultimately achieving information extraction and structured representation of the business requirement model.

[0106] For example, after the deployment of the demand management microservice architecture is completed, it is necessary to further implement intelligent parsing and structuring of the business demand model, converting the unstructured demand text into a structured demand description document, and providing clear and accurate input for subsequent demand confirmation and development. This application mainly introduces the key technologies and implementation steps of business demand model parsing and structuring.

[0107] Since business requirements are usually submitted in the form of natural language text, there are problems such as irregular grammar, inconsistent wording, incomplete description, etc., so they need to be preprocessed to improve the accuracy of subsequent parsing. The main tasks of preprocessing include: sentence segmentation, word segmentation, part-of-speech tagging, named entity recognition, etc. The following is a typical example of a requirement text:

[0108] "The system shall allow users to search products by keyword, filterresults by category and price range, and sort results by relevance or price. The search function needs to support fuzzy matching and synonymexpansion.";

[0109] After preprocessing the text, the following results can be obtained:

[0110] - Sentence 1: The system shall allow users to search products by keyword, filter results by category and price range, and sort results by relevance or price;

[0111] -Words and parts of speech: The / DT,system / NN,shall / MD,allow / VB,users / NNS,to / TO,search / VB,products / NNS,by / IN,keyword / NN,filter / VB,resu lts / NNS,by / IN,category / NN,and / CC,price / NN,range / NN,and / CC,sort / VB,results / NNS,by / IN,relevance / NN,or / CC,price / NN;

[0112] -Named Entity: None;

[0113] -Sentence 2: The search function needs to support fuzzy matching and synonym expansion;

[0114] -Words and parts of speech: The / DT, search / NN, function / NN, needs / VBZ, to / TO, support / VB, fuzzy / JJ, matching / NN, and / CC, synonym / NN, expansion / NN;

[0115] -Named Entity: None;

[0116] It can be seen that the preprocessing divides the demand text into sentences and words, marks the part of speech of each word, and identifies named entities (none in this example). This information provides the basis for the subsequent demand analysis.

[0117] In order to improve the accuracy and coverage of demand analysis, it is necessary to build a demand domain ontology and dictionary to standardize and disambiguate common concepts, terms, abbreviations, etc. in the domain. Ontology is a formal description of knowledge in a specific domain, which describes important concepts in the domain by defining classes, properties, and relations. A dictionary is a controlled vocabulary that includes standard expressions, synonyms, and abbreviations of commonly used terms in the domain.

[0118] Taking the search function as an example, the following core classes can be defined in the demand domain ontology:

[0119] -Software Application: A software system with certain functions, such as an online shopping mall system.

[0120] - Functional Requirement: Specification of software system functions, such as providing search function.

[0121] -User: The subject who uses the software system, such as shopping users.

[0122] -Product: The object managed and operated by the software system, such as a commodity.

[0123] Then, define the relationship between the classes, such as:

[0124] -SoftwareApplication contains FunctionalRequirement;

[0125] -User uses SoftwareApplication;

[0126] -FunctionalRequirement operation Product;

[0127] Each class can have multiple attributes, such as FunctionalRequirement has a priority attribute.

[0128] When building a demand domain dictionary, we can include the following terms:

[0129] -Login-login,log in,sign in;

[0130] -Registration-register, enrollment, sign up;

[0131] -Search, query, retrieve;

[0132] -Browse-browse, view, go through;

[0133] -delete-delete,remove,erase;

[0134] These terms represent common actions in requirement texts, and mapping them to unified standard expressions helps improve the consistency of requirement parsing.

[0135] (3) Semantic role labeling

[0136] After completing the requirements preprocessing and ontology / dictionary construction, it is necessary to perform semantic role labeling on the requirements text to identify the predicates (verbs) and related arguments (such as agents, patients, tools, etc.) in the sentences. Based on the FrameNet semantic framework, the following semantic roles can be defined:

[0137] -Agent: The subject who performs the action.

[0138] -Patient: The object of the action.

[0139] -Instrument: The tool or method used to perform an action.

[0140] -Purpose: The purpose of performing the action.

[0141] -Manner: The way of performing an action.

[0142] By performing semantic role labeling on the previous requirement examples, we can obtain:

[0143] -[The system] agent shall allow [users] the patient to [search] the action [products] the patient [by keyword] the tool;

[0144] -[The system] agent shall allow [users] objects to [filter] actions [results] objects [by category and price range] tools;

[0145] -[The system] agent shall allow [users] the patient to [sort] actions [results] the patient [by relevance or price] the tool;

[0146] -[The search function] the agent needs to [support] the action [fuzzy matching] the patient and [synonym expansion] the patient;

[0147] The annotation results clearly show the semantic structure of the sentence, laying the foundation for demand information extraction.

[0148] After obtaining the semantic role labeling results of the requirement text, we can further extract the key information elements of the requirement, including requirement goals, processes, data, constraints, etc., and organize them into a structured form. The main extraction strategies include:

[0149] -Rule-based approach: define a series of mapping rules to map specific semantic role annotation patterns into structured demand information. For example:

[0150] -[subject] agent shall[predicate] action[object] patient=>;

[0151] -Subject: [subject];

[0152] -Capability: [predicate] + [object];

[0153] -...[predicate] action[object] patient[adverbial] tool=>;

[0154] -Capability: [predicate] + [object];

[0155] -Means: [adverbial];

[0156] -Learning-based approach: Automatically learn extraction rules from large-scale demand corpus.

[0157] -Collect a batch of demand corpus and manually annotate it to form training data. For example:

[0158] - <subject> The system< / subject> shall allow<object> users< / object> to <action> search products< / action> by <means> keyword< / means> ;

[0159] -Use deep learning models (such as BiLSTM-CRF) to learn the training data. After training, the new demand text can be automatically extracted.

[0160] Taking the rule method as an example, applying the above rules to the demand sample can extract the following structured information:

[0161] Requirement-1:

[0162] -Subject:The system;

[0163] -Capability:allow users to search products;

[0164] -Means: by keyword;

[0165] Requirement-2:

[0166] -Subject:The system;

[0167] -Capability:allow users to filter results;

[0168] -Means: by category and price range;

[0169] Requirement-3:

[0170] -Subject:The system;

[0171] -Capability:allow users to sort results;

[0172] -Means: by relevance or price;

[0173] Requirement-4:

[0174] -Subject:The search function;

[0175] -Capability: support fuzzy matching and synonym expansion;

[0176] Finally, the extracted results are further deduplicated and merged, and other information (such as priority) is supplemented to generate a structured JSON format requirement description document.

[0177] The above are the main technical methods and implementation steps for automatically parsing and structuring business demand models based on the cloud platform's demand management microservice architecture. Through demand preprocessing, ontology and dictionary construction, semantic role labeling, rule-based and learning-based information extraction, etc., structured and standardized demand descriptions are extracted from unstructured demand texts, providing a solid foundation for subsequent demand confirmation, design and development. At the same time, with the elastic scaling and microservice architecture of the cloud platform, the system has good concurrent processing capabilities and scalability, and can efficiently cope with large-scale and rapidly changing demand scenarios.

[0178] In an optional embodiment,

[0179] Deploy the requirement verification service on the cloud platform, and automatically verify the formalized business requirement logic by using the formal verification method of control flow analysis or data flow analysis combined with the business domain ontology model. Generate a requirement verification report including:

[0180] Deploy a requirement verification service on the cloud platform. The requirement verification service includes two core components: a formalization engine and a reasoning engine. The formalization engine is responsible for converting structured business requirements into formalized requirement specifications, and the reasoning engine is responsible for automated verification and problem detection of formalized requirement specifications.

[0181] Convert the extracted structured process requirements into a Petri net model, map the process activities into transitions, map the process data and states into places, and map the sequential relationships between activities into directed arcs by defining mapping rules. Then use the Petri net analysis technology to verify the control flow of the generated Petri net model, check the abnormal states of deadlock and livelock by building a reachable graph, verify the completeness and termination of the process by calculating invariants, check the consistency and certainty of the process by analyzing conflicts and concurrency relationships, and generate counterexample paths and repair suggestions for the detected problems.

[0182] The extracted structured requirement description document is converted into a data flow diagram model. By defining mapping rules, the data objects in the requirements are mapped into data elements, and the data processing activities are mapped into processing processes. Then, the generated data flow diagram model is verified using abstract interpretation technology to generate a requirement verification report.

[0183] For example, after the business requirement model is extracted and structured, it needs to be further formally verified to check the correctness, consistency, completeness and other attributes of the requirements, so as to find and correct defects and problems in the requirements as early as possible. This application introduces how to deploy a requirement verification service on a cloud platform, use a model-based formal verification method to automatically analyze and check the structured business requirements, and generate a requirement verification report.

[0184] The requirements verification service deployed on the cloud platform mainly includes two core components: the formal engine and the reasoning engine. Among them, the formal engine is responsible for converting the structured business requirements (such as JSON format) into formal requirements specifications, such as Petri nets, data flow diagrams, etc. The reasoning engine is responsible for automatic reasoning and verification of formal requirements specifications, and checks various attributes of requirements through a series of formal analysis techniques (such as reachability analysis and invariant analysis) to find problems and defects.

[0185] The structured requirements are first submitted to the formalization engine, and different mapping rules are used according to the requirement type (such as process requirements and data requirements) to convert them into corresponding formal models. The formal model is passed to the reasoning engine through the message middleware. The reasoning engine calls the predefined reasoning rules and constraints, and verifies the model using theorem proving, model checking and other technologies. Problems found during the reasoning process will be recorded in the verification report. After the verification is completed, the reasoning engine sends the verification report to the report database for storage and notifies the requirements engineer of the verification results.

[0186] For the needs of describing system processes, this paper uses Petri net as its formal representation. The formal definition is as follows:

[0187] A Petri net is a triple N = (P, T, F), where:

[0188] -P is a finite set of places;

[0189] -T is a finite set of transitions, and

[0190] - is a set of directed arcs.

[0191] Places are represented by circles, representing the state or resources of the system; transitions are represented by rectangles, representing the events or activities of the system; directed arcs represent the relationship between places and transitions. Petri nets can also place several tokens in places to represent the number of instances of the state. The distribution of tokens is called the identification of the Petri net. Through the triggering of transitions, tokens flow in the net, depicting the dynamic changes of the system state.

[0192] In order to convert process requirements into Petri net models, a set of mapping rules need to be defined:

[0193] Process activities are mapped to transitions; process data / states are mapped to places; sequence flows between activities are mapped to directed arcs; decision / aggregation nodes (Gateway) are mapped to transitions or places according to their types; and the state of process data is mapped to tokens in places.

[0194] Transition A represents activity A, and transitions B and C represent activities B and C respectively. Places p1 and p2 represent the data / states transferred between activities. Transition G represents a decision gateway, with two concurrent branches branching from A. When transition A is triggered, the token flows from p1 to p2 and G, and then transitions B and C are triggered concurrently.

[0195] After obtaining the Petri net model of the process, you can use Petri net analysis technology to verify it and check some key properties of the model, including:

[0196] Deadlock: The system enters a state that can never be left. By constructing the reachability graph of the Petri net, enumerating all possible state identifiers, and checking whether there is a termination identifier that can be triggered without a transition.

[0197] Livelock: The system is running but the business is not progressing. By constructing a coverability tree, we can find the infinite increasing sequence of identifiers and determine whether there is a livelock.

[0198] Invariant: It describes the constraints that Petri net identifiers need to satisfy. Common invariants include place invariants (P-Invariant) and transition invariants (T-Invariant). Invariants can be automatically generated by solving linear equations. Users can also define their own invariants according to their needs and check the completeness of the requirements and business rules.

[0199] Conflict and concurrency: Describes the dependency constraints between activities. By building a dependency graph, you can generate conflict sets and concurrency sets to determine whether there is resource competition or synchronization anomalies between activities.

[0200] After discovering a problem, the reasoning engine will generate a counterexample path (i.e., an execution sequence that leads to the problem) and provide repair suggestions, which will be fed back to the requirements engineer for manual review and revision.

[0201] Take a simple online shopping mall scenario as an example. Assume that the extracted structured process requirements are as follows:

[0202] The customer submits the order, and the order status changes to "Awaiting Payment"

[0203] The system starts two concurrent tasks at the same time:

[0204] Task 1: Wait for the customer to pay. If the customer completes the payment within 30 minutes, the order status changes to "paid"; otherwise, the order status changes to "closed";

[0205] Task 2: Wait for the system to confirm the inventory of the product. If the inventory is sufficient, the order status changes to "preparing stock"; otherwise, the order status changes to "out of stock";

[0206] When the order status changes to "paid" and "in stock", the system triggers the delivery process and the order status changes to "shipped";

[0207] When the customer confirms receipt, the order status changes to "Completed".

[0208] The reasoning engine generates the following counterexample path for the above problem:

[0209] 1. Deadlock counterexample: t1 (submit order) → t2 → t4 (timeout closed) → t3 → t5 (payment successful), then t6 cannot be triggered, resulting in deadlock.

[0210] 2. Invariant counterexample: t1→t2→t3→t5→t6, the order status is "shipped", but at this time both places p4 (paid) and p6 (out of stock) have tokens, which does not satisfy the P-invariant.

[0211] 3. Concurrent exception counterexample: t1→t7 (confirmation of receipt)→t6 (shipment), the order of activities is reversed.

[0212] To avoid deadlock, an output place "Closed" can be added to the payment timeout transition t4. When the token enters this place, it means that the order has been closed and no payment is accepted. At the same time, an input arc of the "Closed" place is added to t6 (shipment) to prohibit shipment when the order is closed.

[0213] To satisfy the P-invariant, the input / output arcs of t5 and t6 need to be adjusted. Specifically, the output arc of t5 is changed to point to p4 (paid), and the two input places of t6 are changed to p4 (paid) and p5 (in stock). After the adjustment, the P-invariant of place p7 becomes "p7=p4+p5", which meets the demand constraint.

[0214] Add two places p8 (in transit) and p9 (received) between t7 (confirmation of receipt) and t6 (shipment), and add directed arcs from t6 to p8, p8 to t7, and t7 to p9 to form an order constraint of t6→p8→t7→p9 to prevent concurrent exceptions.

[0215] The requirements engineer makes necessary modifications to the process requirements based on the counterexamples and repair suggestions, and then resubmits for verification until all problems are resolved. After formal verification, the correctness, consistency, and completeness of the process requirements will be effectively guaranteed.

[0216] For data processing requirements, this article uses Data Flow Diagram (DFD) as its formal representation. Data flow diagram is a structured analysis and design method that describes the data flow and processing of the system in a graphical way, emphasizing the data dependency and functional composition of the system. The basic elements of DFD include:

[0217] Process: It refers to the process of operating and transforming data, represented by a circle.

[0218] Data Flow: Indicates the transfer of data between different processes, represented by a straight line with an arrow.

[0219] Data Store: Indicates the location where data is stored, represented by two parallel lines.

[0220] External Entity: A person or organization outside the system that serves as the source and destination of data and is represented by a rectangle.

[0221] DFD uses a hierarchical abstract description method, with the top layer being level 0 (environmental diagram), followed by layers of refinement until sufficient details are achieved. The balance of different levels of DFD is ensured by the continuity of data flow.

[0222] The main mapping rules for converting data requirements into DFD models are as follows:

[0223] The system name is mapped to the central processing of the top-level diagram; the data object is mapped to data storage; the data processing activity is mapped to processing; the dependency relationship between data objects is mapped to data flow; and the external data source / destination is mapped to external entity.

[0224] Assume that the extracted structured data requirement fragment is as follows:

[0225] 1. The system reads data from the customer table (Customer), product table (Product) and order table (Order).

[0226] 2. Associate the customer table and order table based on the customer ID to obtain a list of orders for each customer.

[0227] 3. Associate the product table and order table based on the product ID to obtain the product details of each order.

[0228] 4. Summarize each customer’s order list by amount to get the customer’s total consumption.

[0229] 5. Group and summarize the product details by product category to obtain sales statistics for each category.

[0230] 6. Export customer spending data to the marketing analysis system and export product category sales statistics to the purchasing forecast system.

[0231] Common DFD verification techniques include:

[0232] Balance check: Verify the consistency of the parent graph and the child graph in the data flow input and output, and ensure the data continuity between different abstraction levels. Data dictionary analysis: Define the structure and value range of data flow and data storage, and check the legality and completeness of data items. Processing logic verification: Use decision tables or decision trees, etc.

[0233] In an optional embodiment,

[0234] The method further comprises:

[0235] Construct a business domain ontology model for requirement verification, use ontology description language and ontology development tools to build a general requirement verification ontology framework, instantiate and expand the ontology for specific business domains, design semantic reasoning rules based on the business domain ontology model, check whether the key terms in the requirement statement are clearly defined in the ontology by defining concept matching rules, and check whether the attribute assignment in the requirement statement meets the data type and value range restrictions in the ontology by defining attribute constraint rules;

[0236] The semantic reasoning engine is used to perform semantic verification on the formally expressed requirement statements. The semantic consistency between the requirement statements and the domain ontology is automatically checked through the logical reasoning algorithm. The semantic defects and errors in the requirement statements are inferred, and intuitive problem descriptions and modification suggestions are generated for the detected semantic problems.

[0237] For example, in addition to structural verification, business requirements also need to be checked at the semantic level to ensure that the concepts, terms, relationships, etc. used in the requirement statements are consistent with the business domain knowledge and do not contain ambiguity or errors. This application describes how to build a business domain ontology model for requirement verification and use semantic reasoning technology to automatically semantically verify formally expressed requirement statements.

[0238] Ontology is a formal description of knowledge in a certain field, which consists of basic elements such as concepts, attributes, relationships, and axioms. Through ontology, the semantic information of the business field can be clearly defined, providing a unified conceptual system and reasoning basis for demand verification. This paper adopts the W3C standard OWL (Web Ontology Language) as the ontology description language, and uses open source tools such as Protégé and NeOn Toolkit for ontology development.

[0239] First, we need to build a general requirements verification ontology framework to define the core concepts involved in the requirements management and verification process, such as requirements, stakeholders, validation rules, etc. There are certain hierarchical relationships and semantic connections between these concepts, which can be described by logical structures such as OWL classes, subclasses, and properties. Based on the general framework, we then build domain-specific ontology models for specific business areas (such as e-commerce, logistics, manufacturing, etc.), inherit and extend general concepts, and introduce terminology, rules, and constraints unique to the field.

[0240] Take the online shopping mall field as an example. Based on the business requirements extracted in the previous article, the following core concepts can be defined:

[0241] Customer: A user who shops in a mall, with attributes such as name, contact information, delivery address, etc. Product: An item sold in a mall, with attributes such as name, category, price, inventory, etc.

[0242] Order: A purchase request placed by a customer, which links the customer and the product, and has attributes such as order number, order time, amount, status, etc. Payment: An activity in which a customer pays for an order, and has attributes such as payment serial number, payment channel, payment amount, payment status, etc. Delivery: An activity in which the mall arranges logistics delivery for an order, and has attributes such as express order number, carrier, recipient, delivery status, etc.

[0243] There are certain semantic relationships between the main concepts, for example:

[0244] Customers can place orders (place), i.e. Customer→place→Order;

[0245] The order contains the product (contain), that is, Order→contain→Product;

[0246] Order triggers payment (trigger), i.e. Order→trigger→Payment;

[0247] After payment is completed, activate the delivery (Payment→activate→Delivery);

[0248] The delivery destination is the customer's delivery address (destinateAt), that is, Delivery→destinateAt→Customer.Address.

[0249] After the ontology is built, semantic reasoning engines such as Pellet and HermiT can be used to check its consistency, eliminate logical errors such as circular recursion in concept definition and contradictions in attribute definition, and ensure the validity and completeness of the ontology. The quality of the ontology model directly affects the accuracy of demand verification.

[0250] The constructed business ontology model can be used to semantically verify the formalized requirement statements. The basic idea of ​​verification is: first, the requirement statements described in natural language are converted into logical expressions corresponding to the ontology concepts through natural language processing technology (such as word segmentation, part-of-speech tagging, syntactic analysis, etc.). Then, a series of semantic reasoning rules are defined based on the domain ontology, and the semantic consistency between the requirement statements and the ontology definition is checked through the ontology reasoning engine (such as Jena, Drools, etc.) to find potential semantic defects and errors. Semantic reasoning rules are mainly divided into two categories:

[0251] The first category is concept matching rules, which are used to check whether the key terms in the requirement statement are clearly defined in the ontology.

[0252] The second category is attribute constraint rules, which are used to check whether the attribute assignment in the requirement statement satisfies the data type and value range defined in the ontology.

[0253] In addition to the above two basic rules, more complex reasoning rules can be defined according to business scenarios, such as checking conflicts between requirements, inferring implicit requirements, etc. These rules often need to use the axioms and relations defined in the ontology for reasoning, which can be implemented using rule-based reasoning, description logic reasoning and other methods.

[0254] When the semantic reasoning engine finds semantic problems in a requirement statement, it will generate intuitive problem descriptions and modification suggestions and provide feedback to the requirement engineer. For example:

[0255] Warning: "In requirement R1, the term 'shopping cart' is not defined in the mall ontology, and there may be differences in the understanding of the concept. It is recommended to add a definition or unify the terminology."

[0256] Error: "In requirement R2, the value of the product price attribute is assigned to -100, but according to the ontology definition, the price must be a non-negative real number. It is recommended to modify the assignment or adjust the attribute definition."

[0257] Conflict: "Requirement R3 states that 'unpaid orders cannot be canceled', but requirement R4 states that 'all orders can be canceled within 24 hours of placing an order'. There is a logical contradiction between the two. It is recommended to clarify the requirements to eliminate ambiguity."

[0258] The requirement engineer makes necessary changes to the requirement text according to the feedback, and then re-verifies the semantics until all semantic problems are eliminated. After semantic verification based on ontology, the correctness and consistency of the requirements can be guaranteed from the perspective of domain semantics, thus improving the quality of requirements.

[0259] In summary, this application introduces the deployment architecture and implementation process of the requirement verification service on the cloud platform, and uses formal and ontological methods to automatically verify structured requirements, checking errors, conflicts and defects in requirements from multiple dimensions such as structure, logic, and semantics, in order to improve the quality of requirements and reduce development risks.

[0260] In an optional embodiment,

[0261] According to the requirement verification report, judging whether there is a semantic contradiction or a logical loophole in the business requirement logic, and when a semantic contradiction or a logical loophole is detected, correcting the business requirement logic that fails the verification in combination with the business domain ontology model includes:

[0262] Convert the process model containing process deadlock defects into a Petri net representation, and use the formal semantics of Petri nets to explicitly model process activities, resources, and control flow relationships;

[0263] Based on the Petri net model, the reachability graph analysis is performed to identify the deadlock state in the Petri net by searching for the termination node in the reachability graph. The termination node indicates that there is no migration that can be triggered in the current state.

[0264] For each deadlock state, a corresponding deadlock dependency graph is generated. The nodes in the deadlock dependency graph represent the resources and migrations that cause the deadlock, and the edges represent the resource application and occupancy dependencies. The deadlock dependency graph describes the resource constraints that form the deadlock loop.

[0265] Run the minimum cut algorithm on the deadlock dependency graph to find the resource dependency edge set that can cut off the deadlock loop and minimize the modification cost. The minimum cut algorithm ensures that the adjustment to the original process structure is minimized while breaking the deadlock.

[0266] Generate a process modification plan based on the minimum cost edge set, and automatically recommend specific modification operations such as adjusting the resource application sequence, increasing resource capacity, and inserting a synchronization mechanism by combining the semantic information of process activity resources and expert modification rules;

[0267] The deadlock reachability of the process modification plan is re-verified based on Petri nets to ensure that the process modification plan effectively eliminates the deadlock and does not introduce new defects.

[0268] For example, for complex business process requirements, after the aforementioned structural verification and semantic verification, there may still be some deep-level logical problems, such as deadlocks in process activities. Deadlock means that in a certain state of process execution, multiple concurrent activities wait for each other due to resource dependencies and sequence constraints, resulting in the inability to continue the process. This application introduces how to use the formal modeling tool Petri net to detect and automatically repair deadlock defects in process requirements.

[0269] Petri net is a mathematical tool used to describe concurrent systems. It consists of three basic elements: Place, Transition, and Arc. In order to convert process requirements into Petri net models, a set of mapping rules needs to be defined:

[0270] Process activity (Activity): mapped to the transition of Petri net, representing the execution of an activity task. Resource / data that the activity depends on: mapped to the library, representing the conditions required for the activity to execute. The activity reads resources from the input library and writes resources to the output library. Sequence flow (Sequence Flow): mapped to the ordinary directed arc of Petri net, representing the execution relationship between activities. Message flow (Message Flow): mapped to the message arc of Petri net, representing the asynchronous communication mechanism between activities. Gateway (Gateway): mapped to the branch transition of Petri net, representing the branch convergence logic of the process execution path.

[0271] For example, for a simple order processing flow:

[0272] (1) The customer submits the order, and the order enters the payment waiting state;

[0273] (2) The customer completes the order payment and the order enters the paid status;

[0274] (3) The merchant reviews the paid orders;

[0275] (3.1) If approved, the order will enter the stocking status;

[0276] (3.2) If the review fails, the refund process will be initiated and the order will be cancelled;

[0277] (4) The merchant arranges for the shipment of the order after the stocking is completed, and the order enters the delivery status;

[0278] (5) The customer signs for the order and the order enters the completed state;

[0279] Using the above mapping rules, the corresponding Petri net model can be constructed, where places P1 to P5 represent the status of the order after different activities, and the resource capacity is 1. Each activity A1 to A6 is mapped to transitions T1 to T6. Gateway G1 uses XOR (exclusive or) semantics and is split into two transitions T3 and T4 and two output places P3 and P4.

[0280] In the initial state, only place P1 has a token, indicating that there is a pending order. When transitions T1 and T2 are triggered successively, the token passes through P2 and arrives at P3, indicating that the order has been paid and is waiting for review. Transitions T3 and T4 correspond to two branch paths, and the token will enter P3 or P4 according to the review results. The triggering of subsequent transitions simulates the flow of orders between different activities until the token reaches the terminal place P5.

[0281] Using the formal semantics of Petri nets, its state space can be generated, that is, all possible Markings (place token distribution) and their transition relationships, called the Reachability Graph. The deadlock state corresponds to the terminal node in the reachability graph, and there is no transition that can be triggered in this state.

[0282] For example, in a more complex order processing process, there are two concurrent activities A and B, which apply for resources X and Y respectively. The reachability graph analysis finds that when activity A holds resource X and waits for resource Y, and activity B holds resource Y and waits for resource X, the system enters a deadlock.

[0283] By identifying all the terminal nodes of the reachable graph, all the deadlock states in the process model can be obtained. However, it should be noted that the state space of the reachable graph may be very large, and it is computationally infeasible to exhaustively search all states. Therefore, it is necessary to adopt some heuristic search strategies, such as breadth-first and best-first, to selectively explore the state space and find deadlock states early.

[0284] For each detected deadlock state S, the resource constraint relationship that forms the deadlock is extracted to generate the corresponding deadlock dependency graph. The deadlock dependency graph is a directed graph, where nodes represent resources and activities that apply for resources, and edges represent the application and occupation of resources by activities.

[0285] Taking the above state S as an example, its deadlock dependency graph contains 4 nodes: activity A, activity B, resource X, and resource Y. There is an occupied edge between activity A and resource X, and there is a request edge from activity A to resource Y. The relationship between activity B and the two resources is similar. These four nodes and their directed edges form a deadlock loop.

[0286] To eliminate deadlock, the deadlock loop must be broken. The intuitive approach is to reduce the resource occupation of a certain activity or increase the capacity of a certain resource. However, arbitrary adjustment of resource allocation may affect the semantic correctness of the process, so it is necessary to break the loop at the lowest cost while maintaining the original process logic. This problem can be transformed into the minimum cut problem of the deadlock dependency graph.

[0287] The minimum cut algorithm is used to find a minimum set of edges in a graph. After deleting these edges, the original graph is divided into two disconnected subgraphs. In a deadlock dependency graph, resource nodes and activity nodes must belong to different subgraphs to cut off the deadlock dependency relationship between them. At the same time, the algorithm must ensure that the cut edge set has the least semantic impact on the process. Commonly used minimum cut algorithms include the Edmonds-Karp algorithm and the Push-Relabel algorithm.

[0288] For example, in the deadlock loop above, the minimum cut is to delete the occupied Y edge and the requested X edge of activity B, so that B releases the occupation of Y and postpones the application for X. Intuitively, this is equivalent to adjusting the timing of activity B's application for resources so that A can complete the application for Y first, thus breaking the circular waiting. Similarly, if resource Y can be occupied by two activities at the same time, that is, the capacity is greater than 1, the deadlock condition can also be broken. The algorithm needs to evaluate the feasibility and modification cost of different cut set solutions and select the optimal solution.

[0289] According to the minimum cut solution, the process model needs to be modified accordingly, such as adjusting the time points of resource application and release, increasing resource capacity, inserting synchronization mechanisms, etc. This requires considering the specific semantics of process activities and resources, and can be assisted by modification rules in the expert knowledge base. For example, the rule can point out that "for the order processing process, increasing the number of manual review positions can alleviate the blockage of review activities."

[0290] After the Petri net model is modified, it is necessary to re-analyze the reachability graph to verify whether the modification scheme effectively eliminates the deadlock and does not introduce new logical errors. If the verification fails, it is necessary to regenerate the repair scheme until all constraints are met.

[0291] Take the order review deadlock as an example. Assume that the original process requires that the order be reviewed within a specified time, and that it will be automatically canceled and refunded if it is overdue. The reachability graph analysis found that when a large number of orders are poured in, the review and refund activities may be deadlocked due to fierce competition for resources.

[0292] State S1:

[0293] Order o1 is waiting for review, and order o2 is waiting for refund.

[0294] The review activity occupies manual review position r1, waiting for order o2 to complete the refund and release funds;

[0295] The refund activity occupies funds, waiting for order o1 to complete the review and release the manual review position r1.

[0296] The minimum cut analysis of the deadlock dependency graph found that the minimum cost solution to destroy the loop is to increase the number of manual review positions. After the process was modified, the reachability graph analysis of the Petri net model was performed again to confirm that the mortelil deadlock state is unreachable under the new resource constraints. The repair plan was verified.

[0297] In summary, this application introduces an automatic repair method for requirement defects based on Petri nets and graph theory algorithms. Compared with manual analysis, formal methods can systematically model resource constraints and identify deadlock loops, and automatically recommend optimized process modification solutions. This can greatly improve the efficiency of requirement verification and reduce human omissions. Combined with the ontology semantic check in the previous article, a multi-angle and multi-level requirement verification framework is basically formed.

[0298] Figure 2 FIG. 1 is a schematic diagram of a business demand confirmation system based on a cloud platform according to an embodiment of the present invention. Figure 2 As shown, the system comprises:

[0299] The first unit is used to build a business process engine on the cloud platform according to business scenarios and business rules, and to perform visual modeling of business requirements through the business process engine to generate a standardized business requirement model; based on the business requirement model, a demand management microservice is deployed on the cloud platform, and the business requirement model is intelligently parsed through the demand management microservice to extract key information of business requirements and generate a structured demand description document;

[0300] The second unit is used to perform semantic analysis on the demand description document using natural language processing technology, establish a business domain ontology model through knowledge graph construction technology, map the unstructured text in the demand description document to the concept nodes in the business domain ontology model, and formally represent the business demand logic; deploy the demand verification service on the cloud platform, and automatically verify the formally represented business demand logic through the formal verification method of control flow analysis or data flow analysis in combination with the business domain ontology model to generate a demand verification report;

[0301] The third unit is used to determine whether there is a semantic contradiction or logical loophole in the business demand logic based on the demand verification report. When a semantic contradiction or logical loophole is detected, the business demand logic that fails the verification is corrected in combination with the business domain ontology model; the demand collaboration service is deployed on the cloud platform, and the corrected business demand logic is published in the form of a standardized interface for subscription by the collaborating parties.

[0302] According to a third aspect of the embodiments of the present invention,

[0303] An electronic device is provided, comprising:

[0304] processor;

[0305] a memory for storing processor-executable instructions;

[0306] The processor is configured to call the instructions stored in the memory to execute the aforementioned method.

[0307] According to a fourth aspect of the embodiments of the present invention,

[0308] A computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the aforementioned method is implemented.

[0309] The present invention may be a method, an apparatus, a system and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for executing various aspects of the present invention.

[0310] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for confirming business requirements based on a cloud platform, characterized in that: include: According to business scenarios and business rules, a business process engine is built on the cloud platform, and business requirements are visually modeled through the business process engine to generate a standardized business requirement model; based on the business requirement model, a demand management microservice is deployed on the cloud platform, and the business requirement model is intelligently parsed through the demand management microservice to extract key information of business requirements and generate a structured demand description document; Use natural language processing technology to perform semantic analysis on the demand description document, establish a business domain ontology model through knowledge graph construction technology, map the unstructured text in the demand description document to the concept nodes in the business domain ontology model, and formally represent the business demand logic; deploy the demand verification service on the cloud platform, and automatically verify the formally represented business demand logic through the formal verification method of control flow analysis or data flow analysis in combination with the business domain ontology model to generate a demand verification report; According to the demand verification report, determine whether there is a semantic contradiction or logical loophole in the business demand logic. When a semantic contradiction or logical loophole is detected, correct the business demand logic that has not passed the verification in combination with the business domain ontology model; deploy the demand collaboration service on the cloud platform, and publish the corrected business demand logic in the form of a standardized interface for subscription by the collaborating parties; According to business scenarios and business rules, a business process engine is built on the cloud platform. Business requirements are visualized and modeled through the business process engine to generate a standardized business requirement model including: Build a business process engine on the cloud platform and complete the deployment of the business process engine through the services provided by the cloud platform according to the scale and complexity of the business scenario; define process modeling elements in the business process engine and design a graphical interface for process modeling; introduce a rule management module into the business process engine to achieve decoupling of business rules and business processes; Using the visual modeling function provided by the business process engine, identify the elements involved in business requirements and build a business domain model; abstract the business activities in business requirements into task nodes, use connecting lines to define the execution order and dependency relationships between business activities, introduce gateway nodes to implement branching and merging of business activities, and embed business rules into corresponding task nodes; According to the process modeling standard, each node and connection line in the business domain model is labeled with type and attribute configuration, and the business rules are mapped and bound to the task nodes through the interface of the rule engine to generate a standardized business demand model.

2. The method according to claim 1, characterized in that Based on the business demand model, a demand management microservice is deployed on the cloud platform. The business demand model is intelligently parsed by the demand management microservice to extract key business demand information and generate a structured demand description document including: A demand management microservice architecture is built on the cloud platform. The demand management microservice architecture adopts a design mode of front-end and back-end separation, and divides the core service modules into demand metadata management module, demand document generation module, demand change management module and demand tracking and analysis module. The demand metadata management module is responsible for storing and managing the metadata in the business demand model; the demand document generation module is responsible for automatically generating structured demand description documents based on the business demand model; the demand change management module is responsible for processing demand change requests and evaluating the impact of the change; the demand tracking and analysis module is responsible for recording the life cycle status of the demand and analyzing the progress and quality of the demand implementation; Utilize the PaaS service provided by the cloud platform, encapsulate the demand management microservice architecture into a standardized deployment unit through containerization technology, and use container orchestration tools to achieve automated deployment, orchestration, and scheduling of microservices. At the same time, combine the monitoring and log services of the cloud platform to conduct real-time monitoring and early warning of the operating status and performance indicators of the standardized deployment units. The unstructured text description information in the business demand model is preprocessed through the demand management microservice architecture in the cloud platform, and the key terms and concepts in the business demand are standardized and semantically disambiguated by constructing a demand domain ontology and dictionary. Then, the key entities, attributes and relationships in the business demand description are identified using semantic role labeling technology, and a semantic dependency graph corresponding to the business demand is constructed. Based on the semantic dependency graph, rule-based and learning-based methods are used to further extract and organize business requirements to generate structured requirement description documents; the rule-based method uses predefined templates and rule matching to extract key elements of goals, processes, data, and constraints in business requirements, and the learning-based method uses deep learning models to automatically learn and extract patterns and features of business requirement elements from large-scale requirement corpora, ultimately achieving information extraction and structured representation of the business requirement model.

3. The method according to claim 1, characterized in that Deploy the requirement verification service on the cloud platform, and automatically verify the formalized business requirement logic by using the formal verification method of control flow analysis or data flow analysis combined with the business domain ontology model. Generate a requirement verification report including: Deploy a requirement verification service on the cloud platform. The requirement verification service includes two core components: a formalization engine and a reasoning engine. The formalization engine is responsible for converting structured business requirements into formalized requirement specifications, and the reasoning engine is responsible for automated verification and problem detection of formalized requirement specifications. Convert the extracted structured process requirements into a Petri net model, map the process activities into transitions, map the process data and states into places, and map the sequential relationships between activities into directed arcs by defining mapping rules. Then use the Petri net analysis technology to verify the control flow of the generated Petri net model, check the abnormal states of deadlock and livelock by building a reachable graph, verify the completeness and termination of the process by calculating invariants, check the consistency and certainty of the process by analyzing conflicts and concurrency relationships, and generate counterexample paths and repair suggestions for the detected problems. The extracted structured requirement description document is converted into a data flow diagram model. By defining mapping rules, the data objects in the requirements are mapped into data elements, and the data processing activities are mapped into processing processes. Then, the generated data flow diagram model is verified using abstract interpretation technology to generate a requirement verification report.

4. The method according to claim 3, characterized in that The method further comprises: Construct a business domain ontology model for requirement verification, use ontology description language and ontology development tools to build a general requirement verification ontology framework, instantiate and expand the ontology for specific business domains, design semantic reasoning rules based on the business domain ontology model, check whether the key terms in the requirement statement are clearly defined in the ontology by defining concept matching rules, and check whether the attribute assignment in the requirement statement meets the data type and value range restrictions in the ontology by defining attribute constraint rules; The semantic reasoning engine is used to perform semantic verification on the formally expressed requirement statements. The semantic consistency between the requirement statements and the domain ontology is automatically checked through the logical reasoning algorithm. The semantic defects and errors in the requirement statements are inferred, and intuitive problem descriptions and modification suggestions are generated for the detected semantic problems.

5. The method according to claim 1, characterized in that According to the requirement verification report, judging whether there is a semantic contradiction or a logical loophole in the business requirement logic, and when a semantic contradiction or a logical loophole is detected, correcting the business requirement logic that fails the verification in combination with the business domain ontology model includes: Convert the process model containing process deadlock defects into a Petri net representation, and use the formal semantics of Petri nets to explicitly model process activities, resources, and control flow relationships; Based on the Petri net model, the reachability graph analysis is performed to identify the deadlock state in the Petri net by searching for the termination node in the reachability graph. The termination node indicates that there is no migration that can be triggered in the current state. For each deadlock state, a corresponding deadlock dependency graph is generated. The nodes in the deadlock dependency graph represent the resources and migrations that cause the deadlock, and the edges represent the resource application and occupancy dependencies. The deadlock dependency graph describes the resource constraints that form the deadlock loop. Run the minimum cut algorithm on the deadlock dependency graph to find the resource dependency edge set that can cut off the deadlock loop and minimize the modification cost. The minimum cut algorithm ensures that the adjustment to the original process structure is minimized while breaking the deadlock. Generate a process modification plan based on the minimum cost edge set, and automatically recommend specific modification operations such as adjusting the resource application sequence, increasing resource capacity, and inserting a synchronization mechanism by combining the semantic information of process activity resources and expert modification rules; The deadlock reachability of the process modification plan is re-verified based on Petri nets to ensure that the process modification plan effectively eliminates the deadlock and does not introduce new defects.

6. A cloud platform-based business demand confirmation system, used to implement the method described in any one of claims 1 to 5, characterized in that: include: The first unit is used to build a business process engine on the cloud platform according to business scenarios and business rules, and to perform visual modeling of business requirements through the business process engine to generate a standardized business requirement model; based on the business requirement model, a demand management microservice is deployed on the cloud platform, and the business requirement model is intelligently parsed through the demand management microservice to extract key information of business requirements and generate a structured demand description document; The second unit is used to perform semantic analysis on the demand description document using natural language processing technology, establish a business domain ontology model through knowledge graph construction technology, map the unstructured text in the demand description document to the concept nodes in the business domain ontology model, and formally represent the business demand logic; deploy the demand verification service on the cloud platform, and automatically verify the formally represented business demand logic through the formal verification method of control flow analysis or data flow analysis in combination with the business domain ontology model to generate a demand verification report; The third unit is used to determine whether there is a semantic contradiction or logical loophole in the business demand logic based on the demand verification report. When a semantic contradiction or logical loophole is detected, the business demand logic that fails the verification is corrected in combination with the business domain ontology model; the demand collaboration service is deployed on the cloud platform, and the corrected business demand logic is published in the form of a standardized interface for subscription by the collaborating parties.

7. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to call the instructions stored in the memory to execute the method described in any one of claims 1 to 5.

8. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 5 is implemented.

Images