Aerospace software demand dynamic management system based on atlas and big data technology
The aerospace software requirement dynamic management system, which utilizes graph and big data technologies, solves the problems of multi-source, dynamic, and complex aerospace software requirement management. It achieves automated processing, standardized storage, and associated management of requirement information, thereby improving information utilization and dynamic traceability capabilities.
Patent Information
- Application Number
- CN202511957123.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-23
- Publication Date
- 2026-05-05
AI Technical Summary
Aerospace software requirements management faces multi-source, dynamic, and complex issues. Existing technologies rely on manual collection and organization, resulting in long cycles, inconsistent standards, unstructured key information, low utilization rates, and difficulty in tracing dynamic changes.
The aerospace software requirement dynamic management system, based on graph and big data technologies, includes a data layer, a technology layer, and a functional layer. The big data analysis module enables automated analysis of multi-source requirement information, while the knowledge graph management module constructs a requirement association network, providing functions for requirement information collection, processing, querying, and dynamic change management.
It improved the efficiency of demand processing, ensured the standardization and consistency of demands, increased information utilization, and enabled dynamic traceability of demands, thereby reducing research and development risks.
Smart Images

Figure CN121979491A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of software design technology and relates to a dynamic management system for aerospace software requirements based on graph and big data technologies. Background Technology
[0002] As the core control unit of aerospace equipment, the accuracy and dynamism of aerospace software requirements management directly determine the quality of equipment development and the success rate of missions. Currently, in the early stages and throughout the development of aerospace models, requirements information management still relies on manual collection and organization, which suffers from problems such as long cycles, inconsistent standards, unstructured key information, low utilization rates, and difficulty in tracing dynamic changes. Based on this research background, this study investigates the dynamic management of aerospace software requirements based on graph and big data technologies. Through the application of big data technology and knowledge graphs, it provides technical support for the dynamic management of aerospace software requirements. Summary of the Invention
[0003] The technical problem solved by this invention is to address the current situation of multi-source, dynamic, and complex aerospace software requirements, overcome the shortcomings of existing technologies, and propose a dynamic management system for aerospace software requirements based on graph and big data technologies.
[0004] The solution of the present invention is: A dynamic management system for aerospace software requirements based on graph and big data technologies, comprising a data layer, a technology layer, a functional layer, and an application layer; Data layer: Responsible for storing multi-source demand information and graph data. The multi-source demand information includes a raw document library and a structured demand library; the graph data includes a knowledge graph library. The technical layer includes a big data analysis module and a knowledge graph management module. The big data analysis module enables automated analysis of multi-source unstructured demand information. The knowledge graph management module constructs a demand association network in the form of "entity-relationship-attribute" triples to achieve dynamic demand management. Functional layer: Based on the big data analysis module and knowledge graph management module used for the technical layer of demand invocation, it provides users with demand information collection and processing functions, demand graph construction and query functions, demand dynamic change management functions, and demand statistics and analysis functions; Application layer: Provides application services for different roles in research and development.
[0005] Preferably, the original document library stores the original documents of task requirements, system design scheme reports, subsystem design reports and various analysis reports in an encrypted format, and sets access permissions; The structured requirements library stores standardized requirements entries processed by the big data analytics module; The knowledge graph library is based on a graph database to store required knowledge graph data, including entity tables, relation tables, and attribute tables, and supports graph querying and association analysis.
[0006] Preferably, the big data analysis module includes a data acquisition and preprocessing submodule, an unstructured information structure transformation submodule, a multi-dimensional verification and detection submodule for demand quality, and a structured item output and docking submodule; Data Acquisition and Preprocessing Submodule: This module receives multi-source requirement documents from the data layer, including task requirements, system design reports, subsystem design reports, and analysis reports. It then performs format standardization processing on the received multi-source documents, removing redundant information and unifying the format and terminology. The unstructured information structuring transformation submodule: Based on natural language processing technology, it constructs an aerospace requirement entity recognition model, automatically extracts key entities from the requirement documents processed by the data acquisition and preprocessing submodule, identifies the relationships between entities, and forms structured requirement items; the key entities include requirement item name, indicator requirements, constraints, responsible department, and delivery time; The multi-dimensional verification and inspection submodule for requirement quality checks and inspects the completeness, consistency, and rationality of structured requirement items, automatically marks abnormal items, and prompts for manual review. Structured Item Output and Interface Submodule: The structured requirement items verified and detected by the multi-dimensional verification and detection submodule of requirement quality are reviewed and corrected, and then output to subsequent modules, while retaining the interface for manual intervention.
[0007] Preferably, the data acquisition and preprocessing submodule performs format standardization processing on the received multi-source requirement documents, removing redundant information and unifying the format and terminology, as follows: (1) Standardize the format of the received multi-source documents. For PDF documents: Optical character recognition technology is used to extract the text content in the document, and editable text is extracted in combination with PDF parsing tools; For Word / Excel documents: Extract headings, paragraphs, and table data, and convert the table data into a row-column structured format; For complex formulas / charts: Use mathematical formula recognition tools to extract formula content and convert data points in charts into numerical sequences; (2) Delete redundant information, including headers and footers, watermarks, blank paragraphs, and duplicate expressions in the document; (3) Automatically replace non-standard expressions based on the terminology database of aerospace requirements.
[0008] Preferably, the unstructured information to structure transformation submodule forms structured requirement items, as follows: A space demand entity recognition model is constructed using a BERT pre-trained model. The model is trained using historical demand data in the space field as the training set. The input of the space demand entity recognition model is the demand document processed by the data acquisition and preprocessing sub-module, which is segmented by paragraph. The output is the entities in the document. Using the trained aerospace requirement entity recognition model, entities are obtained from the input requirement document; For relationships between entities that are clearly defined, regular expressions are used for matching; for relationships between entities that are complex, the BERT-RE model is used to extract relationship conditions. The "entity-relationship" pairs are combined into structured requirement items according to the aerospace requirement standard format.
[0009] Preferably, the multi-dimensional verification and detection submodule for requirement quality verifies and detects the completeness, consistency, and rationality of the structured requirement items, as follows: Integrity check: Check whether the required fields of the structured requirements entries are missing, mark the entries with missing fields as "incomplete", and suggest possible sources for supplementation; Consistency check: Determine whether the description of the same requirement item is consistent in different documents; Reasonableness check: Based on historical data and by comparing the requirements of similar aerospace models, determine whether the logical relationship between the item indicators is reasonable; Based on the above testing, a "Requirement Quality Inspection Report" is generated. This report includes qualified items and problematic items, and the problematic items are categorized and statistically analyzed according to their "severity," including serious problems, general problems, and acceptable problems. Serious problems refer to issues such as missing core fields or conflicting key indicators, which require immediate modification. General problems refer to issues such as non-standard terminology or unconfirmed rationality of indicators, which require review and confirmation. Acceptable problems refer to issues such as inconsistent units or missing non-core fields, which will be left for subsequent optimization.
[0010] Preferably, the structured entry output and docking submodule is implemented as follows: Requirements engineers manually correct marked problem items using the "Requirements Quality Inspection Report"; The structured entry output and interface submodule will synchronize the qualified and corrected structured entries to the knowledge graph library through an offline interface, providing data support for demand association management. The structured entry output and docking submodule automatically records the entire process log of each entry from "extraction-detection-review-output", including the operator, operation time, and modified content, to ensure traceability.
[0011] Preferably, the knowledge graph analysis module includes a requirement knowledge graph modeling submodule, a requirement source tracing submodule, and a requirement dynamic change management submodule; The requirement knowledge graph modeling submodule defines the core entities, relationships, and attributes of the aerospace software requirement domain and constructs a domain ontology model; it transforms the structured requirement entries generated by the big data analysis module into triple data, stores them in a graph database, and forms a requirement knowledge graph. Demand Source Traceability Submodule: Quickly locate the source document, extract the chapter and relevant responsible person for any demand item through graph query statements; The dynamic change management submodule for requirements automatically records the change node in the graph when requirements change, including the reason for the change, the content of the change, the time of the change and the approver. It also analyzes the scope of the impact of the change through relationship path analysis, so as to achieve traceability and controllability of the change.
[0012] Preferably, the requirement knowledge graph modeling submodule includes an aerospace software requirement knowledge graph design unit, a requirement data access and preprocessing unit, and a knowledge graph construction unit; Aerospace Software Requirements Knowledge Graph Design Unit: Defines the entities, relationships, attributes, and constraint rules of the graph to form a standardized graph pattern; Demand data access and preprocessing unit: Extracts structured demand items from the big data analysis module; Knowledge graph construction unit: The extracted structured requirement items are transformed into "entity-relationship-attribute" triples, imported into a graph database, and a complete requirement knowledge graph is formed; The knowledge graph construction submodule includes: Entity building sub-unit: Batch creation of graph entities according to entity type; Relationship building subunit: Based on the relationship types defined by structured requirement items and graph patterns, the association relationships between entities are built through "rule matching + manual completion"; Automated Relationship Building Subunit: For relationships with clear data connections, batch creation of relationships is achieved through SQL queries and Cypher statements; for relationships based on logical judgments, automatic matching is triggered based on a rule base. Manual completion and review sub-unit: For complex relationships that fail in automated builds, an interactive interface is provided for requirements engineers and test engineers to collaboratively complete the necessary parts.
[0013] Preferably, the knowledge graph construction unit also includes a graph quality verification and optimization subunit; The spectrum quality verification and optimization subunit: The Cypher query is used to count the number of entities with no relation to each other in the constructed knowledge graph. If any are found, they are marked and manual processing is triggered. Check the consistency of attributes and relational logic for the same entity. If they are inconsistent, mark it as an anomaly and trigger manual processing. Remove duplicate entities and invalid relationships.
[0014] Preferably, functional services are provided to users at the functional level, as follows: Requirements information collection and processing function: Supports importing original documents from multiple sources in the data layer, calling the big data analysis module to automatically complete structured transformation and quality inspection, and generate standardized requirements items; Demand graph construction and query function: Automatically constructs demand knowledge graph by calling the knowledge graph management module, providing demand source tracing and related query functions, and can quickly locate relevant information by demand ID, name or source document; Dynamic requirement change management function: Records requirement change history, analyzes the scope of change impact, generates change reports, and supports change approval process management.
[0015] Requirements statistics and analysis function: It can count the number, type, status and number of changes of requirements, generate visual reports, and provide support for research and development decisions.
[0016] Preferably, the application layer provides application services to different roles in the development process, including: For R&D management personnel: Provides services such as viewing the overall progress of requirements, changing statistics reports, understanding the status of requirements management, and formulating R&D plans; For requirements engineers: Use the requirements information collection and processing function and the requirements dynamic change management function to complete the generation of requirements items, quality review and change requests; For software designers and test engineers: Through the requirements mapping and query functions, obtain accurate requirements information to guide software design and test case writing, and understand the impact of requirements changes on design and testing.
[0017] The advantages of this invention compared to the prior art are: (1) Improve demand processing efficiency: This invention uses big data technology to realize the automated extraction and structured transformation of multi-source demand information, shorten the demand processing cycle, and ensure the development progress.
[0018] (2) Ensuring the standardization and consistency of requirements: This invention establishes a unified standard for requirement description and a knowledge graph model to realize the standardized storage and associated management of requirement information and eliminate expression deviations.
[0019] (3) Improve information utilization: This invention transforms unstructured demand information into structured entries, supporting automated applications such as demand retrieval, conflict detection, and impact analysis, thereby enhancing information value.
[0020] (4) Achieve dynamic traceability of requirements: This invention uses knowledge graphs to record the source, change history and relationship of requirement items, providing a complete basis for dynamic management of requirements and reducing development risks. Attached Figure Description
[0021] Figure 1 This is the architecture of the aerospace software requirements dynamic management system of the present invention; Figure 2 Diagram showing the components of a big data analytics module; Figure 3 This is a diagram showing the components of the knowledge graph analysis module. Detailed Implementation
[0022] The invention will now be further described with reference to the accompanying drawings.
[0023] Figure 1 This invention presents the architecture of the aerospace software requirements dynamic management system. The architecture consists of four layers, from bottom to top: data layer, technology layer, functional layer, and application layer.
[0024] (1) Data layer The data layer is the foundation of the system, responsible for storing multi-source demand information and graph data, including: Original document repository. Stores original documents such as task requirements, system design reports, subsystem design reports, and various analysis reports. These documents are stored in encrypted format with access control settings.
[0025] Structured Requirements Library. Stores standardized requirements entries processed by big data technology. Each entry includes fields such as "Requirement ID, Name, Metric Requirements, Constraints, Source Document ID, Responsible Department, Priority, and Status".
[0026] Knowledge graph library. Based on a graph database, it stores required knowledge graph data, including entity tables, relation tables, and attribute tables, supporting efficient graph querying and association analysis.
[0027] (2) Technical layer The technology layer provides core technical support for the system, including: The big data analytics module includes sub-modules for document parsing, text preprocessing, entity recognition, relation extraction, and requirement quality inspection, enabling the transformation of unstructured information into structured entries.
[0028] The knowledge graph management module includes sub-modules for graph modeling, graph construction, graph querying, and change logging, enabling the construction and dynamic management of requirement-related networks.
[0029] Offline security module. Includes sub-modules for data encryption, access control, and offline model updates, ensuring the security of the system during offline operation.
[0030] (3) Functional layer At the functional level, specific functional services are provided to users, including: Requirements information collection and processing functions. Supports importing original documents from multiple sources, automatically completes structured transformation and quality inspection, and generates standardized requirement items.
[0031] Demand graph construction and query functions. Automatically builds a demand knowledge graph, providing demand source tracing and related query functions, and supports quick location of relevant information by demand ID, name, or source document.
[0032] Dynamic requirement change management function. Records requirement change history, analyzes the scope of change impact, generates change reports, and supports change approval process management.
[0033] Requirements statistics and analysis functions. It statistically analyzes indicators such as the quantity, type, status, and number of changes of requirements, generating visual reports (pie charts of requirement type distribution, line charts of change trends, etc.) to support development decisions.
[0034] (4) Application layer At the application level, application services are provided to different roles in aerospace model development, including: ① Research and development management personnel. They can use the system to view the overall progress of requirements and change statistics reports, understand the status of requirements management, and formulate research and development plans.
[0035] ② Requirements Engineer. Utilizes requirements gathering, processing, and change management functions to generate requirements items, conduct quality reviews, and submit change requests.
[0036] ③ Software designers and test engineers: Through the requirements query and correlation analysis functions, they can obtain accurate requirements information, guide software design and test case writing, and understand the impact of requirements changes on design and testing.
[0037] In the technical layer, the big data analytics module is primarily used to solve the problem of automated analysis of multi-source unstructured demand information. Its core components include: a data acquisition and preprocessing submodule, an unstructured information structuring transformation submodule, a multi-dimensional demand quality verification and detection submodule, and a structured item output and integration submodule. For example... Figure 2 As shown.
[0038] The data acquisition and preprocessing submodule uses a document parsing tool to batch acquire multiple source documents such as task requirements and system design reports, supporting various formats including Word, PDF, and Excel. Preprocessing operations such as text cleaning (removing redundant characters and standardizing terminology) and format standardization (extracting headings, paragraphs, and table data) are performed to eliminate data noise.
[0039] The unstructured information structuring submodule, based on Natural Language Processing (NLP) technology, constructs an aerospace requirement entity recognition model to automatically extract key entities such as "requirement item name, indicator requirements, constraints, responsible department, and delivery time" from requirement documents; and uses a relation extraction algorithm to identify the relationships between entities.
[0040] Specifically as follows: A space demand entity recognition model is constructed using a BERT pre-trained model. The model is trained using historical demand data in the space field as the training set. The input of the space demand entity recognition model is the demand document processed by the data acquisition and preprocessing sub-module, which is segmented by paragraph. The output is the entities in the document. Using the trained aerospace requirement entity recognition model, entities are obtained from the input requirement document; For relationships between entities that are clearly defined, regular expressions are used for matching; for relationships between entities that are complex, the BERT-RE model is used to extract relationship conditions. The "entity-relationship" pairs are combined into structured requirement items according to the aerospace requirement standard format.
[0041] The multi-dimensional verification and detection submodule for requirement quality utilizes big data statistical analysis and machine learning algorithms to perform quality checks on structured requirement items, including completeness checks (determining whether key entities are missing), consistency checks (identifying conflicting expressions of the same requirement), and reasonableness checks (judging whether indicators conform to the conventional range in the aerospace field based on historical data). It automatically marks abnormal items and prompts for manual review.
[0042] Specifically as follows: Integrity check: Check whether the required fields of the structured requirements entries are missing, mark the entries with missing fields as "incomplete", and suggest possible sources for supplementation; Consistency check: Determine whether the description of the same requirement item is consistent in different documents; Reasonableness check: Based on historical data and by comparing the requirements of similar aerospace models, determine whether the logical relationship between the item indicators is reasonable; Based on the above testing, a "Requirement Quality Inspection Report" is generated. This report includes qualified items and problematic items, and the problematic items are categorized and statistically analyzed according to their "severity," including serious problems, general problems, and acceptable problems. Serious problems refer to issues such as missing core fields or conflicting key indicators, which require immediate modification. General problems refer to issues such as non-standard terminology or unconfirmed rationality of indicators, which require review and confirmation. Acceptable problems refer to issues such as inconsistent units or missing non-core fields, which will be left for subsequent optimization.
[0043] Structured Item Output and Interface Submodule: The structured requirement items verified and detected by the multi-dimensional verification and detection submodule of requirement quality are reviewed and corrected, and then output to subsequent modules, while retaining the interface for manual intervention.
[0044] The specific implementation is as follows: Requirements engineers manually correct marked problem items using the "Requirements Quality Inspection Report"; The structured entry output and interface submodule will synchronize the qualified and corrected structured entries to the knowledge graph library through an offline interface, providing data support for demand association management. The structured entry output and docking submodule automatically records the entire process log of each entry from "extraction-detection-review-output", including the operator, operation time, and modified content, to ensure traceability.
[0045] The knowledge graph analysis module constructs a requirement association network in the form of "entity-relationship-attribute" triples to achieve dynamic requirement management. Its core functions include: a requirement knowledge graph modeling submodule, a requirement source tracing submodule, and a requirement dynamic change management submodule. For example... Figure 3 As shown.
[0046] ① Requirements Knowledge Graph Modeling Submodule. Requirements knowledge graph modeling mainly involves defining the core entities, relationships, and attributes of the aerospace software requirements domain, constructing a domain ontology model; and converting the structured requirements items generated by big data technology into triple data, storing them in a graph database to form a requirements knowledge graph. ② Requirements Source Traceability Submodule. Requirements source traceability uses graph query statements to quickly locate the source document, extract the relevant chapter, and identify the responsible person for any requirement item.
[0047] ③ Dynamic Requirement Change Management Submodule. The dynamic requirement change management function automatically records the change node in the graph when a requirement changes, including the reason for the change, the content of the change, the time of the change, and the approver. It also analyzes the scope of the change's impact through relationship path analysis, realizing the traceability and controllability of the change.
[0048] The big data analysis module and knowledge graph analysis module of this invention are described in detail below: I. The big data analysis module adopts a three-layer architecture of "data layer - algorithm layer - application layer", with each layer working together to automate the processing of demand information.
[0049] Data Layer. Responsible for accessing and storing multi-source requirement documents, solving the problem of "where does the data come from and where does it go?". Supports commonly used document formats in the aerospace field such as Word, PDF, Excel, and TXT, and achieves encrypted storage of massive amounts of documents through a distributed file system (HDFS). It also interfaces with the terminal's offline data import interface to ensure data security.
[0050] The algorithm layer is the core of the module. Based on technologies such as Natural Language Processing (NLP), machine learning, and statistical analysis, it implements the core logic of "unstructured information extraction - structured transformation - quality verification." Specifically, NLP technology is used to parse the demand entities and relationships in natural language text, machine learning is used to build domain-adaptive recognition models, and statistical analysis is used to verify the rationality of the demands.
[0051] Application Layer. Provides an operation interface for requirements engineers, outputting structured requirements items, quality inspection reports, and other results. It also supports integration with the knowledge graph module, transforming structured data into "entity-relationship-attribute" triples, laying the foundation for subsequent requirements association management.
[0052] The specific implementation steps of the big data analytics module are as follows: Step 1-1: Integrate multi-source requirement documents.
[0053] Objective: To achieve secure access to multiple source documents, including task requirements, system design reports, subsystem design reports, and analysis reports, and to prevent data leakage.
[0054] Document import methods. Supports importing from intranet and offline storage media. When importing offline media, it must pass triple verification: "terminal authentication - file virus scan - format compatibility test"; For large-scale projects (satellites, rockets) with batch documents (1000+ documents), a distributed offline import tool is supported. Import efficiency is improved through multi-node parallel processing, with a single node capable of processing 500 documents per hour.
[0055] Documents are categorized and stored. The directory structure is built according to "source of requirements + development stage".
[0056] Steps 1-2: Document preprocessing.
[0057] Objective: To remove redundant information from documents, standardize formatting and terminology, and lay the foundation for subsequent structured transformation.
[0058] First, format standardization is implemented, using appropriate technical means to process various common file formats.
[0059] For PDF documents, OCR (Optical Character Recognition) technology is used to extract text content from scanned documents, combined with PDF parsing tools to extract editable text, ensuring a text extraction accuracy rate of ≥99.5%. For Word / Excel documents, extract headings, paragraphs, and table data, and convert the table data into a row-column structured format to avoid information loss caused by nested tables. For complex formulas / charts, mathematical formula recognition tools are used to extract the formula content, data points in the charts are converted into numerical sequences, and text cleaning and terminology standardization are performed.
[0060] Remove redundant information. Delete headers, footers, watermarks, blank paragraphs, and duplicate expressions from the document; Standardized terminology. Based on a terminology database for the aerospace sector, non-standard expressions are automatically replaced.
[0061] Steps 1-3: Transform unstructured information into structured information.
[0062] Objective: To extract the required format from the preprocessed text and form structured requirement entries for key entities in the format of "requirement item name, indicator requirements, constraints, responsible department, delivery time, and source document".
[0063] ① Key entity recognition based on BERT-NER model Model training. Using historical demand data in the aerospace field as the training set (containing 50,000+ labeled samples), an "Aerospace Demand Entity Recognition Model" was constructed based on a BERT pre-trained model.
[0064] Recognition process: The preprocessed text is segmented into "paragraphs" and input into the model for entity annotation.
[0065] ② Entity Relationship Extraction Based on Rules and Deep Learning Rule extraction. For explicitly stated relationships, regular expressions are used for matching.
[0066] Deep learning extraction. For complex relationships, the BERT-RE model is used to extract relation conditions.
[0067] Relationship definition. Consistently output all core relationships to ensure the integrity of structured entries.
[0068] Structured entry generation. Entities and relationships are combined into structured entries according to the aerospace requirements standard format.
[0069] Steps 1-4: Multi-dimensional verification and inspection of demand quality.
[0070] Objective: To identify issues of completeness, consistency, and reasonableness in structured entries, and to ensure that the requirements information is accurate and reliable.
[0071] Integrity check. Check if any required fields of a structured entry are missing. Mark entries with missing fields as "incomplete" and suggest possible sources for supplementation.
[0072] Consistency check. Cross-document consistency: comparing the descriptions of the same requirement item in different documents.
[0073] Reasonableness verification. Based on historical data verification, compare the requirements of similar aerospace models, verify the logical reasonableness, and check the logical relationships between the indicators.
[0074] Inspection report generation. Output the "Requirement Quality Inspection Report," categorizing issue items by "severity." Serious issues such as missing core fields or conflicting key indicators require immediate correction; general issues such as non-standard terminology or unconfirmed indicator rationality require review and confirmation; minor issues such as inconsistent units or missing non-core fields can be optimized later.
[0075] Steps 1-5: Output and integration of structured entries.
[0076] Objective: To output qualified structured requirements items to subsequent modules while retaining the interface for manual intervention.
[0077] Item review and correction. Requirements engineers can view structured items and quality inspection reports through the terminal and manually correct marked problematic items. The system supports "batch review" and "single item correction". Items without problems are marked as "passed". Corrected items are re-triggered for quality inspection to ensure that no new problems arise after correction.
[0078] Item output format. Local storage, stored on the server in Excel and XML formats, allowing requirements engineers to download and view; Integration with the knowledge graph module: Transforms structured items into "entity-relationship-attribute" triples, and synchronizes them to the knowledge graph library via an offline interface, providing data support for requirements association management; Log recording. Automatically records the entire process of "extraction-detection-approval-output" for each entry, including the operator, operation time, and modified content, ensuring traceability.
[0079] II. Knowledge Graph Analysis Module: As a structured knowledge representation technology based on "entity-relationship-attribute," knowledge graphs can break down information silos and construct a full-link network of requirement relationships, providing visualized, traceable, and reasonable technical support for requirement analysis. The implementation steps of knowledge graphs in requirement analysis are as follows: Step 2-1: Design of aerospace software requirements knowledge graph.
[0080] Objective: Define the entities, relationships, attributes, and constraint rules of the graph to form a standardized graph schema and avoid confusion in subsequent construction.
[0081] Requirements gathering and entity design. Collaborate with overall engineers, software engineers, and requirements engineers to conduct requirements gathering, clarify the core scenarios for requirements analysis, and determine the types of entities to be covered.
[0082] Rule base design. Design the reasoning rules and constraint rules required for requirements analysis.
[0083] Tool selection and environment setup. Select a graph database that supports offline deployment to ensure compliance with aerospace data security requirements; build a graph visualization and analysis tool that supports graph query, path analysis, conflict marking, and other functions. Step 2-2: Access and preprocessing of demand data.
[0084] Objective: To extract structured information from multi-source demand data to provide high-quality data for map construction. This part involves accessing data from the big data analytics module.
[0085] Steps 2-3: Knowledge graph construction.
[0086] Objective: To transform preprocessed requirement data into "entity-relationship-attribute" triples, import them into a graph database, and form a complete requirement knowledge graph.
[0087] Entity creation. Batch create graph entities by entity type. Entity creation supports batch import, with a single batch capable of importing 100,000+ entities.
[0088] Relationship Construction. Based on the preprocessed data and the relationship types defined in the graph schema, the associations between entities are constructed using a combination of rule matching and manual completion, ensuring the accuracy and completeness of the relationships. Automated relationship building. For relationships with clear data connections, relationships are created in batches using SQL queries and Cypher statements. For relationships based on logical judgments, automatic matching is triggered based on a rule base.
[0089] Manual completion and review. For complex relationships that fail to be automatically constructed, requirements engineers and test engineers collaborate to complete them. They manually drag and drop entities to create relationships in the visualization platform and fill in the relationship attributes. The automatically constructed relationships are manually reviewed at a sampling rate of 10%, with a focus on checking "numerical conflict relationships" and "logical contradiction relationships". The review pass rate must be ≥98%. Relationships that fail the review are returned to the data preprocessing stage for correction.
[0090] Graph quality verification and optimization. Integrity verification: Counting the number of entities with no relationships using Cypher queries; Consistency verification: Checking the consistency of attributes and relationship logic for the same entity, marking anomalies and triggering manual handling; Redundancy cleanup: Deleting duplicate entities and invalid relationships, optimizing the graph storage structure, and improving subsequent query efficiency.
[0091] Steps 2-4: Application of knowledge graphs.
[0092] Based on the completed requirements knowledge graph and combined with the core scenarios of aerospace software development, the automation and intelligence of requirements analysis are realized. This includes applications for requirements sourcing, requirements conflict detection, change impact analysis, requirements coverage analysis, and multi-department collaborative analysis.
[0093] Steps 2-5: Maintenance and optimization of the knowledge graph.
[0094] Aerospace software development has a long cycle, and requirements change dynamically with each development stage. Therefore, a long-term maintenance mechanism is needed to ensure the timeliness and accuracy of the software specifications. This includes routine maintenance, phased maintenance, long-term optimization, and security maintenance.
[0095] This invention discloses a dynamic management system for aerospace software requirements based on knowledge graph and big data technologies. The solution integrates knowledge graph and big data technologies, automatically analyzing raw information such as mission requirements, system design reports, subsystem design reports, and various analysis reports to generate standardized and structured requirement entries. It utilizes knowledge graph technology to construct a requirement association network, ensuring traceability of requirement entry sources and providing evidence for dynamic changes. An offline processing mode ensures aerospace information security. Preliminary verification shows that this solution can shorten the requirement information processing cycle by more than 60% and increase the structuring rate of key information to 95%, providing technical support for dynamic management of aerospace software requirements.
[0096] The parts of this invention not described in detail are common knowledge to those skilled in the art.
Claims
1. A dynamic management system for aerospace software requirements based on graph and big data technologies, characterized in that: It includes the data layer, technology layer, functional layer, and application layer; Data layer: Responsible for storing multi-source demand information and graph data. The multi-source demand information includes a raw document library and a structured demand library; the graph data includes a knowledge graph library. The technical layer includes a big data analysis module and a knowledge graph management module. The big data analysis module enables automated analysis of multi-source unstructured demand information. The knowledge graph management module constructs a demand association network in the form of "entity-relationship-attribute" triples to achieve dynamic demand management. Functional layer: Based on the big data analysis module and knowledge graph management module used for the technical layer of demand invocation, it provides users with demand information collection and processing functions, demand graph construction and query functions, demand dynamic change management functions, and demand statistics and analysis functions; Application layer: Provides application services for different roles in research and development.
2. The aerospace software requirement dynamic management system based on graph and big data technology according to claim 1, characterized in that: The original document library stores original documents of task requirements, system design reports, subsystem design reports and various analysis reports in an encrypted format, and sets access permissions; The structured requirements library stores standardized requirements entries processed by the big data analytics module; The knowledge graph library is based on a graph database to store required knowledge graph data, including entity tables, relation tables, and attribute tables, and supports graph querying and association analysis.
3. The aerospace software requirement dynamic management system based on graph and big data technology according to claim 1, characterized in that: The big data analysis module includes a data acquisition and preprocessing submodule, an unstructured information structure transformation submodule, a multi-dimensional verification and detection submodule for demand quality, and a structured item output and docking submodule. Data Acquisition and Preprocessing Submodule: This module receives multi-source requirement documents from the data layer, including task requirements, system design reports, subsystem design reports, and analysis reports. It then performs format standardization processing on the received multi-source documents, removing redundant information and unifying the format and terminology. The unstructured information structuring transformation submodule: Based on natural language processing technology, it constructs an aerospace requirement entity recognition model, automatically extracts key entities from the requirement documents processed by the data acquisition and preprocessing submodule, identifies the relationships between entities, and forms structured requirement items; the key entities include requirement item name, indicator requirements, constraints, responsible department, and delivery time; The multi-dimensional verification and inspection submodule for requirement quality checks and inspects the completeness, consistency, and reasonableness of structured requirement items, automatically marks abnormal items, and prompts for manual review. Structured Item Output and Interface Submodule: The structured requirement items verified and detected by the multi-dimensional verification and detection submodule of requirement quality are reviewed and corrected, and then output to subsequent modules, while retaining the interface for manual intervention.
4. The aerospace software requirement dynamic management system based on graph and big data technology according to claim 3, characterized in that: The data acquisition and preprocessing submodule performs format standardization processing on the received multi-source requirement documents, removing redundant information and standardizing the format and terminology, as follows: (1) Standardize the format of the received multi-source documents. For PDF documents: Optical character recognition technology is used to extract the text content in the document, and editable text is extracted in combination with PDF parsing tools; For Word / Excel documents: Extract headings, paragraphs, and table data, and convert the table data into a row-column structured format; For complex formulas / charts: Use mathematical formula recognition tools to extract formula content and convert data points in charts into numerical sequences; (2) Delete redundant information, including headers and footers, watermarks, blank paragraphs, and duplicate expressions in the document; (3) Automatically replace non-standard expressions based on the terminology database of aerospace requirements.
5. The aerospace software requirement dynamic management system based on graph and big data technology according to claim 3, characterized in that: The unstructured information to structured transformation submodule generates structured requirement items, as follows: A space demand entity recognition model is constructed using a BERT pre-trained model. The model is trained using historical demand data in the space field as the training set. The input of the space demand entity recognition model is the demand document processed by the data acquisition and preprocessing sub-module, which is segmented by paragraph. The output is the entities in the document. Using the trained aerospace requirement entity recognition model, entities are obtained from the input requirement document; For relationships between entities that are clearly defined, regular expressions are used for matching; for relationships between entities that are complex, the BERT-RE model is used to extract relationship conditions. The "entity-relationship" pairs are combined into structured requirement items according to the aerospace requirement standard format.
6. The aerospace software requirement dynamic management system based on graph and big data technology according to claim 3, characterized in that: The multi-dimensional verification and inspection submodule for requirement quality verifies and inspects the completeness, consistency, and rationality of structured requirement items, as detailed below: Integrity check: Check whether the required fields of the structured requirements entries are missing, mark the entries with missing fields as "incomplete", and suggest possible sources for supplementation; Consistency check: Determine whether the description of the same requirement item is consistent in different documents; Reasonableness check: Based on historical data and by comparing the requirements of similar aerospace models, determine whether the logical relationship between the item indicators is reasonable; Based on the above tests, a "Requirement Quality Inspection Report" is generated. The "Requirement Quality Inspection Report" includes qualified items and problematic items, and the problematic items are classified and statistically analyzed according to "severity", including serious problems, general problems, and acceptable problems. Serious problems refer to issues such as missing core fields or conflicting key indicators, which need to be corrected immediately. General issues refer to problems such as non-standard terminology and unconfirmed rationality of indicators, which require review and confirmation; acceptable issues refer to problems such as inconsistent units and missing non-core fields, which will be left for subsequent optimization.
7. The aerospace software requirement dynamic management system based on graph and big data technology according to claim 6, characterized in that: The specific implementation of the structured entry output and docking submodule is as follows: Requirements engineers manually correct marked problem items using the "Requirements Quality Inspection Report"; The structured entry output and interface submodule will synchronize the qualified and corrected structured entries to the knowledge graph library through an offline interface, providing data support for demand association management. The structured entry output and docking submodule automatically records the entire process log of each entry from "extraction-detection-approval-output", including the operator, operation time, and modified content, to ensure traceability.
8. The aerospace software requirement dynamic management system based on graph and big data technology according to claim 1, characterized in that: The knowledge graph analysis module includes a requirement knowledge graph modeling submodule, a requirement source tracing submodule, and a requirement dynamic change management submodule; The requirement knowledge graph modeling submodule defines the core entities, relationships, and attributes of the aerospace software requirement domain and constructs a domain ontology model; it transforms the structured requirement entries generated by the big data analysis module into triple data, stores them in a graph database, and forms a requirement knowledge graph. Demand Source Traceability Submodule: Quickly locate the source document, extract the chapter and relevant responsible person for any demand item through graph query statements; The dynamic change management submodule for requirements automatically records the change node in the graph when requirements change, including the reason for the change, the content of the change, the time of the change and the approver. It also analyzes the scope of the impact of the change through relationship path analysis, so as to achieve traceability and controllability of the change.
9. The aerospace software requirement dynamic management system based on graph and big data technology according to claim 1, characterized in that: The requirement knowledge graph modeling submodule includes an aerospace software requirement knowledge graph design unit, a requirement data access and preprocessing unit, and a knowledge graph construction unit. Aerospace Software Requirements Knowledge Graph Design Unit: Defines the entities, relationships, attributes, and constraint rules of the graph to form a standardized graph pattern; Demand data access and preprocessing unit: Extracts structured demand items from the big data analysis module; Knowledge graph construction unit: The extracted structured requirement items are transformed into "entity-relationship-attribute" triples, imported into a graph database, and a complete requirement knowledge graph is formed; The knowledge graph construction submodule includes: Entity building sub-unit: Batch creation of graph entities according to entity type; Relationship building subunit: Based on the relationship types defined by structured requirement items and graph patterns, the association relationships between entities are built through "rule matching + manual completion"; Automated Relationship Building Subunit: For relationships with clear data connections, batch creation of relationships is achieved through SQL queries and Cypher statements; for relationships based on logical judgments, automatic matching is triggered based on a rule base. Manual completion and review sub-unit: For complex relationships that fail in automated builds, an interactive interface is provided for requirements engineers and test engineers to collaboratively complete the necessary parts.
10. A dynamic management system for aerospace software requirements based on graph and big data technology according to claim 9, characterized in that: The knowledge graph construction unit also includes a graph quality verification and optimization subunit; The spectrum quality verification and optimization subunit: The Cypher query is used to count the number of entities with no relation to each other in the constructed knowledge graph. If any are found, they are marked and manual processing is triggered. Check the consistency of attributes and relational logic for the same entity. If they are inconsistent, mark it as an anomaly and trigger manual processing. Remove duplicate entities and invalid relationships.
11. The aerospace software requirement dynamic management system based on graph and big data technology according to claim 1, characterized in that: At the functional level, functional services are provided to users, as follows: Requirements information collection and processing function: Supports importing original documents from multiple sources in the data layer, calling the big data analysis module to automatically complete structured transformation and quality inspection, and generate standardized requirements items; Demand graph construction and query function: Automatically constructs demand knowledge graph by calling the knowledge graph management module, providing demand source tracing and related query functions, and can quickly locate relevant information by demand ID, name or source document; Dynamic requirement change management function: Records requirement change history, analyzes the scope of change impact, generates change reports, and supports change approval process management. Requirements statistics and analysis function: It can count the number, type, status and number of changes of requirements, generate visual reports, and provide support for research and development decisions.
12. The aerospace software requirement dynamic management system based on graph and big data technology according to claim 1, characterized in that: At the application level, application services are provided to different roles in research and development, including: For R&D management personnel: Provides services such as viewing the overall progress of requirements, changing statistics reports, understanding the status of requirements management, and formulating R&D plans; For requirements engineers: Use the requirements information collection and processing function and the requirements dynamic change management function to complete the generation of requirements items, quality review and change requests; For software designers and test engineers: Through the requirements mapping and query functions, obtain accurate requirements information to guide software design and test case writing, and understand the impact of requirements changes on design and testing.
