A semantic analysis-based informationization requirement review method

Abstract

The application discloses a kind of information-based demand review methods based on semantic analysis, it is related to information-based demand management and intelligent review field, including the following steps: collecting information-based demand materials and generating review data frame;According to enterprise information-based assets, review rules and historical review records, review constraint graph is constructed and constraint edge weight is generated;Review data frame is input into the demand state evolution network containing RWKV coding layer, and the state tracking of cross-paragraph, cross-attachment and cross-version demand content is generated label sequence and relation set;Demand semantic unit is generated and effective demand element is determined;Demand semantic unit is mapped to review constraint graph, and abnormal mark and evidence chain are generated by rule engine, graph path query and constraint verification;According to abnormal mark, constraint edge weight and evidence chain, generate problem list;Improved MAP-Elites algorithm is used to generate parameter optimization library.The application improves the accuracy and traceability of demand review.

Description

Technical Field

[0001] This invention relates to the field of information technology requirements management and intelligent review technology, and in particular to an information technology requirements review method based on semantic parsing. Background Technology

[0002] With the continuous advancement of enterprise informatization, system integration, and digital transformation of business processes, technologies for semantic parsing, automatic review, and risk alerts of requirement materials have received widespread attention. Existing technologies include publicly available AI-based project document review systems that achieve automatic document review through knowledge bases, project knowledge graphs, and review rule prompts; publicly available methods for automatically generating requirement specification documents based on knowledge graphs, generating requirement documents through named entity recognition, relation extraction, entity disambiguation, and requirement specification graph embedding; and publicly available methods for constructing requirement graphs for requirement documents, building requirement graphs through dependency syntax, semantic role labeling, and requirement triples. These technologies demonstrate that utilizing semantic extraction, knowledge graphs, and rule-based review to process requirement materials already constitutes an existing technological foundation in the field of informatization requirement review.

[0003] However, in real-world enterprise requirement review scenarios, requirement materials are typically scattered across the main text, tables, interface attachments, permission descriptions, acceptance clauses, and multiple rounds of revisions. Existing technologies often focus on single-time semantic extraction, static graph construction, or general document review, making it difficult to continuously track the status of requirements across paragraphs, attachments, and versions. Furthermore, existing review results often lack linkage between source credibility, version level, graph path query results, and evidence chains, leading to difficulties in reliably locating and categorizing issues such as missing interface support, unclear permission boundaries, unverifiable acceptance, and semantic conflicts. In addition, review rule parameters often rely on fixed configurations based on human experience, making continuous optimization based on false positives, missed positives, and requirement modifications difficult, resulting in the recurrence of the same types of problems in subsequent reviews.

[0004] Therefore, how to provide a semantic parsing-based method for reviewing information requirements is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] One objective of this invention is to propose an information requirements review method based on semantic parsing. This invention fully utilizes structured parsing, review constraint graphs, RWKV state tracking, and an improved MAP-Elites algorithm to perform semantic recognition, constraint verification, risk classification, and parameter optimization for information requirements that cross paragraphs, attachments, and versions. It has the advantages of high review accuracy, traceable problem evidence, clear risk classification, and strong continuous optimization capabilities.

[0006] An information requirements review method based on semantic parsing according to an embodiment of the present invention includes the following steps: Step 1: Collect information technology requirement materials, perform structured parsing, source identifier writing, and version identifier writing on the information technology requirement materials, and generate review data frames; Step 2: Construct a review constraint diagram based on the enterprise's IT assets, review rules, and historical review records, and generate constraint edge weights based on source credibility and version level; Step 3: Input the review data frame into the requirement state evolution network. The requirement state evolution network includes an embedding layer, an RWKV encoding layer, a sequence labeling layer, and a relation classification layer. The RWKV encoding layer tracks the state of requirement content across paragraphs, attachments, and versions, and generates label sequences and relation sets. Step 4: Generate semantic units of requirements based on the tag sequence and relation set, and determine the effective requirement elements based on version level, source credibility, and output confidence. Step 5: Map the semantic units of the requirements to the review constraint graph, and perform requirement integrity, interface support, permission boundaries, acceptance verifiability and semantic conflict review based on the rule engine, graph path query and constraint verification, and generate anomaly markers and evidence chains; Step Six: Generate a list of risk-level review issues based on anomaly markers, constraint weights, and evidence chains; Step 7: Read the review feedback results and requirement modification results, optimize the review parameters using the improved MAP-Elites algorithm, generate a parameter optimization library, and execute the next round of information technology requirement review based on the parameter optimization library.

[0007] Optionally, step one specifically includes: Collect information technology requirement materials, perform document type identification, hash verification, document layout analysis and content extraction on the information technology requirement materials, extract the main text title, requirement number, paragraph text, table header fields, field values, row and column relationships and attachment reference relationships, and generate review marks for unparseable content or content with recognition confidence below the preset threshold. Data fragments are generated based on the content extraction results. The data fragments include text fragments, table field fragments, and attachment-related fragments. Position anchors are written for each data fragment. Perform cleaning and splicing processing on the data fragments, and write source identifier and version identifier to the processed data fragments; When multiple version fragments exist, a version chain is established and replacement, supplementation, or obsolescence relationships are recorded. A review data frame is generated using data segments that have been cleaned, spliced, and labeled as the basic recording unit. The review data frame includes segment content, segment type, source identifier, version identifier, location anchor, reference relationship, version chain relationship, and review mark.

[0008] Optionally, step two specifically includes: Acquire enterprise information assets, review rules, and historical review records, and perform entity standardization processing on enterprise information assets, using name normalization, synonym mapping, and unique identifier matching to generate system entities, business entities, data entities, interface entities, permission entities, acceptance entities, and historical defect entities; System nodes, business nodes, data nodes, interface nodes, permission nodes, acceptance nodes, and historical defect nodes are generated based on system entities, business entities, data entities, interface entities, permission nodes, acceptance nodes, and historical defect nodes, respectively. The review constraint diagram edges are generated based on the data source relationships, interface call relationships, access control relationships, business pre- and post-processing relationships, and acceptance support relationships among enterprise information assets; Generate historical defect similarity edges based on historical review records, perform text vectorization processing on historical issue items, and establish historical defect similarity edges between corresponding nodes and historical defect nodes based on semantic similarity. Generate graph constraint rules based on the review rules, and bind integrity rules, interface support rules, permission boundary rules, acceptance verification rules, and semantic conflict rules to the corresponding review constraint graph nodes or review constraint graph edges; Generate constraint edge weights for the edges in the review constraint graph. The constraint edge weights are determined based on the source credibility, version level, and manual confirmation status. Generate a review constraint graph that includes a set of nodes, a set of edges, a set of graph constraint rules, and a set of constraint edge weights.

[0009] Optionally, step three specifically includes: The review data frame is input into the demand state evolution network, which includes an embedding layer, an RWKV encoding layer, a sequence labeling layer, and a relation classification layer. The review data frame is vectorized through the embedding layer. Word embeddings are generated based on fragment content, type embeddings are generated based on fragment type and source identifier, version embeddings are generated based on version identifier and version chain relationship, position embeddings are generated based on position anchors, relationship position embeddings are generated based on reference relationship, and review embeddings are generated based on review mark. After fusing word embeddings, type embeddings, version embeddings, position embeddings, relational position embeddings, and verification embeddings, the execution layer normalizes them to obtain the input embedding sequence; Based on the source identifier, version identifier and field content in the review data frame, the data fragment is pre-matched with the candidate nodes or candidate edges in the review constraint graph to obtain the constraint edge weights corresponding to the pre-matching results, and the constraint edge weights corresponding to the pre-matching results are used as the state update input of the RWKV coding layer. The input embedded sequence and the constraint edge weights corresponding to the pre-matching results are input into the RWKV encoding layer. The RWKV encoding layer performs state tracking on the requirements across paragraphs, attachments and versions, and generates a context state sequence. The context state sequence is input into the sequence labeling layer. The BIO labeling method is used to label business objectives, functional actions, data objects, source systems, target systems, interface names, permission roles, exception handling, and acceptance indicators. The Conditional Random Field (CRF) is used to constrain the label transition results and generate a label sequence. Input the context state sequence and label sequence into the relation classification layer, determine the entity span based on the label sequence, and perform span pooling on each entity span to obtain the entity vector; Biaffine classification is performed on entity pairs composed of entity vectors, and the relationship categories of entity pairs are output through Softmax to generate a relationship set, which includes source relationship, flow relationship, call relationship, authorization relationship and verification relationship.

[0010] Optionally, the step of using the RWKV encoding layer to track the state of required content across paragraphs, attachments, and versions, and generating a context state sequence, specifically includes: The input embedding sequence is fed into the RWKV coding layer, which uses a time mixing, a collaborative weighted recursive mechanism of receive vector, key vector and value vector, a cyclic state buffer and channel mixing to generate a context state sequence. The temporal mixing in the RWKV coding layer generates a mixed representation based on the current segment embedding, the previous segment embedding, the source identifier, the version identifier, the verification mark, and the constraint edge weights obtained by pre-matching, so that data segments with high-confidence sources, high version levels, no verification marks, and high constraint edge weights are preferentially written into the context state sequence. The RWKV coding layer generates a receive vector, a time decay vector, a key vector, and a value vector based on the hybrid representation. It updates the weighted content accumulation state and the weight accumulation state using a weighted recursive method, and writes the weighted content accumulation state, the weight accumulation state, and the current encoded output into the loop state buffer. For text segments, attachment segments, and table field segments that have reference relationships in the review data frame, the RWKV encoding layer establishes a state index relationship between the referenced segment and the referenced segment, and writes the interface, permission, acceptance, and exception handling state components in the referenced segment into the requirement state corresponding to the referenced text segment. The RWKV encoding layer performs channel mixing on the current encoding output and adjusts the channel weights according to the fragment source, the channel type of the demand element, and the constraint edge weights obtained from pre-matching. When the same requirement object has different descriptions in different version fragments, the RWKV encoding layer adjusts the state update weight according to the version chain relationship; When the channel output score of the current segment in the corresponding requirement element channel is lower than the preset element threshold, the state component of the corresponding requirement element in the previous state is retained to obtain a context state sequence that is continuously updated across paragraphs, attachments and versions.

[0011] Optionally, step four specifically includes: Based on the tag sequence and relationship set, the data fragments in the review data frame are subjected to field matching processing, with the requirement number, title path, business objective and functional action as matching fields, and data fragments with matching fields are merged into the same candidate requirement set. Based on the relation set, the candidate requirement set is subjected to relation assembly processing to generate requirement semantic units. The requirement semantic units are structured requirement records with business objectives and functional actions as core fields and data objects, source systems, target systems, interface names, permission roles, exception handling and acceptance indicators as associated fields. For the same type of field values ​​in the same semantic unit of demand, perform confidence ranking processing according to the weighted result of version level, source credibility and output confidence, and determine the valid demand elements based on the confidence ranking result; When the difference in the sorting scores of two or more field values ​​is less than the preset conflict threshold and the field contents are inconsistent, a feature conflict marker is generated. Perform field integrity checks and index association processing on valid demand elements to generate missing element tags and index association information.

[0012] Optionally, step five specifically includes: Obtain requirement semantic units, valid requirement elements, element conflict markers, missing element markers, index association information, and review constraint diagrams; Match the business objectives, functional actions, data objects, source systems, target systems, interface names, permission roles, exception handling, and acceptance indicators in the requirement semantic unit to the corresponding nodes in the review constraint diagram; The graph constraint rules in the rule engine are invoked according to the functional action type of the requirement semantic unit, and graph path query and constraint verification are performed based on the review constraint graph. Valid requirement elements, mapping nodes, constraint edge weights, element conflict markers and missing element markers are used as inputs for rule verification. Perform requirements integrity review, interface support review, permission boundary review, acceptance verification review, and semantic conflict review, and generate exception markers based on the review results; For each anomaly marker, an evidence chain assembly process is performed to generate an evidence chain corresponding to the anomaly marker. The evidence chain includes the demand semantic unit number, valid demand elements, index association information, mapping nodes, query paths, triggering rules, constraint edge weights, element conflict markers, and anomaly triggering locations.

[0013] Optionally, step six specifically includes: Obtain anomaly markers, evidence chains, element conflict markers, and constraint edge weights, and group the anomaly markers according to the requirement semantic unit number to generate candidate groups of review issues; For each candidate group of review issues, anomaly type coding is performed, and triggering rules, mapping nodes, query paths, anomaly trigger locations, index association information, and element conflict markers are extracted from the evidence chain. The constraint influence value of the candidate group of review issues is determined based on the constraint edge weights of the graph edges corresponding to the evidence chain. The review risk score is generated by combining the anomaly type value, constraint impact value, number of evidence chains, and element conflict markers according to preset weights. The risk scores of the review are assessed according to the medium risk threshold and the high risk threshold to determine the risk level, and to generate a low risk level, a medium risk level, or a high risk level. The candidate groups of review issues are sorted according to the issue level and review risk score, and a risk-level review issue list is generated.

[0014] Optionally, step seven specifically includes: Obtain review feedback results and requirement modification results, and write manually confirmed issue items, false alarm issue items, missing supplementary items and modified requirement fragments into the historical review record, false alarm sample set, supplementary review sample set and index association information of valid requirement elements respectively; A review effectiveness sample is constructed based on the risk grading review issue list, constraint weights, evidence chain, false alarm sample set, supplementary review sample set, and manual confirmation results. An improved MAP-Elites algorithm behavior feature space is constructed, which takes the demand type, number of systems involved, number of interface dependencies, number of permission roles and similarity of historical defects as behavior feature dimensions, and divides them into multiple behavior feature units according to a preset partitioning rule. Candidate solutions are defined, which are combinations of review parameters, including constraint edge weight coefficients, risk score weights, historical defect similarity thresholds, medium risk thresholds, and high risk thresholds. Initialize the candidate solution population, apply the candidate solutions to the review effect sample, and recalculate the anomaly label, risk level, and problem list ranking results; The recalculated results are input into the improved MAP-Elites algorithm, which generates a parameter optimization library. The next round of information technology requirements review is then performed based on this library.

[0015] Optionally, the generation of the parameter optimization library by the improved MAP-Elites algorithm specifically includes: Constraint screening is performed on candidate solutions. When the recall rate of a high-risk problem corresponding to a candidate solution is lower than the preset recall threshold, the false positive rate is higher than the preset false positive threshold, the medium-risk threshold is not less than the high-risk threshold, or the review parameters exceed the preset parameter boundaries, the candidate solution is removed from the elite screening object. Fitness evaluation is performed on the candidate solutions that pass the constraint screening, and fitness values ​​are generated based on the recall rate of high-risk issues, the accuracy of review issue identification, the false alarm rate, and the cost of manual review. Based on the behavioral characteristics corresponding to the review effect samples, determine the behavioral feature unit to which the candidate solution belongs, and compare the fitness values ​​of the candidate solutions within the corresponding behavioral feature unit; When the fitness value of a new candidate solution is higher than the fitness value of the existing elite parameter in the corresponding behavioral feature unit, the new candidate solution is determined as the new elite parameter. When the fitness value of a new candidate solution is not higher than the fitness value of the existing elite parameter in the corresponding behavioral feature unit, the existing elite parameter is retained. The elite parameters are perturbed and updated to generate new candidate solutions. Constraint screening, fitness evaluation, behavioral feature unit archiving, and elite parameter replacement are then repeated. A parameter optimization library is generated based on the elite parameters retained within each behavioral feature unit. The parameter optimization library includes the behavioral feature unit identifier, elite parameters, fitness value, applicable requirement type, and update time.

[0016] The beneficial effects of this invention are: This invention addresses the problems of unclear sources and difficulty in tracing version conflicts caused by existing requirement materials being scattered across the main text, tables, attachments, and multiple revisions. It generates a review data frame with citation relationships, version chain relationships, and verification markers by performing structured parsing, source identification, and version identification on information requirement materials. By constructing a review constraint graph and generating constraint weights, it establishes queryable constraint relationships between enterprise information assets, review rules, and historical review records, resolving the issue of relying on manual item-by-item verification for interface support, permission boundaries, and acceptance criteria. Through an RWKV encoding layer combined with constraint weights, citation relationships, version chain relationships, and verification markers, it performs cross-paragraph, cross-attachment, and cross-version status tracking, improving the continuity and consistency of requirement semantic units and effective requirement elements. Anomaly markers and evidence chains are generated through a rule engine, graph path query, and constraint verification, enabling review issues to be located at the original material, mapping node, triggering rule, and query path. Finally, an improved MAP-Elites algorithm optimizes review parameters based on feedback and modification results, reducing false positives and false negatives caused by fixed thresholds. Its significance lies in forming a closed loop of requirements analysis, graph constraint review, evidence chain location, and parameter self-optimization, thereby improving the traceability, verifiability, and continuous adaptability of information requirements review. Attached Figure Description

[0017] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of an information requirements review method based on semantic parsing proposed in this invention; Figure 2 This is a framework diagram of the requirement state evolution network in the information requirement review method based on semantic parsing proposed in this invention; Figure 3 This is a schematic diagram of the improved MAP-Elites algorithm in the semantic parsing-based information requirements review method proposed in this invention. Detailed Implementation

[0018] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0019] refer to Figures 1-3 A semantic parsing-based method for reviewing information technology requirements includes the following steps: Step 1: Collect information technology requirement materials, perform structured parsing, source identifier writing, and version identifier writing on the information technology requirement materials, and generate review data frames; Step 2: Construct a review constraint diagram based on the enterprise's IT assets, review rules, and historical review records, and generate constraint edge weights based on source credibility and version level; Step 3: Input the review data frame into the requirement state evolution network. The requirement state evolution network includes an embedding layer, an RWKV encoding layer, a sequence labeling layer, and a relation classification layer. The RWKV encoding layer tracks the state of requirement content across paragraphs, attachments, and versions, and generates label sequences and relation sets. Step 4: Generate semantic units of requirements based on the tag sequence and relation set, and determine the effective requirement elements based on version level, source credibility, and output confidence. Step 5: Map the semantic units of the requirements to the review constraint graph, and perform requirement integrity, interface support, permission boundaries, acceptance verifiability and semantic conflict review based on the rule engine, graph path query and constraint verification, and generate anomaly markers and evidence chains; Step Six: Generate a list of risk-level review issues based on anomaly markers, constraint weights, and evidence chains; Step 7: Obtain the review feedback results and requirement modification results, optimize the review parameters using the improved MAP-Elites algorithm, generate a parameter optimization library, and execute the next round of information technology requirement review based on the parameter optimization library.

[0020] In this embodiment, step one specifically includes: Information technology requirement materials are collected, including requirement description materials, business process materials, interface constraint materials, permission constraint materials, acceptance constraint materials, and historical review materials. Requirement description materials record business objectives, functional requirements, and business scope; business process materials record business nodes, processing order, and flow conditions; interface constraint materials record data call relationships between systems, interface names, and interface status; permission constraint materials record user roles, operation actions, and operation scope; acceptance constraint materials record delivery verification conditions, test indicators, and judgment criteria; and historical review materials record historical issues, issue types, manual confirmation results, and modification records. The document type identification is performed on the information requirements materials, and the identification results include text documents, table documents, scanned documents and attachment documents; hash verification is performed on the information requirements materials, and a document identifier is generated based on the document hash value, project number and submission batch; submission batches are generated according to the submission time order of materials under the same project; Document layout analysis technology is used to identify the main text area, title area, table area, and attachment reference area, and convert text-based documents, table-based documents, scanned documents, and attachment-based documents into parsable file objects. For scanned documents, OCR recognition technology is used to extract text content, and text content with a recognition confidence level lower than a preset recognition confidence level threshold is marked as a review mark. The preset recognition confidence level threshold is determined based on the statistical results of historical OCR recognition samples, and is set to 0.90 in this embodiment. Content extraction is performed on parsable file objects. Title level recognition and number matching are used to extract the main text title, requirement number and paragraph text. Table structure recovery technology is used to extract table header, field value and row and column relationship. Attachment number matching is used to establish the reference relationship between the main text content and the attachment content. Data fragments are generated based on the content extraction results; text fragments are generated according to the title level, requirement number and paragraph boundary; table field fragments are generated according to the correspondence between table header fields and field values; and attachment-related fragments are generated according to attachment number and reference position. Write location anchors for each data segment. The location anchors include file identifier, page number, paragraph number, table row and column coordinates, and attachment number. Perform cleaning and splicing processing on data fragments, remove duplicate headers and footers, eliminate blank fragments and format placeholder fragments, splice cross-page text according to paragraph continuity, and splice cross-page tables according to table coordinates. The cleaned and spliced ​​data segments are written with source and version identifiers; the source identifier is generated based on material category, file identifier, and location anchor; the version identifier is generated based on submission batch, revision number, and timestamp. When multiple version fragments exist under the same requirement number or title path, a version chain is established according to the version identifier; when a new version fragment replaces an old version fragment, the replacement relationship is recorded; when a new version fragment adds fields or supplements attachment content to an old version fragment, the supplementation relationship is recorded; when a new version fragment declares an old version fragment invalid, the obsolescence relationship is recorded. Review data frames are generated using data segments that have undergone cleaning, splicing, source identifier writing, version identifier writing, and version chain processing as the basic recording unit. The review data frame includes segment content, segment type, source identifier, version identifier, location anchor, reference relationship, version chain relationship, and review mark. In the contract management system transformation project, the requirement text fragment states "to realize the synchronization of contract information from the ERP system to the contract management system", the interface attachment fragment states "the ERP system opens the contract information query interface", and the acceptance material fragment states "the contract information synchronization success rate is not less than 99%". The above data fragments are linked through the requirement number and attachment reference relationship, and the source identifier, version identifier and location anchor are written in the review data frame respectively.

[0021] In this embodiment, step two specifically includes: Obtain enterprise IT assets, review rules, and historical review records; Enterprise IT assets include system assets, data assets, interface assets, access control assets, and acceptance assets. They also include the data source relationships, interface call relationships, access control relationships, business pre- and post-processing relationships, and acceptance support relationships among system assets, data assets, interface assets, access control assets, and acceptance assets. The review rules include integrity rules, interface support rules, permission boundary rules, acceptance verification rules, and semantic conflict rules. Integrity rules are used to verify whether the fields of the requirement elements are complete. Interface support rules are used to verify whether there are interface call paths in cross-system business. Permission boundary rules are used to verify the correspondence between permission roles and operation scopes. Acceptance verification rules are used to verify acceptance indicators, test conditions, judgment criteria, and target objects. Semantic conflict rules are used to verify data source conflicts, interface direction conflicts, permission scope conflicts, and business pre- and post-conflicts. Historical review records include historical issue items, issue types, triggering rules, manual confirmation results, and rectification results; Enterprise IT assets are subject to entity standardization; name normalization, synonym mapping, and unique identifier matching are used to merge different descriptions of the same system, data object, interface, permission role, or acceptance indicator into the same entity, and entity type and entity identifier are written for each entity; name normalization includes removing spaces, unifying capitalization, and unifying system abbreviation and full name; synonym mapping includes mapping "contract system" and "contract management platform" to contract management system, and mapping "approval feedback interface" and "approval status interface" to approval status feedback interface; Generate review constraint diagram nodes based on entity standardization results; generate system nodes for system objects, business nodes for business items, data nodes for data objects, interface nodes for interface objects, permission nodes for permission roles, acceptance nodes for acceptance conditions, and historical defect nodes for historical issue items; write interface status attributes to interface nodes, including available, disabled, pending construction, and pending confirmation. Data source edges are generated based on the data source relationships between enterprise information assets; interface call edges are generated based on the relationships between systems that call data or return status through interfaces; access control edges are generated based on the authorization relationships between roles and operations; business pre- and post-processing edges are generated based on the processing order between business nodes; and acceptance support edges are generated based on the correspondence between acceptance conditions and requirement objects. Generate historical defect similarity edges based on historical review records; perform text vectorization processing on historical issue items, and calculate the semantic similarity between historical issue items and business nodes, data nodes, interface nodes, permission nodes, or acceptance nodes; when the semantic similarity reaches a preset similarity threshold, establish historical defect similarity edges between the corresponding node and the historical defect node; the preset similarity threshold is determined based on the ROC curve analysis results of historical issue matching samples, and is set to 0.85 in this embodiment; Generate graph constraint rules based on the review rules; bind integrity rules to business nodes and data nodes, bind interface support rules to system nodes and interface nodes, bind permission boundary rules to permission nodes, bind acceptance verification rules to acceptance nodes, and bind semantic conflict rules to data source edges, interface call edges, and business pre- and post-processing edges; Constraint edge weights are generated for the edges in the review constraint graph. The constraint edge weights are determined based on the source credibility, version level, and manual confirmation status. The source credibility is determined by the source material category of the edge correspondence, the version level is determined by the version identifier of the edge correspondence, and the manual confirmation status is determined by the historical review record or the current project confirmation record. When there are multiple sources for the same constraint relationship, the source with the highest source credibility and the highest version level is selected as the basis for edge weight generation. After completing the generation of review constraint graph nodes, edge generation, graph constraint rule binding, and constraint edge weights, a review constraint graph including a set of nodes, a set of edges, a set of graph constraint rules, and a set of constraint edge weights is generated. In the contract management system transformation project, system nodes are generated for the ERP system, OA system, and contract management system; data nodes are generated for contract information and approval status; interface nodes are generated for the contract information query interface and approval status feedback interface; permission nodes are generated for the handlers and department heads; and acceptance nodes are generated for the synchronization success rate and status feedback latency. When the contract information query interface is derived from the interface constraint materials and the version is a confirmed draft, the corresponding interface call side is written with a higher constraint side weight. When "can be connected to the OA system" is derived from the meeting minutes and the version is a draft, the corresponding interface call side is written with a lower constraint side weight.

[0022] In this embodiment, step three specifically includes: The review data frame is input into the demand state evolution network, which includes an embedding layer, an RWKV encoding layer, a sequence labeling layer, and a relation classification layer. The review data frame is vectorized through the embedding layer; the fragment content is segmented and word embeddings are generated; the fragment type and source identifier are generated; the version identifier and version chain relationship are generated; the position anchor is generated; the reference relationship is generated; and the review mark is generated. After fusing word embeddings, type embeddings, version embeddings, position embeddings, relational position embeddings, and verification embeddings, the execution layer normalizes them to obtain the input embedding sequence; Based on the source identifier, version identifier, and field content in the review data frame, the data fragments are pre-matched with candidate nodes or candidate edges in the review constraint graph to obtain the constraint edge weights corresponding to the pre-matching results, and the constraint edge weights are used as the state update input for the RWKV encoding layer. During the pre-matching process, when the fragment content contains system name, interface name, data object, or permission role, candidate nodes in the review constraint graph are searched based on the name normalization results and synonym mapping results. When the fragment content contains data flow, interface call, or permission action, candidate edges in the review constraint graph are searched. The input embedding sequence is fed into the RWKV coding layer; the RWKV coding layer uses a time mixing, receive vector, time decay vector, key vector and value vector collaborative weighted recursion mechanism, cyclic state buffer and channel mixing to generate the context state sequence. The temporal blending in the RWKV encoding layer generates a hybrid representation based on the current fragment embedding, the previous fragment embedding, the source identifier, the version identifier, the verification mark, and the constraint edge weights obtained from pre-matching. This prioritizes fragments with high-trust sources, high version levels, no verification marks, and high constraint edge weights in the context state sequence. Among these, the confirmation draft content in interface constraint materials, permission constraint materials, and acceptance constraint materials has a higher state writing intensity compared to lower version requirement text, meeting minutes, or fragments with verification marks. The RWKV coding layer generates a receive vector, a time decay vector, a key vector, and a value vector based on the hybrid representation. It updates the weighted content accumulation state and the weight accumulation state using a weighted recursive method, and writes the weighted content accumulation state, the weight accumulation state, and the current encoded output into the loop state buffer. When a subsequent segment is input, the required state is updated based on the loop state buffer and the current segment embedding, without recalculating the previously input historical segments. For text segments, attachment segments, and table field segments that have reference relationships in the review data frame, the RWKV encoding layer establishes a state index relationship between the referenced segment and the referenced segment, and writes the interface, permission, acceptance, and exception handling state components in the referenced segment into the requirement state corresponding to the referenced text segment. When the RWKV encoding layer performs channel mixing on the current encoding output, it first establishes a channel weight vector according to the channel type of the demand element; the channel type of the demand element includes system channel, interface channel, data flow channel, role channel, operation permission channel, acceptance indicator channel, judgment condition channel, and exception handling channel; The RWKV encoding layer generates source channel masks based on the fragment source. When the fragment source is interface constraint material, the mask values ​​for system channel, interface channel, and data flow channel are set to 1, and the mask values ​​for other channels are set to 0. When the fragment source is permission constraint material, the mask values ​​for role channel and operation permission channel are set to 1, and the mask values ​​for other channels are set to 0. When the fragment source is acceptance constraint material, the mask values ​​for acceptance indicator channel and judgment condition channel are set to 1, and the mask values ​​for other channels are set to 0. When the fragment source does not belong to interface constraint material, permission constraint material, or acceptance constraint material, the corresponding channel mask is determined according to the candidate node type obtained by pre-matching in the fragment content. The RWKV encoding layer performs weighted correction on the channel weight vector based on the constraint edge weights obtained from pre-matching. For demand element channels with a mask value of 1, the weight of the demand element channel is amplified according to the first correction coefficient and the corresponding constraint edge weight. For demand element channels with a mask value of 0, the weight of the demand element channel is maintained or reduced according to the second correction coefficient. The first correction coefficient is determined based on the element identification contribution of interface, permission, and acceptance samples, and is set to 0.30 in this embodiment. The second correction coefficient is determined based on the retention ratio of non-target channels, and is set to 0.05 in this embodiment. The RWKV encoding layer performs normalization on the corrected channel weight vector and multiplies the normalized channel weight vector with the current encoding output channel by channel to obtain the channel-mixed encoding output. When the fragment source is interface constraint material and the pre-matched interface call edge constraint weight is 0.80, the system channel, interface channel and data flow channel are weighted according to the product of 0.30 and 0.80, and the remaining channels are attenuated according to 0.05. After normalization, they participate in the channel-by-channel weighting of the current encoding output. When the same requirement object has different descriptions in different version fragments, the RWKV encoding layer generates a version state mask and a version update coefficient according to the version chain relationship, and performs merging on the historical state component and the current state component according to the version state mask and the version update coefficient. When the version chain relationship is a replacement relationship, the channel mask value of the requirement element corresponding to the replaced version fragment is set to 0, the channel mask value of the requirement element corresponding to the current version fragment is set to 1, and the state component corresponding to the replaced version fragment is overwritten with the state component corresponding to the current version fragment. When the version chain relationship is obsolete, the channel mask value of the requirement element corresponding to the obsolete version fragment is set to 0, and the state component corresponding to the obsolete version fragment is removed from the circular state cache or marked as not participating in subsequent state output. When the version chain relationship is a supplementary relationship, the channel mask value of the demand element corresponding to the historical version fragment and the channel mask value of the demand element corresponding to the current supplementary fragment are both set to 1, and the historical state component and the current supplementary state component are weighted and merged according to the historical version update coefficient and the current version update coefficient. When the channel output score of the current segment in the corresponding demand element channel is lower than the preset element threshold, the channel mask value of the demand element corresponding to the current segment is set to 0, the channel mask value of the corresponding demand element in the previous state is set to 1, and the state component of the corresponding demand element in the previous state is used to obtain the context state sequence that is continuously updated across paragraphs, attachments and versions; the preset element threshold is determined by cross-validation of annotated corpus, and is set to 0.75 in this embodiment; The context state sequence is input into the sequence labeling layer, and BIO labeling and Conditional Random Field (CRF) are used to label the requirement elements to obtain the label sequence. The label sequence includes the starting label, internal label and non-feature label corresponding to business objectives, functional actions, data objects, source systems, target systems, interface names, permission roles, exception handling and acceptance indicators. The context state sequence and label sequence are input into the relationship classification layer. The entity span is determined based on the label sequence. Span pooling is performed on each entity span to obtain an entity vector. The Biaffine classifier and Softmax classification are used to determine the relationship between entity pairs, generating a relationship set. The relationship set includes the source relationship between data objects and source systems, the flow relationship between data objects and target systems, the call relationship between interface names and target systems, the authorization relationship between permission roles and functional actions, and the verification relationship between acceptance indicators and functional actions. In the contract information synchronization requirement, the main text fragment states "achieve automatic synchronization of contract information", the interface attachment fragment states "ERP system opens contract information query interface", and the acceptance material fragment states "synchronization success rate is not less than 99%". The main text fragment and the interface attachment fragment have a reference relationship, and the interface attachment fragment corresponds to the contract information query interface node and interface call edge in the review constraint diagram. The RWKV encoding layer establishes a state index relationship in the loop state cache, writes the interface state component in the interface attachment fragment into the requirement state corresponding to the main text fragment, and writes the acceptance indicator state component in the acceptance material fragment into the same requirement state. The sequence labeling layer identifies the data object "contract information", the source system "ERP system", the target system "contract management system", the interface name "contract information query interface", and the acceptance indicator "synchronization success rate is not less than 99%".

[0023] In this embodiment, step four specifically includes: Obtain the label sequence and relation set output from step three; Using requirement number, title path, business objective, and functional action as matching fields, perform field matching processing on data fragments in the review data frame; when the matching fields of multiple data fragments are consistent, the corresponding data fragments are merged into the same candidate requirement set, and the corresponding source identifier, version identifier, location anchor point, and output confidence information are retained; Based on the relation set, the candidate requirement set is subjected to relation assembly processing to generate requirement semantic units. The requirement semantic unit is a structured requirement record with business objectives and functional actions as core fields, and data objects, source systems, target systems, interface names, permission roles, exception handling and acceptance indicators as associated fields, and the relationship between fields is established according to the relation set. For the same type of field values ​​in the same semantic unit of requirement, confidence level sorting is performed according to the weighted result of version level, source confidence level and output confidence level; version level is determined by version identifier, source confidence level is determined by source identifier, and output confidence level is generated by requirement state evolution network; Based on the confidence ranking results, valid demand elements are determined, and the field value with the highest ranking result is determined as the valid demand element under the corresponding field category. When the difference in ranking scores of two or more field values ​​is less than the preset conflict threshold and the field content is inconsistent, an element conflict mark is generated, and the data segment number corresponding to the conflict field value is recorded. The preset conflict threshold is determined by statistical method of historical manual review results, and is 0.05 in this embodiment. Perform field integrity checks on valid requirement elements; when the functional action belongs to the data synchronization, interface call, permission approval, statistical analysis or acceptance delivery type, check whether the required fields are missing according to the corresponding requirement type; if there are missing fields, generate missing element markers; Perform index association processing on valid demand elements, and establish index association between valid demand elements and corresponding data segment numbers, location anchors, source identifiers, version identifiers and output confidence scores; In the contract information synchronization requirement, the initial draft fragment states "contract information comes from the OA system," the confirmed draft fragment states "contract information comes from the ERP system," and the interface constraint material states "the ERP system has an open contract information query interface." For the same field "source system," there are two candidate field values: OA system and ERP system. The version level of the confirmed draft is higher than that of the initial draft, the source credibility of the interface constraint material is higher than that of the requirement description material, and the output confidence of the ERP system candidate field is higher than that of the OA system candidate field. Therefore, the ERP system is determined as the source system field in the valid requirement elements, and the data fragment number corresponding to the OA system candidate field is recorded.

[0024] In this embodiment, step five specifically includes: Obtain the requirement semantic units, valid requirement elements, element conflict markers, missing element markers, and index association information generated in step four, and obtain the review constraint diagram constructed in step two; Extract business objectives, functional actions, data objects, source systems, target systems, interface names, permission roles, exception handling, and acceptance indicators from the semantic units of requirements to form a set of elements to be mapped; Perform entity matching processing on the set of elements to be mapped; based on field name, thesaurus, entity identifier and text similarity, match business targets to business nodes, match data objects to data nodes, match source system and target system to system nodes, match interface name to interface nodes, match permission role to permission nodes, and match acceptance indicators to acceptance nodes. For valid requirement elements that do not match any graph nodes, a node missing record is generated, and the node missing record is used as the triggering basis for requirement integrity exception, interface support exception, permission boundary exception, or acceptance unprovable mark. For valid requirement elements that match multiple candidate graph nodes, they are sorted according to node name consistency, source credibility, constraint edge weight, and text similarity, and the graph node with the highest ranking is selected as the mapping node. The graph constraint rules in the rule engine are invoked based on the functional action type of the demand semantic unit, and the valid demand elements, mapping nodes, constraint edge weights, element conflict markers and missing element markers are used as inputs for rule validation. Perform a requirement integrity review, obtain the corresponding set of required fields according to the type of function action, check whether the data object, system object, interface object, permission role, exception handling and acceptance indicator fields in the valid requirement elements are empty, and generate requirement integrity exception tags based on empty fields and missing element tags; Perform interface support review, query the interface call path between source system node, interface node and target system node in the review constraint diagram, and determine whether the interface call path exists, whether the interface node status attribute is available, whether the interface call direction is consistent with the association relationship between fields in the requirement semantic unit, and whether the constraint edge weight in the interface call path reaches the preset edge weight threshold. Generate an interface support anomaly mark based on the judgment results. The preset edge weight threshold is determined by statistical method of successful delivery cases in historical projects. In this implementation, it is set to 0.70. Perform permission boundary review, query the permission control edge between permission role node and function action in the review constraint diagram, determine whether the permission control edge exists, whether the operation scope corresponding to the permission control edge covers the function action, whether the permission role is consistent with the permission role in the requirement semantic unit, and generate permission boundary exception markers based on the judgment results. Perform acceptance verification review, query the acceptance support edge between the acceptance node and the business node, data node, and interface node in the review constraint diagram, determine whether the acceptance support edge exists, whether the acceptance index includes test conditions, judgment criteria and target object, and generate an acceptance non-verifiable mark based on the judgment result. Perform semantic conflict review. Based on the relationship between fields in the semantic unit of the requirement, query the corresponding graph edge in the review constraint graph to determine whether there are multiple valid source systems for the same data object, whether there are opposite call directions for the same interface, whether there are mutually exclusive operation ranges for the same permission role, and whether there are mutually exclusive pre- and post-requirement relationships for the same business node. Generate semantic conflict markers based on the judgment results. For each anomaly marker, evidence chain assembly is performed to extract the demand semantic unit number, valid demand elements, index association information, mapping nodes, query paths, triggering rules, constraint edge weights, element conflict markers, and anomaly triggering locations, and generate an evidence chain corresponding to the anomaly marker. In the requirement for approval status feedback, the requirement semantic unit records "approval status feedback from OA system to contract management system". Valid requirement elements include the data object "approval status", the source system "OA system", the target system "contract management system", and the function action "status feedback". In the review constraint diagram, the OA system node and the contract management system node are successfully matched, the approval status field matches the data node, and there is no "approval status feedback interface" with an available status in the interface node. After the rule engine calls the interface support rule, it performs a graph path query between the source system node, the interface node, and the target system node. The query result shows that the interface node is missing, and the path interruption position is the interface call edge between the OA system node and the contract management system node. An interface support anomaly marker is generated, and an evidence chain is assembled. This evidence chain includes the requirement semantic unit number, the original fragment position, the valid requirement element "approval status feedback", the mapping nodes "OA system" and "contract management system", the interruption position "interface node missing", the triggering rule "cross-system status feedback requirement must have an available interface", and the anomaly marker "interface support anomaly marker". In the permission boundary review, the requirement semantic unit records "the person in charge can export all contract information"; in the review constraint diagram, there is a permission control edge between the person in charge permission role node and the "contract query" action, but no authorization edge between the person in charge permission role node and the "export all contracts" action, or the operation scope corresponding to the permission control edge only covers contracts of this department; after the rule engine performs the permission boundary review, it generates permission boundary anomaly markers and assembles an evidence chain including permission role node, function action, permission control edge, anomaly trigger location and original fragment location.

[0025] In this embodiment, step six specifically includes: Obtain the anomaly markers and evidence chains generated in step five, and obtain the element conflict markers generated in step four and the constraint edge weights generated in step two; The exception markers are grouped according to the requirement semantic unit number. The requirement integrity exception markers, interface support exception markers, permission boundary exception markers, acceptance unprovable markers, and semantic conflict markers belonging to the same requirement semantic unit are merged into the same review issue candidate group. Perform exception type coding for each review issue candidate group; set interface support exception markers, permission boundary exception markers, and semantic conflict markers as high-weight exception types, and set requirement integrity exception markers and acceptance unprovable markers as medium-weight exception types. Extract triggering rules, mapping nodes, query paths, abnormal triggering locations, index association information, and element conflict markers from the evidence chain, and write the corresponding content into the review issue candidate group; Obtain the constraint edge weights of the graph edges corresponding to the evidence chain, and determine the constraint impact value of the candidate group of review issues based on the constraint edge weights; when there are multiple graph edges in the evidence chain, select the constraint edge weight of the graph edge corresponding to the path interruption position as the constraint impact value; when no path interruption occurs, select the constraint edge weight of the graph edge corresponding to the abnormal triggering rule as the constraint impact value. An assessment risk score is generated by combining anomaly type value, constraint impact value, number of evidence chains, and element conflict markers according to preset weights. The weight of anomaly type value is 0.40, constraint impact value is 0.30, number of evidence chains is 0.20, and element conflict marker is 0.10. The maximum assessment risk score is 100 points. Risk levels are determined based on the review risk scores according to medium-risk and high-risk thresholds. When the review risk score is less than the medium-risk threshold, a low-risk issue level is generated. When the review risk score is greater than or equal to the medium-risk threshold but less than the high-risk threshold, a medium-risk issue level is generated. When the review risk score is greater than or equal to the high-risk threshold, a high-risk issue level is generated. In this embodiment, the medium-risk threshold is 60 points and the high-risk threshold is 80 points. Candidate groups of review issues are sorted according to their issue level; within the same issue level, they are sorted from highest to lowest review risk score; if review risk scores are the same, they are sorted from most to least number of chains of evidence. Generate review issue entries for the sorted candidate review issues; each review issue entry includes issue number, requirement semantic unit number, issue type, issue level, exception marker, trigger rule, evidence chain, source location, and modification prompt; During the handling of the missing approval status feedback interface, the interface support exception marker corresponds to a high exception type value, the source system node, target system node and interface call relationship in the evidence chain correspond to high constraint edge weights, the generated review risk score reaches the high risk threshold, and the problem level is judged as high risk; the corresponding review problem entry records the problem type as missing interface support, the triggering rule is that the cross-system status feedback requirement must have a usable interface, the source location is the corresponding paragraph of the requirement specification and the interface attachment directory, and the modification prompt is to supplement the approval status feedback interface name, interface call direction, interface status, exception handling method and acceptance indicators.

[0026] In this embodiment, step seven specifically includes: Obtain review feedback results and requirement modification results; review feedback results include manual confirmation results, false alarm markers, missing supplementary items, and issue level adjustment results; requirement modification results include the modified requirement fragment, modification location, modification version, and modification confirmation status. Manually confirmed issues are written into the historical review record, falsely reported issues are written into the false report sample set, and missing supplementary items are written into the supplementary review sample set. The modified requirement fragments are then indexed and associated with the corresponding valid requirement elements. A review effectiveness sample is constructed based on the risk grading review issue list, constraint weights, evidence chain, false alarm sample set, supplementary review sample set, and manual confirmation results. An improved MAP-Elites algorithm behavioral feature space is constructed. The requirement type, number of involved systems, number of interface dependencies, number of permission roles, and historical defect similarity are used as behavioral feature dimensions, and divided into multiple behavioral feature units according to preset partitioning rules. Requirement types are divided into data synchronization, interface call, permission approval, statistical analysis, and acceptance / delivery categories. When the number of involved systems is 1, it is divided into a single-system interval; when the number of involved systems is 2 to 3, it is divided into a dual-system interval; and when the number of involved systems is greater than 3, it is divided into a multi-system interval. The number of interface dependencies is divided into no interfaces, single interfaces, and multiple interfaces. The number of permission roles is divided into no permission roles, single roles, and multiple roles. Historical defect similarity is less than 0.60 and divided into a low-similarity interval; between 0.60 and 0.85 and divided into a medium-similarity interval; and greater than 0.85 and divided into a high-similarity interval. Candidate solutions are defined, which are combinations of review parameters, including constraint edge weight coefficients, risk score weights, historical defect similarity thresholds, medium risk thresholds, and high risk thresholds. Initialize the candidate solution population by generating multiple candidate solutions from the current review parameters, the review parameters that have been adopted and confirmed in the historical reviews, and the random perturbation parameters; the size of the candidate solution population is determined according to the dimension of the review parameters, and 30 candidate solutions are selected in this embodiment; Apply the candidate solutions to the review effect sample and recalculate the anomaly markers, risk levels, and problem list ranking results; Constraint screening is performed on candidate solutions. When the recall rate of a high-risk problem corresponding to a candidate solution is lower than the preset recall threshold, the false positive rate is higher than the preset false positive threshold, the medium-risk threshold is not less than the high-risk threshold, or the parameter value exceeds the preset parameter boundary, the candidate solution is removed from the elite screening object. In this embodiment, the recall threshold is 0.90, the false positive threshold is 0.15, the constraint edge weight coefficient ranges from 0.50 to 2.00, the historical defect similarity threshold ranges from 0.60 to 0.95, the medium-risk threshold ranges from 40 to 70, and the high-risk threshold ranges from 70 to 95. A fitness evaluation is performed on the candidate solutions that pass the constraint screening. Fitness values ​​are generated based on the recall rate of high-risk issues, the accuracy of the identification of review issues, the false positive rate, and the cost of manual review. The fitness values ​​are calculated according to the positive contributions of the recall rate of high-risk issues and the accuracy of the identification of review issues, and the negative contributions of the false positive rate and the cost of manual review. Based on the behavioral characteristics corresponding to the review effect sample, determine the corresponding behavioral feature unit, and evaluate the candidate solutions within the corresponding behavioral feature unit; Within each behavioral feature unit, the fitness values ​​of candidate solutions are compared, and the candidate solution with the highest fitness value is determined as the elite parameter of that behavioral feature unit. When a new candidate solution satisfies the constraint screening conditions and its fitness value is higher than that of the existing elite parameter in that behavioral feature unit, the new candidate solution is determined as the new elite parameter. When a new candidate solution does not satisfy the constraint screening conditions, or its fitness value is not higher than that of the existing elite parameter, the existing elite parameter is retained. The elite parameters are updated by perturbation. Random perturbations of preset magnitude are applied to the constraint edge weight coefficients, risk score weights, historical defect similarity thresholds, medium-risk thresholds, and high-risk thresholds to generate new candidate solutions. The perturbation magnitude of the constraint edge weight coefficients is ±0.10, the perturbation magnitude of the risk score weights is ±0.05, the perturbation magnitude of the historical defect similarity threshold is ±0.03, and the perturbation magnitudes of the medium-risk and high-risk thresholds are ±5 points. Repeat the process of candidate solution action, constraint screening, fitness evaluation, behavioral feature unit determination, elite parameter replacement and perturbation update until the preset number of iterations is reached, the elite parameters have not been replaced for multiple consecutive rounds, or the number of review effect samples is lower than the preset update number. In this embodiment, the preset number of iterations is 50, the iteration stops when the elite parameters have not been replaced for 10 consecutive rounds, and the preset update number is 20 review effect samples. A parameter optimization library is generated based on the elite parameters retained within each behavioral feature unit. The parameter optimization library includes the behavioral feature unit identifier, elite parameters, fitness value, applicable requirement type, and update time. In the next round of information technology requirements review, the behavioral feature units in the parameter optimization library will be matched based on the behavioral features of the semantic units of the requirements to be reviewed, and the corresponding elite parameters will be called to update the constraint edge weight generation rules, risk scoring rules, historical defect similarity thresholds, medium risk thresholds and high risk thresholds. In the approval status feedback requirement, this requirement belongs to the interface call category, involving two systems: the OA system and the contract management system. It has one interface dependency, two permission roles, and a high similarity in historical defects. This requirement is classified into the behavioral feature unit of "interface call type, dual systems, single interface, multiple roles, high similarity." When a candidate solution achieves a high-risk issue recall rate above the preset recall threshold and a false positive rate below the preset false positive threshold within this behavioral feature unit, it enters elite screening. When the fitness value of the candidate solution is higher than the existing elite parameters in this unit, the candidate solution is determined as a new elite parameter and written into the parameter optimization library. When a similar approval status interface requirement appears in the next round, the elite parameters corresponding to this behavioral feature unit are called from the parameter optimization library, and the risk score weight, historical defect similarity threshold, and high-risk threshold for interface support anomaly marking are updated.

[0027] Example 1: To verify the feasibility of this invention in implementation, it was applied to the information technology requirements review scenario of a group's contract management system transformation project. This project involved an ERP system, OA system, contract management system, master data platform, and data middle platform. A total of 18 requirement description materials, 9 business process materials, 12 interface constraint materials, 7 permission constraint materials, 8 acceptance constraint materials, and 120 historical review materials were collected, forming 1684 data fragments, including 924 text fragments, 516 table field fragments, and 244 attachment association fragments. After manual review and the establishment of a test benchmark, 912 valid requirement elements, 236 cross-attachment associations, 68 cross-version conflict or replacement relationships, and 54 high-risk review issues were confirmed. After entity standardization, system assets, data assets, interface assets, permission assets, and acceptance assets generated 286 review constraint graph nodes and 742 review constraint graph edges, with constraint edge weights ranging from 0.32 to 0.96. The OCR identification confidence threshold is set to 0.90, the historical defect similarity threshold is set to 0.85, the element threshold is set to 0.75, the medium risk threshold is set to 60 points, and the high risk threshold is set to 80 points.

[0028] During implementation, the information requirements materials are converted into review data frames, and the source identifier, version identifier, citation relationship, version chain relationship, and review mark are input into the requirement state evolution network. The RWKV encoding layer uses constraint edge weights, source channel masks, version state masks, and citation fragment state indexes to track the state of cross-paragraph, cross-attachment, and cross-version content, generating label sequences and relationship sets. Then, requirement semantic units are generated based on the label sequences and relationship sets, and valid requirement elements are mapped to the review constraint graph. For the requirement of "approval status being returned from the OA system to the contract management system", the system matches the OA system node, the contract management system node, and the approval status data node in the review constraint graph, but does not match the approval status return interface node with an available status. Therefore, an interface support anomaly mark is generated, forming an evidence chain containing the original fragment location, mapping node, query path, triggering rule, and constraint edge weights.

[0029] In the comparative test, Method A used a manual rule list and keyword retrieval to locate review issues; Method B used a standard BERT model to extract requirement elements and then combined it with static rules for anomaly detection; the unimproved model used a standard RWKV encoding layer and rule engine, without introducing constraint edge weights, reference relationships, version chain relationships, and review markers to participate in state updates, nor did it use the improved MAP-Elites algorithm for review parameter optimization. This invention uses the review data frame, review constraint graph, requirement state evolution network, rule engine, graph path query, evidence chain, and improved MAP-Elites algorithm as defined in the claims for processing.

[0030] Table 1. Comparison of different review methods in the contract management system transformation project.

[0031] As shown in Table 1, although Method A has a low number of valid requirement elements identified and cross-attachment relationships identified, its false positive rate is 12.8%, and the manual confirmation rate of the issue list is 81.3%, indicating that the manual rule list has strong constraints on high-risk issues with clearly defined existing rules, and the output results are relatively conservative. Meanwhile, this method has an average single-item review time of 54.6 seconds and only 151 cross-attachment relationship identifications, indicating that its processing efficiency is low when the main text, interface attachments, permission descriptions, and acceptance clauses are scattered. Method B identified 818 valid requirement elements, indicating that the ordinary BERT model extracts text fields such as business objectives, functional actions, and data objects well; however, its cross-version conflict identification is only 46 groups, with a false positive rate of 19.5%, indicating that relying solely on semantic extraction and static rules can easily lead to the repeated judgment of similar fields in the initial draft, the confirmed draft, and supplementary attachments as anomalies. The average time for a single review of the unimproved model is 17.9 seconds, which is faster than the present invention. The number of effective demand elements identified also reaches 829. However, the number of cross-version conflict identifications is 51, and the evidence chain integrity rate is 75.6%. This indicates that although the ordinary RWKV encoding layer can handle continuous text states, it does not make sufficient use of version chain relationships, constraint edge weights, and reference fragment state indexes.

[0032] This invention identified 852 valid requirement elements, 211 cross-attachment relationships, 59 cross-version conflicts, and 50 high-risk issues, with a false positive rate of 10.9%, an evidence chain completeness rate of 89.1%, and a manual confirmation rate of 89.4% for the issue list. Compared to the unimproved model, this invention increased the number of valid requirement elements identified by 23, the number of cross-attachment relationships identified by 21, the number of cross-version conflicts identified by 8, and the number of high-risk issues recalled by 5. This primarily corresponds to the participation of constraint edge weights in RWKV encoding layer state updates, the weighted correction of source channel masks for interface and permission-related channels, and the handling of replacement, supplementary, and obsolescence relationships by version state masks. The average single-item review time of this invention is 20.6 seconds, slightly higher than the 17.9 seconds of the unimproved model. This is because this invention adds graph path query, evidence chain assembly, and parameter optimization library matching steps, but its evidence chain completeness rate and the number of high-risk issues recalled are significantly improved.

[0033] In this embodiment, the present invention, in the processes of contract information synchronization, approval status feedback, and contract export permission review, can merge text fragments, interface attachment fragments, permission constraint fragments, and acceptance material fragments into corresponding requirement semantic units, and query interface call paths, permission control edges, and acceptance support edges through review constraint graphs. For issues such as missing approval status feedback interfaces, out-of-bounds permissions for exporting all contract information by the responsible party, and lack of judgment criteria for acceptance indicators, the present invention can generate anomaly markers and evidence chains. After the review feedback results and requirement modification results are formed, the elite parameters within the corresponding behavioral feature units are updated using an improved MAP-Elites algorithm. Therefore, the present invention demonstrates comprehensive effectiveness in requirement element identification, cross-attachment relationship association, cross-version conflict handling, evidence chain location, and continuous optimization of review parameters in implementation scenarios.

[0034] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for reviewing information technology requirements based on semantic parsing, characterized in that, Includes the following steps: Step 1: Collect information technology requirement materials, perform structured parsing, source identifier writing, and version identifier writing on the information technology requirement materials, and generate review data frames; Step 2: Construct a review constraint diagram based on the enterprise's IT assets, review rules, and historical review records, and generate constraint edge weights based on source credibility and version level; Step 3: Input the review data frame into the requirement state evolution network. The requirement state evolution network includes an embedding layer, an RWKV encoding layer, a sequence labeling layer, and a relation classification layer. The RWKV encoding layer tracks the state of requirement content across paragraphs, attachments, and versions, and generates label sequences and relation sets. Step 4: Generate semantic units of requirements based on the tag sequence and relation set, and determine the effective requirement elements based on version level, source credibility, and output confidence. Step 5: Map the semantic units of the requirements to the review constraint graph, and perform requirement integrity, interface support, permission boundaries, acceptance verifiability and semantic conflict review based on the rule engine, graph path query and constraint verification, and generate anomaly markers and evidence chains; Step Six: Generate a list of risk-level review issues based on anomaly markers, constraint weights, and evidence chains; Step 7: Read the review feedback results and requirement modification results, optimize the review parameters using the improved MAP-Elites algorithm, generate a parameter optimization library, and execute the next round of information technology requirement review based on the parameter optimization library.

2. The information requirements review method based on semantic parsing according to claim 1, characterized in that, Step one specifically includes: Collect information technology requirement materials, perform document type identification, hash verification, document layout analysis and content extraction on the information technology requirement materials, extract the main text title, requirement number, paragraph text, table header fields, field values, row and column relationships and attachment reference relationships, and generate review marks for unparseable content or content with recognition confidence below the preset threshold. Data fragments are generated based on the content extraction results. The data fragments include text fragments, table field fragments, and attachment-related fragments. Position anchors are written for each data fragment. Perform cleaning and splicing processing on the data fragments, and write source identifier and version identifier to the processed data fragments; When multiple version fragments exist, a version chain is established and replacement, supplementation, or obsolescence relationships are recorded. A review data frame is generated using data segments that have been cleaned, spliced, and labeled as the basic recording unit. The review data frame includes segment content, segment type, source identifier, version identifier, location anchor, reference relationship, version chain relationship, and review mark.

3. The information requirements review method based on semantic parsing according to claim 1, characterized in that, Step two specifically includes: Acquire enterprise information assets, review rules, and historical review records, and perform entity standardization processing on enterprise information assets, using name normalization, synonym mapping, and unique identifier matching to generate system entities, business entities, data entities, interface entities, permission entities, acceptance entities, and historical defect entities; System nodes, business nodes, data nodes, interface nodes, permission nodes, acceptance nodes, and historical defect nodes are generated based on system entities, business entities, data entities, interface entities, permission nodes, acceptance nodes, and historical defect nodes, respectively. The review constraint diagram edges are generated based on the data source relationships, interface call relationships, access control relationships, business pre- and post-processing relationships, and acceptance support relationships among enterprise information assets; Generate historical defect similarity edges based on historical review records, perform text vectorization processing on historical issue items, and establish historical defect similarity edges between corresponding nodes and historical defect nodes based on semantic similarity. Generate graph constraint rules based on the review rules, and bind integrity rules, interface support rules, permission boundary rules, acceptance verification rules, and semantic conflict rules to the corresponding review constraint graph nodes or review constraint graph edges; Generate constraint edge weights for the edges in the review constraint graph. The constraint edge weights are determined based on the source credibility, version level, and manual confirmation status. Generate a review constraint graph that includes a set of nodes, a set of edges, a set of graph constraint rules, and a set of constraint edge weights.

4. The information requirements review method based on semantic parsing according to claim 1, characterized in that, Step three specifically includes: The review data frame is input into the demand state evolution network, which includes an embedding layer, an RWKV encoding layer, a sequence labeling layer, and a relation classification layer. The review data frame is vectorized through the embedding layer. Word embeddings are generated based on fragment content, type embeddings are generated based on fragment type and source identifier, version embeddings are generated based on version identifier and version chain relationship, position embeddings are generated based on position anchors, relationship position embeddings are generated based on reference relationship, and review embeddings are generated based on review mark. After fusing word embeddings, type embeddings, version embeddings, position embeddings, relational position embeddings, and verification embeddings, the execution layer normalizes them to obtain the input embedding sequence; Based on the source identifier, version identifier and field content in the review data frame, the data fragment is pre-matched with the candidate nodes or candidate edges in the review constraint graph to obtain the constraint edge weights corresponding to the pre-matching results, and the constraint edge weights corresponding to the pre-matching results are used as the state update input of the RWKV coding layer. The input embedded sequence and the constraint edge weights corresponding to the pre-matching results are input into the RWKV encoding layer. The RWKV encoding layer performs state tracking on the requirements across paragraphs, attachments and versions, and generates a context state sequence. The context state sequence is input into the sequence labeling layer. The BIO labeling method is used to label business objectives, functional actions, data objects, source systems, target systems, interface names, permission roles, exception handling, and acceptance indicators. The Conditional Random Field (CRF) is used to constrain the label transition results and generate a label sequence. Input the context state sequence and label sequence into the relation classification layer, determine the entity span based on the label sequence, and perform span pooling on each entity span to obtain the entity vector; Biaffine classification is performed on entity pairs composed of entity vectors, and the relationship categories of entity pairs are output through Softmax to generate a relationship set, which includes source relationship, flow relationship, call relationship, authorization relationship and verification relationship.

5. The information requirements review method based on semantic parsing according to claim 4, characterized in that, The RWKV encoding layer performs state tracking on the required content across paragraphs, attachments, and versions, generating a context state sequence, specifically including: The input embedding sequence is fed into the RWKV coding layer, which uses a time mixing, a collaborative weighted recursive mechanism of receive vector, key vector and value vector, a cyclic state buffer and channel mixing to generate a context state sequence. The temporal mixing in the RWKV coding layer generates a mixed representation based on the current segment embedding, the previous segment embedding, the source identifier, the version identifier, the verification mark, and the constraint edge weights obtained by pre-matching, so that data segments with high-confidence sources, high version levels, no verification marks, and high constraint edge weights are preferentially written into the context state sequence. The RWKV coding layer generates a receive vector, a time decay vector, a key vector, and a value vector based on the hybrid representation. It updates the weighted content accumulation state and the weight accumulation state using a weighted recursive method, and writes the weighted content accumulation state, the weight accumulation state, and the current encoded output into the loop state buffer. For text segments, attachment segments, and table field segments that have reference relationships in the review data frame, the RWKV encoding layer establishes a state index relationship between the referenced segment and the referenced segment, and writes the interface, permission, acceptance, and exception handling state components in the referenced segment into the requirement state corresponding to the referenced text segment. The RWKV encoding layer performs channel mixing on the current encoding output and adjusts the channel weights according to the fragment source, the channel type of the demand element, and the constraint edge weights obtained from pre-matching. When the same requirement object has different descriptions in different version fragments, the RWKV encoding layer adjusts the state update weight according to the version chain relationship; When the channel output score of the current segment in the corresponding requirement element channel is lower than the preset element threshold, the state component of the corresponding requirement element in the previous state is retained to obtain a context state sequence that is continuously updated across paragraphs, attachments and versions.

6. The information requirements review method based on semantic parsing according to claim 1, characterized in that, Step four specifically includes: Based on the tag sequence and relationship set, the data fragments in the review data frame are subjected to field matching processing, with the requirement number, title path, business objective and functional action as matching fields, and data fragments with matching fields are merged into the same candidate requirement set. Based on the relation set, the candidate requirement set is subjected to relation assembly processing to generate requirement semantic units. The requirement semantic units are structured requirement records with business objectives and functional actions as core fields and data objects, source systems, target systems, interface names, permission roles, exception handling and acceptance indicators as associated fields. For the same type of field values ​​in the same semantic unit of demand, perform confidence ranking processing according to the weighted result of version level, source credibility and output confidence, and determine the valid demand elements based on the confidence ranking result; When the difference in the sorting scores of two or more field values ​​is less than the preset conflict threshold and the field contents are inconsistent, a feature conflict marker is generated. Perform field integrity checks and index association processing on valid demand elements to generate missing element tags and index association information.

7. The information requirements review method based on semantic parsing according to claim 1, characterized in that, Step five specifically includes: Obtain requirement semantic units, valid requirement elements, element conflict markers, missing element markers, index association information, and review constraint diagrams; Match the business objectives, functional actions, data objects, source systems, target systems, interface names, permission roles, exception handling, and acceptance indicators in the requirement semantic unit to the corresponding nodes in the review constraint diagram; The graph constraint rules in the rule engine are invoked according to the functional action type of the requirement semantic unit, and graph path query and constraint verification are performed based on the review constraint graph. Valid requirement elements, mapping nodes, constraint edge weights, element conflict markers and missing element markers are used as inputs for rule verification. Perform requirements integrity review, interface support review, permission boundary review, acceptance verification review, and semantic conflict review, and generate exception markers based on the review results; For each anomaly marker, an evidence chain assembly process is performed to generate an evidence chain corresponding to the anomaly marker. The evidence chain includes the demand semantic unit number, valid demand elements, index association information, mapping nodes, query paths, triggering rules, constraint edge weights, element conflict markers, and anomaly triggering locations.

8. The information requirements review method based on semantic parsing according to claim 1, characterized in that, Step six specifically includes: Obtain anomaly markers, evidence chains, element conflict markers, and constraint edge weights, and group the anomaly markers according to the requirement semantic unit number to generate candidate groups of review issues; For each candidate group of review issues, anomaly type coding is performed, and triggering rules, mapping nodes, query paths, anomaly trigger locations, index association information, and element conflict markers are extracted from the evidence chain. The constraint influence value of the candidate group of review issues is determined based on the constraint edge weights of the graph edges corresponding to the evidence chain. The review risk score is generated by combining the anomaly type value, constraint impact value, number of evidence chains, and element conflict markers according to preset weights. The risk scores of the review are assessed according to the medium risk threshold and the high risk threshold to determine the risk level, and to generate a low risk level, a medium risk level, or a high risk level. The candidate groups of review issues are sorted according to the issue level and review risk score, and a risk-level review issue list is generated.

9. The information requirements review method based on semantic parsing according to claim 1, characterized in that, Step seven specifically includes: Obtain review feedback results and requirement modification results, and write manually confirmed issue items, false alarm issue items, missing supplementary items and modified requirement fragments into the historical review record, false alarm sample set, supplementary review sample set and index association information of valid requirement elements respectively; A review effectiveness sample is constructed based on the risk grading review issue list, constraint weights, evidence chain, false alarm sample set, supplementary review sample set, and manual confirmation results. An improved MAP-Elites algorithm behavior feature space is constructed, which takes the demand type, number of systems involved, number of interface dependencies, number of permission roles and similarity of historical defects as behavior feature dimensions, and divides them into multiple behavior feature units according to a preset partitioning rule. Candidate solutions are defined, which are combinations of review parameters, including constraint edge weight coefficients, risk score weights, historical defect similarity thresholds, medium risk thresholds, and high risk thresholds. Initialize the candidate solution population, apply the candidate solutions to the review effect sample, and recalculate the anomaly label, risk level, and problem list ranking results; The recalculated results are input into the improved MAP-Elites algorithm, which generates a parameter optimization library. The next round of information technology requirements review is then performed based on this library.

10. The information requirements review method based on semantic parsing according to claim 9, characterized in that, The parameter optimization library generated by the improved MAP-Elites algorithm specifically includes: Constraint screening is performed on candidate solutions. When the recall rate of a high-risk problem corresponding to a candidate solution is lower than the preset recall threshold, the false positive rate is higher than the preset false positive threshold, the medium-risk threshold is not less than the high-risk threshold, or the review parameters exceed the preset parameter boundaries, the candidate solution is removed from the elite screening object. Fitness evaluation is performed on the candidate solutions that pass the constraint screening, and fitness values ​​are generated based on the recall rate of high-risk issues, the accuracy of review issue identification, the false alarm rate, and the cost of manual review. Based on the behavioral characteristics corresponding to the review effect samples, determine the behavioral feature unit to which the candidate solution belongs, and compare the fitness values ​​of the candidate solutions within the corresponding behavioral feature unit; When the fitness value of a new candidate solution is higher than the fitness value of the existing elite parameter in the corresponding behavioral feature unit, the new candidate solution is determined as the new elite parameter. When the fitness value of a new candidate solution is not higher than the fitness value of the existing elite parameter in the corresponding behavioral feature unit, the existing elite parameter is retained. The elite parameters are perturbed and updated to generate new candidate solutions. Constraint screening, fitness evaluation, behavioral feature unit archiving, and elite parameter replacement are then repeated. A parameter optimization library is generated based on the elite parameters retained within each behavioral feature unit. The parameter optimization library includes the behavioral feature unit identifier, elite parameters, fitness value, applicable requirement type, and update time.

Images