Business demand management method and device in enterprise architecture, storage medium and server

Abstract

The embodiment of the invention discloses a business demand management method and device in an enterprise architecture, a storage medium and a server, and relates to the field of office automation. The method comprises the following steps: obtaining business requirements and enterprise architecture design information, and associating a multi-node review process; generating a report containing demand and architecture matching analysis, a digital construction state and an unconstructed capability list through the multi-modal large model, and outputting a review suggestion; automatically pushing the demand information, the architecture document, the analysis report and the suggestion to each review node by using a process engine; and collecting the review opinions and then summarizing to generate a structured review report. According to the method, unified demand management is realized, visual mapping of demand and architecture design is established, an online automatic review mechanism is provided, intelligent decision is supported, a demand-architecture-analysis closed-loop management system is formed, and digital transformation accuracy and execution efficiency are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of office automation, and in particular to a business requirement management method and device in enterprise architecture, a storage medium and a server. BACKGROUND

[0002] Under the background of rapid development of information technology, the relevance of business requirement management and architecture design in enterprise digital transformation is put forward with higher requirements. However, the existing requirement management method has significant limitations in practical application, which restricts the full play of the efficiency of digital construction.

[0003] Business requirement management presents a decentralized feature. Enterprise business requirements are usually stored in personal computers or different business systems, and there is a lack of unified management platform, which makes it difficult to search, track and manage the whole life cycle of requirements. This decentralized storage mode is easy to cause confusion of requirement versions and information island phenomenon, which seriously affects the standardization and continuity of requirement management.

[0004] Business requirements and architecture design lack effective correlation mechanism. The existing technology fails to establish the mapping relationship between requirements and architecture design documents, and the requirement management department is difficult to master the requirement conversion state in real time, and cannot accurately judge which requirements have completed architecture design and which have entered the development stage, resulting in the disconnection between requirements and construction progress.

[0005] The control means still stays at the manual stage. The compliance review of business requirements mainly depends on the manual verification of paper documents, and the system control lacks online and automated capabilities. This mode is not only inefficient, but also difficult to achieve full inspection, which easily leads to the problem of "two skins" of architecture design and development implementation.

[0006] The intelligent auxiliary means is missing. The requirement evaluation and analysis excessively rely on personal experience, and lack of intelligent analysis tools based on data-driven, which leads to efficiency bottleneck and quality risk in requirement priority judgment, conflict detection and feasibility evaluation.

[0007] The above problems make it difficult for enterprises to build an integrated management system of requirements, architecture and development, which restricts the realization of accurate landing of requirements and efficient allocation of resources in the process of digital transformation. Therefore, a new technical solution is needed to integrate the whole process of requirement management, establish the correlation between requirements and architecture design, and have intelligent control capability. SUMMARY

[0008] The embodiments of the present application provide a business requirement management method and device in enterprise architecture, a storage medium and a server, which can solve the problem of low correlation efficiency of business requirements in the prior art. The technical solution is as follows:

[0009] In a first aspect, the embodiments of the present application provide a management method of business requirements in enterprise architecture, the method comprising:

[0010] obtaining business requirement information and enterprise architecture design information input by a user;

[0011] determining an evaluation process associated with the user, the evaluation process comprising a plurality of process nodes, each process node being associated with an evaluator;

[0012] inputting the business requirement information and the enterprise architecture design information input by the user into a pre-trained multi-modal large model to output an analysis report, and generating corresponding evaluation suggestions according to the analysis report; the analysis report comprising: whether the business requirement information and the enterprise architecture design information match, whether a business capability involved in the business requirement information is completed in digital construction, and a list of business capabilities involved in the business requirement information that are not completed in digital construction;

[0013] pushing the business requirement information, the enterprise architecture design information, the analysis report and the evaluation suggestions to an evaluation interface of the evaluator associated with each process node based on a process engine;

[0014] receiving evaluation opinions submitted by the evaluator through the evaluation interface;

[0015] generating an evaluation report by aggregating the evaluation opinions of each evaluator after each evaluator completes the evaluation operation.

[0016] In a second aspect, the embodiments of the present application provide a management device of business requirements in enterprise architecture, the device comprising:

[0017] an obtaining unit configured to obtain business requirement information and enterprise architecture design information input by a user;

[0018] a determining unit configured to determine an evaluation process associated with the user, the evaluation process comprising a plurality of process nodes, each process node being associated with an evaluator;

[0019] a generating unit configured to input the business requirement information and the enterprise architecture design information input by the user into a pre-trained multi-modal large model to output an analysis report, and generate corresponding evaluation suggestions according to the analysis report; the analysis report comprising: whether the business requirement information and the enterprise architecture design information match, whether a business capability involved in the business requirement information is completed in digital construction, and a list of business capabilities involved in the business requirement information that are not completed in digital construction;

[0020] The review unit is used to push the business requirement information, the enterprise architecture design information, the analysis report, and the review suggestions to the review interface of the reviewers associated with each process node based on the process engine.

[0021] The receiving unit is used to receive review comments submitted by reviewers through the review interface;

[0022] The summary unit is used to summarize the review comments of each reviewer after the review operation is completed and generate a review report.

[0023] Thirdly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0024] Fourthly, embodiments of this application provide a server that may include a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0025] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following:

[0026] A unified requirements processing hub is established, enabling structured parsing and standardized storage of requirements information through a multimodal large-scale model. The system automatically extracts key requirements elements and creates indexes, supporting global retrieval and version control across documents and systems, eliminating information silos. The multimodal large-scale model automatically establishes the relationship between business requirements and enterprise architecture design documents through semantic understanding and graph construction technologies. The generated analysis reports intuitively display the requirements transformation status, including a list of business capabilities with implemented architecture designs and those yet to be built, enabling visual tracking of requirements and construction progress. A process engine drives an online review process, automatically pushing requirements information, architecture design documents, and intelligent analysis reports to designated review nodes. A preset rule engine automatically summarizes review opinions and performs conflict detection, generating review reports containing decision-making basis, replacing the traditional manual paper review mode. Based on a pre-trained multimodal large-scale model, the system can automatically complete requirements-architecture matching analysis, digital construction status diagnosis, and generate a list of unbuilt capabilities. Natural language processing technology enables intelligent interpretation of requirements documents, and graph database technology is used to construct a three-dimensional relationship model of requirements-capabilities-architecture, providing data-driven intelligent assistance for review decisions. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a schematic diagram of the network architecture provided in the embodiments of this application;

[0029] Figure 2 This is a flowchart illustrating the method for managing business requirements in an enterprise architecture provided in this application embodiment;

[0030] Figure 3 This is a schematic diagram of the structure of a management device for business requirements in an enterprise architecture provided in this application;

[0031] Figure 4 This is a schematic diagram of a computer storage medium provided in an embodiment of this application;

[0032] Figure 5 This is a schematic diagram of the structure of a server provided in this application. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0034] It should be noted that the business requirement management method in the enterprise architecture provided in this application is generally executed by the server, and correspondingly, the business requirement management device in the enterprise architecture is generally set in the server.

[0035] Figure 1 An exemplary network architecture is shown that can be applied to a management method or apparatus for business requirements in an enterprise architecture that can be used in this application.

[0036] like Figure 1 As shown, the network architecture may include: terminal device 101 and server 102. Terminal device 101 and server 102 can communicate with each other via the network, which serves as the medium for providing communication links between the various units. The network may include various types of wired or wireless communication links, such as: wired communication links including fiber optic cables, twisted-pair cables, or coaxial cables; and wireless communication links including Bluetooth communication links, Wi-Fi communication links, or microwave communication links.

[0037] Server 102 is used to perform business requirement management of the enterprise architecture of this application.

[0038] It should be noted that the terminal device 101 and the server 102 can be either hardware or software. When the terminal device 101 and the server 102 are hardware, they can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the terminal device 101 and the server 102 are software, they can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0039] The terminal device of this application can be equipped with various communication client applications, such as video recording applications, video playback applications, voice interaction applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0040] A terminal device can be either hardware or software. When the terminal device is hardware, it can be various terminal devices with a display screen, including but not limited to smartphones, tablets, laptops, and desktop computers. When the terminal device is software, it can be installed on the terminal devices listed above. It can be implemented as multiple software programs or software modules (e.g., used to provide distributed services) or as a single software program or software module; no specific limitation is made here.

[0041] When the terminal device is hardware, it can also be equipped with a display device and a camera. The display device can be any device capable of displaying information, and the camera is used to capture video streams. For example, the display device can be a cathode ray tube display (CR), a light-emitting diode display (LED), an e-ink screen, a liquid crystal display (LCD), or a plasma display panel (PDP). Users can use the display device on the terminal device to view displayed text, images, videos, and other information.

[0042] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is for illustrative purposes only. Depending on implementation needs, there can be any number of terminal devices, networks, and servers.

[0043] The following will be combined with the appendix Figure 2 This application provides a detailed description of the method for managing business requirements in an enterprise architecture, as provided in the embodiments of this application. The management device for business requirements in the enterprise architecture of this application embodiment can be... Figure 1 The server shown.

[0044] Please see Figure 2 This application provides a flowchart illustrating a method for managing business requirements within an enterprise architecture. For example... Figure 2 As shown, the method described in this application embodiment may include the following steps:

[0045] S201. Obtain business requirement information and enterprise architecture design information input by the user.

[0046] The business requirement information includes: requirement title, requirement description, and requirement priority. The enterprise architecture design information includes: business domain, involved business capabilities, application systems, and modules. The server receives the user-submitted business requirement information and enterprise architecture design information through a front-end user interface. The business requirement information includes the requirement title, requirement description, and requirement priority. The enterprise architecture design information is based on the TOGAF framework and includes the business domain, involved business capabilities, application systems, and modules. The server validates this input data to ensure correct format and no missing values, and then stores it in a back-end database table to provide a data source for subsequent steps. The stored procedure uses a transaction processing mechanism to ensure data consistency and integrity.

[0047] For example, a user enters a business requirement titled "Order Processing Optimization" in a front-end form, describing it as improving order processing efficiency, with a high priority. They also enter enterprise architecture design information: the business domain is sales management, the relevant business capabilities include order management and customer management, the application system is an ERP system, and the modules include order entry and inventory management. After receiving and verifying this information, the server stores it in the corresponding table in the database.

[0048] In some possible embodiments of this application, obtaining user-inputted business requirement information and enterprise architecture design information includes:

[0049] Obtain business requirement information entered by the user in the form interface, the business requirement information including: requirement title, requirement description and requirement priority;

[0050] Based on the drop-down selection box on the form interface, select one enterprise architecture design information from multiple candidate enterprise architecture design information, and associate the selected enterprise architecture design information with the business requirement information entered by the user; or

[0051] Import an Excel file based on the import control set on the user's form interface. The Excel file includes: business requirement information and enterprise architecture design information.

[0052] The Excel file is parsed, and the parsed business requirements information and enterprise architecture design information are associated.

[0053] The server receives user input of business requirement titles, descriptions, and priority data via a front-end form interface. Simultaneously, it loads a pre-built TOGAF enterprise architecture design information database, displaying candidate items in a dropdown selection box format. After the user selects specific enterprise architecture design information, the server captures this selection action and extracts the unique identifier of the business requirement information and the selected architecture. The system implements a two-way binding mechanism, establishing logical associations between the requirement title, description, and priority fields and the business domains, business capabilities, application systems, and modules within the architecture. After integrity verification, the associated data is persistently stored in a database relational table using a transactional approach, ensuring the traceability of the mapping relationship between requirements and architectures.

[0054] The candidate enterprise architecture design information in the dropdown selection box is dynamically loaded from the architecture library by the server in real time. During loading, access control is applied, displaying only items visible to the current user. Before user submission, the server executes linked verification rules, such as verifying whether the selected architecture includes the business capabilities mentioned in the requirement description. If a conflict exists, a notification is sent to the front end in real time. An optimistic locking mechanism is used during data storage to prevent inconsistencies in architecture information versions caused by concurrent operations.

[0055] This embodiment achieves a precise correlation between business requirements and enterprise architecture design information, ensuring data validity through dynamic loading and real-time verification. A two-way binding mechanism eliminates errors from manual matching, and transactional storage ensures the integrity and traceability of the relationships, providing a highly consistent data foundation for subsequent architecture matching analysis and significantly improving the reliability of the review process.

[0056] In some possible embodiments of this application, obtaining user-inputted business requirement information and enterprise architecture design information includes:

[0057] Import an Excel file based on the import control set on the user's form interface. The Excel file includes: business requirement information and enterprise architecture design information.

[0058] The Excel file is parsed, and the parsed business requirements information and enterprise architecture design information are associated.

[0059] The server receives user-uploaded Excel files via a front-end import control. Excel file transfer can employ chunked and parallel upload mechanisms to ensure stability and efficiency for large file transfers. The server verifies the file format and template compatibility, confirming that the file contains a predefined worksheet structure. The business requirements information table must include a requirements title, description, and priority fields, while the enterprise architecture design information table must include business domain, business capabilities, application systems, and module fields. The parsing engine reads cell data row by row and column by column, automatically identifying the mapping relationship between table headers and content, marking empty or incorrectly formatted entries as exceptions, and generating a cleaning log.

[0060] After parsing, the server associates business requirement items with enterprise architecture design items according to predefined rules. These rules include matching requirement titles with business domain keywords and semantic similarity analysis between requirement descriptions and business capabilities. Upon successful association, the system generates a unique association identifier for each pair of relationships. Through database transactions, the cleaned business requirement information, enterprise architecture design information, and association relationships are synchronously written to three relational database tables, ensuring atomicity and consistency. Abnormal data is moved to a repair queue, triggering an administrator notification mechanism.

[0061] This embodiment enables efficient batch collection of enterprise-level data, effectively reducing manual operation costs through automated parsing and intelligent association rules. The structured storage mechanism ensures a precise mapping between business needs and architectural design, providing a complete and reliable data source for subsequent multimodal analysis, significantly improving overall processing efficiency and data traceability.

[0062] S202. Determine the review process associated with the user, wherein the review process includes multiple process nodes, and each process node is associated with a reviewer.

[0063] The server queries a pre-defined review process configuration library based on user identity or role information to determine the associated review process. Each review process consists of multiple process nodes, each associated with a specific reviewer. The server retrieves process templates by matching user attributes such as department or project team and dynamically loads node details. Reviewer association information comes from the enterprise directory service to ensure correct permissions. After generating a process instance, the server initializes its status to pending review and records it in the process engine's metadata.

[0064] For example, if a user belongs to the finance department, the server queries the review process configuration library and finds that the department is associated with a review process containing three nodes: node one is associated with the finance manager, node two with the technical director, and node three with the business analyst. The server loads this information, creates a process instance, and stores it, ready for subsequent push notifications.

[0065] S203. Based on the pre-trained multimodal large model, input the user-inputted business requirement information and enterprise architecture design information into the multimodal large model and output an analysis report. The analysis report includes: whether the business requirement information and the enterprise architecture design information match; whether the business capabilities involved in the business requirement information have completed digital construction; and a list of business capabilities involved in the business requirement information that have not completed digital construction; and generating corresponding review suggestions based on the analysis report.

[0066] The process involves the server invoking a pre-deployed multimodal large model service, using business requirement information and enterprise architecture design information stored in S201 as input. The model processes text data, analyzes the match between business requirements and architecture design, and assesses whether business capabilities have completed digital transformation. The output analysis report includes matching results, digital transformation status, and a list of business capabilities that have not yet completed digital transformation. Based on the report, the server automatically generates review recommendations, such as suggesting prioritizing high-priority requirements or supplementing digital capabilities. The entire process utilizes asynchronous calls and result caching mechanisms to improve efficiency and handle high concurrency.

[0067] For example, the server inputs a business requirement titled "Customer Service Optimization," described as "Shortening Response Time," with a medium priority. The enterprise architecture design information identifies the business domain as Customer Support, business capabilities as Ticket Processing, the application system as a CRM system, and the module as a Feedback module. The model outputs an analysis report showing that the requirement matches the architecture, but the Ticket Processing capability has not yet been digitized; this capability is listed in the inventory. The server generates review recommendations, suggesting prioritizing review and initiating digitization transformation.

[0068] In some possible embodiments of this application, the step of inputting user-inputted business requirement information and enterprise architecture design information into the pre-trained multimodal large model and then outputting an analysis report, and generating corresponding review suggestions based on the analysis report, includes:

[0069] Extract business requirements information and enterprise architecture design information from the storage, perform word segmentation, stop word filtering and entity recognition on the extracted data, convert it into a standardized vector format, and finally generate a structured feature matrix;

[0070] The preprocessed feature matrix is ​​encapsulated into an API request, which is then used to call a pre-deployed multimodal large model microservice. The multimodal large model service loads the trained parameter weights and performs the following parallel computations: it calculates the semantic correlation between the requirement description and the business capability through a cross-modal attention mechanism; and then, based on the historical architecture change log library, it retrieves the system implementation status corresponding to the business capability.

[0071] After obtaining the original calculation results returned by the multimodal large model service, the rule engine is executed for processing: if the semantic relevance exceeds the threshold, it is marked as a match; otherwise, it is marked as a mismatch and the conflict point is output. According to the system implementation status feedback, the business capabilities are marked as "digitized" or "not digitized". All "not digitized" business capabilities are aggregated, sorted by demand priority to generate a list, and then an analysis report including the above three fields in a JSON object is output.

[0072] The analysis report is parsed, and review suggestions are dynamically generated using a pre-defined rule template.

[0073] The analysis report and the review recommendations are stored in a distributed cache database, and a lifecycle is set.

[0074] The server extracts structured and unstructured data sources from a document repository. Business requirement information includes title text, description text, and priority values; enterprise architecture design information covers business domain classification, business capability definitions, application system lists, and module component trees. The text parsing engine first performs domain-adaptive word segmentation on descriptive fields and loads an industry terminology dictionary to solve the problem of compound word segmentation. Then, it performs stop word filtering and retains noun phrases by combining part-of-speech tagging. The entity recognition module uses a pre-trained model to label business capability entities and application system entities, and maps them to the enterprise unified architecture library through the entity linking service. The vector transformation service inputs the processed text sequence into the Sentence-BERT model to generate a 512-dimensional semantic vector, and finally constructs a structured feature matrix according to requirement-capability pairs.

[0075] The server encapsulates the feature matrix into a gRPC request message, attaching session identifiers and timestamp metadata. It then invokes a pre-deployed multimodal computing service via the service mesh, which loads model parameters fine-tuned from the business corpus. Within the computing unit, two tasks are executed in parallel: first, calculating the cosine similarity between the requirement description vector and the business capability vector across modal attention layers, employing a multi-head attention mechanism to capture fine-grained semantic relationships; second, initiating a change log retrieval, querying application system deployment records associated with the business capabilities based on the Elasticsearch index to obtain the most recent valid version status.

[0076] After receiving the raw calculation results, the server activates the decision engine. The semantic relevance score is input into the dynamic threshold determination module, which generates a floating threshold by combining historical matching data with current requirement priorities. Items below the threshold trigger the conflict analyzer, which locates the semantic deviation dimension through feature inversion. The implementation status analyzer parses the deployment event chain in the change log; if a valid production environment running record exists, it is marked as digitized; otherwise, it is classified as undigitized. All undigitized business capabilities are aggregated and sorted topologically based primarily on requirement priority weight and secondarily on the scope of business domain impact, generating a list of capabilities to be transformed. The final output is a JSON report containing a triplet of matching status markers, conflict dimension descriptions, and digitization status classifications.

[0077] The report parsing engine extracts key decision factors and matches them against a pre-defined rule template library. When it detects that business capabilities are not digitized, it automatically associates them with architectural metadata to generate a system transformation path. For semantically conflicting entries, it outputs architectural optimization solutions based on business domain characteristics. The server writes the report and recommendations to a Redis sharded cluster using a distributed lock, and stores JSON data using hash slot partitioning. A lifecycle management strategy is set up, automatically archiving expired data to object storage and writing it to audit logs to track processing.

[0078] This embodiment achieves a closed-loop dynamic governance of enterprise architecture. It accurately identifies discrepancies between requirements and capabilities through multimodal semantic computation, and ensures the accuracy of digital status determination by relying on real-time change logs. A rule engine-driven suggestion generation mechanism enhances the effectiveness of architecture assessment decisions, while a distributed processing framework guarantees service reliability in high-concurrency scenarios. Ultimately, this forms a traceable and operable architecture governance knowledge base, significantly reducing technology investment risks.

[0079] S204. Based on the process engine, push the business requirement information, the enterprise architecture design information, the analysis report, and the review suggestions to the review interface of the reviewers associated with each process node.

[0080] The server utilizes an integrated workflow engine to package the business requirements information (S201), enterprise architecture design information (S202), and analysis reports and review suggestions (S203) into a task data package. Based on the review process node sequence determined in S202, the workflow engine pushes the data package to the personal review interface of each reviewer associated with each node. The push mechanism uses a message queue for asynchronous transmission, ensuring data reliability and real-time performance. The server monitors the push status and retryes or issues an alert if a failure occurs.

[0081] For example, the process engine might package data including demand titles, order processing optimizations, business domain sales management information, analysis reports showing matching but incomplete digitized order management lists, and review recommendations for priority processing. This data is then pushed to the interface of reviewers, such as finance managers, where it is displayed as an interactive form.

[0082] In some possible embodiments of this application, the step of pushing the business requirement information, the enterprise architecture design information, the analysis report, and the review suggestions to the review interface of the reviewers associated with each process node based on the process engine includes:

[0083] Extract business requirements, enterprise architecture design information, analysis reports, and review recommendations associated with the current process instance from the database;

[0084] The above data is integrated into a structured review data package according to a predefined template;

[0085] The review data package is processed differently based on the reviewers' roles and permissions;

[0086] The review task is pushed to the client of the reviewer corresponding to the current process node via the WebSocket channel.

[0087] The server drives transactions through a process engine, synchronously retrieving data from three independent data sources:

[0088] The business requirements database retrieves the title, description, and priority fields.

[0089] The enterprise architecture library extracts business domain topology, capability definitions, and system module mapping tables.

[0090] The triplet structure and review suggestion tree of the distributed cache read analysis report.

[0091] The data assembly engine uses a hierarchical nesting structure based on predefined XML templates: the top layer encapsulates process instance IDs and timestamps; the middle layer groups requirement-capability pairs by business domain; and the bottom layer binds status markers and conflict details from analysis reports. This ultimately generates a structured review data package with version numbers.

[0092] The server activates the RBAC (Role-Based Access Control) engine and loads the review matrix configuration:

[0093] Business architect role: Receives complete data packets, including mappings of underlying system modules.

[0094] Risk control reviewer role: Filtering technology implementation details, retaining business domain conflict analysis.

[0095] Technical lead role: Enhance implementation status data and add historical change records.

[0096] The data anonymization module dynamically processes sensitive fields, such as the core system IP address, to ensure that terminals with different roles only display authorized content.

[0097] The server maintains a WebSocket session registry and establishes a four-layer push protection mechanism:

[0098] Session Management: Create an independent channel for each reviewer and bind it to the process instance ID.

[0099] Data serialization: Converts review data packets into Protocol Buffers binary format.

[0100] Push trigger: The process engine sends an event to the message queue when a node switches.

[0101] Retransmission guarantee: Enable ACK confirmation retransmission for offline clients, and save the data to the pending queue if it times out.

[0102] The process state machine is updated synchronously during the push process, and the task arrival timestamp is marked.

[0103] Data packets are written to a blockchain-style audit log during generation, recording data hash values ​​and operation traces. When a network outage or client anomaly is detected:

[0104] Initiate local transaction rollback to maintain process state consistency, send task arrival notification via backup SMS channel, cache data packet snapshots on the server, and retain a recoverable window of preset duration.

[0105] This embodiment automates the end-to-end review of architecture governance, ensuring information integrity through structured data packets and meeting compliance requirements through a role-based dynamic filtering mechanism. A real-time push system eliminates delays caused by manual distribution, and an audit trail function ensures the verifiability of the review process. Ultimately, this forms a closed-loop enterprise architecture decision-making chain, significantly improving the efficiency and risk control level of reviewing major technical changes.

[0106] S205. Receive review comments submitted by reviewers through the review interface.

[0107] The server listens for events on the review interface and receives data via an API when reviewers submit comments. Review comments are stored in a structured format such as JSON, including text comments and options such as "pass" or "reject." The server cleans and validates the input data to prevent malicious injection and stores it in the review database. The receiving process uses transaction processing to ensure the atomicity and traceability of each comment.

[0108] For example, a reviewer (finance manager) might enter their opinion on the interface as "agreeing with the request, but suggesting increased budget support." The server receives this opinion, verifies it, and stores it as a structured record, including the opinion text and a status indicating "pending summary."

[0109] In some possible embodiments of this application, receiving review comments submitted by reviewers through the review interface includes:

[0110] The front-end API gateway receives HTTP POST requests sent by users through the client's review interface, and the HTTP POST requests carry review comments.

[0111] Extract the review comments from the request body and record the client IP and submission timestamp;

[0112] Verify the legality of the extracted review comments: check whether required fields are missing, verify that rejection comments must include modification suggestions, and confirm that the reviewers have approval authority for the current process node;

[0113] Once the verification is successful, the current process node, reviewers, and review comments will be bound and cached.

[0114] The server receives HTTP POST requests through the API gateway, and the request body encapsulates the review comments data packet in JSON format. The load balancer routes the request to a stateless processing node, which performs three steps: extracting the identity token and process instance ID from the request header, parsing the JSON body to obtain the comment content, decision status (pass / reject), modification suggestions, and other fields, and recording the client IP address and nanosecond-level timestamp into the request context.

[0115] The server startup verification pipeline performs three levels of verification:

[0116] Field integrity verification: Invokes the pre-loaded process template configuration to verify the existence of required fields. If core fields such as title or decision status are missing, a structured error code is generated and the process is terminated.

[0117] When the decision status is rejected, the rule engine is triggered to check the modification suggestion field: verify the suggestion text length threshold, detect whether it contains keywords of specific improvement measures, and perform similarity deduplication by referring to the historical suggestion library.

[0118] The distributed permission service verifies three key elements: the role of the reviewer corresponding to the identity token, the approval permission matrix of the current process node, and the state machine position of the process instance. If authentication fails, the request is frozen and a security audit is triggered.

[0119] After successful verification, the server performs atomic operations: generating a globally unique opinion identifier and constructing a four-dimensional binding relationship: process instance ID - node ID - reviewer ID - opinion identifier. The complete data packet is written to the distributed cache cluster, and the database is updated synchronously using a write-through strategy.

[0120] The cache structure uses a two-level storage:

[0121] Hot data layer: Stores opinions on the current activity process and retains them for a preset duration using an in-memory database.

[0122] Cold data layer: Archive historical opinions to columnar storage and create time-partitioned indexes.

[0123] The server deploys a circuit breaker strategy to handle abnormal scenarios: when field validation fails, it returns a precise error location with a list of missing fields; when there is a permission conflict, it triggers a real-time alarm and freezes the account session; when the service is unavailable, it starts a local transaction log and replays it asynchronously after recovery.

[0124] This embodiment constructs a highly reliable review comment processing pipeline. A multi-layered verification system effectively mitigates the risk of unauthorized operations, and atomic data binding ensures the traceability of the review process. The distributed storage architecture supports high-concurrency comment submissions, and a circuit breaker mechanism guarantees system resilience. Ultimately, this forms a closed-loop enterprise architecture governance decision-making chain, significantly reducing the risk of process anomalies caused by human error.

[0125] S206. After each reviewer completes their review, the reviewers' comments are summarized to generate a review report.

[0126] The server monitors the completion status of all process nodes, triggering a summary mechanism when all node reviews are completed. The server extracts the comments from each reviewer from the database, aggregating the data, including merging text comments and statistical decision results. The summary process uses natural language processing technology to generate a structured review report, including a summary of key comments and final conclusions. After generation, the report is stored as a document file, and relevant users are notified. The entire process ensures data consistency and report integrity.

[0127] For example: Once all three process nodes are completed, the server extracts feedback such as the finance manager's approval, the technical lead's suggested modifications, and the business analyst's rejection. This is then compiled into a review report, concluding that the requirements need optimization and resubmission. The report is stored and a notification email is sent.

[0128] In some possible embodiments of this application, the step of summarizing the review opinions of each reviewer to generate a review report after each reviewer has completed the review operation includes:

[0129] The status of each process node in the review process instance is continuously monitored. When the process engine marks all process node statuses as "completed", an automatic polling mechanism is triggered to extract the node completion timestamp sequence from the distributed cache.

[0130] Perform multi-source data collection based on process instance ID: extract structured decision data from review opinion forms, load the original text of attachments from object storage systems, associate business requirements with architecture design metadata, and establish an opinion aggregation tree based on requirements, with each requirement item having a review opinion and attachment index for each process node.

[0131] A rules engine is used to handle conflicting opinions: the approval / rejection ratio is calculated based on the decision status, decision weights are assigned according to the reviewer's job level, modification suggestions are clustered and merged, and a conflict resolution report is output, marking key points of disagreement that require manual arbitration.

[0132] The server assembles the final review report according to a predefined template. The review report includes: an execution summary, sub-reviews, conflict statements, and an attachment index. The review report is available in both PDF and JSON versions.

[0133] The review report is stored in the document database and a corresponding version number is generated. A report ready message is returned to the user, which carries the report access address and digital fingerprint.

[0134] The server deploys a process listener to track state machine changes in real time. When it detects that all nodes of the process instance are marked as completed: a distributed lock is activated to ensure single-instance processing, and the node completion time series is extracted from the process engine to calculate the time difference between the first and last nodes as the process timeliness benchmark value.

[0135] The server initiates four-way data collection based on the process instance ID:

[0136] Structured opinion extraction: Extract fields such as decision status, modification suggestions, and signature fingerprints from the review opinion form.

[0137] Unstructured attachment loading: Obtain the original text of the review attachments through the object storage interface and establish a file hash index.

[0138] Metadata association: A mapping table between requirement entries in the business requirement library and capability entries in the architecture library.

[0139] Construct an aggregation tree: with business requirements as the root node, attach the opinion sets of each review node to form a data forest with version tags.

[0140] The server activation rule engine performs four-layer decision analysis: calculating the pass rate of each requirement item, identifying disputed items below the threshold, loading the reviewer's job level weight matrix, assigning higher decision weights to rejection opinions from higher-level reviewers, merging similar modification suggestions using text vector clustering technology, generating an optimization scheme map, recording three types of disagreements: cross-business domain impact conflicts, resource allocation disputes, and technical route disagreements, outputting a conflict resolution report, and marking key decision items requiring manual intervention.

[0141] The server generates dual-version reports based on a predefined template engine:

[0142] The PDF version includes the following fields:

[0143] Executive Summary: Process timeliness analysis + key decision statistics.

[0144] Sub-item review: Present the requirement implementation path by grouping by business domain.

[0145] Conflict Explanation: Risk levels are indicated by red, yellow, and green colors.

[0146] Attachment Index: A list of verifiable files with hash values.

[0147] The JSON version of the report retains the complete structured data, including the decision path tracing chain, generating semantic version numbers (such as REPORT-1.3.5), and generating digital fingerprints through cryptographic hashing.

[0148] The server performs atomic storage operations: the PDF report is stored in a document database shard, the JSON version is written to the blockchain notarization service, the version number and digital fingerprint are registered to the metadata registry center, and the message service pushes a report ready notification to the associated users, including a signed access address.

[0149] This embodiment achieves an intelligent closed-loop for enterprise architecture review, with multi-source data aggregation ensuring the integrity of decision-making basis and a conflict resolution engine effectively extracting core points of disagreement. Dual-version report output meets the needs of different scenarios, and blockchain notarization ensures the immutability of the review process. Ultimately, a verifiable and auditable enterprise-level technical decision knowledge base is formed, significantly improving the governance quality of major architectural changes.

[0150] This application has the following specific beneficial effects:

[0151] A unified requirements processing hub is established, enabling structured parsing and standardized storage of requirements information through a multimodal large-scale model. The system automatically extracts key requirements elements and creates indexes, supporting global retrieval and version control across documents and systems, eliminating information silos. The multimodal large-scale model automatically establishes the relationship between business requirements and enterprise architecture design documents through semantic understanding and graph construction technologies. The generated analysis reports intuitively display the requirements transformation status, including a list of business capabilities with implemented architecture designs and those yet to be built, enabling visual tracking of requirements and construction progress. A process engine drives an online review process, automatically pushing requirements information, architecture design documents, and intelligent analysis reports to designated review nodes. A preset rule engine automatically summarizes review opinions and performs conflict detection, generating review reports containing decision-making basis, replacing the traditional manual paper review mode. Based on a pre-trained multimodal large-scale model, the system can automatically complete requirements-architecture matching analysis, digital construction status diagnosis, and generate a list of unbuilt capabilities. Natural language processing technology enables intelligent interpretation of requirements documents, and graph database technology is used to construct a three-dimensional relationship model of requirements-capabilities-architecture, providing data-driven intelligent assistance for review decisions.

[0152] This application addresses the challenge of fragmented requirements management by constructing a requirements-architecture design mapping mechanism, innovating control methods to achieve automated review, enhancing intelligent decision-making capabilities, and ultimately forming a closed-loop management system integrating requirements management, architecture design, and intelligent analysis, significantly improving the accuracy and efficiency of enterprise digital transformation.

[0153] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0154] Please see Figure 3This illustration shows a structural diagram of a management device for business requirements in an enterprise architecture provided by an exemplary embodiment of this application, hereinafter referred to as device 3. Device 3 can be implemented as all or part of a server through software, hardware, or a combination of both. Device 3 includes: an acquisition unit 301, a determination unit 302, a generation unit 303, a review unit 304, a receiving unit 305, and a summarizing unit 306.

[0155] Acquisition unit 301 is used to acquire business requirement information and enterprise architecture design information input by the user;

[0156] The determining unit 302 is used to determine the review process associated with the user, the review process including multiple process nodes, each process node being associated with a reviewer;

[0157] The generation unit 303 is used to input user-inputted business requirement information and enterprise architecture design information into the pre-trained multimodal large model and output an analysis report, and generate corresponding review suggestions based on the analysis report; the analysis report includes: whether the business requirement information and the enterprise architecture design information match, whether the business capabilities involved in the business requirement information have completed digital construction, and a list of business capabilities involved in the business requirement information that have not completed digital construction;

[0158] The review unit 304 is used to push the business requirement information, the enterprise architecture design information, the analysis report and the review suggestions to the review interface of the reviewers associated with each process node based on the process engine.

[0159] The receiving unit 305 is used to receive the review comments submitted by the reviewers through the review interface;

[0160] The summary unit 306 is used to summarize the review opinions of each reviewer and generate a review report after each reviewer has completed the review operation.

[0161] In one or more possible embodiments, obtaining user-inputted business requirement information and enterprise architecture design information includes:

[0162] Obtain business requirement information entered by the user in the form interface, the business requirement information including: requirement title, requirement description and requirement priority;

[0163] Based on the drop-down selection box on the form interface, select one enterprise architecture design information from multiple candidate enterprise architecture design information, and associate the selected enterprise architecture design information with the business requirement information entered by the user; or

[0164] Import an Excel file based on the import control set on the user's form interface. The Excel file includes: business requirement information and enterprise architecture design information.

[0165] The Excel file is parsed, and the parsed business requirements information and enterprise architecture design information are associated.

[0166] In one or more possible embodiments, the Excel file is transmitted in a segmented parallel manner.

[0167] In one or more possible embodiments, the step of inputting user-inputted business requirements and enterprise architecture design information into the pre-trained multimodal large model and then outputting an analysis report, and generating corresponding review suggestions based on the analysis report, includes:

[0168] Extract business requirements information and enterprise architecture design information from the storage, perform word segmentation, stop word filtering and entity recognition on the extracted data, convert it into a standardized vector format, and finally generate a structured feature matrix;

[0169] The preprocessed feature matrix is ​​encapsulated into an API request, which is then used to call a pre-deployed multimodal large model microservice. The multimodal large model service loads the trained parameter weights and performs the following parallel computations: it calculates the semantic correlation between the requirement description and the business capability through a cross-modal attention mechanism; and then, based on the historical architecture change log library, it retrieves the system implementation status corresponding to the business capability.

[0170] After obtaining the original calculation results returned by the multimodal large model service, the rule engine is executed for processing: if the semantic relevance exceeds the threshold, it is marked as a match; otherwise, it is marked as a mismatch and the conflict point is output. According to the system implementation status feedback, the business capabilities are marked as "digitized" or "not digitized". All "not digitized" business capabilities are aggregated, sorted by demand priority to generate a list, and then an analysis report including the above three fields in a JSON object is output.

[0171] The analysis report is parsed, and review suggestions are dynamically generated using a pre-defined rule template.

[0172] The analysis report and the review recommendations are stored in a distributed cache database, and a lifecycle is set.

[0173] In one or more possible embodiments, the step of pushing the business requirement information, the enterprise architecture design information, the analysis report, and the review suggestions based on the process engine to the review interface of the reviewers associated with each process node includes:

[0174] Extract business requirements, enterprise architecture design information, analysis reports, and review recommendations associated with the current process instance from the database;

[0175] The above data is integrated into a structured review data package according to a predefined template;

[0176] The review data package is processed differently based on the reviewers' roles and permissions;

[0177] The review task is pushed to the client of the reviewer corresponding to the current process node via the WebSocket channel.

[0178] In one or more possible embodiments, receiving review comments submitted by reviewers through the review interface includes:

[0179] The front-end API gateway receives HTTP POST requests sent by users through the client's review interface, and the HTTP POST requests carry review comments.

[0180] Extract the review comments from the request body and record the client IP and submission timestamp;

[0181] Verify the legality of the extracted review comments: check whether required fields are missing, verify that rejection comments must include modification suggestions, and confirm that the reviewers have approval authority for the current process node;

[0182] Once the verification is successful, the current process node, reviewers, and review comments will be bound and cached.

[0183] In one or more possible embodiments, the step of summarizing the review comments of each reviewer to generate a review report after each reviewer has completed their review operation includes:

[0184] The status of each process node in the review process instance is continuously monitored. When the process engine marks all process node statuses as "completed", an automatic polling mechanism is triggered to extract the node completion timestamp sequence from the distributed cache.

[0185] Perform multi-source data collection based on process instance ID: extract structured decision data from review opinion forms, load the original text of attachments from object storage systems, associate business requirements with architecture design metadata, and establish an opinion aggregation tree based on requirements, with each requirement item having a review opinion and attachment index for each process node.

[0186] A rules engine is used to handle conflicting opinions: the approval / rejection ratio is calculated based on the decision status, decision weights are assigned according to the reviewer's job level, modification suggestions are clustered and merged, and a conflict resolution report is output, marking key points of disagreement that require manual arbitration.

[0187] The server assembles the final review report according to a predefined template. The review report includes: an execution summary, sub-reviews, conflict statements, and an attachment index. The review report is available in both PDF and JSON versions.

[0188] The review report is stored in the document database and a corresponding version number is generated. A report ready message is returned to the user, which carries the report access address and digital fingerprint.

[0189] It should be noted that the device 3 provided in the above embodiments, when executing the business requirement management method in the enterprise architecture, is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the above functions. In addition, the business requirement management device in the enterprise architecture provided in the above embodiments and the business requirement management method embodiments in the enterprise architecture belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0190] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0191] See Figure 4 The diagram shown is a schematic of a computer storage medium provided in an embodiment of this application. The computer storage medium can store multiple instructions (i.e., Figure 4 The computer program shown above, the instructions of which are adapted to be loaded and executed by a processor as described above. Figure 2 The method steps of the illustrated embodiment can be found in the following documentation for detailed execution. Figure 2 The specific details of the illustrated embodiments will not be elaborated here.

[0192] This application also provides a computer program product that stores at least one instruction, which is loaded and executed by the processor to implement the management method for business requirements in the enterprise architecture described in the above embodiments.

[0193] Please see Figure 5 This provides a schematic diagram of a server structure for an embodiment of this application. Figure 5 As shown, the server 500 may include: at least one processor 501, at least one network interface 504, a user interface 503, a memory 505, and at least one communication bus 502.

[0194] The communication bus 502 is used to enable communication between these components.

[0195] The user interface 503 may include a display screen and a camera. Optionally, the user interface 503 may also include a standard wired interface and a wireless interface.

[0196] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0197] The processor 501 may include one or more processing cores. The processor 501 connects to various parts of the server 500 via various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 505, and by calling data stored in the memory 505. Optionally, the processor 501 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 501 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 501 and may be implemented as a separate chip.

[0198] The memory 505 may include random access memory (RAM) or read-only memory. Optionally, the memory 505 may include a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 505 may also be at least one storage device located remotely from the aforementioned processor 501.Figure 5 As shown, the memory 505, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and application programs.

[0199] exist Figure 5 In the server 500 shown, the user interface 503 is mainly used to provide an input interface for users and obtain user input data; while the processor 501 can be used to call the application program stored in the memory 505 and specifically execute, such as Figure 2 The method shown can be referred to for details. Figure 2 As shown, it will not be elaborated further here.

[0200] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0201] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for managing business requirements in an enterprise architecture, characterized in that, include: Obtain business requirements and enterprise architecture design information input by users; Determine the review process associated with the user, the review process includes multiple process nodes, and each process node is associated with a reviewer; Based on a pre-trained multimodal large model, the user-inputted business requirements information and enterprise architecture design information are input into the multimodal large model, and an analysis report is output. Based on the analysis report, corresponding review suggestions are generated. The analysis report includes: whether the business requirements information and the enterprise architecture design information match, whether the business capabilities involved in the business requirements information have completed digital construction, and a list of business capabilities involved in the business requirements information that have not completed digital construction. Based on the process engine, the business requirement information, the enterprise architecture design information, the analysis report, and the review suggestions are pushed to the review interface of the reviewers associated with each process node. Receive review comments submitted by reviewers through the review interface; After each reviewer completes their review, their comments are compiled to generate a review report.

2. The method according to claim 1, characterized in that, The acquisition of user-inputted business requirements and enterprise architecture design information includes: Obtain business requirement information entered by the user in the form interface, the business requirement information including: requirement title, requirement description and requirement priority; Based on the drop-down selection box on the form interface, select one enterprise architecture design information from multiple candidate enterprise architecture design information, and associate the selected enterprise architecture design information with the business requirement information entered by the user; or Import an Excel file based on the import control set on the user's form interface. The Excel file includes: business requirement information and enterprise architecture design information. The Excel file is parsed, and the parsed business requirements information and enterprise architecture design information are associated.

3. The method according to claim 2, characterized in that, The Excel file is transmitted in a segmented parallel manner.

4. The method according to claim 1, 2, or 3, characterized in that, The process of inputting user-inputted business requirements and enterprise architecture design information into a pre-trained multimodal large model, outputting an analysis report, and generating corresponding review suggestions based on the analysis report includes: Extract business requirements information and enterprise architecture design information from the storage, perform word segmentation, stop word filtering and entity recognition on the extracted data, convert it into a standardized vector format, and finally generate a structured feature matrix; The preprocessed feature matrix is ​​encapsulated into an API request, which is then used to call a pre-deployed multimodal large model microservice. The multimodal large model service loads the trained parameter weights and performs the following parallel computations: it calculates the semantic correlation between the requirement description and the business capability through a cross-modal attention mechanism; and then, based on the historical architecture change log library, it retrieves the system implementation status corresponding to the business capability. After obtaining the original calculation results returned by the multimodal large model service, the rule engine is executed for processing: if the semantic relevance exceeds the threshold, it is marked as a match; otherwise, it is marked as a mismatch and the conflict point is output. According to the system implementation status feedback, the business capabilities are marked as "digitized" or "not digitized". All "not digitized" business capabilities are aggregated, sorted by demand priority to generate a list, and then an analysis report including the above three fields in a JSON object is output. The analysis report is parsed, and review suggestions are dynamically generated using a pre-defined rule template. The analysis report and the review recommendations are stored in a distributed cache database, and a lifecycle is set.

5. The method according to claim 4, characterized in that, The process engine-based push of the business requirement information, enterprise architecture design information, analysis report, and review suggestions to the review interfaces of reviewers associated with each process node includes: Extract business requirements, enterprise architecture design information, analysis reports, and review recommendations associated with the current process instance from the database; The above data is integrated into a structured review data package according to a predefined template; The review data package is processed differently based on the reviewers' roles and permissions; The review task is pushed to the client of the reviewer corresponding to the current process node via the WebSocket channel.

6. The method according to claim 1, 2, 3, or 5, characterized in that, The review comments submitted by reviewers through the review interface include: The front-end API gateway receives HTTP POST requests sent by users through the client's review interface, and the HTTP POST requests carry review comments. Extract the review comments from the request body and record the client IP and submission timestamp; Verify the legality of the extracted review comments: check whether required fields are missing, verify that rejection comments must include modification suggestions, and confirm that the reviewers have approval authority for the current process node; Once the verification is successful, the current process node, reviewers, and review comments will be bound and cached.

7. The method according to claim 6, characterized in that, After each reviewer completes their review, the review comments are summarized to generate a review report, including: The status of each process node in the review process instance is continuously monitored. When the process engine marks all process node statuses as "completed", an automatic polling mechanism is triggered to extract the node completion timestamp sequence from the distributed cache. Perform multi-source data collection based on process instance ID: extract structured decision data from review opinion form, load original attachment text from object storage system, associate business requirements and architecture design metadata, and establish opinion aggregation tree based on requirements, with review opinions and attachment indexes of each process node attached under each requirement item; A rules engine is used to handle conflicting opinions: the approval / rejection ratio is calculated based on the decision status, decision weights are assigned according to the reviewer's job level, modification suggestions are clustered and merged, and a conflict resolution report is output, marking key points of disagreement that require manual arbitration. The server assembles the final review report according to a predefined template. The review report includes: an execution summary, sub-reviews, conflict statements, and an attachment index. The review report is available in both PDF and JSON versions. The review report is stored in the document database and a corresponding version number is generated. A report ready message is returned to the user, which carries the report access address and digital fingerprint.

8. A management device for business requirements in an enterprise architecture, characterized in that, include: The acquisition unit is used to acquire business requirement information and enterprise architecture design information input by the user. A determining unit is used to determine the review process associated with the user, the review process including multiple process nodes, each process node being associated with a reviewer; The generation unit is used to input user-inputted business requirement information and enterprise architecture design information into a pre-trained multimodal large model and output an analysis report, as well as generate corresponding review suggestions based on the analysis report. The analysis report includes: whether the business requirement information and the enterprise architecture design information match, whether the business capabilities involved in the business requirement information have completed digital construction, and a list of business capabilities involved in the business requirement information that have not completed digital construction. The review unit is used to push the business requirement information, the enterprise architecture design information, the analysis report, and the review suggestions to the review interface of the reviewers associated with each process node based on the process engine. The receiving unit is used to receive review comments submitted by reviewers through the review interface; The summary unit is used to summarize the review comments of each reviewer after the review operation is completed and generate a review report.

9. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions, which are adapted to be loaded by a processor and executed as method steps as claimed in any one of claims 1 to 7.

10. A server, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed the method steps as claimed in any one of claims 1 to 7.

Images