Pre-analysis method and device for business demand defects, medium and program product

Abstract

The invention provides a pre-analysis method and device for business demand defects, a medium and a program product. Relates to the technical field of data processing. The method comprises the following steps: acquiring a demand document containing a business operation rule and a constraint requirement, splitting sub-tasks according to a preset splitting rule, distributing the sub-tasks to different computing nodes, and performing parallel analysis by combining a preset demand feature template to obtain a result; performing natural language processing on an analysis result to extract structured demand features, adjusting trigger scene feature weights in a historical defect database, matching the features with database trigger scenes to obtain defect information, and generating an early warning report; and finally, obtaining production operation data association structural features corresponding to the early warning report, performing analysis to obtain newly added defect information, supplementing the newly added defect information to the database, and updating the weight. The large-scale document analysis efficiency is effectively improved, the defect recognition accuracy and adaptability are enhanced, a dynamic iteration closed loop is formed, the disjunction limitation of traditional analysis and post-investment operation is broken through, and defect full-life-cycle management is achieved.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a method, device, medium, and program product for pre-analysis of business requirement defects. Background Technology

[0002] In many fields with stringent requirements for business continuity and data security, the quality of business requirement implementation directly impacts production system stability and service experience, making related technology development a key focus in the field of data processing technology. As business scenarios become increasingly complex, logical conflicts and rule loopholes hidden in requirement documents can easily escalate into defects during the production phase, not only disrupting normal business operations but also potentially causing economic losses or compliance issues.

[0003] In existing technologies, the processing flow of business requirements mostly revolves around task distribution and development scheduling. The core logic is to receive the requirement document and then distribute tasks and allocate time based on the resource attributes of the R&D team. The technical focus of this type of solution is on improving resource allocation efficiency, without building a deep analysis mechanism for the content of the requirement document. It neither extracts requirement features through technical means to identify potential defects nor establishes a correlation path between requirements and historical defect data, relying solely on the experience of developers to troubleshoot problems.

[0004] The lack of pre-implementation defect analysis capabilities that combine the characteristics of the existing business requirements makes it impossible to predict defects by accurately matching historical defect scenarios. As a result, a large number of defects that could have been avoided in advance are exposed after production, which increases the later maintenance costs and damages the stability of business operations. This problem can essentially be attributed to the lack of a pre-implementation defect identification and matching mechanism. Summary of the Invention

[0005] This application provides a method, device, medium, and program product for pre-analysis of business requirement defects, which aims to achieve pre-identification and accurate prediction of defects before the implementation of business requirements by extracting features from business requirement documents, matching historical defects, and generating early warning reports, thereby reducing the defect rate and subsequent maintenance costs after production.

[0006] In a first aspect, embodiments of this application provide a method for pre-analysis of business requirement defects, comprising: obtaining a business requirement document, wherein the business requirement document contains business operation rules and constraints;

[0007] The business requirement document is split into multiple parsing subtasks by a preset splitting rule, which are then assigned to different computing nodes and parsed in parallel using a preset requirement feature template to obtain the parsing results.

[0008] The parsing results are subjected to natural language processing to obtain structured requirement features, which include business information, functional scenario subclasses, and compliance constraint tags.

[0009] Adjust the matching weight of trigger scenario features in the preset historical defect database based on the business information corresponding to the structured demand features.

[0010] Defect information is obtained by associating and matching the structured requirement features with the triggering scenarios in the preset historical defect database;

[0011] An early warning report is generated based on the constraints and the defect information. The early warning report includes the defect type, the repair plan, and the scenario-based priority.

[0012] Obtain the functional deployment and operation data corresponding to the early warning report, and associate the operation data with the structured demand characteristics;

[0013] The newly added defect information is obtained by analyzing the running data, and the newly added defect information is added to the preset historical defect database. The matching weight of the triggering scenario feature is also updated.

[0014] In one possible implementation, the parsing result is subjected to natural language processing to obtain structured requirement features, including:

[0015] Obtain a preset business classification dictionary and semantic annotation rules, wherein the business classification dictionary contains business domain-specific terms and corresponding classification tags;

[0016] The parsing results are segmented and invalid words are filtered out to obtain a set of business terms.

[0017] Based on the semantic annotation rules and the preset business classification dictionary, the business vocabulary set is classified and labeled to obtain business classification tags;

[0018] Extract the constraint clauses from the parsing results and perform standardized transformation to obtain compliance constraint labels;

[0019] The structured requirement features are obtained by integrating the business category tags, functional scenario subcategories, and compliance constraint tags.

[0020] In one possible implementation, the constraint clauses in the parsing result are extracted and standardized to obtain compliance constraint labels, including:

[0021] The constraint clauses in the parsed results are split by text matching to obtain independent constraint units;

[0022] The independent constraint unit is compared with the preset constraint clause to obtain the constraint type; the preset constraint clause includes the constraint type and the corresponding label rule;

[0023] Based on the labeling rules, corresponding compliance constraint labels are generated for the constraint types.

[0024] In one possible implementation, adjusting the matching weights of trigger scenario features in a preset historical defect database based on the business information corresponding to the structured requirement features includes:

[0025] Extract business information from the structured requirements features;

[0026] The business information is matched with a preset business information weight mapping table to obtain the corresponding weight adjustment parameters; the preset business information weight mapping table includes the weight adjustment parameters corresponding to each business information.

[0027] The weight adjustment parameters are input into a preset weight calculation model to obtain the calculation result;

[0028] The matching weights of the corresponding triggering scenario features in the preset historical defect database are updated based on the calculation results.

[0029] In one possible implementation, the defect information is obtained by associating and matching the structured requirement features with triggering scenarios in the preset historical defect database, including:

[0030] The structured requirement features are matched with the triggering scenarios to obtain a preliminary defect set;

[0031] The structured demand features are input into a preset defect prediction model to obtain a set of predicted defects and defect confidence levels.

[0032] The preliminary defect set and the predicted defect set are merged and duplicate defect records are removed to obtain the target defect;

[0033] The target defects are sorted according to the preset defect priority and the defect confidence level to obtain a defect sequence;

[0034] The defect information is obtained by extracting a preset number of target defects in sequence from the defect sequence and integrating them.

[0035] In one possible implementation, merging the preliminary defect set and the predicted defect set and removing duplicate defects to obtain the target defect includes:

[0036] Obtain a unique identifier corresponding to each defect record in the preliminary defect set and the predicted defect set. The unique identifier is generated by the defect type and the triggering condition.

[0037] The preliminary defect set and the predicted defect set are traversed to establish an index table for unique defect identifiers;

[0038] Duplicate records are generated by comparing the number of occurrences of the unique identifier in the index table;

[0039] The defect entry with the highest confidence level among the duplicate records is retained, and the remaining duplicate entries are deleted;

[0040] The target defect is obtained by integrating the defect entries.

[0041] In one possible implementation, it also includes:

[0042] Obtain the interface parameters and target receiving account information of the preset development collaboration system;

[0043] A communication connection with the development collaboration system is established through the interface parameters;

[0044] The warning report is packaged according to a preset data format and sent to the target receiving account;

[0045] The system receives a report reception confirmation from the development collaboration system and associates the report reception confirmation with the identifier of the business requirement document, storing it in a preset record database.

[0046] In one possible implementation, the process involves acquiring the functional deployment and operation data corresponding to the early warning report, and associating the operation data with the structured requirement features, including:

[0047] Obtain the functional deployment and operation data corresponding to the early warning report. The functional deployment and operation data includes business operation logs, system interaction data, functional response data, and abnormal return information.

[0048] Extract the business requirement document identifier associated with the structured requirement features;

[0049] The mapping between the functional deployment and operation data and the structured requirement features is established by identifying the business requirement document.

[0050] In one possible implementation, the operational data is analyzed to obtain new defect information, the new defect information is added to the preset historical defect database, and the matching weight of the triggering scenario features is updated, including:

[0051] The operational data is compared with a preset normal operating threshold to obtain newly added defect information;

[0052] Extract the unique identifier corresponding to the newly added defect information;

[0053] The unique identifier is compared with the defect identifier in the preset historical defect database to remove duplicates, and the deduplicated new defect information is obtained.

[0054] Add the newly added defect information after deduplication to the preset historical defect database;

[0055] Based on the frequency of occurrence and business relevance of the newly added defect information, the weights are adjusted using a preset weight calculation model to obtain the updated trigger scenario feature matching weights.

[0056] The updated trigger scenario feature matching weights are then updated in the preset historical defect database.

[0057] Secondly, embodiments of this application provide a pre-analysis device for business requirement defects, comprising:

[0058] The acquisition module is used to acquire a business requirements document, which contains business operation rules and constraints.

[0059] The parsing module is used to split the business requirement document into multiple parsing subtasks according to preset splitting rules, distribute them to different computing nodes, and perform parallel parsing in combination with preset requirement feature templates to obtain the parsing results;

[0060] The processing module is used to perform natural language processing on the parsing results to obtain structured requirement features, which include business information, functional scenario subclasses, and compliance constraint tags.

[0061] The adjustment module is used to adjust the matching weight of trigger scenario features in the preset historical defect database based on the business information corresponding to the structured requirement features.

[0062] The matching module is used to associate and match the structured requirement features with the triggering scenarios in the preset historical defect database to obtain defect information;

[0063] A generation module is used to generate an early warning report based on the constraints and the defect information. The early warning report includes the defect type, repair plan, and scenario-based priority.

[0064] The acquisition module is also used to acquire the functional production and operation data corresponding to the early warning report, and associate the operation data with the structured demand features;

[0065] The update module is used to analyze the running data to obtain new defect information, add the new defect information to the preset historical defect database, and update the matching weight of the triggering scenario features.

[0066] In one possible implementation, the processing module is specifically used for:

[0067] Obtain a preset business classification dictionary and semantic annotation rules, wherein the business classification dictionary contains business domain-specific terms and corresponding classification tags;

[0068] The parsing results are segmented and invalid words are filtered out to obtain a set of business terms.

[0069] Based on the semantic annotation rules and the preset business classification dictionary, the business vocabulary set is classified and labeled to obtain business classification tags;

[0070] Extract the constraint clauses from the parsing results and perform standardized transformation to obtain compliance constraint labels;

[0071] The structured requirement features are obtained by integrating the business category tags, functional scenario subcategories, and compliance constraint tags.

[0072] In one possible implementation, the processing module is further configured to:

[0073] The constraint clauses in the parsed results are split by text matching to obtain independent constraint units;

[0074] The independent constraint unit is compared with the preset constraint clause to obtain the constraint type; the preset constraint clause includes the constraint type and the corresponding label rule;

[0075] Based on the labeling rules, corresponding compliance constraint labels are generated for the constraint types.

[0076] In one possible implementation, the adjustment module is specifically used for:

[0077] Extract business information from the structured requirements features;

[0078] The business information is matched with a preset business information weight mapping table to obtain the corresponding weight adjustment parameters; the preset business information weight mapping table includes the weight adjustment parameters corresponding to each business information.

[0079] The weight adjustment parameters are input into a preset weight calculation model to obtain the calculation result;

[0080] The matching weights of the corresponding triggering scenario features in the preset historical defect database are updated based on the calculation results.

[0081] In one possible implementation, the matching module is specifically used for:

[0082] The structured requirement features are matched with the triggering scenarios to obtain a preliminary defect set;

[0083] The structured demand features are input into a preset defect prediction model to obtain a set of predicted defects and defect confidence levels.

[0084] The preliminary defect set and the predicted defect set are merged and duplicate defect records are removed to obtain the target defect;

[0085] The target defects are sorted according to the preset defect priority and the defect confidence level to obtain a defect sequence;

[0086] The defect information is obtained by extracting a preset number of target defects in sequence from the defect sequence and integrating them.

[0087] In one possible implementation, the matching module is further configured to:

[0088] Obtain a unique identifier corresponding to each defect record in the preliminary defect set and the predicted defect set. The unique identifier is generated by the defect type and the triggering condition.

[0089] The preliminary defect set and the predicted defect set are traversed to establish an index table for unique defect identifiers;

[0090] Duplicate records are generated by comparing the number of occurrences of the unique identifier in the index table;

[0091] The defect entry with the highest confidence level among the duplicate records is retained, and the remaining duplicate entries are deleted;

[0092] The target defect is obtained by integrating the defect entries.

[0093] In one possible implementation, the acquisition module is further configured to:

[0094] Obtain the interface parameters and target receiving account information of the preset development collaboration system;

[0095] A communication connection with the development collaboration system is established through the interface parameters;

[0096] The warning report is packaged according to a preset data format and sent to the target receiving account;

[0097] The system receives a report reception confirmation from the development collaboration system and associates the report reception confirmation with the identifier of the business requirement document, storing it in a preset record database.

[0098] In one possible implementation, the acquisition module is further configured to:

[0099] Obtain the functional deployment and operation data corresponding to the early warning report. The functional deployment and operation data includes business operation logs, system interaction data, functional response data, and abnormal return information.

[0100] Extract the business requirement document identifier associated with the structured requirement features;

[0101] The mapping between the functional deployment and operation data and the structured requirement features is established by identifying the business requirement document.

[0102] In one possible implementation, the update module is specifically used for:

[0103] The operational data is compared with a preset normal operating threshold to obtain newly added defect information;

[0104] Extract the unique identifier corresponding to the newly added defect information;

[0105] The unique identifier is compared with the defect identifier in the preset historical defect database to remove duplicates, and the deduplicated new defect information is obtained.

[0106] Add the newly added defect information after deduplication to the preset historical defect database;

[0107] Based on the frequency of occurrence and business relevance of the newly added defect information, the weights are adjusted using a preset weight calculation model to obtain the updated trigger scenario feature matching weights.

[0108] The updated trigger scenario feature matching weights are then updated in the preset historical defect database.

[0109] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0110] The memory stores computer-executed instructions;

[0111] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0112] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0113] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0114] The pre-analysis method, device, medium, and program product for business requirement defects provided in this application embodiment acquires business requirement documents and breaks them down into multiple parsing sub-tasks using preset splitting rules. These sub-tasks are then distributed to different computing nodes and parsed in parallel using preset requirement feature templates to obtain parsing results. Natural language processing is performed on the parsing results to extract structured requirement features. Based on these structured requirement features, the matching weights of trigger scenario features in a preset historical defect database are adjusted. The structured requirement features are then correlated with the trigger scenarios in the defect database to obtain defect information and generate early warning reports. Simultaneously, the corresponding functional deployment and operation data for the early warning reports are acquired and correlated with the structured requirement features. After analyzing the operation data to obtain new defect information, it is added to the defect database, and the matching weights of trigger scenario features are updated. This effectively improves the parsing efficiency of large-scale business requirement documents, enhances the accuracy and scenario adaptability of pre-defect identification, forms a dynamic iterative closed loop for defect analysis, and overcomes the limitations of traditional pre-analysis being disconnected from post-deployment operation status. This enables full lifecycle management of business requirement defects from pre-identification to continuous optimization. Attached Figure Description

[0115] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0116] Figure 1 A flowchart illustrating the pre-analysis method for business requirement defects provided in this application;

[0117] Figure 2 A schematic diagram of the pre-analysis device for business requirement defects provided in this application;

[0118] Figure 3 A schematic diagram of the structure of the electronic device provided in this application.

[0119] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0120] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0121] The collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0122] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0123] First, let me explain the terms used in this application:

[0124] Structured requirement features: These are standardized feature sets extracted from business requirement documents after natural language processing. They include business information, functional scenario subclasses, and compliance constraint tags. They are the core basis for defect matching.

[0125] Pre-built historical defect database: refers to a structured database that is pre-built and continuously updated, storing information such as the triggering scenario characteristics, defect types, and repair solutions of historical business defects, and is used for defect matching and weight adjustment;

[0126] Triggering scenario features: These refer to the key features of the business scenarios associated with defects in the pre-defined historical defect database, including the business operation conditions and data interaction nodes where the defect occurred. They are the comparison dimensions for defect matching.

[0127] Early warning report: refers to a report generated based on defect information and constraint requirements, which includes defect type, repair plan and scenario priority, and is used to guide defect remediation before business function is put into production;

[0128] Functional deployment and operation data: refers to the business operation logs, system interaction data, functional response data, and abnormal return information collected after the business function corresponding to the early warning report is deployed to the production environment;

[0129] Distributed computing framework: refers to a computing architecture used to split and distribute the task of parsing business requirement documents to multiple computing nodes for parallel processing, aiming to improve the parsing efficiency of large-scale requirement documents;

[0130] Parallel processing architecture: refers to a system architecture that supports multiple computing nodes to execute parsing subtasks simultaneously, and works in conjunction with a distributed computing framework to achieve parallel execution of tasks;

[0131] Pre-defined requirement feature templates: These are standardized data models extracted from historical requirement documents in the business domain, containing frequently occurring feature items, feature association rules, and annotation standards, used to assist in the rapid parsing of requirement documents;

[0132] Parsing results: refers to the structured set output after the business requirement document is split and parsed in parallel, which includes local parsing data of subtasks, high-frequency feature matching results and global integrated data. It is the direct input for generating structured requirement features.

[0133] In existing technologies, relying on developers' subjective experience to manually review business requirement documents without extracting structured features from the requirement content or dynamically adjusting the matching logic of historical defects based on requirement attributes results in technical problems such as the inability to accurately identify potential defects before the implementation of business requirements and a lack of targeted defect prediction.

[0134] The pre-analysis method for business requirement defects provided in this application obtains business requirement documents containing business operation rules and constraints, extracts structured requirement features including business information, functional scenario subcategories, and compliance constraint tags through natural language processing, and then dynamically adjusts the matching weights of trigger scenario features in a preset historical defect database based on the business information in these features. This allows for the association and matching of structured requirement features with trigger scenarios in the historical defect database to obtain defect information. Finally, it combines constraint requirements to generate an early warning report containing defect type, repair plan, and scenario-based priority. This technical approach solves the technical problem in existing technologies where the lack of pre-analysis capabilities that combine the characteristics of business requirements before implementation leads to high defect rates and high maintenance costs after deployment. Its core technical concept lies in constructing a pre-analysis system with structured requirement features, dynamic defect matching, and accurate early warning reports, enabling early identification and prediction of defects. Simultaneously, by improving the coverage and matching accuracy of the defect database, a closed-loop iterative mechanism for business requirement defect analysis is formed, enhancing the adaptability and effectiveness of the pre-analysis method for business requirement defects.

[0135] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0136] Figure 1 A flowchart illustrating the pre-analysis method for business requirement defects provided in this application is shown below. Figure 1 As shown, this embodiment provides a method for pre-analysis of business requirement defects, which includes the following steps:

[0137] Step S101: Obtain the business requirements document, which contains business operation rules and constraints.

[0138] Specifically, by using data interface calls and document parsing tools, we can obtain full information on business requirements, ensuring that the acquired documents cover the complete data dimensions of business execution logic and boundary constraints, providing a standardized input foundation for subsequent analysis. By ensuring the complete acquisition of business operation rules and constraints, we can avoid judgment biases caused by missing core information in subsequent analysis, guaranteeing the comprehensiveness of analysis results from the data source, and laying the foundation for defect identification to cover all business scenarios.

[0139] Step S102: The business requirement document is split into multiple parsing subtasks by a preset splitting rule, which are then assigned to different computing nodes and parsed in parallel using a preset requirement feature template to obtain the parsing results.

[0140] Specifically, the process of constructing the preset requirement feature template includes: obtaining historical business requirement documents; processing the historical business requirement documents to obtain a standardized historical feature dataset; analyzing the frequency of occurrence of each feature item in the standardized historical feature dataset, and classifying feature items with a frequency greater than the preset frequency to obtain an initial feature set; validating and correcting the initial feature set to obtain target feature information; and storing the target feature information in a structured manner according to a preset data format to obtain the preset requirement feature template.

[0141] The parsing result refers to the structured data set formed by the parallel parsing of the business requirement document by different computing nodes in combination with the preset requirement feature template, after being split by the preset splitting rules and then globally integrated.

[0142] The parsing process specifically includes: according to preset splitting rules (such as by business module, document chapter, or functional logic), the complete business requirements document is split into multiple independent parsing subtasks to ensure that the subtasks cover all the core content of the document without duplication or omission.

[0143] The split parsing subtasks are evenly distributed to different computing nodes, and a distributed computing framework is used to achieve parallel processing of multiple nodes, avoiding the bottleneck of single-node computing power.

[0144] Each computing node calls a preset requirement feature template (including high-frequency business feature items, feature association rules, and annotation standards) to parse the assigned sub-tasks: on the one hand, it identifies basic elements such as business terms, core fields, and functional actions in the sub-segments; on the other hand, it matches the standardized feature combinations in the template, directly reuses the template annotation results, and reduces repetitive semantic analysis.

[0145] After each computing node completes the subtask parsing, it outputs the subtask local parsing data, which includes the local feature extraction results and template matching results.

[0146] The local parsing results of all computing nodes are summarized, and the global integrated parsing results are obtained through logical consistency verification (such as verification of business logic connection across subtasks), redundancy data deduplication, and missing information completion.

[0147] Based on a distributed parallel processing architecture, the task splitting and collaborative execution of business requirement documents are decomposed into independent parsing subtasks according to preset splitting rules. Parsing efficiency is improved by parallel processing of multiple computing nodes, and parsing direction is standardized based on preset requirement feature templates to reduce parsing complexity.

[0148] This solution effectively addresses the issue of low efficiency in parsing large-scale business requirement documents. Template-assisted parsing ensures the standardization of the parsing process, generating standardized parsing results to support subsequent processing. It significantly reduces the parsing time for business requirement documents, improves the scalability of the parsing process, and can adapt to the rapid growth in the number of business requirement documents. Simultaneously, it ensures the standardization of parsing results, laying a solid foundation for subsequent structured feature extraction.

[0149] Step S103: Perform natural language processing on the parsing results to obtain structured requirement features, which include business information, functional scenario subclasses, and compliance constraint tags.

[0150] Specifically, based on word segmentation algorithms, semantic clustering models, and tag mapping rules in natural language processing technology, combined with a pre-defined business classification system, the document text undergoes syntactic parsing, semantic extraction, and feature standardization, transforming unstructured text into a computer-recognizable structured data format. This achieves the structured transformation of business requirement information and the extraction of core features. By splitting features into three dimensions—business information, functional scenarios, and compliance constraints—a bridge is established between requirement content and defect analysis dimensions, providing accurate feature input for subsequent weight adjustments and defect matching. This effectively solves the problems of cluttered text information and hidden core elements in traditional requirement documents, transforming vague requirement descriptions into clear feature indicators, significantly improving the efficiency and accuracy of subsequent defect matching, and avoiding missed defect detections due to misunderstandings in requirement interpretation.

[0151] Step S104: Adjust the matching weight of the trigger scenario features in the preset historical defect database based on the business information corresponding to the structured demand features.

[0152] Specifically, by dynamically allocating the matching priority of each trigger scenario feature through quantitative calculation, the matching logic is made to meet the actual needs of the current business scenario. By dynamically adjusting the weights based on the relevance of business information, historical defect trigger scenarios that are highly relevant to the current needs are highlighted, reducing the interference of low-relevance defect scenarios on the matching results. This transforms defect matching from a comprehensive scan to precise localization, reduces the generation of irrelevant defect candidate sets, improves the computational efficiency of the matching process, and increases the detection probability of highly relevant defects, providing targeted weight support for subsequent precise matching.

[0153] Step S105: Match the structured requirement features with the trigger scenarios in the preset historical defect database to obtain defect information.

[0154] Specifically, an algorithm combining feature vector similarity calculation and rule matching is used. Based on the adjusted matching weights, structured requirement features are compared with trigger scenario features in a pre-set historical defect database from multiple dimensions. Defect data that meets the conditions is obtained through threshold filtering. By utilizing historical defect data resources, defect entries matching the current requirements are filtered from massive historical information through feature association. Historical experience is transformed into the basis for defect analysis of the current requirements, realizing pre-identification of defects. By reusing historical data, the reliance on human experience in defect identification is reduced, improving the timeliness and accuracy of defect discovery.

[0155] Step S106: Generate an early warning report based on the constraints and defect information. The early warning report includes the defect type, remediation plan, and scenario-based priority.

[0156] Specifically, using business constraints as the compliance verification standard, defect information is categorized and integrated. Combined with scenario-based priority judgment rules, defect types, corresponding remediation solutions, and priority indicators are structured and output in a pre-defined data format to form standardized reports. This transforms computer-recognized defect data into guidance information that developers can directly apply, clarifying the content, methods, and sequence of defect handling. It realizes the transformation of analysis results into practical operations. By providing structured remediation guidance and priority ranking, it reduces the cost for developers to reinterpret defect information, making defect remediation work more targeted and planned, indirectly reducing the time and manpower costs of defect remediation, and improving development process efficiency.

[0157] Step S107: Obtain the functional deployment and operation data corresponding to the early warning report, and associate the operation data with the structured demand characteristics.

[0158] Specifically, by acquiring functional production operation data through preset data acquisition interfaces or automated monitoring tools, and by establishing a unique mapping relationship between operation data and corresponding structured requirement features using business requirement document identifiers, the system achieves precise data association. This ensures that post-deployment operation data can be accurately matched to corresponding business requirements, providing data support for subsequent defect analysis and database iteration. It also connects post-deployment operation data with pre-deployment requirement features, ensuring that new defect information can be accurately associated with corresponding business requirements, and providing data support for the dynamic iteration of the defect database and the optimization of analysis methods.

[0159] Step S108: Analyze the running data to obtain new defect information, add the new defect information to the preset historical defect database, and update the matching weight of the trigger scene features.

[0160] Specifically, based on anomaly identification in operational data and iterative optimization of the database, abnormal patterns in operational data are identified by comparing them with preset normal operation thresholds. New defect information is extracted, deduplicated, and added to a preset historical defect database. Simultaneously, the matching weights of trigger scenario features are updated based on the attribute characteristics of the new defects. This enables dynamic iteration of the historical defect database and continuous optimization of the matching strategy, forming a process of pre-analysis, post-implementation monitoring, data feedback, and model optimization. This gradually improves the pre-defect analysis process, enriches the defect coverage of the preset historical defect database, and enhances the timeliness and accuracy of trigger scenario feature matching weights. This allows the pre-defect analysis method to continuously adapt to changes in business needs, constantly improving the accuracy and coverage of defect identification.

[0161] The pre-analysis method for business requirement defects provided in this invention overcomes the limitations of parsing efficiency for large-scale business requirement documents in the traditional single-node mode by combining distributed parallel parsing with preset requirement feature templates. It supports horizontal expansion by adding computing nodes to adapt to business growth. Standardized feature extraction relies on natural language processing technology to transform the parsing results into standardized structured requirement features, significantly improving the accuracy and standardization of defect identification. The dynamic weight adjustment mechanism optimizes the matching weights of trigger scenario features in the historical defect database based on current business information, enhancing the scenario adaptability of defect matching. The post-deployment data feedback loop builds a bridge between pre-analysis and post-deployment operation, supplementing the database and updating the matching weights by identifying new defect information, thus achieving continuous iteration of analysis capabilities. At the same time, the entire process adopts standardized templates and preset rules, reducing the difficulty of cross-domain adaptation and the cost of implementation and maintenance, facilitating integration with existing systems, and providing efficient and scalable technical support for defect prevention and long-term quality improvement before business function deployment.

[0162] This embodiment provides a detailed description of the process in the above embodiments of obtaining structured requirement features through natural language processing of the parsing results. The specific implementation of this process includes the following steps:

[0163] Step a1: Obtain the preset business category dictionary and semantic annotation rules. The business category dictionary contains business domain-specific terms and corresponding category tags.

[0164] Specifically, by calling the pre-defined data resource library interface, a business classification dictionary and unified semantic annotation rules verified by domain experts are obtained. A data pre-configuration mechanism ensures that the correspondence between terms and classification labels conforms to the actual needs of the business scenario, providing a unified benchmark for subsequent text processing. It provides the basis for semantic parsing in the business domain, clarifies terminology classification standards and annotation logic, avoids deviations in the interpretation of professional terms by general processing tools, and provides fundamental support for subsequent accurate word segmentation and classification annotation.

[0165] By introducing domain-specific resources, subsequent text processing is transformed from general parsing to professional adaptation, reducing feature extraction errors caused by misunderstandings of terminology and providing a prerequisite for the domain-specific nature of structured feature requirements.

[0166] Step a2: After segmenting the parsing results and filtering out invalid words, a set of business vocabulary is obtained.

[0167] Specifically, based on word segmentation algorithms in natural language processing (such as hybrid algorithms combining mechanical and computational word segmentation), the document text is subjected to grammatical boundary identification and vocabulary splitting. Based on a preset stop word list and invalid word filtering rules, words such as auxiliary words and adverbs that have no actual business significance are deleted, while words related to core business are retained.

[0168] This method performs preliminary processing of the parsed text, splitting continuous text into discrete lexical units and removing interference information to provide accurate lexical-level input for subsequent classification and labeling. It solves the problem of messy and invalid information interference in the original document text, significantly reduces the computational load of subsequent processing, and improves feature extraction efficiency.

[0169] Step a3: Classify and label the set of business terms based on semantic annotation rules and a preset business classification dictionary to obtain business classification labels.

[0170] Specifically, the construction process of the pre-defined business classification dictionary is as follows: Based on the industry standard terminology library of the business domain, combined with high-frequency terms in historical business requirement documents, the terms are classified through term clustering algorithms (such as hierarchical clustering), and the correspondence between terms and classification labels is determined after verification by domain experts; the specific semantic annotation rules are based on the part-of-speech tagging results, and the mapping rules between noun terms and business classification labels, and between verb terms and functional operation labels are predefined. At the same time, the polysemy judgment rules of terms are supplemented, and a unique classification label is determined according to the context of the business scenario.

[0171] By combining semantic similarity calculation with rule matching, each word in the business vocabulary set is compared with the terms in the preset business classification dictionary. The business category to which the word belongs is determined by combining semantic annotation rules, and standardized business classification labels are generated through a label mapping mechanism.

[0172] By establishing a link between business terms and a business classification system, discrete terms are transformed into labeled data with clear business attributes, enabling structured expression of business information. This provides core business attribute basis for subsequent weight adjustment, transforming vague business information into quantifiable and matchable label features. This avoids subjectivity in interpreting business content, improves the accuracy of business information expression, and lays the foundation for precise processing in subsequent stages.

[0173] Step a4: Extract the constraint clauses from the parsing results and perform standardized transformation to obtain compliance constraint labels.

[0174] Specifically, based on text semantic understanding and regular expression matching, text fragments containing constraint attributes in a document are located. Combined with preset constraint clause parsing rules, the core content of the constraints is extracted. Through a standardized tag mapping table, the constraints described in natural language are transformed into compliant constraint tags in a unified format.

[0175] It effectively separates the constraint attributes and operational attributes in business requirements, enabling the independent extraction and standardized expression of constraint information. This supplements the core features of compliance dimensions to the structured requirement characteristics, supports subsequent defect analysis based on constraint requirements, solves the problem of compliance analysis difficulties caused by scattered and inconsistent expression of constraint clauses, and transforms constraint requirements into standardized features that can be recognized by computers, providing clear compliance basis for subsequent defect matching and early warning report generation.

[0176] Step a5: Integrate the business category tags, functional scenario subcategories, and compliance constraint tags to obtain structured requirement features.

[0177] Specifically, following a pre-defined structured data format, the tag features of three dimensions—business attributes, functional scenarios, and compliance constraints—are associated and combined to construct a unified feature model containing multi-dimensional information. This transforms business requirement information from scattered tags into complete structured features, forming standardized data inputs that can support subsequent weight adjustments, defect matching, and other processes. The resulting comprehensive and unified structured requirement feature model ensures accurate processing based on multi-dimensional features in subsequent stages, providing core data support for the effectiveness of the entire pre-analysis process.

[0178] In some alternative implementations, step a4 above includes:

[0179] Step a41: The constraint clause content in the parsed result is split by text matching to obtain independent constraint units.

[0180] Specifically, by employing a text segmentation algorithm based on semantic association, combined with preset constraint delimiter rules (such as punctuation marks and logical connectors), the identified constraint clause text is semantically delineated to ensure that each segmented unit contains only a single constraint logic.

[0181] This approach enables fine-grained decomposition of constraint clauses, breaking down complex texts that may contain multi-dimensional constraints into independent single constraint units. This avoids feature extraction confusion caused by the mixing of multiple constraints, improves the granularity and accuracy of constraint analysis, eliminates the problems of overlapping content and logical confusion in constraint clauses, and ensures that each constraint requirement can be independently identified and processed. This provides accurate unit-level input for subsequent constraint type determination and reduces errors in constraint feature extraction.

[0182] Step a42: Compare the independent constraint unit with the preset constraint clause to obtain the constraint type; the preset constraint clause includes the constraint type and the corresponding label rule.

[0183] Specifically, existing feature matching algorithms can be selected according to actual needs. No specific restrictions are imposed here. The core semantic features of each independent constraint unit are compared with the constraint type features in the preset constraint clause library. The constraint type is determined by the similarity threshold. The corresponding label rules are called according to the preset association relationship.

[0184] By establishing the association between independent constraint units and standard constraint types, the attribute category of each constraint is clarified, providing a type basis for subsequent standardized label generation and ensuring the consistency of constraint feature classification; this transforms scattered constraint units into structured data with clear type attributes, avoiding the subjectivity of constraint type determination, providing a unified benchmark for the standardized generation of constraint labels, and improving the standardization of compliant constraint features.

[0185] Step a43: Generate corresponding compliance constraint labels for constraint types based on label rules.

[0186] Specifically, based on the preset labeling rules corresponding to the constraint type, a label generation algorithm transforms the constraint type described in natural language into standardized labels containing information such as constraint attributes and boundary conditions, ensuring the consistency of label format and content. This final transformation of constraint information from natural language to standardized features generates compliant constraint labels that can be directly used for subsequent defect matching, achieving the integration and adaptation of constraint features with business information and functional scenario features. This effectively solves the problems of inconsistent constraint information expression and inability to be directly processed by computers. The generated standardized labels can seamlessly connect to subsequent analysis stages, providing compliance dimension support for the completeness of structured requirement features.

[0187] This invention, through sequentially completing steps such as domain resource allocation, text purification, classification and labeling, constraint extraction and standardization, and feature fusion, achieves accurate transformation of parsing results from unstructured text to multi-dimensional structured features. This solves the problems of poor domain adaptability and fuzzy feature extraction in traditional processing. By supplementing compliance dimension features through refined processing of constraint information, it provides comprehensive and accurate core data support for subsequent defect pre-analysis, effectively improving the professionalism and reliability of the defect analysis process.

[0188] This embodiment provides a detailed explanation of the process in the above embodiment of adjusting the matching weights of trigger scenario features in the preset historical defect database based on business information corresponding to structured demand features. The specific implementation of this process includes the following steps:

[0189] Step b1: Extract business information from structured requirement characteristics.

[0190] Specifically, based on preset feature extraction rules, the fields marked as business information in the structured requirement features are located. Through field value reading and semantic deduplication algorithms, core information with clear business attributes is extracted, ensuring the extraction results are relevant to the business scenario. By separating business attribute information directly related to defect matching weights from multi-dimensional structured features and removing irrelevant features such as functional scenarios and compliance constraints, accurate input is provided for subsequent weight parameter matching. This avoids parameter matching deviations caused by irrelevant features, ensuring that the basis for weight adjustment is highly consistent with current business needs, thus improving the targeting and reliability of weight adjustment from the data source.

[0191] Step b2: Match the business information with the preset business information weight mapping table to obtain the corresponding weight adjustment parameters; the preset business information weight mapping table includes the weight adjustment parameters corresponding to each business information.

[0192] Specifically, based on requirements, algorithms such as feature matching and keyword association are selected to compare the extracted business information with the index items in a pre-defined business information weight mapping table. Through semantic similarity calculation or precise matching mechanisms, the corresponding weight adjustment parameters are located. The relationships in the mapping table are pre-determined based on domain experience and historical data training. A quantitative correlation is established between business information and weight adjustment parameters, transforming qualitative business attributes into calculable quantitative parameters. This addresses the lack of objective basis for weight adjustment and provides standardized data support for subsequent weight calculations.

[0193] It effectively replaces the subjective experience-based judgment of traditional weight adjustment, making the parameter acquisition process have clear rules and reducing human error. At the same time, it ensures the consistency and repeatability of weight parameter matching in different business scenarios through a preset mapping table.

[0194] Step b3: Input the weight adjustment parameters into the preset weight calculation model to obtain the calculation result.

[0195] Specifically, the preset weight calculation model is based on the weight influence logic of the business scenario, with built-in linear weighting or non-linear fusion algorithms. It combines the initial weights of the trigger scenario features with the input adjustment parameters, and completes the iterative calculation of the weight values ​​through preset calculation formulas to ensure that the results conform to the priority ranking rules of business defects.

[0196] This system enables the numerical transformation and optimization of weight adjustment parameters, integrating single-dimensional adjustment parameters into final weight values ​​that can be directly applied to the defect database. This solves the problem of scattered parameters that cannot be directly applied to the database. Through model calculations, the system achieves scientific calibration of weight values, ensuring that the adjusted weights reflect both the relevance of business information and conform to the quantitative logic of defect matching, thereby enhancing the practical value of the weight values.

[0197] Step b4: Update the matching weights of the corresponding trigger scene features in the preset historical defect database based on the calculation results.

[0198] Specifically, based on structured query and update of the database, the target feature record in the preset historical defect database is located according to the trigger scenario feature identifier in the calculation result. The original matching weight value is replaced by field update operation, and a weight update log is generated to ensure data traceability.

[0199] The optimized weight values ​​obtained from the calculation are applied to the historical defect database, enabling the subsequent defect matching process to directly call the dynamically adjusted weights. This achieves seamless integration between weight adjustment and defect matching processes, dynamic updates of matching weights, and allows the matching logic of the historical defect database to adapt to changes in business needs in real time, significantly improving the adaptability of the subsequent defect matching process to the current business scenario.

[0200] This invention, through a complete process of business information extraction, weight parameter matching, model calculation and transformation, and database weight update, solves the problems of fixed defect matching weights and poor adaptability to business needs in the prior art. It enables the trigger scenario matching logic of the preset historical defect database to accurately match the current business attributes, providing business-specific weight support for subsequent defect association matching, thereby improving the accuracy and efficiency of defect matching.

[0201] This embodiment provides a detailed explanation of the process in the above embodiments of associating and matching structured requirement features with trigger scenarios in a preset historical defect database to obtain defect information. The specific implementation of this process includes the following steps:

[0202] Step c1 involves matching the structured requirement features with the triggering scenarios to obtain a preliminary defect set.

[0203] Specifically, by performing multi-field precise matching and fuzzy matching between the business information and functional scenario subclasses in the structured requirement features and the trigger scenario features in the preset historical defect database, trigger scenarios that meet the correlation standards are selected through weight thresholds, and a preliminary defect set is generated accordingly. The preliminary defect set includes the defect confidence level.

[0204] The detection probability of highly correlated scenarios is increased by dynamically adjusted matching weights, providing a basic candidate set of defects for subsequent analysis, while avoiding missed detection of regular defects that may be caused by pure model prediction. The system quickly completes the association mapping between structured requirements and historical triggering scenarios, ensuring matching efficiency while leveraging weights to ensure the relevance of the initial defect set to current business needs.

[0205] Step c2: Input the structured demand features into the preset defect prediction model to obtain the predicted defect set and defect confidence level.

[0206] Specifically, the preset defect prediction model is a machine learning model (such as a classification model based on gradient boosting tree) trained on historical defect data and demand feature data. By extracting high-dimensional vector representations of structured demand features, it is compared with the defect feature patterns trained by the model, and outputs a prediction set containing potential defects and the matching confidence of each defect (reflecting the probability of the defect's existence).

[0207] By extracting potential defect patterns hidden in structured demand features and not covered by rules, the completeness of the initial defect set is supplemented. Simultaneously, the likelihood of defect existence is quantified using confidence levels, providing a basis for subsequent screening. This avoids missing novel defects due to rule lag, and the confidence level output also provides a core quantitative indicator for subsequent deduplication and ranking.

[0208] Step c3: Merge the preliminary defect set and the predicted defect set, remove duplicate defect records, and obtain the target defect.

[0209] Specifically, a candidate pool is formed by integrating the preliminary defect set and the predicted defect set. Matching criteria are constructed based on the core characteristics of defect records (such as defect type and triggering conditions). Duplicate records are identified and filtered using defect confidence levels, resulting in unique target defects. This effectively eliminates defect redundancy between the two sets, while deduplication logic retains more reliable defect records, achieving accurate integration of defect information. It avoids interference from duplicate defects in subsequent analysis, improves the accuracy of target defects through deduplication filtering, and ensures that the integrated defect data covers both regular and potential defects while eliminating invalid and redundant information.

[0210] When merging the preliminary defect set and the predicted defect set, if there are conflicting records with the same defect type but different triggering conditions / repair schemes, they are handled by confidence priority and source priority rules: records with confidence greater than the preset threshold are retained first; if the confidence levels are the same, records in the predicted defect set are retained, ensuring that the processing logic for conflicting records is clear.

[0211] Step c4: Sort the target defects according to the preset defect priority and defect confidence to obtain the defect sequence.

[0212] Specifically, preset defect priorities (reflecting the severity of a defect's impact on business operations) and defect confidence levels (reflecting the reliability of a defect's existence) are assigned preset weights. A weighted calculation yields a comprehensive score for each target defect, which is then sorted in descending order of the comprehensive score to generate a defect sequence. Clearly defining the order of defect handling ensures that the defect sequence accurately reflects the importance and reliability of defects, providing developers with clear guidance on defect handling, preventing core defects from being masked by secondary defects, and improving defect handling efficiency.

[0213] Step c5: Extract a preset number of target defects from the defect sequence in sequence and integrate them to obtain defect information.

[0214] Specifically, based on a preset defect extraction threshold (which can be determined according to the accuracy requirements of the business scenario for defect information), the first N defect records are extracted in descending order of the defect sequence. Through field normalization and information completion (associating with historical repair solutions), they are integrated into a structurally unified defect information. This avoids information overload for developers due to an excessive number of defects, and at the same time, information completion provides complete support for defect processing, realizing the transformation of defect sequences into practical defect information.

[0215] In some alternative implementations, step c3 above includes:

[0216] Step c31: Obtain the unique identifier corresponding to each defect record in the preliminary defect set and the predicted defect set. The unique identifier is generated by the defect type and triggering conditions.

[0217] Specifically, by using hash algorithms and feature encoding mechanisms, the defect type (such as data format defects and logical conflict defects) and core triggering conditions (such as specific business operations and constraint boundaries) of each defect record can be effectively extracted. A globally unique defect identifier is generated through feature combination and hash operations, ensuring that different records with the same defect correspond to the same identifier. This achieves a unified standard for defect duplication judgment, significantly improving the accuracy and efficiency of duplicate identification, avoiding missed detection of duplicate defects or misjudgment of non-duplicate defects due to differences in description, and providing reliable support for subsequent deduplication logic.

[0218] Step c32: Traverse the preliminary defect set and the predicted defect set to establish an index table with unique defect identifiers.

[0219] Specifically, by employing a hash table data structure, all defect records in the two sets are traversed. A key-value index table is constructed using the defect's unique identifier as the key and the defect record and confidence level as the value. Simultaneously, the frequency of each unique identifier is recorded, enabling rapid retrieval and calculation of defect records. Scattered defect records are aggregated by unique identifier, enabling rapid location of duplicate identifiers. This provides efficient data structure support for subsequent duplicate record filtering, reducing the time complexity of duplicate defect determination and improving the efficiency of set traversal and duplicate calculation.

[0220] Step c33: Compare the occurrence counts of unique identifiers in the index table to generate duplicate records.

[0221] Specifically, based on the frequency of unique identifiers in the index table, a conditional filtering algorithm is used to locate identifiers that appear more than once. All defect records corresponding to these identifiers are then extracted, forming a subset of duplicate records. Simultaneously, the confidence information of each record is retained for subsequent filtering. By separating duplicate and non-duplicate records in the index table, the scope of defects requiring further filtering is clarified, avoiding invalid processing of non-duplicate records and improving the targeting and efficiency of the deduplication process, while fully preserving the association information of duplicate records.

[0222] Step c34: Keep the defect entry with the highest confidence among the duplicate records and delete the remaining duplicate entries.

[0223] Specifically, based on preset filtering rules, the confidence score of each defect entry in the subset of duplicate records is extracted. The defect entry corresponding to the maximum confidence score is determined by a numerical comparison algorithm. This entry is retained while other entries under the same unique identifier are deleted, ensuring that the retained entries have the highest reliability.

[0224] Step c35: Integrate the defect entries to obtain the target defect.

[0225] Specifically, the non-duplicate defect entries retained after deduplication are merged with the entries selected from the duplicate records, and the defect attributes (such as defect type and trigger scenario) are organized according to the preset data format to form a target defect with a unified structure, thus completing the final integration of defect records.

[0226] This invention, through a complete process of rule matching for initial screening, model prediction for completion, unique identifier deduplication, comprehensive dimension sorting, and core defect extraction, solves the problems of singular defect identification, interference from duplicate records, and ambiguous sorting criteria in existing technologies. It ensures the comprehensiveness and reliability of defect identification, focuses on core defects through deduplication and sorting, and ultimately provides accurate and efficient defect information support for the generation of early warning reports, thereby enhancing the practical value of pre-defect analysis for business needs.

[0227] In some optional implementations, the following steps are also included:

[0228] Step d1: Obtain the interface parameters and target receiving account information of the preset development collaboration system.

[0229] Specifically, by calling the preset configuration database interface, the system reads the communication parameters of the development collaboration system (such as interface address, port number, authentication key) and the identification information of the target receiving account (such as account ID, receiving terminal address), and ensures the integrity and format validity of the obtained information through parameter verification rules.

[0230] By accurately acquiring standardized interface parameters and account information, push failures caused by missing parameters or incorrect formats are avoided, ensuring the feasibility and accuracy of the push process from the source and removing obstacles to data transmission between systems.

[0231] Step d2: Establish a communication connection with the development collaboration system through interface parameters.

[0232] Specifically, based on the communication protocol specified in the interface parameters, such as Hypertext Transfer Protocol (HTTP) or Secure Hypertext Transfer Protocol (HTTPS), a connection request is initiated and an authentication key is submitted to complete identity verification. A stable data transmission channel is built through connection establishment mechanisms such as a three-way handshake, while a connection status monitoring mechanism is enabled to ensure smooth link operation.

[0233] By building a communication link between the business requirement defect analysis system and the development collaboration system, a basic link for cross-system data transmission is established, providing reliable network support for the sending of early warning reports and connecting the two links of parameter acquisition and report push.

[0234] A secure and stable cross-system communication link was successfully established, resolving the data isolation issue between systems and ensuring that early warning reports could be smoothly transmitted to the development collaboration system. At the same time, the identity verification mechanism improved the security of data transmission, preventing information from being illegally intercepted or tampered with.

[0235] Step d3: Package the warning report according to the preset data format and send it to the target receiving account.

[0236] Specifically, it conforms to preset data exchange standards, such as Extensible Markup Language (XML) and JavaScript Object Notation (JSON) formats, and encapsulates information such as defect types and remediation plans in the early warning report in a structured manner. It adds data verification codes to ensure the integrity of the content and pushes the encapsulated report to the terminal address corresponding to the target receiving account through the established communication link.

[0237] This system transforms early warning reports from raw data into a standardized transmission format, ensuring that the receiving end can correctly parse the report content. It also accurately locates the target receiving account, enabling precise delivery of analysis results to the development team and providing developers with timely guidance on defect handling. Standardized packaging ensures readability and efficient parsing of the report content, avoiding information distortion caused by format incompatibility. Precise delivery ensures that early warning reports reach relevant developers directly, shortening the defect information transmission cycle and creating conditions for timely defect remediation.

[0238] Step d4: Receive the report reception confirmation information returned by the development collaboration system, associate the report reception confirmation information with the identifier of the business requirement document, and store it in the preset record database.

[0239] Specifically, based on the bidirectional data transmission of the communication link, the receiving status information (such as receiving time, receiving account, and content verification result) fed back by the development collaboration system is received. Using the unique identifier of the business requirement document as the association key, the confirmation information is associated with the metadata of the corresponding requirement document through database write operations, and operation logs are generated to ensure data traceability.

[0240] It enables full traceability of the push process, and the associated stored information can provide reliable support for troubleshooting push anomalies and defining responsibilities, while improving the standardization and manageability of the entire business process.

[0241] This invention, through a complete process of acquiring push parameters, establishing cross-system communication, encapsulating and pushing reports, and recording received results, achieves accurate, secure, and efficient transmission of defect analysis results to the development stage. At the same time, the complete recording mechanism enhances the traceability of the process and provides strong support for the full lifecycle management of defects in business requirements.

[0242] This embodiment details the process of obtaining the functional deployment and operation data corresponding to the early warning report in the above embodiments, and associating the operation data with structured demand characteristics. The specific implementation of this process includes the following steps:

[0243] Step m1: Obtain the functional deployment and operation data corresponding to the early warning report. The functional deployment and operation data includes business operation logs, system interaction data, functional response data, and abnormal return information.

[0244] Specifically, based on the targeted correlation logic of data collection, and according to the business identification information in the early warning report, multi-dimensional data of the corresponding function's production and operation phase is acquired according to the preset data collection specifications, covering core data dimensions such as business operations, system interactions, function responses, and anomaly feedback. This provides a complete, accurate, and directly business-relevant data source for subsequent correlation analysis of operational data and structured requirement characteristics, as well as analysis of new defects, ensuring the business relevance and dimensional completeness of the data. It guarantees the comprehensiveness and business matching degree of the function's production and operation data, avoiding data gaps or irrelevant data interference, and laying a reliable data foundation for subsequent correlation analysis and defect identification.

[0245] Step m2: Extract the business requirement document identifier associated with the structured requirement features.

[0246] Specifically, by extracting the unique identifier of the pre-stored business requirement document in the structured requirement features, the feature data and the original document can be accurately traced, the core index information that can connect the functional production and operation data with the structured requirement features can be obtained, the unique matching basis for data association can be clarified, the logical ambiguity in the process of associating operation data with structured requirement features can be eliminated, and data mismatch or association failure can be avoided.

[0247] Step m3: Establish a mapping between functional deployment and operation data and structured requirement characteristics by identifying business requirement documents.

[0248] Specifically, the business requirement document identifiers corresponding to the functional deployment and operation data are matched with the document identifiers of the structured requirement features to establish a correspondence between the two types of data. This completes the association and coupling between functional deployment and operation data and structured requirement features, enabling data in the post-deployment operation phase to accurately correspond to the requirement feature data in the pre-deployment analysis phase. It achieves effective connection between pre-deployment requirement analysis data and post-deployment operation data, breaking down data silos and providing support for subsequent new defect analysis and iterative optimization of the defect database based on correlated data.

[0249] This invention, through a complete process of targeted collection of production operation data corresponding to early warning reports, extraction of business requirement document identifiers, and establishment of data mapping relationships, realizes the association between pre-deployment requirement analysis and post-deployment operation status, achieves precise binding between post-deployment data and structured requirement characteristics, provides a reliable data association foundation for new defect analysis and iterative optimization of the preset historical defect database, and improves the completeness and effectiveness of the closed loop of business requirement defect analysis.

[0250] This embodiment details the process described in the above embodiment of analyzing runtime data to obtain new defect information, supplementing the new defect information into a preset historical defect database, and updating the matching weights of trigger scene features. The specific implementation of this process includes the following steps:

[0251] Step n1: Compare the running data with the preset normal operating threshold to obtain the newly added defect information.

[0252] Specifically, based on threshold comparison logic for data anomaly identification, the system compares the operational data of the function in production with preset normal operation thresholds from multiple dimensions, identifies data features that deviate from the threshold range, and integrates them into new defect information. Abnormal data is filtered from the operational data and transformed into structured new defect information, providing a core data source for subsequent defect database supplementation. This enables accurate identification of abnormal patterns in the operational data, ensuring that the new defect information accurately reflects the actual problems encountered during the operational deployment of business functions.

[0253] Step n2: Extract the unique identifier corresponding to the newly added defect information.

[0254] Specifically, based on the unique identifier generation rules for defect information, core elements that characterize the defect type and triggering conditions are extracted from newly added defect information, and unique identifiers are generated according to preset coding rules. This adds unique identification features to newly added defect information, providing a unified basis for subsequent comparison and deduplication with the historical defect database. It ensures that each newly added defect record has a distinguishable identifier, avoiding deduplication failures or duplicate storage issues caused by missing identifiers.

[0255] Step n3: Compare the unique identifier with the defect identifier in the preset historical defect database to remove duplicates and obtain the deduplicated new defect information.

[0256] Specifically, the unique identifier of newly added defect information is compared with the identifiers of defects already stored in the preset historical defect database, and newly added defect information that does not match is filtered out. Entries in the newly added defect information that are duplicates of historical defects are deleted to ensure that the defect information added to the database is unique and novel. This effectively avoids duplicate defect records in the preset historical defect database, maintains the cleanliness and data quality of the database, and reduces the interference of redundant data on subsequent matching analysis.

[0257] Step n4: Add the deduplicated new defect information to the preset historical defect database.

[0258] Specifically, based on the database's data writing rules, deduplicated new defect information is stored in a designated data partition of the preset historical defect database according to a preset data structure. This completes the supplementary entry of new defect information into the historical defect database, enriching the database's defect coverage and scenario types. By expanding the defect sample size of the preset historical defect database, the database's coverage of defects in various business scenarios is improved, providing more comprehensive data support for subsequent defect matching.

[0259] Step n5: Based on the frequency of occurrence and business relevance of the newly added defect information, the weights are adjusted using a preset weight calculation model to obtain the updated trigger scenario feature matching weights.

[0260] Specifically, by combining the frequency of newly added defect information with its business relevance as input parameters, a preset algorithm is used to calculate the updated weights of trigger scenario features. The matching weights of these trigger scenario features are then optimized based on the attribute characteristics of the newly added defect information, ensuring that the weight allocation aligns with the actual business operations. This enables dynamic iteration of the trigger scenario feature matching weights, improving the priority of identifying high-frequency, highly relevant defect scenarios during subsequent defect matching.

[0261] Step n6: Update the updated trigger scenario feature matching weights to the preset historical defect database.

[0262] Specifically, the calculated and updated trigger scenario feature matching weights are synchronized to the corresponding trigger scenario feature records in the preset historical defect database. This completes the storage update of the trigger scenario feature matching weights in the database, enabling subsequent defect matching processes to call the latest weight parameters. It ensures that the weight data in the preset historical defect database remains synchronized with the business operation status, maintaining the timeliness and accuracy of the defect matching strategy.

[0263] This invention provides a complete process for identifying abnormal data, generating new defect information, assigning unique identifiers to remove duplicates, adding it to the defect database, and dynamically updating the matching weights of triggering scenario features. This process enables continuous iterative optimization of the preset historical defect database, improves the coverage and matching accuracy of the defect database, forms a closed-loop iterative mechanism for business requirement defect analysis, and enhances the adaptability and effectiveness of the pre-analysis method for business requirement defects.

[0264] Figure 2 A schematic diagram of the pre-analysis device for business requirement defects provided in this application. Figure 2 As shown, the pre-analysis device 20 for the business requirement defect includes:

[0265] Module 201 is used to obtain the business requirements document, which contains business operation rules and constraints.

[0266] The parsing module 202 is used to split the business requirement document into multiple parsing subtasks according to preset splitting rules, allocate them to different computing nodes, and perform parallel parsing in combination with preset requirement feature templates to obtain the parsing results.

[0267] The processing module 203 is used to perform natural language processing on the parsed results to obtain structured requirement features, which include business information, functional scenario subclasses, and compliance constraint tags.

[0268] The adjustment module 204 is used to adjust the matching weight of the trigger scenario features in the preset historical defect database based on the business information corresponding to the structured demand features.

[0269] The matching module 205 is used to associate and match structured requirement features with trigger scenarios in a preset historical defect database to obtain defect information.

[0270] The generation module 206 is used to generate an early warning report based on the constraints and defect information. The early warning report includes the defect type, the repair plan, and the scenario-based priority.

[0271] The acquisition module 201 is also used to acquire the functional production and operation data corresponding to the early warning report, and associate the operation data with the structured demand characteristics.

[0272] The update module 207 is used to analyze the running data to obtain new defect information, add the new defect information to the preset historical defect database, and update the matching weight of the trigger scene features.

[0273] In one possible implementation, the processing module 203 is specifically used for:

[0274] Obtain the preset business category dictionary and semantic annotation rules. The business category dictionary contains business domain-specific terms and corresponding category tags.

[0275] After segmenting the parsing results and filtering out invalid words, a set of business vocabulary is obtained.

[0276] Based on semantic annotation rules and a pre-defined business classification dictionary, the set of business terms is classified and labeled to obtain business classification tags.

[0277] Extract the constraint clauses from the parsing results and perform standardized transformation to obtain compliance constraint labels.

[0278] By integrating business category tags, functional scenario subcategories, and compliance constraint tags, structured requirement characteristics are obtained.

[0279] In one possible implementation, the processing module 203 is further configured to:

[0280] By splitting the constraint clause content in the parsed results through text matching, independent constraint units are obtained.

[0281] The constraint type is determined by comparing the independent constraint unit with the preset constraint clause. The preset constraint clause includes the constraint type and the corresponding labeling rule.

[0282] Generate corresponding compliance constraint labels for constraint types based on label rules.

[0283] In one possible implementation, the adjustment module 204 is specifically used for:

[0284] Extract business information from structured requirements characteristics.

[0285] The business information is matched with a preset business information weight mapping table to obtain the corresponding weight adjustment parameters. The preset business information weight mapping table includes the weight adjustment parameters corresponding to each piece of business information.

[0286] Input the weight adjustment parameters into the preset weight calculation model to obtain the calculation result.

[0287] The matching weights of the corresponding trigger scene features in the preset historical defect database are updated based on the calculation results.

[0288] In one possible implementation, the matching module 205 is specifically used for:

[0289] A preliminary defect set is obtained by matching structured demand characteristics with triggering scenarios.

[0290] By inputting structured demand features into a preset defect prediction model, a set of predicted defects and defect confidence scores are obtained.

[0291] The initial defect set and the predicted defect set are merged and duplicate defect records are removed to obtain the target defect.

[0292] The target defects are sorted according to the preset defect priority and defect confidence level to obtain the defect sequence.

[0293] Defect information is obtained by extracting a preset number of target defects in sequence from the defect sequence and integrating them.

[0294] In one possible implementation, the matching module 205 is further configured to:

[0295] Obtain the unique identifier corresponding to each defect record in the preliminary defect set and the predicted defect set. The unique identifier is generated by the defect type and the triggering condition.

[0296] The preliminary defect set and the predicted defect set are traversed to establish an index table with unique defect identifiers.

[0297] Duplicate records are generated by comparing the number of occurrences of the unique identifier in the index table.

[0298] The defect entry with the highest confidence among the duplicate records is retained, and the remaining duplicate entries are deleted.

[0299] The target defect is obtained by integrating the defect entries.

[0300] In one possible implementation, the acquisition module 201 is further configured to:

[0301] Obtain the interface parameters and target receiving account information of the preset development collaboration system.

[0302] Establish a communication connection with the development collaboration system through interface parameters.

[0303] The warning report is packaged according to a preset data format and sent to the target receiving account.

[0304] Receive the report reception confirmation information returned by the development collaboration system, associate the report reception confirmation information with the identifier of the business requirement document, and store it in the preset record database.

[0305] In one possible implementation, the acquisition module 201 is further configured to:

[0306] Obtain the functional deployment and operation data corresponding to the early warning report. The functional deployment and operation data includes business operation logs, system interaction data, functional response data, and abnormal return information.

[0307] Extract the business requirement document identifiers associated with the structured requirement features.

[0308] By identifying business requirements documents, a mapping is established between functional deployment and operational data and structured requirement characteristics.

[0309] In one possible implementation, the update module 207 is specifically used for:

[0310] The running data is compared with the preset normal operating threshold to obtain information on newly added defects.

[0311] Extract the unique identifier corresponding to the newly added defect information.

[0312] The unique identifier is compared with the defect identifier in the preset historical defect database to remove duplicates, and the newly added defect information is obtained after deduplication.

[0313] The newly added defect information after deduplication will be added to the preset historical defect database.

[0314] Based on the frequency of occurrence and business relevance of newly added defect information, the weights are adjusted using a preset weight calculation model to obtain the updated trigger scenario feature matching weights.

[0315] Update the trigger scenario feature matching weights to the preset historical defect database.

[0316] The pre-analysis device for business requirement defects provided in this embodiment can be used to execute the pre-analysis method for business requirement defects described above. Its implementation principle and technical effect are similar, and will not be described again in this embodiment.

[0317] Figure 3A schematic diagram of the structure of the electronic device provided in this application. Figure 3 As shown, the electronic device 30 provided in this embodiment includes at least one processor 301 and a memory 302. Optionally, the electronic device 30 further includes a communication component 303. The processor 301, memory 302, and communication component 303 are connected via a bus.

[0318] In a specific implementation, at least one processor 301 executes computer execution instructions stored in memory 302, causing at least one processor 301 to perform the above-described method.

[0319] The specific implementation process of processor 301 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0320] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0321] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0322] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0323] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0324] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0325] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0326] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0327] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0328] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0329] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0330] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0331] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0332] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A pre-analysis method for business requirement defects, characterized in that, include: Obtain the business requirements document, which contains business operation rules and constraints; The business requirement document is split into multiple parsing subtasks by a preset splitting rule, which are then assigned to different computing nodes and parsed in parallel using a preset requirement feature template to obtain the parsing results. The parsing results are subjected to natural language processing to obtain structured requirement features, which include business information, functional scenario subclasses, and compliance constraint tags. Adjust the matching weight of trigger scenario features in the preset historical defect database based on the business information corresponding to the structured demand features. Defect information is obtained by associating and matching the structured requirement features with the triggering scenarios in the preset historical defect database; An early warning report is generated based on the constraints and the defect information. The early warning report includes the defect type, the repair plan, and the scenario-based priority. Obtain the functional deployment and operation data corresponding to the early warning report, and associate the operation data with the structured demand characteristics; The newly added defect information is obtained by analyzing the running data, and the newly added defect information is added to the preset historical defect database. The matching weight of the triggering scenario feature is also updated.

2. The method according to claim 1, characterized in that, Natural language processing is performed on the parsed results to obtain structured requirement features, including: Obtain a preset business classification dictionary and semantic annotation rules, wherein the business classification dictionary contains business domain-specific terms and corresponding classification tags; The parsing results are segmented and invalid words are filtered out to obtain a set of business terms. Based on the semantic annotation rules and the preset business classification dictionary, the business vocabulary set is classified and labeled to obtain business classification tags; Extract the constraint clauses from the parsing results and perform standardized transformation to obtain compliance constraint labels; The structured requirement features are obtained by integrating the business category tags, functional scenario subcategories, and compliance constraint tags.

3. The method according to claim 2, characterized in that, Extract the constraint clauses from the parsing results and perform standardized transformation to obtain compliance constraint tags, including: The constraint clauses in the parsed results are split by text matching to obtain independent constraint units; The independent constraint unit is compared with the preset constraint clause to obtain the constraint type; the preset constraint clause includes the constraint type and the corresponding label rule; Based on the labeling rules, corresponding compliance constraint labels are generated for the constraint types.

4. The method according to claim 1, characterized in that, Adjusting the matching weights of trigger scenario features in the preset historical defect database based on the business information corresponding to the structured demand features, including: Extract business information from the structured requirements features; The business information is matched with a preset business information weight mapping table to obtain the corresponding weight adjustment parameters; the preset business information weight mapping table includes the weight adjustment parameters corresponding to each business information. The weight adjustment parameters are input into a preset weight calculation model to obtain the calculation result; The matching weights of the corresponding triggering scenario features in the preset historical defect database are updated based on the calculation results.

5. The method according to claim 1, characterized in that, The defect information is obtained by associating and matching the structured requirement features with the triggering scenarios in the preset historical defect database, including: The structured requirement features are matched with the triggering scenarios to obtain a preliminary defect set; The structured demand features are input into a preset defect prediction model to obtain a set of predicted defects and defect confidence levels. The preliminary defect set and the predicted defect set are merged and duplicate defect records are removed to obtain the target defect; The target defects are sorted according to the preset defect priority and the defect confidence level to obtain a defect sequence; The defect information is obtained by extracting a preset number of target defects in sequence from the defect sequence and integrating them.

6. The method according to claim 5, characterized in that, The preliminary defect set and the predicted defect set are merged and duplicate defects are removed to obtain the target defect, including: Obtain a unique identifier corresponding to each defect record in the preliminary defect set and the predicted defect set. The unique identifier is generated by the defect type and the triggering condition. The preliminary defect set and the predicted defect set are traversed to establish an index table for unique defect identifiers; Duplicate records are generated by comparing the number of occurrences of the unique identifier in the index table; The defect entry with the highest confidence level among the duplicate records is retained, and the remaining duplicate entries are deleted; The target defect is obtained by integrating the defect entries.

7. The method according to claim 1, characterized in that, Also includes: Obtain the interface parameters and target receiving account information of the preset development collaboration system; A communication connection with the development collaboration system is established through the interface parameters; The warning report is packaged according to a preset data format and sent to the target receiving account; The system receives a report reception confirmation from the development collaboration system and associates the report reception confirmation with the identifier of the business requirement document, storing it in a preset record database.

8. The method according to claim 1, characterized in that, Obtain the functional deployment and operation data corresponding to the early warning report, and associate the operation data with the structured requirement features, including: Obtain the functional deployment and operation data corresponding to the early warning report. The functional deployment and operation data includes business operation logs, system interaction data, functional response data, and abnormal return information. Extract the business requirement document identifier associated with the structured requirement features; The mapping between the functional deployment and operation data and the structured requirement features is established by identifying the business requirement document.

9. The method according to claim 1, characterized in that, The analysis of the operational data yields new defect information, which is then added to the preset historical defect database. The matching weights of the triggering scenario features are also updated, including: The operational data is compared with a preset normal operating threshold to obtain newly added defect information; Extract the unique identifier corresponding to the newly added defect information; The unique identifier is compared with the defect identifier in the preset historical defect database to remove duplicates, and the deduplicated new defect information is obtained. Add the newly added defect information after deduplication to the preset historical defect database; Based on the frequency of occurrence and business relevance of the newly added defect information, the weights are adjusted using a preset weight calculation model to obtain the updated trigger scenario feature matching weights. The updated trigger scenario feature matching weights are then updated in the preset historical defect database.

10. A pre-analysis device for business requirement defects, characterized in that, include: The acquisition module is used to acquire a business requirements document, which contains business operation rules and constraints. The parsing module is used to split the business requirement document into multiple parsing subtasks according to preset splitting rules, distribute them to different computing nodes, and perform parallel parsing in combination with preset requirement feature templates to obtain the parsing results; The processing module is used to perform natural language processing on the parsing results to obtain structured requirement features, which include business information, functional scenario subclasses, and compliance constraint tags. The adjustment module is used to adjust the matching weight of trigger scenario features in the preset historical defect database based on the business information corresponding to the structured requirement features. The matching module is used to associate and match the structured requirement features with the triggering scenarios in the preset historical defect database to obtain defect information; A generation module is used to generate an early warning report based on the constraints and the defect information. The early warning report includes the defect type, repair plan, and scenario-based priority. The acquisition module is also used to acquire the functional production and operation data corresponding to the early warning report, and associate the operation data with the structured demand features; The update module is used to analyze the running data to obtain new defect information, add the new defect information to the preset historical defect database, and update the matching weight of the triggering scenario features.

11. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-9.

13. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-9.

Images