Design specification generation method for ship data management system

Abstract

The invention relates to a design specification generation method of a ship data management system, and belongs to the field of ship design. The method comprises the following steps: designing a standardized demand specification and a design specification template; filling a historical document as an input basis for subsequent generation; detecting differences based on a text comparison technology and generating a change report; in combination with the demand classification template and a large language model workflow based on a demand analysis framework, analyzing the newly added demand, and generating a standardized demand description; generating modification suggestions and filling the modification suggestions into a template in a classified manner; intelligently allocating tasks by using a workflow routing mechanism of a large language model; modular design content is generated; and integrating contents through a template engine and carrying out multiple rounds of verification. According to the method, the generation and updating efficiency of the design specification is greatly improved through automatic and intelligent means, manual intervention is reduced, the consistency and accuracy of documents are ensured, and the standardization and high efficiency of the ship data management system design process are greatly improved.

Description

Technical Field

[0001] The present invention relates to the technical field of ship data management systems, and in particular to a design specification generation method for ship data management systems. Background Art

[0002] In the design and development process of ship data management systems, the frequent changes and diversified requirements make the writing and updating of design specifications complicated and cumbersome. Traditional design specification generation methods usually rely on manual operations, which require analyzing requirement changes one by one and manually adjusting document content. This method is not only inefficient, but also prone to deviations in subsequent system generation due to missing information or untimely version updates, affecting project progress and quality.

[0003] At present, there are some methods that use computer technology to assist in the automatic generation of design specifications, but most of them focus on the static generation of documents and lack dynamic response and real-time update to changes in requirements. The design specifications of ship data management systems usually contain multiple functional modules, performance requirements, interface design, safety specifications, etc., and these contents will be frequently adjusted as requirements change. Therefore, there is an urgent need for an intelligent technical means that can automatically and accurately generate and update design specifications based on changes in requirements, ensure the accuracy, consistency and standardization of documents, and thus meet the project requirements and technical specifications of the shipbuilding industry. Summary of the invention

[0004] The present invention provides a design specification generation method for a ship data management system, so as to solve the problem of how to realize the automatic generation and efficient update of the design specification of a ship data management system based on standardized requirements and historical design specifications through intelligent text comparison, parsing and modular generation methods, so as to ensure the accuracy, consistency and standardization of the documents and meet the project requirements and technical specifications.

[0005] In order to solve the above technical problems, the present invention provides a method for generating a design specification for a ship data management system, comprising:

[0006] Design standardized requirement specifications and design manual format templates, clearly defining the core elements included;

[0007] Fill in historical requirements specifications and design specifications, and serve as the input basis for subsequent document generation;

[0008] Detect differences between the requirements specification and the design manual based on text comparison technology, identify new, modified and / or deleted content, and generate a change report;

[0009] Combine the requirement classification template and the large language model workflow based on the requirement parsing framework to parse new requirements, generate standardized requirement descriptions, and analyze internal differences and conflicts in requirements;

[0010] Generate modification suggestions based on standardized requirements and design specifications, and fill them into the template in categories;

[0011] Using the workflow routing mechanism of the large language model, tasks are intelligently assigned to corresponding modules based on the different categories of modification opinions to generate content;

[0012] Generate modular design content through a large language model based on modification suggestions;

[0013] The template engine integrates the content generated by each module and performs multiple rounds of verification to verify the accuracy and consistency of the design specifications.

[0014] Furthermore, the step of detecting differences between the requirement specification and the design specification based on text comparison technology specifically includes:

[0015] Perform a text comparison between the historical requirement specification and the new requirement specification, identify the newly added, modified and / or deleted content through text comparison technology, and generate difference information.

[0016] Furthermore, the step of generating a change report specifically includes:

[0017] The changed content is extracted from the difference information, and a change report is generated, indicating the specific content that is added, modified and / or deleted.

[0018] Furthermore, the step of combining the demand classification template and the large language model workflow based on the demand parsing framework to parse the new demand specifically includes:

[0019] Obtain new requirements, conduct preliminary analysis through the requirements classification template, extract key requirements information, and perform structured processing;

[0020] The new requirements are input into the large language model for parsing, and a standardized requirement description is generated through model reasoning.

[0021] Furthermore, the step of generating a standardized requirement description specifically includes:

[0022] Based on the structured demand information, a detailed demand description is generated through a large language model and organized into a demand expression in a standardized format.

[0023] Furthermore, the step of generating modification suggestions and filling them into the template by category specifically includes:

[0024] Generate modification suggestions based on standardized requirements and historical design specifications, and classify them according to their categories to identify the modules and parts that need to be changed;

[0025] The generated modification suggestions are filled into the standardized template by category.

[0026] Furthermore, the workflow routing mechanism using the large language model to intelligently assign tasks to corresponding modules according to the categories of modification opinions specifically includes:

[0027] After obtaining the modification opinions, tasks are intelligently assigned to relevant modules for processing based on the categories of the modification opinions through the workflow routing mechanism of the large language model.

[0028] Furthermore, the step of generating modular design content through a large language model based on the modification suggestions specifically includes:

[0029] The modification opinions are input into the large language model, and the design content of the corresponding module is generated according to the modification opinions.

[0030] Furthermore, the step of generating modular design content specifically includes:

[0031] Adjust the content generated by each module in the workflow based on the task routing results.

[0032] Furthermore, the step of integrating the modules to generate content through the template engine specifically includes:

[0033] The template engine is used to merge the contents of each module into a complete design specification in a standardized format.

[0034] The key innovative features of the present invention include:

[0035] (1) Standardized template design and automated filling: By standardizing templates and filling historical documents, the generation process of ship data management system design documents is automated, avoiding the errors and tediousness of manual operations.

[0036] (2) Text comparison technology and difference detection: Based on text comparison technology, it automatically identifies and processes new, modified or deleted content in design documents to ensure the accuracy of updated content.

[0037] (3) Large language model and workflow routing mechanism: The large language model is used to analyze demand changes, and the workflow mechanism is used to intelligently assign tasks and generate modular design content, thereby ensuring that each design module accurately matches the demand changes.

[0038] The present invention realizes the automatic generation and efficient update of the design specification of the ship data management system by adopting the design specification generation method based on the large language model and intelligent text comparison technology. Compared with the traditional method of manually writing and manually updating the design document, the present invention shows significant beneficial effects in many aspects:

[0039] First, by designing standardized requirement specifications and design manual templates and filling in historical requirement documents as the input basis, the present invention realizes the standardization and structured processing of complex ship data management system design requirements, effectively avoiding common errors and omissions in the manual editing process, and ensuring the consistency and accuracy of the document content.

[0040] Secondly, text comparison technology is used to detect differences between requirement specifications and design instructions, which can accurately identify new, modified or deleted content and generate change reports. Compared with traditional manual comparison, it greatly improves the efficiency of document updates and reduces errors.

[0041] Finally, by utilizing the workflow routing mechanism of the large language model, tasks are intelligently assigned to corresponding modules according to the different categories of modification opinions, ensuring that the generated design content accurately corresponds to the changes in requirements in terms of function, performance, interface, etc., and can realize the automatic generation of modular design content, greatly improving the degree of automation of document generation and updating. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 A flowchart of a method for generating a design specification for a ship data management system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by technicians in the technical field of the present application; the terms used in the specification of the application herein are only for the purpose of describing specific embodiments and are not intended to limit the present application; the terms "including" and "having" and any variations thereof in the specification and claims of the present application and the above-mentioned drawings are intended to cover non-exclusive inclusions. The terms "first", "second", etc. in the specification and claims of the present application or the above-mentioned drawings are used to distinguish different objects, not to describe a specific order.

[0044] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0045] Example 1: Reference Figure 1 , is a flow chart of a method for generating a design specification for a ship data management system provided by an embodiment of the present invention. The flow chart may include at least steps S100-S800:

[0046] S100, design standardized requirements specifications and design manual format templates, clearly including the core elements;

[0047] S200, fill in the historical requirements specification and design manual, and use it as the input basis for subsequent document generation;

[0048] S300, based on text comparison technology, detect differences between the requirements specification and the design specification, identify new, modified or deleted content, and generate a change report;

[0049] S400, parse the new requirements by combining the requirements classification template and the large language model workflow based on the requirements parsing framework, and describe the new requirements in detail, generate standardized requirements descriptions, and analyze internal differences and conflicts in requirements;

[0050] S500, based on the standardized requirements and design specifications, generate modification suggestions and fill them into the template by category;

[0051] S600, using the workflow routing mechanism of the large language model, intelligently assigning tasks to corresponding modules according to different categories of modification opinions to generate content;

[0052] S700, based on the modification suggestions, generate modular design content through the large language model;

[0053] S800, integrates the content generated by each module through the template engine, performs multiple rounds of verification, and verifies the accuracy and consistency of the design specification.

[0054] Step S100 at least includes steps S110-S130:

[0055] S110: Obtain the core elements of the requirements specification and design manual of the ship data management system, analyze them, and obtain the design structure of the standardized template.

[0056] First, obtain the core elements of the requirements specification and design manual of the ship data management system. Specifically, the "core elements" include system function modules, data processing requirements, system interface definitions, data storage requirements, security requirements, and performance requirements. By analyzing these elements, the preliminary design structure of the standardized template can be obtained.

[0057] First, obtain the core elements of the requirements specification and design manual. From the requirements document of the ship data management system, first extract all the core elements, such as:

[0058] System functional modules: including data acquisition, transmission, processing, storage and other functions.

[0059] Data processing requirements: Requirements that describe how data is processed, stored, and analyzed.

[0060] Interface definition: interface requirements between the system and external devices and systems, including communication protocols, data formats, etc.

[0061] Performance requirements: performance indicators in terms of system response time, processing speed, throughput, etc.

[0062] Security requirements: data security, privacy protection, user permissions and other related requirements.

[0063] Further, an analysis is conducted to obtain the design structure of the standardized template. The extracted core elements are analyzed to determine the position and importance of each element in the design specification. For example, data processing requirements can be located in the early part of the design specification, while interface definitions and system function modules can be placed in the later part. Through this structured analysis, the preliminary framework structure of the standardized template is obtained. This structure should ensure that each element has a clear description and definition so that it can be accurately filled in the subsequent design specification.

[0064] Further, summarize the design structure of the core elements and modules. According to the analysis results, determine the design structure of the template. The design structure includes the following parts:

[0065] Introduction: includes system overview, demand background, design goals, etc.

[0066] Core module part: including system functions, data processing requirements, performance requirements, security, etc.

[0067] Appendix: includes technical references, term definitions, interface descriptions, etc.

[0068] The output of this step is a standardized template structure that meets the requirements of ship data management systems, contains core elements and provides a basis for subsequent modular design.

[0069] S120: Design a standardized requirement specification format template based on industry standards and ship design specifications, and clearly include the core elements, such as system functional modules and data processing requirements.

[0070] In this step, standardized requirement specifications and design manual templates are further refined and designed based on industry standards and ship design specifications to ensure that the format is standardized and contains all necessary core elements.

[0071] First, design the template according to industry standards and ship design specifications. Refer to the common ship data management system design specifications and standards in the industry to ensure that the format of the template meets the current technical standards and specifications. Specifically, industry standards include:

[0072] Ship design standards of the International Organization for Standardization (ISO);

[0073] Data transmission and storage security requirements in ship safety management regulations;

[0074] Ship information technology system standards (such as ship automation, navigation systems, etc.);

[0075] Standard requirements for data formats and communication protocols.

[0076] Based on these standards, design the structure of the template and clarify the definition and location of the core elements in each module. For example, the system function module in the design specification may need to list each function of the system in detail, and the data processing requirements may involve specific data formats, processing rules, storage requirements, etc.

[0077] Furthermore, clarify the content requirements of each core element in the template. In the template, clarify the specific content and format requirements of each core element. For example:

[0078] System function module: For each function in the ship data management system, the template needs to define the input, output, processing flow and exception handling flow of the function.

[0079] Data processing requirements: It is necessary to clarify specific requirements such as data input source, data cleaning, processing logic, storage method, etc.

[0080] Interface definition: describes the data interaction method between the system and external devices or subsystems, including protocols, formats, communication frequencies, etc.

[0081] Performance requirements: The template requires performance criteria such as response time, data throughput, and maximum load to be specified.

[0082] Security requirements: Security measures such as data encryption, user authentication, and data access permissions need to be defined.

[0083] Furthermore, ensure the uniformity and standardization of the template format. Based on the above analysis, design a standardized requirement specification format template, and ensure that the structure, content and format of the template meet the specifications. By defining the core elements in the standardized template, ensure that the template is uniformly applied in different projects, thereby avoiding design problems caused by project differences.

[0084] For example, all interface definition modules in the template are described using the same format, and all data processing modules should be described in the prescribed order and structure to ensure that the template can be processed uniformly when filling in requirements and designing content later.

[0085] S130: Based on the standardized design template, define the format of the ship system requirements specification and design manual to ensure that the format meets the standardization requirements and obtain a structured template.

[0086] First, in this step, the formats of the ship system requirements specifications and design instructions are further refined and defined based on the designed standardized template, and ensure that the format meets the standardization requirements.

[0087] Furthermore, the format of the ship system requirements is defined based on the standardized template. Based on the standardized template obtained in the previous step, the format of the requirements specification is further refined in combination with the specific requirements of the ship system. For example, the system function module part needs to define the function description, data flow, operation process, interface requirements, etc. of each function module in detail; the data processing requirements part needs to define specific data processing steps, storage requirements, fault-tolerant processing, etc.

[0088] Specifically, each core element involved in the ship system is disassembled in detail to ensure that the description of each element has a clear format and specification and complies with industry standards and ship design specifications.

[0089] Furthermore, ensure that the structure of the requirements specification and design manual is consistent with the ship design requirements. For example, the design manual of a ship data management system should include the following parts:

[0090] System Overview: Briefly describe the functions, architecture, main features, etc. of the ship data management system.

[0091] Functional module: Describe in detail the function, input and output, data flow, etc. of each functional module.

[0092] Data storage and processing requirements: clarify data storage methods, database structure, data processing procedures, etc.

[0093] Interface design: describes the interface standards, protocols, etc. with other systems or modules.

[0094] Through the above steps, the standardized template is converted into the structure of the actual requirements specification and design manual of the ship system. The final template will have a structured format, contain all the necessary core elements, and can be directly applied in the subsequent document generation process.

[0095] For example, the system function module part in the template will be filled with the detailed content of each module according to the design specifications, and the data processing part will be filled with the corresponding data format and processing flow according to the actual system requirements.

[0096] Step S200 at least includes steps S210-S230:

[0097] S210: Obtain historical versions of requirement specifications and design instructions, fill them into standardized templates, and ensure that the documents comply with the template structure and requirements.

[0098] First, obtain the historical version of the requirements specification and design manual through the version control tool (such as Git, etc.) of the ship data management system. Specifically, the historical version document includes:

[0099] Requirements Specification: records the system functional requirements, performance requirements, data processing requirements, etc. defined in the previous version.

[0100] Design specification: describes in detail the specific design contents such as system architecture, module design, interface definition, etc.

[0101] These documents provide a reference for the subsequent filling of standardized templates. Understandably, these historical version documents contain a lot of key information of ship data management systems, and further, this information needs to be integrated into the new standardized templates.

[0102] Furthermore, after obtaining the historical version document, the document content (such as functional module description, data storage design, etc.) should be filled in according to the pre-designed standardized template. Specifically:

[0103] Functional module: Extract the functional module part from the historical requirement specification, such as "data acquisition module", "data processing module", etc., and fill it into the corresponding position according to the definition of the standardized template.

[0104] System design part: Extract system architecture, interface definition, technical specifications and other contents from the design specification and fill them in according to the template requirements.

[0105] Safety and performance requirements: Obtain the system's safety and performance requirements from historical documents and fill in the relevant parts of the design specification.

[0106] The goal of this step is to ensure that each part of the historical document content can be accurately reflected in the standardized template and conform to the structure and requirements of the template. Through this step, the historical document information will be effectively converted into a unified and standardized format, laying the foundation for the generation of subsequent content.

[0107] After the filling is completed, the filling content is further checked to see if it meets the template structure and content requirements. This step includes:

[0108] Format alignment: Check whether the titles, paragraph formats, numbering, etc. of each part of the document meet the format requirements of the standardized template.

[0109] Content integrity check: Ensure that all core content (such as functional modules, data processing requirements, interface design, etc.) have been filled in the corresponding template positions without omissions.

[0110] Document consistency verification: Compare historical documents with filled template documents to ensure content consistency and avoid omissions or errors.

[0111] The output of this step is a document that has been populated and conforms to the template structure requirements, serving as the basis for subsequent document generation.

[0112] S220: Extract valid information from historical requirement specifications, such as functional modules, process design, and technical specifications, fill them into the design specification template, and generate a structured document.

[0113] First, in this step, we need to analyze and extract valid information from the historical requirements specification, including:

[0114] Functional module: Extract the specific description of each system functional module, such as "data acquisition module", "data processing module", "interface module", etc.

[0115] Process design: Extract process designs related to system functions, such as data flow, processing logic, control flow, etc.

[0116] Technical Specifications: Extract technical specifications defined in historical documents, including hardware requirements, software platforms, communication protocols, etc.

[0117] The extraction process of effective information involves classifying and organizing various types of information in the document to ensure that the information meets the standardization requirements after extraction. Specifically, the goal of this extraction process is to organize the scattered information in the historical document into an organized structure.

[0118] Furthermore, the extracted valid information is filled into the corresponding part of the design specification template. The specific filling content is as follows:

[0119] Functional module filling: Fill each functional module description in the historical requirement specification into the design specification template to ensure that the module functions are clearly and accurately displayed.

[0120] Fill in process design: Fill in information such as data flow and processing flow into the process design part of the design specification template to ensure that the system workflow can be clearly displayed in the design document.

[0121] Fill in technical specifications: Fill in technical specifications, hardware requirements, protocols and other information into the technical specifications section of the design specification template to ensure that it meets the technical requirements of the project.

[0122] In this step, the information is not only extracted from historical documents, but also needs to be sorted and classified to meet the structural requirements of the design specification.

[0123] Furthermore, after filling in valid information, a structured document is generated. The characteristics of a structured document are:

[0124] Clear hierarchy: Each part of the content is organized into levels, and the functional modules, process design, technical specifications and other contents are independent and interconnected.

[0125] Complete content: All key information from historical documents has been extracted and filled into the design specification template without omission.

[0126] Unified format: All content is arranged according to the format requirements of the standardized template to ensure the uniform format of the document.

[0127] The output of this step is a structured design specification that has been filled in and organized with valid information from the historical requirements specification to facilitate subsequent document modification and updating.

[0128] S230: Use the filled historical requirement specifications and design instructions as the input basis for subsequent document generation to ensure that the new version of the document maintains consistent and standardized format when updated.

[0129] First, in this step, the filled historical requirements specifications and design specifications will serve as the input basis for subsequent document generation. Specifically, these filled documents provide preliminary data for subsequent version document updates.

[0130] For example, assuming that the system function module description contained in the historical version document already conforms to the template structure, then this part of the content will directly serve as the basis for the module in subsequent versions to avoid re-modification.

[0131] Similarly, the data processing requirements, technical specifications and other parts of the historical documents will provide reference for the new version of the documents.

[0132] Furthermore, when updating the new version of the document, the filled document content is used for revision to ensure that the new document maintains a format consistent with the standardized template. The specific steps include:

[0133] Document structure consistency: During the generation of a new version of the document, ensure that each section is aligned with the standardized template without changing the structure and format of the document.

[0134] Content coherence: The content in the historical document should be coherent with that in the new version to ensure that no content is omitted in the new version and that the order and format of the content in each module are consistent.

[0135] After completing the filling and generation of the new version of the document, multiple rounds of verification and validation are performed to ensure that all content meets the template requirements. The verification in this step mainly includes:

[0136] Format verification: Ensure that the format of all content is consistent and meets the requirements of the design specification template.

[0137] Content check: Ensure the accuracy and consistency of the content of the new version of the document, especially the accuracy of key parts such as functional modules and data processing requirements.

[0138] The output of this step is a new version of the design specification that fully complies with the template requirements, ensuring that the document meets the latest standards in both content and format.

[0139] Step S300 at least includes steps S310-S330:

[0140] S310: Compare the historical requirement specification with the new requirement specification, identify the newly added, modified or deleted content through text comparison technology (such as Levenshte in distance algorithm), and obtain difference information.

[0141] First, in this step, the historical version of the requirements specification and the new requirements specification are obtained. Specifically, the "historical requirements specification" contains the old version of the ship data management system's functional requirements, performance requirements, interface definitions, etc., while the "new requirements specification" contains the modified or expanded content.

[0142] When comparing the two, text comparison techniques are used, including the classic Levenshte in distance algorithm (edit distance). This algorithm can calculate the minimum edit distance between two strings, determine the similarity of the text, and identify new, modified or deleted content in the text.

[0143] New content: refers to the content that appears in the new requirements specification but is not included in the previous version.

[0144] Modified content: refers to the content that existed in the historical version and has been modified in the new version (for example, different descriptions, updated parameters, etc.).

[0145] Deleted content: refers to the content that has been removed in the new version.

[0146] By comparing texts and using the results of the Levenshte in distance algorithm, a series of difference information can be obtained. These difference information specifically include:

[0147] Identification of new content: Through algorithm judgment, the new parts that appear in the new version of the requirements specification are marked as "new".

[0148] Identification of modified content: Through comparison, the parts that are similar but different between the historical version and the new version are marked as "modified".

[0149] Marking of deleted content: Content missing from the new version of the requirements specification will be marked as "deleted".

[0150] This difference information will be used for subsequent change report generation.

[0151] The difference information is summarized and output as a preliminary comparison result, which includes the specific content of addition, modification and deletion. This result is the basis for the subsequent generation of change reports and can provide a clear and definite reference for document updates.

[0152] S320: Extract the changed content from the difference detection result, generate a change report, and indicate the specific content that is added, modified or deleted.

[0153] From the difference detection results obtained in step S310, all newly added, modified or deleted contents are extracted. Specifically, the changed contents include:

[0154] New content: such as new modules required by system functions, new data processing procedures, etc.

[0155] Modification content: such as improvement or adjustment of existing functional modules, update of technical requirements, change of interface definition, etc.

[0156] Deleted content: such as removal of original functions, deletion of outdated technical specifications, etc.

[0157] Furthermore, the extracted changes should be listed in detail for subsequent analysis and processing. Each change needs to be marked with the location of the document to ensure that it can be traced and updated in subsequent steps.

[0158] Generate a change report based on the extracted changes. This report will list in detail all the added, modified, and deleted content. The format of the report should be clear and concise to facilitate subsequent document modification and review. The specific contents of the change report include:

[0159] Newly added section: List the modules or requirements that are newly added to the new version of the requirements specification, with descriptions and background information.

[0160] Modifications: List all modifications and note the differences between the original and modified text to ensure the accuracy of the changes.

[0161] Deletion section: List all the content that has been deleted in the new version, and explain the reasons and impact of the deletion.

[0162] The change report will serve as the basis for subsequent document modifications to ensure that the new design instructions and requirement specifications accurately reflect changes in system requirements.

[0163] When generating a change report, you also need to ensure the completeness and standardization of the report. Each change should be clearly identified and should be output in the format required by the template to ensure the accuracy and operability of the report content.

[0164] S330: Classify and organize the identified differences and generate a standardized change report for subsequent processing and document updating.

[0165] In this step, the identified differences are first classified and sorted by type. Specifically, the differences can be divided into the following categories:

[0166] Functional changes: such as new or modified functional modules, process designs, data processing requirements, etc.

[0167] Technical changes: such as changes in interface definitions, updates to technical specifications, adjustments to system architecture, etc.

[0168] Performance changes: such as improvement and optimization of performance requirements.

[0169] Safety changes: such as modifications to safety standards or new safety requirements.

[0170] Each type of change should be clearly identified in the report and listed by category to ensure that subsequent modifications can be made in a targeted manner.

[0171] After the differences are categorized, they are organized and filled into a standardized change report template. The standardized change report template will include the following main parts:

[0172] Change Type: Indicates the specific type of content that is added, modified, or deleted.

[0173] Change Description: Describe the change in detail and provide necessary background information.

[0174] Change impact: Describe the impact of the change on system functions, performance, security, etc.

[0175] Corresponding document part: Indicate the specific document part corresponding to the changed content (such as module name, interface, process, etc.).

[0176] The report format should comply with standardization requirements, ensure clarity and conciseness, and be able to effectively guide subsequent document modification and updating.

[0177] When generating a change report, multiple verifications are required to ensure that the content in the report is accurate. Especially for complex functional and technical changes, the change description must be accurate and unambiguous. At the same time, check whether each change in the report meets the requirements of the document template to ensure consistency in format.

[0178] The output of this step is a standardized, detailed change report, which will serve as the basis for subsequent document updates and modifications to ensure that changes can be effectively recorded and implemented.

[0179] Step S400 at least includes steps S410-S430:

[0180] S410: Obtain new requirements, perform preliminary analysis through the requirement classification template, extract key requirement information, and perform structured processing.

[0181] In this step, new requirements are first obtained from the ship data management system. Specifically, these new requirements can come from multiple input data sources, including:

[0182] Historical requirement change records: obtain the requirement changes through the version management system (such as Git).

[0183] Requirements submitted by the project team: Requirements proposed by the project team based on new technical requirements or customer needs.

[0184] External regulations or industry standards updates: Changes in requirements that may arise from new ship design or management standards.

[0185] The new requirements usually involve adjustments or expansions to system functions, performance, security, etc., such as adding new data processing modules, adjusting security requirements, adding new interface standards, etc.

[0186] After acquiring the new demand data, a pre-designed demand classification template is used to perform a preliminary analysis of the new demand. Specifically, the template classifies the new demand into categories, which include:

[0187] Functional requirements: such as new functional modules and process design added to the system.

[0188] Performance requirements: For example, requirements for performance indicators such as response time and data throughput.

[0189] Technical specification requirements: such as changes in interface protocols, data format requirements, etc.

[0190] Security requirements: such as data encryption requirements, access control requirements, etc.

[0191] Through this template, new requirements are classified into different types of requirements, and the core information of each type of requirements is further extracted, such as:

[0192] Functional requirements: including functional description of the new module, input and output requirements, etc.

[0193] Performance requirements: including performance indicators such as processing speed and system load capacity.

[0194] Technical specification requirements: including new interface standards, data transmission protocols, etc.

[0195] Security requirements: including new security standards, encryption methods, etc.

[0196] After the preliminary analysis, the extracted demand information is structured. This process includes:

[0197] Requirement information organization: organize each requirement according to requirement type, priority, dependency, etc.

[0198] Define requirement items: Through analysis, extract the key parameters of each requirement (such as module name, interface definition, performance indicators, etc.) and store them in a structured format for subsequent processing.

[0199] Ultimately, the structured requirement information will form a standardized requirement description for further parsing through a large language model.

[0200] S420: Input the newly added requirements into the large language model workflow based on the requirements parsing framework for parsing, and generate standardized requirements descriptions through model reasoning to ensure that the requirements are clearly expressed and accurate.

[0201] The newly added requirements that have been structured by the requirements classification template are passed as input data to the pre-trained large language model. The large language model can understand and generate high-quality requirements descriptions, and it can perform the following operations on the newly added requirements:

[0202] Reasoning to generate standardized descriptions: Perform language model reasoning on each requirement item and generate a standardized requirement description based on the given context.

[0203] Ensure clear and accurate expressions: Use the natural language processing capabilities of the language model to ensure that the generated requirements description is clear and accurate to avoid ambiguity and misunderstanding.

[0204] For example, for a newly added data processing module, the input data may include requirements for data input, processing algorithms, and output results, and the large language model will infer a detailed description of the requirements based on the context, such as "the newly added module should be able to process real-time data streams from sensors and store the processing results in a database to support real-time monitoring functions."

[0205] The large language model will generate a detailed requirement description based on the input structured requirement information. The generated description will include:

[0206] Function definition: A specific description of the new function, listing in detail the input and output, processing logic, operation steps, etc.

[0207] Performance requirements: Provide a detailed description of the performance requirements for new features, such as response time, processing speed, throughput, etc.

[0208] Interface definition: Define the interface standards between the new functions and other systems or modules to ensure that the format, protocol and other requirements for data exchange are clear.

[0209] Security requirements: Describe the security requirements of new features, including data encryption, access control, etc.

[0210] Finally, the new requirements parsed by the large language model will be output as standardized requirement descriptions. These descriptions conform to unified standards and are convenient for subsequent document use and updating.

[0211] S430: Analyze the differences and conflicts between new requirements and existing requirements, generate detailed requirements descriptions, and provide adjustment suggestions based on the conflicts between requirements.

[0212] In this step, you first need to compare and analyze the new requirements with the existing requirements. Specifically, analyze the differences between the historical version of the requirements specification and the new requirements, focusing on the following aspects:

[0213] Functional differences: whether the new requirements involve the expansion or modification of existing functions, and whether they conflict with existing functional modules.

[0214] Performance differences: Whether the performance requirements of the new requirements conflict with the existing requirements, such as differences in response time, throughput, etc.

[0215] Technical differences: Whether the technical specifications involved in the new requirements conflict with existing technical requirements, such as interface protocols, data formats, etc.

[0216] Security differences: Whether the new security requirements conflict with existing security requirements and whether they will lead to adjustments to the system architecture.

[0217] Through comparison, potential conflicts and inconsistencies between new requirements and existing requirements can be identified.

[0218] Generate a detailed requirement description for the analyzed differences and conflicts. The requirement description will include:

[0219] Identification of conflicting content: Mark the differences and conflict points between new requirements and existing requirements, and describe the causes and impacts of the conflict.

[0220] Adjustment suggestions: Based on the differences and conflicts between requirements, make adjustment suggestions. These suggestions may include modifying existing requirements, adjusting new requirements, or adding new functional modules to resolve conflicts.

[0221] For example, if new requirements require an increase in data processing speed, and existing requirements have set fixed performance standards, it may be necessary to adjust the existing requirements, increase requirements for performance optimization, or propose new technical solutions to meet the requirements.

[0222] For the analyzed demand conflicts, the system will provide specific adjustment suggestions, including:

[0223] Modify existing requirements: such as adjusting the implementation methods of existing functional modules, modifying technical specifications, etc.

[0224] Add or delete requirements: Based on the requirements for new features, decide whether to add or delete certain content to ensure the consistency of the system.

[0225] Optimization plan: Propose a plan to optimize the existing system architecture or functional modules to resolve conflicts between requirements.

[0226] These adjustment suggestions will serve as guidance for subsequent document updates and requirement modifications to ensure that the new version of the document can accurately reflect the changes in requirements and will not cause system conflicts.

[0227] Step S500 at least includes steps S510-S530:

[0228] S510: Generate modification suggestions based on standardized requirements and historical design specifications, classify the modification suggestions, and identify modules and parts that may need to be changed.

[0229] In this step, we first need to obtain the standardized new requirements and historical versions of the design specifications. Specifically, the "standardized requirements" are the content that has been processed by the large language model and generated into standardized requirements descriptions, covering requirements in terms of system functions, performance, interfaces, security, etc. The "historical design specifications" are old versions of the design documents for ship data management systems, including system architecture, functional modules, interface design, etc.

[0230] Compare the historical design specifications with the standardized requirements, analyze the differences between the existing design and the new requirements, and generate modification suggestions based on these differences. Specifically, modification suggestions can be divided into the following categories:

[0231] New functional modules: If the new requirements include new functional modules, the modification opinions will suggest adding relevant content to the design specification and clarify the functions, input and output requirements, etc. of the module.

[0232] Performance requirement adjustments: If the new requirements involve changes to performance (such as response time, processing speed, etc.), the modification suggestions will point out these changes and recommend updating the relevant parts in the design specification.

[0233] Interface definition changes: If the new requirements involve the addition, modification or deletion of interfaces, the modification opinions will suggest adjustments to the interface definition section in the design specification.

[0234] Changes in security requirements: If there are adjustments to the security requirements in the new requirements (such as new encryption requirements or access control mechanisms), the modification comments will point out and update the security section of the design specification.

[0235] Furthermore, the modification opinions will be automatically generated based on the comparison results, and the changes in each module and part need to be recorded. For example, the newly added data processing module will correspond to the data storage module or data flow part in the historical design specification, and the modification opinions will point out the description of the new module that needs to be added to the design.

[0236] After generating the modification opinions, the next step is to classify the modification opinions to ensure the accurate positioning of each modification opinion. The classification criteria include:

[0237] Functional modification: involves the addition, modification or deletion of functional modules, such as adding data processing modules, adjusting existing functions, etc.

[0238] Performance modification: involves changes in requirements for system performance, such as changes in processing speed, throughput, and other performance requirements.

[0239] Interface modification: involves changes in system interfaces, such as adding new interfaces, modifying protocols or data formats, etc.

[0240] Security modifications: Changes involving security-related requirements, such as data encryption, permission management, etc.

[0241] Specifically, each type of modification suggestion needs to be classified according to the above classification standards, and filled in and processed in detail in the subsequent steps.

[0242] After the classification is completed, it is necessary to further identify the design specification module corresponding to each modification suggestion.

[0243] For example:

[0244] For modification suggestions for new functional modules, identify the modules that need to be updated, such as the "data processing module".

[0245] For modification suggestions regarding performance requirement changes, identify the relevant performance modules and determine the parts of the performance requirements that need to be updated.

[0246] For modification opinions on changes in interface definitions, identify the interface modules that need to be updated, especially the communication interface part with the external system.

[0247] Understandably, in this step, the modification suggestions will be located according to the requirements and historical design documents to ensure the accuracy and completeness of the design documents when they are updated.

[0248] S520: Fill the generated modification suggestions into the standardized template by category to ensure that the modifications of each part comply with the specifications and can be directly applied to the revision of the design specification.

[0249] In this step, the classified modification opinions are filled into the standardized template of the design specification. The template is a pre-defined standardized format used to unify the content of all modifications. Each type of modification opinion will be filled in according to the specific part of the template. For example:

[0250] Functional modification: For newly added functional modules, fill the corresponding module description into the template to ensure a complete description of the module's functions, inputs and outputs, data flows, and other information.

[0251] Performance modification: For changes in performance requirements, fill in new performance indicators into the relevant parts of the design specification to clarify performance requirements such as processing speed and system response time.

[0252] Interface modification: For modifications to the interface definition, fill the newly added or modified interface description into the interface definition part to ensure that the new protocol, data format and communication method can be reflected in the design specification.

[0253] Security modification: For changes in security requirements, new encryption methods, permission management mechanisms, etc. are added to the security module in the design specification.

[0254] During the filling process, it is necessary to strictly follow the requirements of the standardized template to ensure that the modification of each part meets the specifications. For example:

[0255] Ensure that each new functional module complies with the description format of the template, including function definition, input and output requirements, etc.

[0256] Ensure that modifications to performance requirements, interface definitions, etc. comply with the technical specifications of the design manual.

[0257] Ensure that the safety modifications correctly reflect the new safety requirements and comply with industry standards and ship design specifications.

[0258] The filled content needs to generate a modified part that can be directly applied to the revision of the design specification. After the modification opinions are classified and filled, a clear and standardized document part will be formed for subsequent revision of the design document. These modified contents will be marked as new version updates to ensure that the requirements changes can be accurately reflected in subsequent use.

[0259] S530: According to the classification of the modification opinions, they are matched with relevant modules to generate standardized and accurate modification opinion content.

[0260] In this step, the classified modification suggestions are matched with specific design specification modules. For example:

[0261] Functional modification: connect the newly added or modified functional modules with the corresponding functional modules in the existing design specifications to ensure that the new functional requirements can be accurately reflected in the design specifications.

[0262] Performance modification: Connect the modified performance indicators with the existing performance requirement modules to ensure that the performance requirements are updated consistently.

[0263] Interface modification: align the modified interface requirements with the interface part in the design specification to ensure that the interface definition part reflects the new or modified interface information.

[0264] Safety modification: Align the modified safety requirements with the safety module in the design specification to ensure the accurate implementation of the new safety standards.

[0265] According to the corresponding module, the modified opinion content will be generated into a standardized format. The generated content will conform to the structure of the standardized template and maintain consistency and accuracy in content. For example:

[0266] For the addition of functional modules, the generated description should include detailed description of the new functions, input and output requirements, data flow and other information.

[0267] For modifications to performance requirements, the generated content should include new performance indicators and expected processing capabilities.

[0268] For interface modifications, the generated content should include updates to interface protocols, data formats, communication standards, etc.

[0269] Furthermore, the modification suggestions generated through this step will ensure that the content of each part complies with the specifications and can be directly applied when the design specifications are subsequently updated.

[0270] Finally, a standardized document will be generated based on the classification and corresponding modification opinions. The document will include all modules that need to be updated, partial modification content, and all modifications will follow unified specifications to ensure the consistency and accuracy of the document.

[0271] Step S600 at least includes steps S610-S630:

[0272] S610: After obtaining the modification opinions, intelligently assign tasks to relevant modules for processing based on the categories of the modification opinions through the workflow routing mechanism of the large language model.

[0273] In this step, modification suggestions are first obtained from the previous modules (such as S510, S520, S530). These modification suggestions are generated based on the comparison and analysis of the standardized requirements and the historical design specifications, and cover various changes such as new functional modules, performance adjustments, interface changes, and security requirements. Specifically, the modification suggestions can be divided into the following categories:

[0274] Functional modification: adding new functional modules or modifying existing functions.

[0275] Performance modification: Improvement or adjustment of performance requirements, such as response time, data throughput, etc.

[0276] Interface modification: addition, deletion or adjustment of interface definition.

[0277] Security modification: Addition or adjustment of security-related requirements, such as data encryption, access control, etc.

[0278] Based on the modification opinions obtained, they are first classified to ensure that each modification opinion can accurately reflect the modification objectives and categories. The classification criteria include:

[0279] Functional modification: involves the addition, adjustment or deletion of system functional modules, mainly including system architecture, module function description, input and output requirements, etc.

[0280] Performance modification: mainly involves performance-related requirements, such as response time, data processing speed, throughput, etc.

[0281] Interface modification: involves the definition of new interfaces or the modification of existing interfaces.

[0282] Security modification: involves new security requirements or adjustments to existing security requirements, such as data encryption, permission management, etc.

[0283] Understandably, the goal of this step is to separate different types of modification suggestions from the overall requirements through clear classification and prepare them for processing by the corresponding modules. Each type of modification suggestion is identified and assigned a task category for subsequent task allocation.

[0284] Furthermore, the workflow routing mechanism of the large language model is used to distribute the classified modification opinions to different work modules for processing. The workflow routing mechanism determines the distribution of tasks based on the category of the modification opinions:

[0285] Functional modifications are assigned to the "Functional Module Design" workflow.

[0286] Performance modifications are assigned to the Performance Requirements Adjustment workflow.

[0287] Interface modifications will be assigned to the "Interface Design" workflow.

[0288] Security modifications are assigned to the Security by Design workflow.

[0289] Business model modifications are assigned to the Business Model Design workflow.

[0290] Workflow modifications are assigned to the Workflow Design workflow.

[0291] The large language model determines the type of each modification suggestion through reasoning and assigns it to the most appropriate workflow module based on the type to ensure efficient and accurate processing of tasks.

[0292] S620: According to the assigned tasks, relevant content is input into the workflow, and the modular design content is generated using the large language model to ensure that the content generation of each module meets the requirements.

[0293] In S610, the modification opinions have been assigned to different workflows according to their categories. Next, when entering step S620, the content of each category of modification opinions is input into the corresponding workflow module. Specifically:

[0294] Functional modification: The modification suggestions involving the addition or modification of functional modules are input into the "Functional Module Design" workflow, requiring the generation of new functional descriptions or the modification of the descriptions of existing functions.

[0295] Performance modification: Input the performance adjustment requirements into the "Performance Requirements Adjustment" workflow to ensure that the modified performance requirements are accurately reflected in the design.

[0296] Interface modification: Input interface-related modification suggestions into the "Interface Design" workflow to generate new interface definitions or modify the specifications of existing interfaces.

[0297] Security Modifications: Input security-related modification suggestions into the "Security Design" workflow to ensure that new or modified security requirements are implemented.

[0298] Business model modification: Input business model-related modification suggestions into the "Business Model" workflow to ensure that new or modified business model requirements are implemented.

[0299] In the workflow, the input modification opinions will be further parsed by the large language model and modular design content will be generated. Specifically, the large language model generates detailed design document content based on the input modification opinions and background information. After the design content of each module is generated, it will cover:

[0300] Functional description: For functional modifications, a detailed functional description will be generated to clarify the input, output, operation process, etc.

[0301] Performance requirements: For performance modifications, new performance indicators and requirements will be generated and ensured to meet the design specifications.

[0302] Interface definition: For interface modifications, updates to the interface protocol, data format, communication method, etc. will be generated.

[0303] Security measures: For security modifications, encryption schemes, permission management methods, etc. will be generated to ensure that security requirements are met.

[0304] Furthermore, the generated content of each module will be modified according to the corresponding suggestions to ensure that each content meets the requirements. In this way, the first round of generation of each modular design content is completed.

[0305] The key in this step is to ensure that the generated content of each module can fully meet the modification opinions and standardization requirements. For example, the addition of functional modules must include clear functional descriptions, the adjustment of performance requirements must include specific performance indicators, and the modification of interface design must include clear interface descriptions. The content generated by the large language model should ensure that it is unambiguous and meets the requirements.

[0306] S630: According to the task routing result, adjust the content generated by each module in the workflow to ensure that the modification opinions are accurately implemented in each module.

[0307] In steps S610 and S620, the routing and task allocation of the workflow have been completed, the modification opinions have been input into the corresponding modules and the modular design content has been generated. Next, the content generated by each module in the workflow needs to be analyzed according to the task routing results to ensure that the generated content of each module meets the modification opinions and requirements. For example:

[0308] Functional module design: Check whether the generated functional description is complete and accurate, and whether it includes all new or modified functional requirements.

[0309] Performance requirements: Check whether the generated performance requirements reflect the changes in new requirements, especially the specific values ​​and requirements of performance indicators.

[0310] Interface design: Check whether the generated interface specifications meet the requirements of new or modified interfaces and ensure compatibility with other modules.

[0311] Security design: Check whether the generated security design meets the new or modified security requirements, especially encryption standards, permission control, etc.

[0312] Specifically, if it is found that the generated content deviates from the modification suggestions, the generated content needs to be adjusted to ensure that the modification suggestions can be accurately implemented. For example:

[0313] For functional modifications, if the description of the new functions is incomplete, more details may need to be added, such as input and output requirements.

[0314] For performance modifications, if the performance requirement indicators are not clear, specific parameters such as response time and throughput need to be added.

[0315] For interface modifications, if the interface definition is inaccurate, the interface protocol, data format and other information need to be adjusted.

[0316] For security modifications, if the security measures are not comprehensive, encryption algorithms, permission management methods, etc. need to be supplemented.

[0317] After the adjustment is completed, it is necessary to ensure that the generated content of all modules is consistent and meets the requirements of the modification suggestions. By comparing the generated content with the modification suggestions, check whether all updates are accurately implemented to ensure the accuracy and consistency of the document.

[0318] Step S700 at least includes steps S710-S730:

[0319] S710: Based on the modification suggestions generated above, the large language model is used to generate the contents of different modules to ensure that the content of each module meets the standardization requirements.

[0320] In this step, the modification opinions have been generated and classified through the previous steps (such as S510, S520, S530). Specifically, the modification opinions include updates of various requirements, such as newly added functional modules, modified performance requirements, interface updates, etc. These modification opinions are divided into different categories, and corresponding content is generated for each category.

[0321] The modification opinions mentioned above refer to the contents that have been compared and analyzed in the early stage and adjusted according to the changes in requirements, covering changes in functionality, performance, interface and security. For example, a functional modification opinion may involve the addition of a new data processing module, and a performance modification opinion may involve higher data processing capabilities, etc.

[0322] Next, the modification suggestions are input into the trained large language model for processing. Specifically, the large language model will generate corresponding design content according to the requirements of different modules. For example:

[0323] Functional modification: Generate detailed functional design specifications for newly added functional modules, including input and output requirements, functional description, data flow, etc.

[0324] Performance modification: Generate design content related to performance requirements and clarify indicators such as response time and processing speed.

[0325] Interface modification: Generate interface design content, define interface protocol, data format, etc.

[0326] Security modification: Generate security requirements and define security measures such as data encryption and access control.

[0327] Specifically, the large language model will infer the design content of each module based on the description of the modification suggestions and ensure that these contents are consistent with the structure in the existing design documents. The reasoning process of the large language model combines the understanding of the modification suggestions and generates design content that meets the standardization requirements.

[0328] The generated design content must comply with unified specifications and standards to ensure its consistency and integrity in the document. For example, the generated content of the functional module needs to follow a unified template to clarify the function, input and output, and operation process of each module; the generated content of the performance requirements needs to clarify specific indicators such as response time and throughput; the generated content of the interface needs to clarify the interface standard, protocol, and data format.

[0329] In this step, the standardization requirements refer to the unified standards of system design documents, including the uniformity of format, structure, content, etc. These requirements ensure that the generated content can be seamlessly integrated into the subsequent design specifications and be consistent with other modules.

[0330] S720: Input the content corresponding to the modification opinions into the large language model to generate the design content of the corresponding modules, so as to ensure that the design content of each module is unified and accurate.

[0331] In step S710, the modification opinions have generated preliminary content through the large language model. Next, the modification opinions need to be matched with the corresponding modules and input into the large language model for further processing. Specifically, the modification opinions are sorted by category, and each category corresponds to one or more modules. For example:

[0332] Functional modification: input to the functional module generation module.

[0333] Performance modification: Input to the performance requirements module.

[0334] Interface modification: input into the interface design module.

[0335] Security modifications: Input to the security design module.

[0336] In this way, it is ensured that each type of modification suggestion corresponds to the corresponding module, so that the generated design content can accurately reflect the modification requirements.

[0337] After receiving the modification suggestions, the large language model will generate detailed design contents of the corresponding modules based on the input modification contents. These modular design contents should include:

[0338] Functional module design: Describe the new or modified functions in detail, including function definition, input and output requirements, operation process, exception handling, etc.

[0339] Performance requirement design: Describe the new performance requirements in detail, including response time, processing speed, data throughput, etc.

[0340] Interface design: Generate interface protocols, data formats, communication standards, etc. to ensure compatibility with other systems or modules.

[0341] Security design: Describe in detail security requirements such as data encryption, permission management, and user authentication.

[0342] The generated design content will be organized completely in a standardized format to ensure that the content of each module complies with the specifications and can be directly applied to subsequent design specifications.

[0343] In this step, it is necessary to ensure that the design content generated by each module is consistent in logic, format, and content. Specifically, the accuracy requirements of the content are as follows:

[0344] Logical consistency: The design content generated by each module should complement the content of other modules to ensure that there are no contradictions and conflicts between the parts.

[0345] Content completeness: The content of each module must contain sufficient detail to ensure that all aspects of the design specification are fully covered.

[0346] Format specification: The generated content should comply with the standard format of the design specification, including titles, paragraphs, numbers, etc., to ensure uniform format.

[0347] S730: Perform structured output based on the generated modular design content to ensure that the content logic is clear, the content is complete, and meets the standardized requirements of the design specification.

[0348] In this step, the modular design content generated in S720 is structured. The modular design content is generated by a large language model, but needs to be organized according to the standardized format of the design specification. This includes:

[0349] Arrange by chapters: Organize different design modules (such as functional modules, performance requirements, interface design, safety design, etc.) according to chapters.

[0350] Standardized numbering: Assign numbers to each module and submodule to ensure that the document is clearly structured and well-organized.

[0351] Paragraph arrangement: Arrange paragraphs for each module according to the document format requirements to ensure that each part complies with the document structure requirements.

[0352] During the output process, ensure that the content of each module is logically clear and complete. Specifically:

[0353] Clear logic: The content of each module should follow a logical order to avoid information confusion and content duplication. For example, the design of a functional module should first describe the functional goals, then the implementation steps, and finally the input and output requirements, etc.

[0354] Complete content: The content of each module should be described in detail to ensure that all requirements are reflected without omission. For example, the description of performance requirements should include not only response time, but also the system's maximum load capacity, data throughput, etc.

[0355] Finally, the structured design content is compared with the standardized requirements of the design specification to ensure that all generated content meets the unified standards. Specifically, the requirements of the design specification in terms of format, terminology, structure, etc. must be met. In this way, it is ensured that the generated design content can be directly applied to the final design specification.

[0356] Furthermore, all generated modular design contents will be presented in the final design specification, ensuring that each part is clear, accurate, unambiguous, and fully meets the requirements.

[0357] Step S800 at least includes steps S810-S830:

[0358] S810: Integrate the generated modular design content using a template engine, and merge the contents of each module into a complete design specification in a standardized format.

[0359] Prior to this step, all modification opinions have been processed by the large language model and the design content of the corresponding modules has been generated. The modular design content includes detailed design information of each module, such as functional modules, performance requirements, interface definitions, security designs, etc. For example, the functional module description may include newly added functional requirements, and the performance requirement description may include new response time requirements, etc.

[0360] Specifically, all modular design contents have been generated in step S720 according to the modification opinions, and these contents comply with standardized formats and requirements.

[0361] Furthermore, the generated contents of each module are input into the template engine for integration. The template engine is a tool for merging contents based on a predefined template format, which can ensure that the contents of each module are merged in a standardized format and generate a complete design specification. Specifically, the working process of the template engine includes:

[0362] Module content merging: Integrate modular content such as functional modifications, performance requirements, interface definitions, etc. into the corresponding chapters of the design specification to ensure that the content sequence, hierarchy, and format meet the requirements.

[0363] Formatting and standardization: The template engine automatically adjusts the content format according to the format requirements of the design specification (such as paragraphs, numbers, titles, etc.) to ensure the standardization of the document.

[0364] Chapter and subsection arrangement: The template engine places the content of each module into corresponding chapters and subsections according to the structure of the design specification. For example, the functional module design content is placed in the "System Function Design" chapter, the interface design is placed in the "Interface Design" chapter, and so on.

[0365] Through the integration of the template engine, the final design specification contains all the necessary module content. The design content of each module has been merged according to the standardized format and requirements to form a complete design document. This design specification includes all modification suggestions and accurately reflects the new requirements.

[0366] Introduction: Briefly describe the project background, design goals, requirements overview, etc.

[0367] Core module part: Describe each module of the system in detail, such as functional design, performance requirements, interface design, security design, etc.

[0368] Appendix: Contains additional information such as technical terms, diagrams, references, etc.

[0369] S820: Perform multiple rounds of verification on the integrated design specifications to verify the accuracy and consistency of the content and ensure that the content of each module is consistent with the requirements specification.

[0370] After integrating the modular design content, the integrated design specifications need to be verified multiple times. The goal of this verification is to verify the accuracy and consistency of the content in the design specifications, and to ensure that the content of each module is consistent with the requirements specification, historical versions, and new requirements. Specifically, the verification process includes:

[0371] Accuracy check: Ensure that the content of each module accurately reflects the modification suggestions and new requirements. For example, whether the description of the newly added functional module is accurate, whether the performance requirements meet the new requirements, etc.

[0372] Consistency check: Ensure that the contents of different modules in the design specification are consistent. For example, whether the response time in the performance requirements is consistent with the operation time in the functional module, whether the data format in the interface design is compatible with other parts of the system, etc.

[0373] Requirements consistency check: Ensure that the content in the design specification is consistent with the requirements specification, especially whether the new or modified requirements are complete and correctly reflected in the design document.

[0374] The verification process should be carried out in multiple rounds:

[0375] The first round of verification: First, perform basic verification on the content to check whether the module content meets the requirements in the requirements specification and whether it accurately reflects the new requirements.

[0376] Second round of verification: further verification of details to check whether the document format and terminology are consistent, and whether the content of the design manual is coherent and clear.

[0377] Third round of verification: Conduct a comprehensive review to ensure that each part of the design specification accurately matches the relevant part of the requirements specification and that there are no omissions or errors.

[0378] In each round of verification, the focus is on checking whether each module is consistent with the requirements specification and whether all modifications are accurately applied. For example, if the performance requirements have changed, it is necessary to ensure that the change has been reflected in the relevant part of the design specification and does not conflict with the requirements of other parts.

[0379] During the verification process, if any inaccuracies or inconsistencies are found, they will be marked and adjusted. This process ensures the high quality and accuracy of the design specifications.

[0380] S830: Optimize and adjust the design specifications based on the verification results to ensure that the final generated design specifications meet the specifications and meet the needs of the enterprise or project.

[0381] After the verification process is completed, the generated verification report is compared with the design specification to analyze and summarize the verification results. The verification report includes:

[0382] Inconsistent parts: List the parts in the design specification that are inconsistent with the requirements specification or modification suggestions.

[0383] Accuracy Issues: List what is inaccurate or incomplete in the document.

[0384] Formatting issues: List the formatting issues in the design specification, such as inconsistent titles, unclear paragraph structure, etc.

[0385] According to the verification results, the design specifications are optimized and adjusted. The specific adjustment steps include:

[0386] Content adjustment: Modify and improve the content to ensure that each part accurately reflects the requirements of the requirements specification and modification suggestions. For example, if the description of a functional module is found to be incomplete, the specific implementation steps or input and output requirements of the module need to be supplemented.

[0387] Format optimization: Adjust the format of the document to ensure that all chapters, paragraphs, titles, etc. meet the requirements of the standardized template. Ensure that the document has a clear hierarchy, clear logic, and the layout meets the specifications.

[0388] Consistency optimization: Ensure the uniformity of the contents of different modules in the document, especially in terms of terminology, definitions, parameter units, etc., to avoid ambiguity and confusion.

[0389] After all optimizations and adjustments are completed, the final draft is carried out. This process ensures that the content of the design specification fully meets the requirements of the project and can accurately reflect the system's demand changes and functional adjustments. The final design specification will be a document that meets the specifications, is clear, accurate, and operational.

[0390] Furthermore, after finalization, the design specification will be saved and used for subsequent implementation of the project. This document will become the core design reference of the ship data management system for use by the development and implementation teams.

[0391] The present invention realizes the automatic generation and efficient update of the design specification of the ship data management system by adopting the design specification generation method based on the large language model and intelligent text comparison technology. Compared with the traditional method of manually writing and manually updating the design document, the present invention shows significant beneficial effects in many aspects:

[0392] First, by designing standardized requirement specifications and design manual templates and filling in historical requirement documents as the input basis, the present invention realizes the standardization and structured processing of complex ship data management system design requirements, effectively avoiding common errors and omissions in the manual editing process, and ensuring the consistency and accuracy of the document content.

[0393] Secondly, text comparison technology is used to detect differences between requirement specifications and design instructions, which can accurately identify new, modified or deleted content and generate change reports. Compared with traditional manual comparison, it greatly improves the efficiency of document updates and reduces errors.

[0394] Finally, by utilizing the workflow routing mechanism of the large language model, tasks are intelligently assigned to corresponding modules according to the different categories of modification opinions, ensuring that the generated design content accurately corresponds to the changes in requirements in terms of function, performance, interface, etc., and can realize the automatic generation of modular design content, greatly improving the degree of automation of document generation and updating.

[0395] Obviously, the embodiments described above are only some embodiments of the present application, rather than all embodiments. The preferred embodiments of the present application are given in the accompanying drawings, but they do not limit the patent scope of the present application. The present application can be implemented in many different forms. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present application more thorough and comprehensive. Although the present application is described in detail with reference to the aforementioned embodiments, for those skilled in the art, it is still possible to modify the technical solutions recorded in the aforementioned specific implementation methods, or to perform equivalent replacement of some of the technical features therein. Any equivalent structure made using the contents of the specification and drawings of this application, directly or indirectly used in other related technical fields, is similarly within the scope of patent protection of this application.

Claims

1. A method for generating a design specification for a ship data management system, characterized in that: The method comprises: Design standardized requirement specifications and design manual format templates, clearly defining the core elements included; Fill in historical requirements specifications and design specifications, and serve as the input basis for subsequent document generation; Detect differences between the requirements specification and the design manual based on text comparison technology, identify new, modified and / or deleted content, and generate a change report; Combine the requirement classification template and the large language model workflow based on the requirement parsing framework to parse new requirements, generate standardized requirement descriptions, and analyze internal differences and conflicts in requirements; Generate modification suggestions based on standardized requirements and design specifications, and fill them into the template in categories; Using the workflow routing mechanism of the large language model, tasks are intelligently assigned to corresponding modules based on the different categories of modification opinions to generate content; Generate modular design content through a large language model based on modification suggestions; The template engine integrates the content generated by each module and performs multiple rounds of verification to verify the accuracy and consistency of the design specifications.

2. The design specification generating method according to claim 1, characterized in that: The step of detecting differences between the requirement specification and the design specification based on text comparison technology specifically includes: Perform a text comparison between the historical requirement specification and the new requirement specification, identify the newly added, modified and / or deleted content through text comparison technology, and generate difference information.

3. The design specification generating method according to claim 1, characterized in that: The step of generating a change report specifically includes: The changed content is extracted from the difference information, and a change report is generated, indicating the specific content that is added, modified and / or deleted.

4. The design specification generating method according to claim 1, characterized in that: The step of combining the demand classification template and the large language model workflow based on the demand parsing framework to parse the new demand specifically includes: Obtain new requirements, split and refine the requirements using a large language model workflow based on the requirements parsing framework, extract key requirements information based on the requirements classification template, and perform structured processing; The new requirements are input into the large language model for parsing, and a standardized requirement description is generated through model reasoning.

5. The design specification generating method according to claim 4, characterized in that: The step of generating a standardized requirement description specifically includes: Based on the structured demand information, a detailed demand description is generated through a large language model.

6. The design specification generating method according to claim 1, characterized in that: The step of generating modification opinions and filling them into the template by categories specifically includes: Generate modification suggestions based on standardized requirements and historical design specifications, and classify them according to their categories to identify the modules and parts that need to be changed; The generated modification suggestions are filled into the standardized template by category.

7. The design specification generating method according to claim 1, characterized in that: The step of using the workflow routing mechanism of the large language model to intelligently assign tasks to corresponding modules according to the categories of modification opinions specifically includes: After obtaining the modification opinions, tasks are intelligently assigned to relevant modules for processing based on the categories of the modification opinions through the workflow routing mechanism of the large language model.

8. The design specification generating method according to claim 7, characterized in that: The step of generating modular design content through a large language model based on the modification opinions specifically includes: The modification opinions are input into the large language model, and the design content of the corresponding module is generated according to the modification opinions.

9. The design specification generating method according to claim 8, characterized in that: The steps of generating modular design content specifically include: Adjust the content generated by each module in the workflow based on the task routing results.

10. The design specification generating method according to claim 1, characterized in that: The step of integrating the modules to generate content through the template engine specifically includes: The template engine is used to merge the contents of each module into a complete design specification in a standardized format.

Images