Demand analysis-oriented automatic writing method and system

Abstract

The invention relates to the technical field of computer software demand analysis and automation, and discloses an automatic writing method and system oriented to demand analysis, and the method comprises the steps: constructing a domain knowledge graph containing a component mutual exclusion and dependency relationship, and deducing and generating a component compatibility matrix; converting the unstructured demand text into structured features by using a natural language processing algorithm; generating a virtual configuration list in combination with the atlas, and performing conflict detection based on a compatibility matrix and a supervision protocol; when violation is detected, the topological connectivity is quantified by calculating the sum of in-degree and out-degree of the component in the map, and the component is retrieved and replaced according to the topological connectivity for automatic correction; monitoring a change event, calculating an influence domain by using a weight conduction algorithm, and triggering local re-verification; and finally, generating a descriptive text, and executing consistency check by reversely extracting numerical values. According to the method, the configuration verification efficiency and the correction stability are improved through matrix operation and topology analysis, and the accuracy of the demand analysis document is ensured.

Description

Technical Field

[0001] This invention relates to the field of computer software requirements analysis and automation technology, specifically to an automated programming method and system oriented towards requirements analysis. Background Technology

[0002] The transformation of domestically developed information technology systems is a key measure to prevent cyberattacks and supply chain disruptions, involving the architectural restructuring and migration of large-scale existing systems. In this process, requirements analysis not only needs to accurately address the specific performance indicators and interface specifications of domestically developed operating systems, databases, middleware, and other basic software, but also needs to adapt to the dynamic environment brought about by the rapid iteration and frequent updates of domestic software versions. This requires the requirements analysis process to have high flexibility and compatibility.

[0003] Existing software engineering methodologies have limitations when dealing with such complex domestic IT innovation transformation scenarios. The traditional waterfall model relies on linear processes, making it difficult to respond promptly to frequent changes in the domestic IT technology stack. This can lead to requirement documents lagging behind the actual development status, failing to effectively guide subsequent work. While agile development emphasizes iterative interaction, it often lacks sufficient systematic analysis methods when dealing with deep compatibility issues involving the adaptation of underlying domestic hardware instruction sets or middleware interface protocols. Furthermore, commonly used use case analysis methods primarily focus on functional logic, neglecting critical non-functional requirements such as system performance, data security, and high availability, thus failing to comprehensively support system reliability construction.

[0004] At the level of automated auxiliary tools, most existing technologies are not specifically optimized for domestic software and hardware environments, and have limited ability to identify compatibility conflicts between domestic basic software. Faced with the rapid evolution of domestically developed software, these tools typically lack sufficient dynamic rule update capabilities and cannot automatically adapt to changes in the underlying dependent environment, leading to cumbersome requirements analysis processes and making them prone to human error. Furthermore, existing tools generally lack in-depth quantitative analysis and closed-loop verification functions for non-functional requirements, making it difficult to meet the stringent standards for system security and stability in domestically developed software upgrades. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides an automated writing method and system for requirements analysis, which solves the problems of poor accuracy in converting unstructured text into technical specifications, difficulty in verifying multi-level dependencies and compatibility between components, and inconsistency between generated documents and original data in requirements analysis of complex systems.

[0006] To achieve the above objectives, the present invention provides the following technical solution: an automated writing method and system for requirements analysis.

[0007] The first aspect of this invention provides an automated coding method for requirements analysis, comprising: A domain knowledge graph containing software components, hardware specifications, and regulatory rules is constructed, and the knowledge foundation is initialized. Based on this, a component compatibility matrix is ​​derived and generated through logical operations according to the mutual exclusion and dependency relationships in the domain knowledge graph. Specifically, this process traverses the mutual exclusion relationships in the graph to mark prohibited items, and simultaneously traverses the dependency relationships to obtain the row vectors corresponding to the dependent components. The prohibited markers are then merged into the row vectors of the dependent components through a logical OR operation, thereby propagating constraints along the dependency chain to calculate and mark implicit conflicts.

[0008] The system receives unstructured requirement text and transforms it into structured features using natural language processing algorithms. These structured features include a set of software entities, hardware constraints, and vectors of non-functional requirement indicators. During processing, a BERT-BiLSTM-CRF-based composite network structure is used for sequence labeling of the text, calculating the probability distribution of entity boundary labels corresponding to characters, and decoding using the Viterbi algorithm to identify entity boundaries. For the identified entity-referencing text fragments, they are input into a pre-trained model to obtain semantic embedding vectors, which are then compared with the semantic embedding vectors of standard entity names in the knowledge graph. A cosine similarity score is obtained by calculating the dot product of the two vectors and dividing it by the product of their L2 norms. The standard knowledge entity with the highest score is used as the mapping result. Simultaneously, dependency parsing is used to parse the path between entities and indicators, generating semantic triples containing numerical values ​​and logical operators. For non-functional requirements, qualitative descriptions are mapped to numerical ranges in a business scenario benchmark table, and normalization is performed to construct feature vectors.

[0009] Based on structured features and a domain knowledge graph, a virtual configuration list containing software stack combinations and hardware specification parameters is generated. This process inputs non-functional requirement indicator vectors into a quantization mapping model to calculate initial hardware specifications, and combines this with a set of software entities to generate a virtual configuration list based on the relationships and deployment rules in the knowledge graph.

[0010] The system queries the component compatibility matrix and regulatory specifications in the domain knowledge graph to perform internal compatibility calculations and external compliance verifications on the virtual configuration list. When a compatibility conflict or compliance violation is detected, the set of conflicting components that caused the verification failure is analyzed. By statistically calculating the sum of the in-degree and out-degree of each component in the conflicting component set in the domain knowledge graph, the topological connectivity of each component is quantified. This topological connectivity is used as the replacement cost gradient, and the component with the smallest cost gradient is identified as the target component to be replaced. Subsequently, candidate replacement components are retrieved using the entity type and function tag of the target component as an index, and the compatibility score between the candidate replacement component and other components in the list is calculated. The candidate component with the highest score is selected for correction and replacement until a verified configuration scheme is generated.

[0011] The system monitors updates to knowledge base data or changes to requirement inputs. Based on dependencies in the domain knowledge graph, it calculates the impact domain of the changes using a weight propagation algorithm. This algorithm locates the source node of the change and sets an initial impact weight value. It then traverses backward along the dependency edges to the upstream parent node, multiplying the current node's impact weight value by the coupling strength coefficient on the edge to obtain the propagation weight value. When the propagation weight value exceeds a preset propagation threshold, the upstream parent node is added to the processing queue, and cascading calculations continue to determine the set of affected nodes. A minimal re-validation subset is constructed for the affected nodes and their neighboring nodes with non-zero-value associations in the component compatibility matrix. Local re-validation is performed only on this subset.

[0012] The validated configuration scheme and non-functional requirement indicators are entered into the document template. A natural language generation algorithm is used to generate descriptive text, and a numerical consistency check is performed before outputting the requirements analysis document. The numerical consistency check includes performing regular expression matching and dependency analysis on the generated descriptive text, extracting quantifiers and technical terms, and calculating the difference between the extracted values ​​and the original values ​​in the configuration scheme. If the difference is not zero, the consistency check fails and a partial regeneration is triggered to ensure the consistency between the text description and the data in the output document.

[0013] A second aspect of the present invention provides an automated writing system oriented towards requirements analysis, comprising: The knowledge base maintenance module is used to build a domain knowledge graph that includes software components, hardware specifications, and regulatory rules, and to generate a component compatibility matrix through logical operations based on mutual exclusion and dependency relationships. The requirement information extraction module is used to receive unstructured requirement text and use natural language processing algorithms to convert the unstructured requirement text into structured features. The non-functional requirement configuration mapping and virtual verification module is used to generate a virtual configuration list based on structured features and domain knowledge graph, and to perform conflict detection and automatic correction on the virtual configuration list using component compatibility matrix and regulatory specifications until a verified configuration scheme is generated. The dynamic requirement change analysis module is used to monitor change events. Based on the domain knowledge graph, it calculates the impact domain of the change through a weight propagation algorithm and triggers the non-functional requirement configuration mapping and virtual verification module to perform local re-verification. The requirements analysis document generation and optimization module is used to receive verified configuration schemes, generate and optimize requirements analysis documents; The model selection and training module is used to build, train, and update the semantic understanding model for the requirement information extraction module and the natural language generation model for the requirement analysis document generation and optimization module.

[0014] This invention provides an automated programming method and system for requirements analysis. It offers the following advantages: 1. This invention transforms the mutual exclusion and dependency relationships in the domain knowledge graph into a component compatibility matrix, and uses logical operations to merge the constraints of dependent components along the dependency chain to upstream components. This mechanism transforms the complex graph path search in traditional methods into efficient matrix vector operations, which not only effectively reduces the computational complexity of multi-level system verification, but also identifies implicit conflicts under deep dependencies during the initialization phase, improving the comprehensiveness and execution speed of virtual configuration manifest verification.

[0015] 2. When automatically correcting configuration conflicts, this invention employs a cost evaluation strategy based on topological connectivity, quantifying the replacement cost by statistically summing the in-degree and out-degree of components in the graph. This strategy encourages the system to prioritize replacing components with lower coupling when encountering compatibility or compliance issues, avoiding large-scale system architecture disruptions or cascading failures caused by modifying highly connected core components. This ensures that the automatically generated configuration scheme meets compliance requirements while maintaining architectural stability.

[0016] 3. This invention establishes a closed-loop verification mechanism for the numerical consistency between descriptive text and structured data. After the natural language text is generated, key indicators are extracted using regular expression matching and dependency analysis, and then compared with the original solution data using a difference comparison. This mechanism can automatically detect and intercept numerical drift or erroneous descriptions generated by the natural language generation algorithm, avoiding the data fabrication phenomenon commonly found in automated documents, and ensuring the accuracy and reliability of the final output requirements analysis document in terms of technical specifications. Attached Figure Description

[0017] Figure 1 This is a flowchart of the functional modules of the system of the present invention; Figure 2 This is a flowchart of the method steps of the present invention. Detailed Implementation

[0018] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] See attached document Figure 1This invention provides an automated writing method and system for requirements analysis, which is deployed in a computing device or distributed computing cluster. The computing device includes a memory and a processor. The memory stores computer-executable instructions, and the processor executes the instructions to implement the logic of the following functional modules. The system includes: a requirements information extraction module, a model selection and training module, a non-functional requirements configuration mapping and virtual verification module, a dynamic requirements change analysis module, a requirements analysis document generation and optimization module, and a knowledge base maintenance module.

[0020] The requirement information extraction module is configured to receive unstructured raw requirement text data, and use natural language processing algorithms to perform entity recognition and dependency parsing on the text, transforming the unstructured text into a structured feature vector that can be processed by a computer. The data output by the requirement information extraction module includes a set of software entities, hardware constraints, and vectors of non-functional requirement indicators.

[0021] The model selection and training module is used to build, train, and update deep learning models. Based on the Transformer architecture or other neural network architectures, the module uses specialized corpus data in the financial information technology innovation field for pre-training and fine-tuning to generate a semantic understanding model for the demand information extraction module and a natural language generation model for the demand analysis document generation and optimization module.

[0022] The non-functional requirement configurability mapping and virtual verification module is connected to the requirement information extraction module and the knowledge base maintenance module. This module establishes a mathematical mapping relationship between non-functional requirement indicators and hardware / software configurations, generating a virtual configuration list. Internally, this module integrates conflict detection logic, using a component compatibility matrix to perform internal compatibility calculations and external compliance checks on the virtual configuration list, outputting a verified configuration scheme.

[0023] The Dynamic Requirements Change Analysis module monitors update events in the knowledge base or change events in requirement inputs. Based on graph dependencies, it calculates the impact domain of changes, identifies affected configuration nodes, and triggers the Non-Functional Requirements Configuration Mapping and Virtual Verification module to perform local re-verification of the affected areas.

[0024] The requirements analysis document generation and optimization module receives verified structured configuration data and non-functional requirement metrics. Using preset document templates and natural language generation algorithms, it converts the structured data into requirements analysis documents that conform to predetermined specifications, and performs final numerical consistency checks and format rendering.

[0025] The knowledge base maintenance module, as the underlying data support unit of the system, is used to collect, store, and manage domain knowledge in the financial information technology innovation field. The knowledge base maintenance module maintains a domain knowledge graph containing software components, hardware specifications, and regulatory rules, as well as a compatibility matrix describing the constraints between components, and provides data query interfaces for the aforementioned computing modules.

[0026] See attached document Figure 2 An automated coding method oriented towards requirements analysis is implemented based on the aforementioned system architecture and includes the following steps: S1. Knowledge Base Initialization and Construction. The knowledge base maintenance module performs data collection tasks, acquiring software version information, hardware specifications, and industry regulatory rules in the financial information technology innovation field. Based on the collected data, the knowledge base maintenance module constructs a domain knowledge graph, defining entity nodes and the dependencies or mutual exclusion relationships between nodes. Simultaneously, the knowledge base maintenance module calculates and generates a component compatibility matrix. This matrix stores the technical compatibility status between any two software and hardware components within the system in a binary format, providing a data foundation for subsequent logical verification.

[0027] S2. Structured Extraction of Requirement Information. The requirement information extraction module receives the unstructured requirement text to be processed. It loads a semantic understanding model pre-trained by the model selection and training module to perform sequence labeling on the unstructured requirement text. The module identifies software entity names, hardware constraints, and non-functional requirement indicators in the text. Using dependency parsing algorithms, it parses the logical relationships between entities and indicators, transforming the text description into a requirement feature vector containing numerical values ​​and logical operators.

[0028] S3. Virtual Configuration Mapping and Initial Verification. The Non-functional Requirements Configurable Mapping and Virtual Verification module reads the requirement feature vector generated in step S2. Based on the performance benchmark data provided by the knowledge base maintenance module, the module uses a preset mapping function to calculate the minimum hardware specifications and recommended software version combination required to satisfy the requirement feature vector, and generates a virtual configuration list.

[0029] S4. Configuration Conflict Detection and Correction. The non-functional requirement configurability mapping and virtual verification module inputs the virtual configuration list into the conflict detection logic. This module queries the component compatibility matrix and calculates the compatibility product between components within the virtual configuration list. Simultaneously, it compares the virtual configuration list with regulatory compliance. When the calculation results indicate a compatibility conflict or compliance violation, the module retrieves alternative components based on the conflict gradient algorithm, updates the virtual configuration list, and re-executes the detection until a verified configuration scheme is generated.

[0030] S5. Dynamic Change Impact Analysis. The dynamic requirement change analysis module continuously monitors the data update status of the knowledge base maintenance module and external requirement change instructions. When a change event is detected, the dynamic requirement change analysis module locates the change source node in the domain knowledge graph. Based on the graph dependency path, the dynamic requirement change analysis module executes a propagation algorithm to calculate the impact weight of the change on the currently generated virtual configuration list. If the impact weight exceeds a preset threshold, the dynamic requirement change analysis module marks the affected configuration subset and triggers the non-functional requirement configuration mapping and virtual verification module to perform a re-verification process only for that subset.

[0031] S6. Document Generation and Consistency Output. The requirements analysis document generation and optimization module obtains the verified configuration scheme and corresponding non-functional requirement indicators. It calls a standard financial industry document template, filling in the hardware and software parameters from the configuration scheme into the configuration suggestion field and the non-functional requirement indicators into the requirement indicator field. The module uses a natural language generation model to generate project background and objective description text. Before outputting the final document, the module performs a numerical comparison to verify whether the indicator values ​​described in the document are consistent with the technical parameters in the configuration scheme. Once confirmed, it outputs the requirements analysis specification.

[0032] During the initialization and construction of the knowledge base, the knowledge base maintenance module acquires the basic data required for building the knowledge graph through a multi-source heterogeneous data acquisition subroutine. This data acquisition process specifically includes the following steps: S101. Configure multi-source data access channels. The knowledge base maintenance module has a pre-configured list of targeted data sources for the financial information technology innovation field. This list includes the portals of financial industry regulatory agencies for obtaining technical specifications, compliance indicators, and regulatory documents; official technical support sites of domestic basic software and hardware manufacturers for obtaining software version release notes, technical white papers, API interface documents, and compatibility certification lists; and performance benchmark test reports published by authoritative third-party evaluation agencies for obtaining theoretical performance data under different hardware specifications. The knowledge base maintenance module defines the access addresses, update frequencies, and data extraction rules of the above data sources through configuration files.

[0033] S102. Implement differentiated data collection strategies. For different types of data sources, the knowledge base maintenance module calls the corresponding data collection adapter. For technical support web pages containing dynamically loaded content, the knowledge base maintenance module utilizes dynamic rendering technology based on a headless browser kernel to simulate a browser environment and execute JavaScript scripts. After the page document object model is fully loaded, page elements are extracted. For unstructured regulatory documents published in formats such as PDF and Word, the knowledge base maintenance module calls a document parsing engine to extract the text stream and embedded table data. For image data containing screenshots of technical parameters, the knowledge base maintenance module calls an optical character recognition (OCR) interface to convert the image information into text characters. For specific network request encapsulation, HTML parsing algorithms, and basic OCR recognition models, those skilled in the art can use existing mature technology libraries for implementation, and will not be elaborated upon here.

[0034] S103. Data Cleaning and Standardization Preprocessing. The knowledge base maintenance module performs cleaning operations on the collected raw data. This includes removing HTML tags, style code, script code, and irrelevant navigation bar noise from the raw web page data. For software version number data, the module uses regular expressions for normalization, converting different vendor naming formats into a standardized format for major version numbers, minor version numbers, and revision numbers. For unstructured technical description text, the module removes special symbols and stop words, retaining keywords with business meaning. For semi-structured parameter tables, the module identifies header fields and maps them to system-predefined attribute key-value pairs, forming a standardized intermediate data format stored in a temporary data buffer for subsequent graph construction.

[0035] After data cleaning is completed, the knowledge base maintenance module uses the cleaned data to execute a domain knowledge graph construction program, which specifically includes the following steps: S104. Establish the knowledge graph ontology model. The knowledge base maintenance module predefines the schema layer of the knowledge graph in the graph database. This schema layer includes entity type definitions and relation type definitions. Entity types include at least: software component entities, used to represent specific software products, whose attributes include vendor name, product name, version number, and applicable architecture; hardware specification entities, used to represent underlying computing resources, whose attributes include processor architecture, number of cores, and memory capacity; and regulatory entity entities, used to represent industry standards or performance benchmarks, whose attributes include indicator name, threshold conditions, and scope of application. Relationship types include at least: dependency relationships, used to represent that the operation of a first component depends on a second component; mutual exclusion relationships, used to represent that the first and second components cannot coexist in the same environment; and satisfaction relationships, used to represent that a component has the ability to comply with specific regulatory rules.

[0036] S105. Entity Extraction and Fusion. The knowledge base maintenance module traverses the standardized intermediate data and extracts specific data items using a named entity recognition algorithm. For each identified independent object, the knowledge base maintenance module checks if a corresponding node exists in the graph database. If it does not exist, a new entity node is created and assigned a unique identifier; if it already exists, the attributes of the existing node are updated or supplemented. The knowledge base maintenance module performs entity alignment operations, calculating the similarity of entities in different data sources, mapping different representations of the same object to the same entity node, eliminating data redundancy and ambiguity.

[0037] S106. Constructing relationships between entities. The knowledge base maintenance module analyzes the association fields and text description logic in the intermediate data and establishes edge connections between nodes. The knowledge base maintenance module parses the environment requirement field in the software version specification. If the field describes that the first component requires the second component to run, a directional dependency relationship edge is established between the first component node and the second component node. The knowledge base maintenance module parses the compatibility specification field. If the field describes that the first component does not support the second component, a bidirectional mutual exclusion relationship edge is established between them. The knowledge base maintenance module parses the certification certificate data. If it describes that the component has passed a certain standard test, a satisfaction relationship edge is established from the component node to the standard node.

[0038] S107. Persistent Storage of Graph Data. The knowledge base maintenance module writes the completed node and edge data into the graph database storage engine. A database system supporting attribute graph models is selected for the graph database. The knowledge base maintenance module establishes inverted indexes for the core attribute fields in the graph, including software name indexes, version number indexes, and regulatory clause indexes, to support high-performance retrieval and traversal operations of the graph data by subsequent modules. For the specific deployment and index optimization configuration of the graph database, those skilled in the art can choose appropriate open-source or commercial software implementations based on the actual data scale, which will not be elaborated here.

[0039] After constructing the domain knowledge graph, the knowledge base maintenance module continues with the component compatibility matrix initialization process in step S1. This process aims to transform the logical constraints in the graph into algebraic matrices to support subsequent efficient computations. This process specifically includes the following sub-steps: S108. Establish a global component index mapping. The knowledge base maintenance module traverses all software component nodes and hardware specification nodes in the domain knowledge graph, and counts the total number of valid component nodes in the system, denoted as N. The knowledge base maintenance module constructs a bidirectional index mapping table in memory, which maps the unique identifier of each component node to a unique integer index value between 0 and N-1. This index value is used to define the row and column coordinates of the component in the subsequently generated compatibility matrix. The knowledge base maintenance module keeps this mapping table in a cache to provide a coordinate query service with a time complexity of O(1).

[0040] S109. Instantiate the matrix space and fill it with initial values. The knowledge base maintenance module allocates a two-dimensional bitmap space or Boolean matrix space of size N×N in memory, defined as the component compatibility matrix. Based on the principle of "if not prohibited, it is permitted" in compatibility determination, the knowledge base maintenance module initializes all elements in this matrix except for the main diagonal to the value 0 (incompatible) or -1 (unknown state), indicating that by default, any two components are considered potentially compatible without explicit constraints. At the same time, the knowledge base maintenance module sets all elements on the main diagonal of the matrix to the value 1, indicating that the component itself has self-compatibility.

[0041] S110. Mapping Explicit Mutually Exclusive Relationships. The knowledge base maintenance module traverses the mutually exclusive relationship edges in the domain knowledge graph. For each mutually exclusive edge connecting the first component and the second component, the knowledge base maintenance module obtains the row index corresponding to the first component and the column index corresponding to the second component through the index mapping table. The knowledge base maintenance module forcibly updates the element values ​​at the corresponding coordinate positions in the component compatibility matrix, as well as the element values ​​at symmetrical positions, to the numerical value 0 or a logical false value. This step directly maps the hard conflicts explicitly specified in the vendor's technical documents or regulatory specifications to the matrix structure.

[0042] S111. Calculate implicit conflicts caused by dependency propagation. To identify indirect incompatibilities propagated due to dependencies between components, the knowledge base maintenance module traverses dependency type relationship edges in the domain knowledge graph. When it is identified that the first component depends on the second component, the knowledge base maintenance module obtains the matrix row vectors corresponding to the first component and the second component. The knowledge base maintenance module performs a bitwise AND operation on these two row vectors and updates the row vector of the first component with the result. Through this operation, if the second component and the third component have a mutual exclusion relationship (i.e., the corresponding position is 0), the value of the first component that depends on the second component at the corresponding position is also calculated as 0. This step ensures that the constraints of the lower-level components can be correctly propagated to the upper-level components along the dependency chain, realizing the explicit expression of implicit conflicts.

[0043] S112. Matrix Versioning and Persistent Storage. After completing the above calculation steps, the knowledge base maintenance module serializes the generated component compatibility matrix into a binary file or stores it in a key-value database. The knowledge base maintenance module assigns a version identifier to this matrix, which is consistent with the current domain knowledge graph data version. When nodes are added or deleted, or relationship attributes change in the domain knowledge graph, the knowledge base maintenance module triggers incremental updates or full reconstruction of the matrix based on the scope of the change, ensuring the consistency between the verification logic and the basic knowledge base.

[0044] To ensure the demand information extraction module accurately understands the specialized terminology and complex logical constraints within the financial information technology innovation field, the model selection and training module executes a model fine-tuning procedure before the system's official launch or during periodic maintenance. This procedure, serving as a preparatory stage for structured demand information extraction, specifically includes the following sub-steps: S201, Constructing a Domain-Adaptive Training Corpus. The model selection and training module extracts structured software product documents, hardware specifications, and regulatory compliance clauses from the knowledge base maintenance module as the basic corpus. The module preprocesses this corpus, using a sliding window algorithm to segment long texts into short sentence sequences that meet the model input length limit. To enhance the model's sensitivity to entities in the information technology innovation domain, the module performs an entity-based masking operation. This operation randomly selects software names or technical indicators from the corpus, masks them, and replaces them with mask markers [MASK], generating training samples for the masked language model task.

[0045] S202. Define the composite neural network architecture. The model selection and training module constructs a composite network structure based on BERT-BiLSTM-CRF. This structure contains three layers: The first layer is a pre-trained language model layer, which uses the BERT model as an encoder to transform the input character sequence into a dynamic word vector sequence containing contextual semantic information.

[0046] The second layer is a bidirectional long short-term memory network layer that receives the word vector sequence output from the first layer. This layer contains forward LSTM units and backward LSTM units, which capture the forward and backward semantic dependency features of the input sequence, respectively, and output the emission score of each character corresponding to each preset label category.

[0047] The third layer is a conditional random field layer, which receives the emission scores from the second layer. This layer introduces a label transition matrix to learn the legitimate transition probabilities between different entity labels, thereby providing a global constraint on the sequence labeling results.

[0048] S203. Supervised Fine-Tuning Training. The model selection and training module loads a set of financial demand samples that have been manually or semi-automatically labeled. This module inputs the sample set into the aforementioned composite neural network and calculates the loss function. This loss function is defined as the negative log-likelihood function of the correct path score. Specifically, the model selection and training module calculates the total score of the real labeled path, which consists of the sum of the emission score of each node on the path and the transition score between nodes; simultaneously, the model calculates the logarithm of the sum of the scores of all paths; finally, the difference between the two is taken as the loss value. The model selection and training module uses the AdamW optimizer or other gradient descent algorithms familiar to those skilled in the art to iteratively update the network parameters until the loss value converges to a preset threshold, completing the solidification and storage of the model parameters.

[0049] After the model has been trained and deployed, the requirement information extraction module performs the following runtime sub-steps during step S2 to transform unstructured text into computer-understandable semantic logic: S204. Sequence Labeling Inference and Entity Boundary Delineation. The requirement information extraction module receives the requirement text sequence to be analyzed and inputs it into a fine-tuned BERT-BiLSTM-CRF model. The module utilizes the conditional random field parameters in the model's output layer to execute the Viterbi decoding algorithm. This algorithm calculates the probability scores of all labeled paths under a given input sequence and searches for the optimal path with the highest global probability. Based on the labeling results of this optimal path, the requirement information extraction module determines the start and end boundaries and category attributes of each entity in the text, thereby extracting the original entity referential text fragments, including software name fragments, version number fragments, hardware parameter fragments, and non-functional indicator name fragments.

[0050] S205. Graph-based Entity Alignment and Normalization. Due to the presence of abbreviations, aliases, or non-standard expressions in the original text, the requirement information extraction module executes an entity linking procedure. The requirement information extraction module uses the entity referential text fragment extracted in step S204 as the query key and searches the domain knowledge graph index constructed by the knowledge base maintenance module. The retrieval strategy employs a multi-level matching mechanism: first, exact string matching is performed; if no match is found, the edit distance or semantic similarity between the query key and the entity alias attribute in the graph is calculated. The requirement information extraction module selects graph nodes with similarity scores exceeding a preset reliability threshold as target entities, replacing the original text fragment with a unique globally unique identifier in the graph, thus completing the mapping from non-standard text to standard knowledge entities.

[0051] S206 Dependency Syntax Analysis and Constraint Relationship Binding. To determine the logical relationship between an entity and its corresponding attribute value or constraint condition, the requirement information extraction module calls the dependency parser to perform structural parsing on sentences containing entities. The requirement information extraction module constructs a dependency syntax tree for the sentence, identifying the dominance and subordinate relationships between words. Using the entity nodes or indicator nodes identified in step S205 as core words, the requirement information extraction module searches for their modifiers or complements along the dependency path. When a numerical descriptive or comparative word is identified to have a noun-head relationship or subject-verb relationship with the core word, the requirement information extraction module extracts and combines the core word, logical operators, and numerical values ​​to form a semantic triple in the form of subject, relation, and object.

[0052] S207. Structured Reorganization of Complex Logic. For parallel structures or negation logic present in the text, the requirement information extraction module performs logic reorganization. When dependency analysis detects that a parallel relation marker connects two entities sharing the same constraint, the requirement information extraction module copies and distributes this constraint, forming independent triples with each of the two entities. When a negation word modifies a relation word, the requirement information extraction module reverses the extracted logical operators. After the above processing, the requirement information extraction module outputs a defined set of software entities and a series of standardized constraint triples, which serve as input data for subsequent virtual configuration generation.

[0053] After the requirement information extraction module completes entity recognition and triple parsing, in order to transform the performance indicators of the text description into a mathematical expression that can be processed by the subsequent calculation module, the requirement information extraction module continues to execute the vectorization mapping procedure for non-functional requirements. This procedure specifically includes the following sub-steps: S208. Establish a performance indicator dimension space. The requirement information extraction module reads predefined performance indicator metadata from the knowledge base maintenance module and constructs a... A non-functional requirement feature vector. Each dimension of this vector corresponds to a specific performance or quality attribute, including but not limited to: transactions per second, average response latency, system availability percentage, recovery time target, and number of concurrent users. The requirement information extraction module semantically matches the relations or objects in each parsed requirement triple with the dimension ID of this space to determine the indicator dimension to which the current requirement description belongs.

[0054] S209. Perform numerical extraction and unit normalization. For requirement triples containing explicit numerical descriptions, the requirement information extraction module uses regular expressions to extract the numerical and unit components. The module then calls unit conversion logic to uniformly convert physical quantities of different dimensions into the system's preset standard basic units. For example, 500 milliseconds or 0.5 seconds are uniformly converted to the numerical value 0.5 seconds; the 99.99% availability description is converted to the numerical value 0.9999. The requirement information extraction module fills the normalized values ​​into the corresponding dimension positions in the feature space.

[0055] S210. Quantitative Mapping of Qualitative Descriptions. For requirement triplets containing only qualitative descriptions without specific numerical values, the requirement information extraction module performs quantitative deduction based on benchmark data. The requirement information extraction module uses the qualitative description text as an index to query the business scenario benchmark table in the knowledge base maintenance module. This benchmark table stores quantitative thresholds corresponding to different business levels. If the standard value of the RTO indicator corresponding to financial-grade disaster recovery is less than or equal to 30 seconds, the requirement information extraction module fills the value 30 into the dimension corresponding to the RTO and marks the comparison operator as <=. This step ensures that ambiguous natural language descriptions can be transformed into definite boundary constraints.

[0056] S211. Construct a non-functional requirement feature vector. After the above processing, the requirement information extraction module aggregates the values ​​of all dimensions into a single feature vector. dimensional non-functional requirement feature vector For dimensions not mentioned in the requirement text, the requirement information extraction module fills them with default values ​​or marks them as unconstrained. Simultaneously, the requirement information extraction module generates a [database name missing]. Same-dimensional weight vector The requirement information extraction module assigns higher weights to corresponding dimensions based on the emphasized words in the requirement description, which are then used for weighted calculations when determining the matching score during the configuration generation phase. and weight vector Output to the non-functional requirement configuration mapping and virtual verification module.

[0057] The non-functional requirement configuration mapping and virtual verification module receives the set of explicit constraint entities output by the requirement information extraction module. and non-functional requirement feature vector Next, the configuration generation phase in step S3 is executed. This phase aims to establish a logical mapping from textual requirements to technical implementation, and to define configuration mapping functions for non-functional requirements and virtual verification modules. The demand characteristics of the target object are transformed into a minimum virtual configuration list that meets the conditions. The mathematical model for this mapping process is expressed as: ;in, This indicates the system's recommended software stack combination. This represents the underlying hardware specifications required to meet the calculated performance indicators. Based on this function model, the process specifically includes the following sub-steps: S301, Building Software Stack Assemblies The non-functional requirement configuration mapping and virtual verification module prioritizes processing the set of explicit constraint entities in the input parameters. .like It contains explicit version constraints, and the module directly locks it into the software stack composition. The core components of [the system / mechanism]. For For missing essential components, the module executes default recommendation logic, queries the recommendation strategy table in the knowledge base, and selects the optimal compatible component version to fill in the missing components based on current market share data in the financial industry or the latest information technology innovation catalog, thereby constructing a complete software stack.

[0058] S302, Calculate underlying hardware specifications Non-functional requirement configuration mapping and virtual verification modules are based on configuration mapping functions. The definition utilizes non-functional requirement feature vectors Derivation of hardware specifications. Module reads non-functional requirement feature vectors. The module retrieves quantitative metrics (such as concurrent users and TPS target) and calls the performance benchmark data table in the knowledge base maintenance module. This data table records the theoretical peak performance under different CPU architectures, core counts, and memory capacity combinations. The module uses linear interpolation or piecewise matching to calculate the hardware specifications that meet the requirements and minimize resource overhead, determining the underlying hardware specification parameters, including the number of CPU cores, clock speed, and memory size. This serves as the standard resource configuration for a single node.

[0059] S303, High Availability Architecture Topology Extension. After determining the single-node configuration, the non-functional requirement configuration mapping and virtual verification module checks the non-functional requirement feature vector. The availability or recovery time target dimension. If the requirement metric demands system availability to be higher than the preset single-machine threshold, or includes architectural keywords such as dual-active, the module will adjust the availability based on the preset architecture template library. and Expand the topology dimension. For example, the module generates a two-node topology with a master node and a backup node, and automatically adds the required load balancer components or virtual IP resources; or calculates the required number of cluster nodes based on the number of concurrent users and updates the node topology structure in the configuration list.

[0060] S304, Instantiate the virtual configuration list After the calculations and combinations described above, the non-functional requirement configuration mapping and virtual verification module will determine the software stack combination. Hardware specifications Encapsulation is performed to generate the final virtual configuration manifest. This list details the component's globally unique identifier, software version number, hardware specifications, and network topology role. The module serializes this list into a structured data stream, which is then used as the basis for subsequent synthesis and verification functions. The input baseline.

[0061] In the non-functional requirement configuration mapping and virtual verification module, a virtual configuration list is generated. Subsequently, to ensure the technical feasibility and regulatory compliance of this configuration, the non-functional requirement configuration mapping and virtual verification module continues to execute the virtual verification procedure in step S3. This procedure defines a comprehensive verification function. Based on the aforementioned component compatibility matrix The virtual configuration manifest is double-checked using the set of regulatory compliance constraints in the knowledge base. The mathematical model for this verification logic is as follows: The process specifically includes the following sub-steps: S305. Perform internal compatibility checks based on matrix operations. The non-functional requirement configuration mapping and virtual verification module extracts the software stack composition from the virtual configuration manifest. The process involves parsing out all software component nodes contained in the combination. The non-functional requirement configuration mapping and virtual verification module uses a full permutation and combination algorithm or a double loop traversal logic to generate all pairwise combinations of components within the software stack. For each generated component combination pair, the module is defined by the components. and The index values ​​in the global index mapping table are used as row and column coordinates to directly query the component compatibility matrix residing in memory. The module reads the corresponding element values ​​from the matrix. If any matrix element returned by the query has a value of 0, it indicates that the component... and There are hard mutual exclusions or implicit conflicts caused by dependency propagation, and the non-functional requirement configuration mapping and virtual verification module determine the internal compatibility verification function. The return value is false, and the specific conflicting component pair ID and conflict type are recorded; the module determines the internal compatibility check result to be true only when the corresponding matrix element values ​​of all component pairs are 1.

[0062] S306. Perform rule-based external compliance verification. The non-functional requirement configuration mapping and virtual verification module loads the current set of regulatory compliance constraints from the knowledge base maintenance module. This constraint set transforms industry standards into computer-processable logical rules, including but not limited to the localization rate of core components, support for national cryptographic algorithms, and supply chain security ratings. For each configuration item, its attribute data is compared item by item with compliance constraint rules. Regarding domestic production requirements, the module checks whether the CPU architecture attribute in the hardware specifications belongs to the predefined whitelist of domestically controllable chip architectures; regarding encryption compliance, the module checks whether the security feature attributes of the database components contain SM4 / SM3 algorithm tags. If any attribute in the configuration list fails to match the rules, the non-functional requirement configuration mapping and virtual verification module determines the external compliance verification function. The return value is false, and the non-compliant configuration item and the corresponding regulatory clause ID are marked; the module determines the external compliance verification result to be true only when all constraints are met.

[0063] S307. Comprehensive Judgment and Verification Result Separation. The non-functional requirement configuration mapping and virtual verification module performs a logical AND operation on the output results of steps S305 and S306. If the operation result is true, meaning both internal compatibility and external compliance are passed, the module will update the current virtual configuration list. The configuration is marked as valid and passed to the documentation generation and optimization module for further processing. If the result is false, the module generates a verification failure report containing conflict details. This report identifies the specific mutually exclusive component pair or violating parameter that caused the verification failure and uses this report as input data to trigger a subsequent automatic correction mechanism.

[0064] When the overall judgment result of virtual verification step S307 is false, the non-functional requirement configuration mapping and virtual verification module do not directly terminate the process, but instead trigger the automatic correction mechanism in step S3. This mechanism aims to find alternative components that meet the constraints through an iterative search algorithm, eliminating conflicting items in the configuration list. This process specifically includes the following sub-steps: S308. Calculation and locking of conflict gradients. Non-functional requirement configuration mapping and virtual verification module parsing of verification failure reports, extracting the set of conflicting components causing verification failures. Mutually exclusive component pairs returned by the component compatibility matrix. Or, non-compliant components returned by external compliance checks. The module calculates the replacement cost gradient for each involved component. This gradient value is determined based on the dependency density and business weight of the component in the domain knowledge graph. Specifically, the module queries the in-degree and out-degree of component nodes; the more complex the dependencies of a component, the higher its replacement cost gradient; the fewer the dependencies, the lower its replacement cost gradient. The non-functional requirement configuration mapping and virtual verification module compares the gradient values ​​of each element in the conflicting component set and locks the component with the smallest gradient value as the target component to be replaced, in order to minimize the impact of the change on the overall system architecture.

[0065] S309. Search and Pre-screening of Alternative Components. After identifying the target component, the Non-functional Requirement Configuration Mapping and Virtual Verification module uses the entity type and functional label of the target component as index keys to perform a search for similar nodes in the domain knowledge graph. The module traverses synonym or membership edges in the graph to obtain a set of candidate alternative components. The Non-functional Requirement Configuration Mapping and Virtual Verification module performs rule-based pre-screening on this set, eliminating those that do not meet the non-functional requirement feature vectors. Candidate nodes for medium hard indicators are selected to generate a valid candidate set.

[0066] S310. Decision-making based on the least conflicting path. The non-functional requirement configuration mapping and virtual verification module performs virtual trial calculations for each candidate component in the valid candidate set. The module temporarily replaces the candidate component with the current virtual configuration list. And quickly query the component compatibility matrix based on the row and column where the candidate component is located. The compatibility score between the component and other existing components in the list is calculated. This score is defined as the proportion of the number of 1s at corresponding positions in the matrix to the total number of interactive components. The non-functional requirement configuration mapping and virtual verification module selects the candidate component with the highest compatibility score and the performance parameters closest to the original target component as the final correction and replacement item.

[0067] S311. Configuration Update and Closed-Loop Revalidation. The non-functional requirement configuration mapping and virtual validation module updates the virtual configuration manifest using the selected correction replacements. The module updates the corresponding hardware specifications. It increments the correction count counter and checks if the counter exceeds a preset convergence threshold to prevent entering an infinite loop. If the threshold is not exceeded, the module updates the virtual configuration list. Re-enter into the comprehensive verification function The module recursively executes steps S305 to S307 until verification passes or the maximum number of attempts is reached. If verification still fails after reaching the maximum number of attempts, the module outputs a final infeasibility report and the constraint conflict path that caused the deadlock.

[0068] To address the frequent business requirement adjustments and underlying software version iterations in financial information technology innovation projects, the dynamic requirement change analysis module executes the change capture and location procedure in step S4. This procedure aims to monitor external inputs and changes in the internal knowledge base in real time, and transform unstructured change events into specific location points on a graph. Specifically, it includes the following sub-steps: S401. Establish a dual-channel event listening mechanism. The dynamic demand change analysis module initializes two independent event listening interfaces, which are used to monitor changes on the demand side and the supply side, respectively.

[0069] The first channel is a requirement change listener, which maintains a persistent connection with the output port of the requirement information extraction module. When a user submits new requirement text or modifies an existing requirement document, the listener captures this operation and obtains the regenerated non-functional requirement feature vector. and new explicit constraint entity sets .

[0070] The second channel is a knowledge base update listener, which subscribes to the change logs or message queue topics of the knowledge base maintenance module. When a software component node in the domain knowledge graph undergoes an attribute change (such as the release of a new version patch to fix a vulnerability) or a relationship change (such as a component being marked as no longer maintained), the listener captures an event message containing the changed component ID and the change type. Regarding the specific implementation technology of the message queue, those skilled in the art can use middleware such as Kafka or RabbitMQ, which are well-known technologies and will not be elaborated upon here.

[0071] S402. Perform differential feature extraction on the demand side. When the first channel captures a requirement change, the dynamic requirement change analysis module loads the non-functional requirement feature vector from the previous version in the system cache. With explicit constraint entity set The module executes the differential calculation logic: First, calculate the Euclidean or Manhattan distance between the old and new feature vectors, or compare the vector element values ​​dimension by dimension. If the first feature vector is found to be... When the value of a dimension's metric changes (e.g., TPS changes from 10000 to 15000), the module marks that dimension as a non-functional metric change point.

[0072] Secondly, the difference between the old and new entity sets is compared. If a new component entity is added to the set or an existing component entity is removed, the module marks the relevant component UUID as the entity constraint change point.

[0073] The module maps the identified change points to the current virtual configuration manifest. The specific configuration items in the document are defined, and these configuration items are defined as the source nodes for the changes.

[0074] S403. Perform supply-side knowledge association mapping. When the second channel captures a knowledge base change event, the dynamic demand change analysis module parses the globally unique identifier of the changed component in the event message. The module iterates through the list of virtual configurations that are currently in effect or pending verification. The module checks if the list contains a configuration item with the same UUID as the changed component. If no match is found, it means the knowledge base update does not affect the current system configuration, and the module ignores the event. If a match is found, the module locates the configuration item in the configuration list and marks its corresponding graph node as either dirty or a change source node. For example, if the knowledge base notifies that OpenSSL 1.1.1 has a high-risk vulnerability and recommends an upgrade, the module locates all middleware nodes that depend on this library in the configuration list and marks them as affected sources.

[0075] S404. Instantiate the change root set. After processing in step S402 or S403, the dynamic requirement change analysis module generates a change root set containing all change source nodes. Each element in this collection contains not only the node's ID but also the type of the changed attribute. The module will modify the root collection. As the initial input, it is passed to the subsequent dependency propagation algorithm to calculate the ripple effect of the change on the entire system.

[0076] The dynamic requirements change analysis module identified the root set of changes. Subsequently, to quantify the potential impact of local changes on the overall system, the module executes the ripple effect propagation analysis procedure in step S4. This procedure, based on the breadth-first search algorithm in graph theory and a predefined dependency coupling model, calculates the propagation and attenuation process of change risk along the component dependency chain, specifically including the following sub-steps: S405. Initialize the propagation queue and influence matrix. The dynamic requirement change analysis module creates a first-in-first-out propagation queue. And will change the root set All change source nodes are pushed into this queue. Simultaneously, the module constructs a node influence mapping table in memory. The initial influence weight of all source nodes in the queue is set to 1.0, representing the deterministic probability that the change event occurs at the source. To prevent infinite loops in the circular dependency structure of the graph, the module initializes a set of visited nodes. And mark the source node as visited.

[0077] S406. Perform a reverse traversal of the dependency relationships. The dynamic requirement change analysis module enters the loop processing logic, as long as the propagation queue... Not empty, meaning a currently processed node is popped from the head of the queue. The module is... The domain knowledge graph built in the knowledge base maintenance module serves as the retrieval anchor. The module performs a reverse search operation. Specifically, it queries all pointers to... directed edges In graph semantics, these edges represent logical relationships of dependency, invocation, or execution. The module uses this operation to obtain the set of all upstream parent nodes that directly depend on the current node. .

[0078] S407. Calculate the coupling strength and propagation weights. For each parent node obtained in step S406... The dynamic demand change analysis module calculates from Transmit to The module first reads the coupling type field from the edge attributes connecting the two edges, and assigns a basic attenuation coefficient according to a preset coupling strength table. If the coupling type is binary static linking, kernel-level module loading, or ABI interface dependency, the module will... Setting it to 1.0 indicates a strong coupling relationship, where downstream changes will be propagated upstream without loss; if the coupling type is a RESTful API call, message queue decoupling, or loose plugin interface, the module will... Values ​​between 0.1 and 0.8 represent weak coupling, where changes are shielded by the interface adaptation layer. The module then uses the formula... Calculate the cumulative influence weight of the parent node, where For the current node in The weight values ​​in the data.

[0079] S408, Threshold Determination and Cascading Triggering. The Dynamic Requirement Change Analysis module will calculate the influence weight of the parent node. Compared with the system's preset security threshold Compare. If A value exceeding this threshold indicates that downstream changes pose a substantial risk of failure to the parent node (e.g., a major version change in the database protocol renders the JDBC driver unavailable, leading to application service startup failure). The module will... The status is marked as potentially failed, update The weight record in the data, and will Push into the propagation queue The tail end, to continue triggering the next level of propagation analysis. If If the value is less than or equal to this threshold, it indicates that the impact of the change has been effectively isolated or attenuated at the current level. The module then stops the subsequent propagation along this branch path and does not... Add to the queue. The module repeats steps S406 to S408 until the queue is propagated. If the value is empty, then the final set of all affected nodes is determined, i.e., the influence domain.

[0080] After the dynamic requirement change analysis module determines the set of affected nodes using the ripple effect propagation algorithm, to avoid redundant recalculation of the full system configuration, the module executes the local re-verification procedure in step S4. This procedure aims to lock in the minimum re-verification subset and perform compatibility and compliance checks only on this subset, thereby reducing the computational complexity from exponential to linear. Specifically, it includes the following sub-steps: S409. Construct the minimum re-verification subset. The dynamic requirement change analysis module extracts all nodes marked as potential failures or change sources from the previous stage and defines them as a dirty node set. For effective compatibility verification, the module needs to consider not only the dirty nodes themselves but also context nodes that have direct constraints with them. The module iterates through each element in the dirty node set and queries the component compatibility matrix. The index identifies all neighboring nodes that have a non-zero value association with the dirty node in the matrix (i.e., a dependency or mutual exclusion relationship). The dynamic requirement change analysis module takes the union of the dirty node set and the neighbor node set, and then uses the current virtual configuration list... Extract the configuration items containing these nodes to form a separate minimal re-verification subset. .

[0081] S410, Perform incremental compatibility and compliance scans. The dynamic requirements change analysis module targets the minimum re-verification subset. Call the comprehensive verification function When performing internal compatibility checks, the module does not scan the entire query component compatibility matrix. Instead, only extract The components involved are arranged in rows and columns to construct a dynamic submatrix. The module checks if there are any elements with a value of 0 in the submatrix to determine whether the changed component has broken existing compatibility constraints (e.g., whether the new version of the middleware no longer supports the original operating system kernel). Simultaneously, when performing external compliance checks, the module only loads regulatory rules related to the changed attributes (e.g., if the change is triggered by an encryption algorithm upgrade, only encryption compliance clauses are checked). Targeted matching is performed on the attributes in the [database name].

[0082] S411, Decision on merging and rolling back verification results. The dynamic requirements change analysis module analyzes the output of step S410. If the minimum re-verification subset... After passing all checks, the module reverse-engineers the component states and parameters in that subset into the virtual configuration manifest. In the process, the system's major version number is updated, and the change log is marked as committed. If verification fails (e.g., an instruction set conflict is found between the new patch and older hardware), the module not only intercepts the change request but also triggers a rollback mechanism, discarding the changes. The module maintains a temporary state, preserving the previous stable version of the global configuration manifest. Simultaneously, it uses the conflicting paths that caused the validation failure as parameters to automatically invoke the aforementioned automatic correction mechanism, attempting to find alternative solutions locally until a new solution is found that both meets the change requirements and passes local validation.

[0083] The virtual configuration list is completed in the non-functional requirement configuration mapping and virtual verification module. After the verification or dynamic requirement change analysis module confirms the impact domain of the change, the document generation and optimization module initiates the template assembly stage in step S5. This stage aims to transform discrete technical parameters and verification results into a document skeleton that conforms to financial industry standards. Through structured template definition and dynamic loading mechanisms, it achieves adaptive adjustment of the document structure, specifically including the following sub-steps: S501. Construct a metadata-based document object model. The document generation and optimization module maintains a hierarchical document template library. Unlike traditional static text files, each template in this library is defined as a programmable document object model. The module decomposes documents into four levels of structured objects: chapters, sections, paragraphs, and atomic data blocks. Each object node contains, but is not limited to, the following metadata attributes: unique identifier, display condition logic, data binding path, and style rendering rules. For example, the high-availability architecture design chapter object is configured to only display non-functional requirement feature vectors. The template will only be activated and loaded when its availability index is greater than 99.95%. For the template storage format, those skilled in the art can use XML or JSON Schema for serialization and storage, which will not be elaborated upon here.

[0084] S502, Execute a context-aware template matching strategy. The document generation and optimization module reads the project metadata output by the requirements information extraction module and the current virtual configuration list. The module runs its built-in rule engine, comparing this contextual information with matching rules in the template library. The rule engine uses decision tree logic: first, it determines the top-level directory structure of the document based on the project type; second, it traverses the component types in the virtual configuration manifest. If the manifest contains a distributed database component, the rule engine automatically mounts a distributed data sharding strategy sub-template under the technical architecture node of the baseline template; if the manifest contains national cryptographic hardware components, the engine mounts an encryption machine deployment scheme sub-template. Through this step, the module generates a dynamic directory tree containing all necessary chapter IDs.

[0085] S503. Instantiation and Structure Control of the Document Skeleton. The document generation and optimization module loads the corresponding document object nodes from the storage medium based on the dynamic directory tree generated in step S502, and assembles them into a complete document skeleton tree in memory. During this process, the module parses and executes the control flow tags in the object nodes. For loop tags, the module uses the virtual configuration manifest... Number of nodes The module automatically copies and expands the corresponding table rows or paragraph objects (for example, generating a separate configuration parameter column for each server in the cluster); for conditional tags, the module retains or prunes specific document branches based on the aforementioned verification result status. Finally, the module constructs a document instance in memory to be populated with data. This instance already has a complete logical structure and awaits subsequent steps to inject specific technical parameters and descriptive text into it.

[0086] After the document generation and optimization module completes the instantiation of the document skeleton, in order to transform the abstract technical data into final document content with business semantics, the module executes the content filling stage in step S5. This stage adopts a hybrid strategy combining deterministic data backfilling and generative text construction, specifically including the following sub-steps: S504. Perform precise backfilling of structured parameters. The document generation and optimization module traverses the instantiated document object model tree in memory, locating all leaf elements marked as data-bound nodes. These nodes correspond to table cells, list items, or key indicator fields in the document. The module builds a virtual configuration list... and non-functional requirement feature vector The key-value mapping index to the document template tags. The module uses this index to... The component version number, hardware specifications, network topology roles, and other technical attributes are precisely written into the corresponding software configuration suggestion table and hardware resource planning table in the document. Simultaneously, the module will... The performance constraint values ​​are entered into the non-functional requirement response table. During this process, the module automatically calls the embedded formatting function to perform unit conversions and precision truncation of the values, ensuring that the format of the entered data conforms to the specifications of financial documents.

[0087] S505. Perform descriptive text generation based on the domain model. For unstructured descriptive paragraphs in the document, such as the overall architecture design description, selection basis, and construction goals, the document generation and optimization module calls a pre-trained natural language generation model for the financial information technology innovation domain. The module constructs a structured hint containing contextual information, which consists of three parts: the set of explicit constraint entities in the original requirements. The currently generated virtual configuration list The module inputs the key features and semantic tags of the current paragraph into the generative model. The model uses an attention mechanism to focus on key technical terms in the input and combines this with the probability distribution of a pre-learned financial document corpus to generate coherent natural language paragraphs. For example, based on the primary / backup database and load balancer in the configuration list, the model automatically generates text blocks describing that this solution adopts a dual-machine hot standby architecture, using load balancing equipment to distribute traffic and eliminate the risk of single-point failure. For the specific architecture of the natural language generation model, those skilled in the art can use a deep neural network structure based on a Transformer decoder, which is a well-known technology in the field and will not be elaborated upon here.

[0088] S506. Perform document style migration and standardization constraints. To ensure that the machine-generated text conforms to the strict writing standards of the financial industry, the document generation and optimization module performs style post-processing on the text blocks generated in step S505. The module loads the financial information technology innovation document style constraint vector and the industry terminology standard dictionary. The module performs lexical scanning on the generated text, forcibly replacing non-standard terms (e.g., replacing colloquial terms like "downtime" with "service interruption," and "patch" with "software patch"). Simultaneously, the module uses the style constraint vector to fine-tune the sentence structure of the text, increasing the frequency of passive voice usage and eliminating first-person subjective descriptions to ensure that the final output document presents objectivity, rigor, and consistency in language style. After completing the above processing, the module inserts the standardized text blocks into the corresponding paragraph positions in the document skeleton, completing the mixed assembly of content.

[0089] After the document generation and optimization module completes the mixing and assembly of text content, to prevent machine illusions or data referencing biases that may occur during natural language generation and to ensure the rigor of the delivered document, the module executes the consistency verification procedure in step S5. This procedure treats the document instance to be output as the object to be tested, and through reverse parsing and rule constraints, performs closed-loop verification of the data consistency and logical self-consistency within the document. Specifically, it includes the following sub-steps: S507. Perform reverse data extraction and comparison of unstructured text. The document generation and optimization module loads a predefined set of key indicator extraction rules, which includes regular expression patterns and named entity recognition models for high-frequency technical parameters in financial documents. The module scans the descriptive text paragraphs generated in step S505, identifies and extracts the quantitative terms, version number strings, and technical terms contained therein. The document generation and optimization module then compares these values ​​extracted from the natural language text with the structured virtual configuration list. The module compares the original data one by one. If the values ​​in the text description are inconsistent with the settings in the configuration list, or if the component version number mentioned in the text conflicts with the version number in the BOM table, the module marks the paragraph as a data drift risk point and records the specific location and difference value of the drift.

[0090] S508. Perform logical cross-checks and completeness checks between paragraphs. The document generation and optimization module constructs a logical dependency graph within the document to check for semantic inconsistencies between different chapters. Specifically, the module verifies whether the topology described in the overall architecture design chapter has corresponding physical nodes in the hardware resource configuration chapter. Simultaneously, the module performs completeness checks, traversing the set of explicit constraint entities. and non-functional requirement feature vector All key metrics are checked to ensure they have corresponding response entries in the requirements response section of the final document. If logical inconsistencies or missing response entries are found, the module generates a validation failure log, indicating the specific section location and logical breakpoint.

[0091] S509. Document Rendering Output and Exception Handling. The document generation and optimization module integrates the verification results of steps S507 and S508. If the document instance passes all consistency checks, the module calls the document rendering engine, reads the document object model tree in memory, and serializes it into the final target format file. During rendering, the module automatically adds a digital watermark containing the project number and timestamp to the document header, footer, or background based on the project's security level. If the verification fails, the module intercepts the output process, feeds back the verification failure log to the hybrid text generation strategy, triggers local regeneration logic, reconstructs the warning words for paragraphs marked as risk points, and performs text generation until the verification passes or the retry limit is reached. For the specific implementation of the document rendering engine, those skilled in the art can use OpenXMLSDK or similar library file operation tools, which are well-known technologies in the field and will not be described in detail here.

[0092] To verify the collaborative working effect of the aforementioned functional modules in a real-world project, all the technical features are linked together. Taking a localization transformation project of a bank's core transaction system as an example, this paper illustrates the entire process from unstructured requirement input to compliant technical solution document output. This embodiment demonstrates how the system handles complex configuration generation and verification tasks under high concurrency, high availability, and strict compliance constraints. The specific process includes the following sub-steps: S601. Structured Analysis and Vector Space Mapping of Requirements. The requirement information extraction module receives project requirement text input by the user: The core transaction system must support an average daily transaction volume of 50 million transactions, with a peak TPS of no less than 20,000, an RPO of 0, and the underlying infrastructure must fully comply with the third phase of the domestic IT innovation acceptance standards. The database adopts a domestic distributed architecture. The requirement information extraction module processes this text and identifies the set of key entities. It includes the core trading system, distributed database, and infrastructure. Simultaneously, the module maps non-functional requirements to non-functional requirement feature vectors. The performance dimension component is assigned a value of 20,000, the availability dimension component corresponds to a strong consistency constraint of RPO=0, and the compliance dimension is marked as the third phase of domestic IT innovation / 100% domestic production.

[0093] S602, virtual configuration instantiation based on benchmark derivation. The non-functional requirement configuration mapping and virtual verification module will convert the non-functional requirement feature vectors... Input configuration mapping function The module queries the benchmark database to match a hardware specification baseline that meets the 20,000 TPS performance target, generating a hardware configuration list: compute nodes use 4-way Kunpeng 920 processors with 512GB DDR4 ECC memory; storage nodes use an all-flash array. Regarding software stack recommendations, based on entity constraints from domestic distributed databases, the module retrieves and locks OpenGauss Enterprise Edition or OceanBase as candidate components from the knowledge base, and automatically recommends KylinOS V10SP2 as the host operating system based on their operating system dependencies. This generates an initial virtual configuration list. .

[0094] S603, Multi-dimensional Constraint Conflict Detection and Closed-Loop Correction. Non-functional requirement configurable mapping and virtual verification module. Perform comprehensive verification. Perform internal compatibility checks. At that time, the module query component compatibility matrix The initial configuration revealed that the WebLogic middleware and the target operating system KylinOSV10 had an intersection value of 0 in the matrix, indicating an unauthorized compliance risk. The module triggered an automatic correction mechanism, identifying the similar domestic middleware TongWebV7.0 based on an alternative component search algorithm. This component had a compatibility score of 1 with the Kylin system and possessed domestic IT innovation certification, and the module performed a replacement operation. External compliance verification was then performed. When the module detects the constraint RPO=0, it automatically checks the database configuration parameters, forces the default asynchronous commit parameter synchronizeous_commit to be changed to on (synchronous commit), and adds metadata tags for the same-city active-active deployment architecture to ensure strong data consistency.

[0095] S604, Dynamic Change Propagation and Local Recalculation. Assume that during the solution generation process, an external regulatory library releases a new security bulletin indicating a high-risk vulnerability in OpenSSH 8.0. The listener of the dynamic requirement change analysis module captures this event and uses the ripple effect propagation algorithm to analyze the dependency chain, discovering that the current KylinOSV10SP2 integrates this version of OpenSSH by default. The module identifies this operating system node as the source of risk and calculates the impact domain to cover all compute nodes. The module triggers local re-verification, automatically retrieving patch information, updating the operating system version number in the configuration list to KylinOSV10SP3 with integrated patches, and performing incremental scanning only on the interface compatibility of the affected operating system, database, and middleware. After confirming that everything is correct, the main configuration is updated.

[0096] S605, Automated Assembly and Output of Full-Element Documentation. The document generation and optimization module loads the standard template of the core trading system's technical specifications. In the structured parameter backfilling stage, the module automatically fills the hardware and software configuration list table with the Kunpeng 920, TongWeb V7.0, OpenGauss, and specific parameter configurations determined in steps S602 and S603. In the mixed text generation stage, based on the local dual-active metadata, the module calls a natural language generation model to construct the high-availability architecture design description section, generating a description: This system adopts a two-site, three-center deployment architecture, with a database configuration of one master and three backups, ensuring a zero RPO through strong synchronous replication technology. Finally, the module performs a consistency check; after verifying that the generated text description and configuration table data are correct, it renders and outputs the final PDF format technical specifications document.

Claims

1. An automated coding method oriented towards requirements analysis, characterized in that, Includes the following steps: S1. Knowledge Foundation Initialization and Construction: Construct a domain knowledge graph containing software components, hardware specifications, and regulatory rules, and derive and generate a component compatibility matrix through logical operations based on the mutual exclusion and dependency relationships in the domain knowledge graph. S2. Structured Extraction of Requirement Information: Receive unstructured requirement text and use natural language processing algorithms to transform the unstructured requirement text into structured features containing software entity sets, hardware constraints, and non-functional requirement index vectors. S3. Virtual Configuration Mapping and Initial Verification: Based on the structured features and the domain knowledge graph, generate a virtual configuration list containing software stack combinations and hardware specification parameters; S4. Configuration Conflict Detection and Correction: Query the component compatibility matrix and the regulatory rules in the domain knowledge graph, perform internal compatibility calculations and external compliance verifications on the virtual configuration list, and automatically retrieve alternative components when compatibility conflicts and compliance violations are detected, update the virtual configuration list and re-execute the detection until a verified configuration scheme is generated. S5. Dynamic Change Impact Analysis: Monitor update events of knowledge base data and change events of requirement input, calculate the change impact domain based on the dependencies in the domain knowledge graph through a weight propagation algorithm, and trigger local re-verification of the affected area; S6. Document Generation and Consistency Output: Fill the verified configuration scheme and non-functional requirement indicators into the document template stored in the knowledge base, generate descriptive text using a natural language generation algorithm, and output the requirement analysis document after performing a numerical consistency check.

2. The automated programming method for requirements analysis as described in claim 1, characterized in that, In step S1, based on the mutual exclusion and dependency relationships in the domain knowledge graph, a component compatibility matrix is ​​derived and generated through logical operations. Specifically, generating the component compatibility matrix includes: Traverse the mutual exclusion relationships in the domain knowledge graph and mark the coordinate positions of component pairs with direct mutual exclusion relationships in the component compatibility matrix as prohibited markers. Traverse the dependencies in the domain knowledge graph. When the first component depends on the second component, obtain the row vector corresponding to the second component in the component compatibility matrix. Merge the prohibition flags in the row vector corresponding to the second component into the row vector corresponding to the first component through a logical AND operation, thereby passing the constraints of the second component to the first component along the dependency chain.

3. The automated programming method for requirements analysis as described in claim 1, characterized in that, In step S2, the unstructured requirement text is transformed into structured features using a natural language processing algorithm. Specifically, the transformation of the unstructured requirement text into structured features includes: The unstructured requirement text is sequence labeled using a composite network structure based on BERT-BiLSTM-CRF. The probability distribution of entity boundary labels corresponding to each character in the text sequence is calculated by operating the Softmax function of the network output layer, and the optimal label sequence is obtained by decoding according to the Viterbi algorithm. The identified entity referential text fragments are input into the BERT model to obtain the semantic embedding vector of the entity referential text fragments and the semantic embedding vectors of each standard entity name stored in the domain knowledge graph. The cosine similarity score between the semantic embedding vector of the entity referential text fragments and the semantic embedding vectors of each standard entity name is calculated by dividing the dot product of the two vectors by the product of the L2 norms of the two vectors. The standard knowledge entity with the highest score is taken as the mapping result. The dependency parsing algorithm is used to parse the dependency paths between entities and indicators, and the text description is transformed into semantic triples containing numerical values ​​and logical operators.

4. The automated programming method for requirements analysis as described in claim 1, characterized in that, Step S2 further includes a step of vectorizing and mapping non-functional requirements, wherein the vectorization and mapping step specifically includes: The qualitative description contained in the text is used as the index key value. A matching query is performed in the business scenario benchmark table stored in the knowledge base to obtain the corresponding numerical range as the determined boundary constraint condition. The boundary constraints obtained through quantitative deduction are normalized and then concatenated according to the dimensional order of the non-functional requirement indicators to construct a non-functional requirement feature vector.

5. The automated programming method for requirements analysis as described in claim 1, characterized in that, In step S4, when compatibility conflicts and compliance violations are detected, alternative components are automatically retrieved, and the virtual configuration list is updated. Updating the virtual configuration list specifically includes: The set of conflicting components that cause verification failure is analyzed. The topological connectivity of each component in the set of conflicting components is quantified by statistically summing the in-degree and out-degree of each component in the domain knowledge graph. The quantified topological connectivity is then used as the replacement cost gradient. The component with the smallest replacement cost gradient is identified as the target component to be replaced. Using the entity type and functional tags of the target component as indexes, a set of candidate alternative components that meet the non-functional requirement indicators are retrieved from the domain knowledge graph. The candidate alternative components are placed into the virtual environment one by one. The compatibility score between the candidate alternative components and other components in the list is calculated by querying the component compatibility matrix. The candidate component with the highest score is selected as the correction replacement item.

6. The automated programming method for requirements analysis as described in claim 1, characterized in that, In step S5, the change impact domain is calculated based on the dependencies in the domain knowledge graph using a weight propagation algorithm. The calculation of the change impact domain specifically includes: Locate the change source node in the domain knowledge graph and set the initial influence weight value of the change source node to the maximum value; Traverse backwards along the dependency edges in the domain knowledge graph to obtain the upstream parent node of the current node; The propagation weight value passed to the upstream parent node is calculated by multiplying the influence weight value of the current node by the coupling strength coefficient stored on the dependency edge. If the propagation weight value is greater than the propagation threshold stored in the knowledge base, the current upstream parent node is added to the processing queue and the reverse traversal and weight calculation are continued to form a cascade calculation until the queue is empty, thereby determining the set of all affected nodes.

7. The automated programming method for requirements analysis as described in claim 6, characterized in that, The triggering of local re-verification of the affected area, specifically includes: Query the component compatibility matrix to obtain all affected nodes that have non-zero value associations with their neighbor nodes in the matrix; The affected nodes are merged with their neighboring nodes to construct a minimum re-verification subset; Compatibility logic checks and compliance rule matching are performed only on the component combinations within the minimum re-verification subset.

8. The automated programming method for requirements analysis as described in claim 1, characterized in that, In step S6, a numerical consistency check is performed, which specifically includes: Regular expression matching and dependency analysis are performed on the descriptive text generated by the natural language generation algorithm to extract the quantifiers and technical terms contained therein as the extracted dataset; The difference between the extracted dataset and the original values ​​in the verified configuration scheme is calculated by subtracting the values ​​from each dataset. Determine whether the difference is zero. If it is not zero, the consistency check is determined to have failed, and the local regeneration logic is triggered.

9. The automated programming method for requirements analysis as described in claim 1, characterized in that, Step S3, generating the virtual configuration manifest specifically includes: The non-functional requirement index vector is used as input, and the initial hardware specification parameters are calculated by the quantization mapping model stored in the knowledge base. Using the software entity set and the hardware specifications as input, a virtual configuration list containing the software stack topology and hardware deployment scheme is generated by querying the associations and deployment rules in the domain knowledge graph.

10. An automated writing system applied to the automated writing method for requirements analysis as described in any one of claims 1-9, characterized in that, include: The knowledge base maintenance module is used to construct a domain knowledge graph containing software components, hardware specifications, and regulatory rules, and to generate a component compatibility matrix through logical operations based on mutual exclusion and dependency relationships; the requirement information extraction module is configured to receive unstructured requirement text and use natural language processing algorithms to convert the unstructured requirement text into structured features. The non-functional requirement configuration mapping and virtual verification module is configured to generate a virtual configuration list based on the structured features and the domain knowledge graph, and to perform conflict detection and automatic correction on the virtual configuration list using the component compatibility matrix and regulatory specifications until a verified configuration scheme is generated. The dynamic requirement change analysis module is configured to monitor change events, calculate the change impact domain based on the domain knowledge graph using a weight propagation algorithm, and trigger the non-functional requirement configuration mapping and virtual verification module to perform local re-verification. The requirements analysis document generation and optimization module is configured to receive the verified configuration scheme, generate and optimize the requirements analysis document; The model selection and training module is configured to build, train, and update the semantic understanding model for the requirement information extraction module and the natural language generation model for the requirement analysis document generation and optimization module.

Images