Complex system demand identification and management method based on knowledge graph and thinking chain reasoning

Abstract

The invention relates to a knowledge graph and thinking chain reasoning-based complex system demand identification and management method. The method comprises the following steps of S1, constructing a system demand classification network model; s2, constructing a demand structured extraction model based on a thinking chain; and S3, constructing a general demand knowledge graph and a target graph, and complementing the target graph. Through fusion of the knowledge graph and the thinking chain reasoning technology, the problems that in the prior art, classification model precision is low, extraction model leak detection is high, and graph model universality is poor are solved, and the method is suitable for demand modeling in the fields of subways and high-end equipment.

Description

Technical Field

[0001] Specifically, this involves a method for constructing a complex system requirement identification and management model that integrates knowledge graph technology, thought chain reasoning mechanism and deep learning model. It is applicable to the automated classification, structured extraction and graph completion of requirements in fields such as subway engineering and high-end equipment. The core is to construct an integrated technical model to provide a reproducible model construction solution for requirement modeling of complex system design. Background Technology

[0002] As the functional complexity of complex systems (such as subway intelligent monitoring systems and high-end equipment control systems) increases, requirement texts become unstructured and semantically ambiguous. Existing requirements management technologies suffer from the following core defects at the model building level: 1. Insufficient semantic modeling in system requirement classification network models: Existing classification models mostly rely on keyword rules (such as "function" corresponding to functional requirements) or a single BERT model, without designing a temporal semantic modeling layer. They cannot handle the ambiguity of "action-entity" association in long texts (such as the semantic difference between "set" in physical requirements and functional requirements in "set emergency button"), resulting in low accuracy of classification models. Furthermore, there is no standardized model training process, making it difficult to reproduce the problem. 2. Structured extraction models lack reasoning mechanisms: Existing extraction models use rule-driven (regular matching "subject: XXX") or simple deep learning models (RoBERTa), without incorporating reasoning logic, and cannot parse nested semantics (such as the multi-subject association of "stations and tunnel sections should be equipped with automatic fire alarm systems"). The feature extraction has a high false negative rate and relies on large-scale manually labeled data, resulting in poor model versatility. 3. Limited universality and completion capabilities of knowledge graph construction: Existing knowledge graphs are mostly oriented towards specific scenarios, and their ontology structures are not uniform, making them difficult to reuse across different systems; moreover, existing methods lack the ability to identify "omitted requirements" and cannot effectively fill the gaps in requirements caused by insufficient experience or missing information during the design process. 4. Low model integration: The existing requirements classification, extraction, representation and completion are mostly independent steps, lacking integrated support, making it difficult to achieve a complete automated process from original document requirements to modeling and analysis.

[0003] Therefore, while existing research has attempted to incorporate Model-Based Systems Engineering (MBSE), thought chain reasoning, and natural language processing techniques, it has failed to effectively integrate the standardized requirements classification of systems engineering with the deep semantic understanding capabilities of artificial intelligence. This results in shortcomings in the intelligence, engineering, and automation levels of requirements management. Therefore, there is an urgent need for a solution for identifying and managing the requirements of complex systems that balances standardization, intelligence, and engineering. Summary of the Invention

[0004] This invention aims to address the technical problems of low accuracy in existing system requirement classification network models, lack of reasoning in structured extraction models, poor versatility of knowledge graph models, and weak overall model integration. It provides a method for constructing complex system requirement identification and management models based on knowledge graphs and thought chain reasoning. By designing an SRsNet classification model, a Manual-CoT extraction model, a knowledge graph completion model, and an overall integration scheme, the invention achieves standardized model construction and efficient application. The technical solution is as follows: A method for identifying and managing the requirements of complex systems based on knowledge graphs and thought chain reasoning includes the following steps: S1, Construction of the system requirement classification network model, the method is as follows: S11, a system modeling language standard based on systems engineering (SysML), divides complex system requirements into five categories: functional requirements, interface requirements, performance requirements, physical requirements, and design constraints. S12, preprocess the original requirement text; S13, Construct a system requirement classification network model that integrates a bidirectional encoder representation converter (BERT) model and a bidirectional long short-term memory network (Bi-LSTM); S14, the preprocessed requirement text is divided into a training set and a test set, the system requirement classification network model is trained and the requirement classification result is output; S2, a demand structure extraction model based on the mind chain is constructed using the following method: Based on the demand classification results obtained in S1, S21 constructs information extraction templates that are adapted to different types of demands. The information extraction templates include eight categories of elements: subject, attribute, object, behavior, function, value, principle, and condition. S22 introduces the Chain-of-Thought (CoT) reasoning mechanism and constructs Manual-CoT prompts; S23, input the demand classification results and Manual-CoT prompts into the large language model to verify the integrity of the output format constraint structure and obtain structured demand information; S3, construct a general requirements knowledge graph and a target graph, and complete the target graph.

[0005] Furthermore, the functional requirements, interface requirements, performance requirements, physical requirements, and design constraints in S11 are defined as follows: Functional requirements: Describe the core functions that the system should have; Interface requirements: Define the interaction methods between the system and external components; Performance requirements: Quantitative indicators that define the system's functionality; Physical requirements: Describe the physical properties of the system; Design constraints: Define the rules that the design must follow.

[0006] Furthermore, in S12, the preprocessing includes deleting chapter numbers and invalid tags, standardizing text format, and splicing context-related scattered content; processing of nested hierarchical requirement sub-items, splicing the content of the requirement sub-items with the main requirement text to ensure requirement context consistency; the original requirement text comes from technical documents in the field of complex system design, including industry standards and specifications, system design manuals or equipment specifications.

[0007] Furthermore, in S13, the system requirement classification network model sequentially includes a BERT word embedding layer, a Bi-LSTM modeling layer, and a Softmax classification layer.

[0008] Furthermore, in S13, the parameter configuration of the system demand classification network model is as follows: BERT-base-chinese is used as the pre-trained BERT model, the batch size is set to 8, the training period is set to 7 epochs, the Bi-LSTM hidden layer dimension is set to 128, the Dropout rate is set to 0.1, and the BERT-BiLSTM layer learning rate is set to 3× The learning rate for the Softmax classification layer is set to 2× Model training is implemented using the PyTorch framework.

[0009] Furthermore, in S21, the matching relationships between various demands and factors are as follows: Functional requirements: subject, attributes, object, behavior, function, condition; Interface requirements: subject, object, behavior, condition; Performance requirements: subject, attributes, values, conditions; Physical requirements: subject, attribute, object, behavior, value, condition; Design constraints: subject, attribute, behavior, principle, condition.

[0010] Furthermore, the S3 method is as follows: S31, based on the structured requirement information obtained in S2, construct a requirement knowledge graph: with the subject, attributes and objects of physical requirements as core nodes and behaviors as connecting edges, construct the basic framework of the graph; integrate the "function" in functional requirements, the "value" in performance requirements, the "principle" in design constraints and the "interaction method" in interface requirements as supplementary information into the graph to form a general requirement knowledge graph; S32 constructs a target graph based on a general requirements knowledge graph; S33 uses a subgraph extraction algorithm to extract the subgraph associated with the target node. It takes the reference graph constructed from the domain standard requirements document and the target graph to be completed as input, and uses the bert-base-chinese model to semantically encode the nodes and text descriptions. A threshold is set, and the cosine similarity is calculated. When the similarity is lower than the threshold, the missing edges and text descriptions in the target graph are completed.

[0011] Furthermore, in S33, the subgraph extraction algorithm includes two steps: single-layer reverse traversal to extract the direct upstream node of the target node and forward depth-first traversal to recursively extract all downstream reachable nodes.

[0012] Furthermore, in S3, the nodes of the knowledge graph adopt differentiated visual identifiers, including: setting different patterns and colors for different requirement nodes, the color of the connecting edges being consistent with the color of the corresponding requirement node, and supporting the display of supplementary text information including functional descriptions and numerical indicators when the mouse hovers over them; using the Pyvis toolkit to implement knowledge graph visualization, and storing data based on the Neo4j graph database.

[0013] Furthermore, prior to S31, it also includes performing terminology standardization operations: based on the domain standard glossary, merging and replacing synonymous expressions in structured requirement information. Attached Figure Description

[0014] Figure 1 Technology Roadmap Figure 2 SRsNet model structure diagram Figure 3 Basic Structure of Manual-CoT Prompts Figure 4 Framework diagram for extracting demand information from complex systems based on thought chain reasoning Figure 5 Basic elements of knowledge graph Figure 6 System Requirements Representation Knowledge Graph Construction Framework Figure 7 Flowchart of the algorithm for constructing a knowledge graph framework based on physical needs Figure 8 Flowchart of Knowledge Graph Extension Algorithm Based on Other Needs Figure 9 Knowledge graph-based requirement completion process Figure 10 The Knowledge Graph Framework Based on Physical Requirements in the "Metro Design Code" Figure 11 System Requirements Characterization Diagram of the Metro Design Code Figure 12Example of the code and some results for completing the "Metro Design Code" Figure 13 Knowledge Graph of System Requirements Representation after Completion of the "Metro Design Code" Figure 14 Example of a complete system requirements document for the "Metro Design Code" (excerpt) Figure 15 Node Relationship Representation Diagram Figure 16 Edge completion algorithm for reference graph G1 and target graph G2 Figure 17 Reference map G1 and target map G2 requirement description completion algorithm Detailed Implementation

[0015] The following mainly combines Figure 1 The technical approach of this invention will be described.

[0016] 1. Core Technology Solution The technical solution of this invention includes four key steps, each step building upon the previous one, forming a fully intelligent demand management system: (1) Construction of SRsNet system requirement classification network model 1) Demand Classification Standards Based on the SysML standard for systems engineering, complex system requirements are divided into five categories, covering all dimensions of system design: Functional requirements: Describe the core functions that the system should have (e.g., "the automatic fare collection system has access control function"). Interface requirements: Define the interaction methods between the system and external components, covering aspects such as data transmission, signal exchange, and physical connections (e.g., "connection between the clearing system and the payment system"). Performance requirements: Specify quantitative indicators of system functionality (e.g., "equipment can run continuously for 24 hours"); Physical requirements: Describe the physical properties of the system (e.g., "Emergency buttons to be installed in the station control room"); Design constraints: Clearly define the rules that the design must follow (such as "follow the principle of centralized management").

[0017] 2) SRsNet classification model structure design The deep classification network SRsNet (System Requirements Sorting Network) has the following structure: Input layer: Standardized requirement text (length ≤ 512 characters), converted into a sequence of word IDs using the bert-base-chinese vocabulary (vocab_size=21128); BERT word embedding layer: Using the bert-base-chinese pre-trained model, the requirement text is encoded into a vector containing contextual semantics; Bi-LSTM modeling layer: captures the temporal dependencies of text through forward and backward LSTM, enhancing the semantic understanding of long texts; Softmax classification layer: Outputs the probability distribution of five types of demand labels, enabling automatic demand classification.

[0018] 3) Model Training Dataset: 516 requirements from the "Metro Design Code" (198 functional requirements, 50 interface requirements, 57 performance requirements, 109 physical requirements, and 102 design constraints) were selected and divided into a training set (464 requirements) and a test set (52 requirements) in a 9:1 ratio. The Kappa coefficient for label consistency was 0.89. Training parameters: PyTorch framework, batch size 8, epochs=7, optimizer Adam (layered learning rate: 3× BERT layer) Classification layer 2× ), loss function cross-entropy; Performance validation: The average precision on the test set was 0.87, recall was 0.85, and F1-Score was 0.84, which is better than the single BERT model (F1=0.70) and the BERT-CNN model (F1=0.78).

[0019] (2) Construction of a structured extraction model based on thought chain reasoning 1) Structured design of prompts in Manual-CoT (Manual-CoT) By introducing the Chain-of-Thought (CoT) reasoning mechanism, a prompt word structure model for Manual-CoT is constructed, such as... Figure 3 As shown, it includes a task description layer, a reasoning guidance layer (following the path of "recognition-reasoning-decision"), a constraint layer, and an output example. The specific content is as follows: Task description layer: "It is necessary to clarify the model's role, task background, and task requirements to ensure that the large language model can accurately understand the core objectives of the task, and to emphasize that the task is a process of transforming unstructured requirement text into structured data through step-by-step reasoning and logical analysis." Reasoning guidance layer: "'The guidance model follows the reasoning logic of 'gradually relying on previous results,' such as 'first identifying and extracting the subject through noun phrases → matching attributes based on the subject's semantics → associating the object pointed to by the subject's actions → locating the behavior that connects the subject and the object → extracting functions / values / principles / conditions as needed,' ensuring that each step of reasoning is based on the information already obtained." The constraint layer defines the limitations in task execution. Content constraints limit the extraction of elements that match the requirement category (e.g., design constraints require the extraction of 'principles', and functional requirements require the extraction of 'functions'). Format constraints limit the output to JSON format containing 'category (requirement category), explanation (reasoning process), structured_data (structured elements)', as well as style and tone, guiding the large model to generate standard-compliant output. Output example: "Store 50 annotated 'input text-output JSON' samples (e.g., 'emergency buttons should be installed in the station control room' → {"category":"physical requirement","structured_data":{"subject":"station control room","attribute":"","object":"emergency button","behavior":"setting",...}}) for the model to learn and extract patterns." 2) Design of Structured Information Extraction Template Based on the semantic features of five types of needs, information extraction templates adapted to different types of needs are constructed. The templates include eight elements: subject, attribute, object, behavior, function, value, principle, and condition. The definitions of each element are as follows: Subject: The main or core entity of the demand, such as "automatic fare collection system" or "station control room", which is the starting point for cognition and is mostly a noun component; Attribute: A characteristic description of the subject, usually presented in the form of "AA of BB", where 'BB' is the attribute of the requirement, such as "electrical load" in "electrical load of the sorting system" and "protection level of the automatic fire alarm system". Object: The target entity to which the subject's action points, forming a "subject-behavior-object" ternary semantic chain with the subject and behavior, such as "emergency control button" in "emergency control button should be installed in the station control room"; Action: An interactive verb that connects a subject with an object or other element. It is an explicit expression of system execution, such as "set", "connect", "possess", "display", etc. Function: A specific element of functional requirements, referring to the task that the subject needs to perform or the service that it needs to provide, such as "user access management function" in "automatic fare collection system needs to have user access management function". Value: Quantitative indicators in performance / physical requirements, such as "≤1Ω", "24h continuous operation", "secondary protection", etc. Leave blank if none; Principle: Design constraint-specific element, referring to the rules that must be followed in the design, such as "centralized management and hierarchical control principle" and "compliance with local fire department requirements". Leave blank if none exist. Condition: The prerequisite environment or triggering scenario for the requirement, such as "when the environment and equipment monitoring system are integrated" or "when a dedicated integrated grounding is used". Leave blank if there is no condition. Based on the semantic features of the five types of needs, a matching relationship between need categories and elements is constructed to ensure the targeting of extraction. The matching relationship between needs and elements is as follows: Functional requirements: Subject, Attributes, Object, Behavior, Function, Conditions Interface requirements: Subject, Object, Behavior, Condition Performance requirements: subject, attributes, values, conditions Physical requirements: subject, attribute, object, behavior, value, condition Design constraints: subject, attribute, behavior, principle, condition; 3) Structured extraction reasoning framework: Using "document input → requirement classification results → prompt guidance → model invocation → output validation → data storage" as the core process, a structured extraction framework for complex system requirements is constructed, such as... Figure 4 As shown, the specific steps are as follows: Input data preparation: The input is the “requirement description + requirement category” output by the SRsNet classification model (e.g., “Automatic ticketing system should implement an interface with the payment system (interface requirement)”). Use “####” to separate the requirement text and “××××” to separate the requirement category to help the model distinguish the input structure. Manual-CoT cue word injection: Concatenate pre-designed cue words (including task description, inference guidance, matching matrix, and output examples) with the input data to clarify the model's inference direction and output format; Large language model invocation: GPT-4 is selected as the inference model, with parameters temperature=0.3 (to ensure output stability) and max_tokens=300 (to adapt to the required text length), and the model is invoked through the API interface; Output validation and correction: Perform double validation on the JSON data output by the model—field validation (check whether “category”, “explanation”, and “structured_data” are complete) and feature validation (check the matching of features in “structured_data” with the requirement categories, such as the interface requirement must include “object” and “behavior”). Unqualified data is returned to the model for regeneration to avoid the “illusion phenomenon”. Structured data storage: The validated structured data is grouped and stored as Excel files according to the requirement category. The fields include "requirement description, requirement category, subject, attribute, object, behavior, function, value, principle, and condition", providing a structured data source for subsequent knowledge graph construction.

[0020] 4) Extraction effect evaluation system To ensure the accuracy of structured extraction, a multi-dimensional evaluation system oriented towards knowledge graph structures is constructed. The specific methods are as follows: Node matching evaluation (subject, attribute, object): Precise string matching is used, meaning every word in the extracted results must be completely identical to the manually labeled text; otherwise, it is considered an incorrect match. If multiple subjects / objects / attributes exist, the number of correct matches will be used as the score for this item. The matching accuracy is calculated using the following formula: (Formula 1) in, Representative elements The exact match score; Representative elements In manually labeled data Example total; Representative model in elements The first in One value; For indicator functions, if The value is 1 if the value is 1, otherwise it is 0. Edge-text matching evaluation (behavior, function, value, principle, condition): BERT word vector encoding (bert-base-chinese) is used to transform the input text into a semantic vector representing the text. Then, cosine similarity calculation based on the word semantic vectors is performed to evaluate other key information elements. If the same data contains multiple elements of the same category, the texts of the same element are first merged and concatenated to form a unified text representation. Based on this, a unified cosine similarity calculation is performed between this representation and manually labeled elements. The calculation formula is: (Formula 2) in, as elements semantic similarity score, Extract semantic vectors from the text for the model. The semantic vector of manually annotated text. Let L2 norm be the vector, and its formula is: The cosine similarity value ranges from [-1, 1]. The closer the value is to 1, the closer the semantics of the text extracted by the model is to the manually annotated text.

[0021] Performance: The accuracy of extracting 516 samples was 84.76%, which significantly outperformed baseline models such as BERT and RoBERTa (both 59.05%). Among them, the accuracy of extracting interface requirements was the highest (90.00%), because the "subject-object-behavior" relationship of interface requirements was clear.

[0022] (3) Demand representation and semantic completion based on knowledge graph 1) Construction of a knowledge graph representing demand By defining the core elements of the graph, clarifying the relationships between nodes, and completing knowledge integration, and by adopting a hierarchical logic of "physical needs as the core + multiple needs expansion", a generalized demand representation knowledge graph is constructed, laying the foundation for demand association visualization and subsequent completion.

[0023] Definition of core elements of the map Based on the structured information (eight categories) of complex system requirements, the three basic elements of the graph and the relationships between nodes are clearly defined, such as... Figure 5 As shown, the details are as follows: Nodes: These are the core entities that carry the requirements, corresponding to the "subject, attribute, and object" in structured information. Nodes are identified by different visual identifiers based on the requirement category (functional requirements - red circle, interface requirements - orange pentagram, performance requirements - green triangle, physical requirements - blue circle, design constraints - purple ellipse) to ensure that the requirement categories are intuitively identifiable. Edges: Connect nodes and express relationships, corresponding to "behaviors" in structured information. The color of the edge is consistent with the color of the corresponding requirement node. When hovered, supplementary text information such as "conditions, values, functions, and principles" can be displayed. Text: Supplements the semantic details of nodes and edges, corresponding to "function, value, principle, and condition" in structured information; Based on the semantic associations required, six types of core node relationships are defined. Specific relationship types, descriptions, and examples are as follows: Figure 15 As shown, it covers the relationship logic between physical requirements and other requirements. For example, "subordination relationship" is used to express the subordinate relationship between physical requirement nodes (such as "integrated monitoring system - configuration - simulation test platform"), and "interface operation relationship" is used to express the interaction between physical requirements and interface requirements (such as "automatic fire alarm system - display - manual / automatic switch status").

[0024] Knowledge integration and layered construction To address synonymous expressions in the requirement text, knowledge fusion is achieved using "standardized word replacement + semantic clustering (based on BERT-base-Chinese encoding)" based on the domain standard glossary. Since physical requirements clearly define entity affiliations, a logic of "physical requirements as the core + multi-requirement category expansion" is adopted to construct the knowledge graph. The system requirement representation knowledge graph framework is as follows: Figure 6 As shown. The specific process is as follows: Basic framework: The "subject, attribute, and object" of physical requirements are nodes, and "behavior" is the connecting edge, forming an entity association skeleton. The algorithm flowchart for constructing the knowledge graph framework based on physical requirements is as follows. Figure 7 As shown; Knowledge Graph Expansion: The "functions" of functional requirements, the "numerical values" of performance requirements, the "principles" of design constraints, and the "interaction relationships" of interface requirements are integrated as additional attributes into the basic knowledge graph, forming a knowledge graph that integrates these five types of requirements. An algorithm flowchart is then constructed based on this knowledge graph framework for other requirements, as shown below. Figure 8 As shown; The graph database Neo4j is used for storage and querying, and Pyvis is used for interactive visualization of the graph.

[0025] 2) Subgraph extraction algorithm To address the issues of large graph size and low retrieval efficiency, an algorithm combining "reverse single-level traversal + forward depth-first search (DFS)" is designed to quickly obtain all upstream and downstream dependency paths centered on a specific target node (e.g., "automatic fire alarm system"), thus aiding system analysis. The subgraph extraction algorithm based on the system requirement representation knowledge graph is as follows: (1) Initialize the subgraph node set V_sub={start_node}, the edge set E_sub to be an empty set, and the visit tag set visited to be an empty set; (2) Perform single-level reverse traversal: Traverse all edges (u, start_node) in the main graph with start_node as the endpoint, add u to V_sub, and add (u, start_node) to E_sub; (3) Perform forward depth-first traversal: Define a recursive function dfs(current_node). If current_node∈visited, return. Otherwise, add current_node to visited. Traverse the edge (current_node, v) starting from current_node in the main graph. If v does not belong to V_sub, add v to V_sub and (current_node, v) to E_sub, and call dfs(v). (4) Call dfs(start_node) to output the subgraph subgraph=(V_sub, E_sub).

[0026] 3) Demand fulfillment mechanism Using the domain standard requirement document-constructed graph G1 as a reference and the graph to be completed G2 (such as the designer document graph) as the target, automatic completion is achieved using "bert-base-chinese semantic encoding and cosine similarity for node similarity calculation," filling in requirement omissions in the design process. The calculation formula is shown in Formula 2, and the requirement completion process is as follows: Figure 9 As shown.

[0027] Semantic encoding: BERT-base-chinese is used to perform vector encoding on nodes and text descriptions; Similarity matching: Calculate the cosine similarity between the node and the text description, setting a threshold of 0.85. If an omission is found, completion will be triggered. Data backtracking: Based on the completed edges, query the original structured data in reverse and update the source data of the target graph to ensure integrity; Edge completion algorithm such as Figure 16 As shown, the text description completion algorithm is as follows: Figure 17 As shown.

[0028] Taking the "Metro Design Code" as an example, this invention verifies the knowledge graph-based requirement representation and semantic completion method for complex systems. Using the reference graph G1 (77 nodes, 87 edges) constructed from the "Metro Design Code" as a baseline, the target graph G2 (initially 50 nodes, 50 edges) constructed from the designer's document "Design Analysis of Metro Automatic Fire Alarm System" is completed. After completion, G2 expands to 77 nodes and 87 edges, adding 27 nodes (e.g., "related communication network," "DC backup power supply"), 37 edges (e.g., "Automatic fire alarm system - associated - related communication network"), and 59 text descriptions (e.g., "grounding resistance ≤ 1Ω"). Requirement coverage increases from 65% to 100%, effectively filling requirement omissions caused by designers' lack of experience or information, ensuring the completeness of requirement representation. Results are as follows... Figure 10-14 .

[0029] (4) Overall module integration Implement module chaining through API interfaces: 1) Data flow: SRsNet classification model outputs "text ID + demand category" → structured extraction model input → output "structured data" → knowledge graph model input → output "graph nodes / edges" → complete model input → output "complete graph"; 2) Interface design: RESTful API is adopted, including SRsNet model interface (POST / srsnet / classify, input text, output category), model extraction interface (POST / cot / extract, input text+category, output structured_data), and graph model interface (POST / kg / build, input structured_data, output graph_id).

[0030] 2. Overview of Innovation Points (1) Semantic Enhancement Classification Model Design: The SRsNet model is constructed by integrating BERT context encoding and Bi-LSTM temporal modeling to solve the semantic ambiguity problem of single model. The classification F1-Score is improved by 14%, and standardized training parameters (batch size, learning rate) are provided to ensure that the model is reproducible. (2) Construction of extraction model driven by thinking chain: Design a three-layer prompt word model of Manual-CoT, which incorporates the reasoning path of "subject-attribute-object", eliminating the need for manual annotation (saving costs >80%), improving the extraction accuracy by 25.71%, and standardizing the output format, which is convenient for subsequent graph integration; (3) Generalized knowledge graph and completion model: The ontology structure is designed with physical needs as the core, and the cross-domain reuse rate is increased to 70%; an integrated completion model of "encoding-computation-completion" is constructed, which increases the demand coverage rate by 35% and realizes automatic graph completion; (4) Full-process model integration: The three sub-models are connected through the API interface to form a technical closed loop of "classification-extraction-map-completion", which improves the processing efficiency by 10 times. Each sub-model can be called independently, taking into account both flexibility and integration requirements.

[0031] The following uses the "Metro Design Code" GB 50157-2013 (Chapters 18-22, Intelligent Management and Monitoring System) as an example to illustrate the implementation process of this invention in detail: 1. Construction and Implementation of the SRsNet System Requirements Classification Network Model (1) Data preparation 1) Raw data: 516 requirements from 5 types of systems, including automatic fare collection systems and automatic fire alarm systems, were selected from the "Metro Design Code"; 2) Data preprocessing: Delete chapter numbers (such as "18.3.4") and special characters (such as ";" and "①"). Standardized format: Remove extra spaces and line breaks, and concatenate the sub-items (such as "1 Control function; 2 Monitoring function") with the main requirement to "The integrated monitoring system has control function and monitoring function"; Data labeling: Based on the SysML standard, three systems engineering experts categorized and labeled the requirements. Inconsistent labels were unified through discussion, resulting in 198 functional requirements, 50 interface requirements, 57 performance requirements, 109 physical requirements, and 102 design constraints. These were then divided into a training set (464 requirements) and a test set (52 requirements) at a ratio of 9:1.

[0032] (2) SRsNet model training and validation 1) Model configuration: Batch size set to 8, training epochs=7, Bi-LSTM hidden layer dimension set to 128, Dropout rate set to 0.1, BERT-BiLSTM layer learning rate set to 3× The learning rate for the Softmax classification layer is set to 2× Training is based on the PyTorch framework; 2) Performance verification: The classification results on the test set are shown in Table 1. The average accuracy of the SRsNet model is 0.87 and the F1-Score is 0.84, which is better than BERT (F1=0.70) and BERT-CNN (F1=0.78). Among them, the functional requirement classification accuracy is the highest (F1=0.98) because the functional requirement is described intuitively (containing keywords such as "has... function").

[0033] Table 1. Classification performance of the SRsNet model on the test set.

[0034] 2. Construction and Implementation of a Structured Extraction Model Based on the Thinking Chain (1) Design and implementation of a prompt word model based on thought chain reasoning (Manual-CoT) Taking the physical requirement that "stations and tunnel sections should be equipped with automatic fire alarm systems" as an example, the prompt text is as follows: Figure 3 Framework diagram for extracting demand information from complex systems based on thought chain reasoning: 1) Task Definition: "Based on a complex system requirements extraction template, extract eight categories of elements from the input text: 'subject, attribute, object, behavior, function, value, principle, and condition.' The requirement category is physical requirements." 2) Reasoning Guidance: "① Subject Extraction: Use noun phrase recognition tools to locate the main entities in the text (such as "station control room" or "tunnel section"). If multiple entities exist, separate them with ","; ② Attribute Matching: Analyze the characteristic attributes of the main entities (such as "location" or "model"). Leave blank if there are no explicit attributes; ③ Object Association: Identify the entities that the main entity's actions directly point to (such as "emergency button" or "FAS"); ④ Behavior Extraction: Extract verbs that connect the main entity and the object (such as "set" or "configure"); ⑤ Function / Value / Principle Extraction: Physical requirements do not require extraction of functions, values, or principles, so leave them blank; ⑥ Condition Extraction: Identify the conditions that limit the actions in the text (such as "when the power goes out"). Leave blank if there are none."

[0035] 3) Output format: The output strictly follows the JSON format, and the fields include "category" (fixed to "physical demand") and "structured_data" (containing eight categories of elements).

[0036] (2) Extraction results and verification 1) Call the GPT-4 API, input 516 categorized requirement texts and the above prompt words, and output structured data; 2) Performance verification: An evaluation system was constructed based on two indicators: node precise matching and text cosine similarity. With a threshold of 0.85, the extraction accuracy reached 84.76%, which is better than BERT (59.05%) and RoBERTa (59.05%). Among them, the extraction accuracy of interface requirements was the highest (90.00%), because the "subject-object-behavior" relationship of interface requirements is clear.

[0037] 3. Implementation of Knowledge Graph Construction and Completion (1) Construction of basic knowledge graph model 1) Basic framework construction: Using the physical requirements of "subject (such as automatic fire alarm system), attribute (such as protection level), object (such as manual alarm button)" as nodes and "behavior (such as setting)" as edges, construct a basic graph containing 47 nodes and 57 edges; 2) Graph Expansion: Integrate functional requirements (such as "having alarm function"), performance requirements (such as "protection level is level 2"), design constraints (such as "complying with fire protection codes"), and interface requirements (such as "connecting with integrated monitoring system") to form a complete graph with 77 nodes and 87 edges. Pyvis visualization is used, and node colors are indicated as in claim 5.

[0038] (2) Example of subgraph extraction algorithm Using "Automatic Fire Alarm System" as the target node, execute the subgraph extraction algorithm: 1) Reverse traversal: Extract the direct upstream node (such as "Control Center"); 1) Forward Depth-First Search (DFS): Recursively extract downstream nodes (such as "manual alarm button" and "fire alarm control panel"); Output subgraph: containing 23 nodes and 28 edges, covering the physical composition, functions, and performance constraints of the system, making it easy for designers to quickly locate related requirements.

[0039] (3) Demand Completion Mechanism Experiment 1) Reference diagram: Diagram of "Automatic Fire Alarm System" in the "Metro Design Code" (77 nodes, 87 edges); 2) Target graph: The graph constructed from the designer document "Design Analysis of Subway Fire Automatic Alarm System" (50 nodes, 50 edges); 3) Completion process: Calculate the similarity between nodes and text in the two graphs, and complete 27 missing edges (e.g., "Automatic fire alarm system - related communication network") and 59 missing texts (e.g., "grounding resistance ≤ 1Ω"). 4) Completion results: The target graph was expanded to 77 nodes and 87 edges, and the demand coverage rate increased from 65% to 100%, verifying the effectiveness of the completion method.

Claims

1. A method for identifying and managing the requirements of complex systems based on knowledge graphs and thought chain reasoning, comprising the following steps: S1, Construction of the system requirement classification network model, the method is as follows: S11, a system modeling language standard based on systems engineering (SysML), divides complex system requirements into five categories: functional requirements, interface requirements, performance requirements, physical requirements, and design constraints. S12, preprocess the original requirement text; S13, Construct a system requirement classification network model that integrates a bidirectional encoder representation converter (BERT) model and a bidirectional long short-term memory network (Bi-LSTM); S14, the preprocessed requirement text is divided into a training set and a test set, the system requirement classification network model is trained and the requirement classification result is output; S2, a demand structure extraction model based on the mind chain is constructed using the following method: Based on the demand classification results obtained in S1, S21 constructs information extraction templates that are adapted to different types of demands. The information extraction templates include eight categories of elements: subject, attribute, object, behavior, function, value, principle, and condition. S22 introduces the Chain-of-Thought (CoT) reasoning mechanism and constructs Manual-CoT prompts; S23, input the demand classification results and Manual-CoT prompts into the large language model to verify the integrity of the output format constraint structure and obtain structured demand information; S3, construct a general requirements knowledge graph and a target graph, and complete the target graph.

2. The method for identifying and managing the requirements of complex systems based on knowledge graphs and thought chain reasoning as described in claim 1, characterized in that, The functional requirements, interface requirements, performance requirements, physical requirements, and design constraints in S11 are defined as follows: Functional requirements: Describe the core functions that the system should have; Interface requirements: Define the interaction methods between the system and external components; Performance requirements: Quantitative indicators that define the system's functionality; Physical requirements: Describe the physical properties of the system; Design constraints: Define the rules that the design must follow.

3. The method for identifying and managing the requirements of complex systems based on knowledge graphs and thought chain reasoning as described in claim 1, characterized in that, In S12, the preprocessing includes deleting chapter numbers and invalid tags, standardizing text format, and splicing scattered content related to the context; for the processing of nested requirement sub-items, the content of the requirement sub-items is spliced ​​with the main requirement text to ensure the consistency of the requirement context; the original requirement text comes from technical documents in the field of complex system design, including industry standards and specifications, system design manuals or equipment specifications.

4. The method for identifying and managing the requirements of complex systems based on knowledge graphs and thought chain reasoning as described in claim 1, characterized in that, In S13, the system requirement classification network model sequentially includes a BERT word embedding layer, a Bi-LSTM modeling layer, and a Softmax classification layer.

5. The method for identifying and managing the requirements of complex systems based on knowledge graphs and thought chain reasoning as described in claim 1, characterized in that, In S13, the parameter configuration of the system demand classification network model is as follows: BERT-base-chinese is used as the pre-trained BERT model, the batch size is set to 8, the training period is set to 7 epochs, the Bi-LSTM hidden layer dimension is set to 128, the dropout rate is set to 0.1, and the BERT-BiLSTM layer learning rate is set to 3× The learning rate for the Softmax classification layer is set to 2× Model training is implemented using the PyTorch framework.

6. The method for identifying and managing the requirements of complex systems based on knowledge graphs and thought chain reasoning as described in claim 1, characterized in that, In S21, the matching relationships between various demands and factors are as follows: Functional requirements: subject, attributes, object, behavior, function, condition; Interface requirements: subject, object, behavior, condition; Performance requirements: subject, attributes, values, conditions; Physical requirements: subject, attribute, object, behavior, value, condition; Design constraints: subject, attribute, behavior, principle, condition.

7. The method for identifying and managing the requirements of complex systems based on knowledge graphs and thought chain reasoning as described in claim 1, characterized in that, The method for S3 is as follows: S31, based on the structured requirement information obtained in S2, construct a requirement knowledge graph: with the subject, attributes and objects of physical requirements as core nodes and behavior as connecting edges, construct the basic framework of the graph; integrate "function" in functional requirements, "numerical value" in performance requirements, "principle" in design constraints and "interaction method" in interface requirements as supplementary information into the graph to form a general requirement knowledge graph; S32 constructs a target graph based on a general requirements knowledge graph; S33 uses a subgraph extraction algorithm to extract the subgraph associated with the target node. It takes the reference graph constructed from the domain standard requirements document and the target graph to be completed as input, and uses the bert-base-chinese model to semantically encode the nodes and text descriptions. A threshold is set, and the cosine similarity is calculated. When the similarity is lower than the threshold, the missing edges and text descriptions in the target graph are completed.

8. The method for identifying and managing the requirements of complex systems based on knowledge graphs and thought chain reasoning as described in claim 7, characterized in that, In S33, the subgraph extraction algorithm includes two steps: single-layer reverse traversal to extract the direct upstream node of the target node and forward depth-first traversal to recursively extract all downstream reachable nodes.

9. The method for identifying and managing the requirements of complex systems based on knowledge graphs and thought chain reasoning as described in claim 7, characterized in that, In S3, the nodes of the knowledge graph are identified by differentiated visual identifiers, including: setting different patterns and colors for different requirement nodes, the color of the connecting edges being consistent with the color of the corresponding requirement node, and supporting the display of supplementary text information including functional descriptions and numerical indicators when the mouse hovers over them; the knowledge graph visualization is implemented using the Pyvis toolkit, and the data is stored based on the Neo4j graph database.

10. The method for identifying and managing the requirements of complex systems based on knowledge graphs and thought chain reasoning according to claim 7, characterized in that, Prior to S31, it also included performing terminology standardization operations: based on the domain standard terminology list, merging and replacing synonyms in structured requirements information.

Images