A Method, Device, Equipment and Medium for Real-time Dynamic Update of System Requirements Document

Abstract

The present application discloses a method, device, equipment and medium for real-time dynamic update of system requirement documents, which relates to the technical field of computer document processing, and includes: monitoring in real time the preset code annotations after the source code of the system is updated according to the current requirement document to obtain corresponding monitoring results; when the monitoring results indicate that there are code changes in the methods at all levels under the preset code annotations, monitoring all business classes under the target-level methods with code changes during the operation of the current system through a Java proxy tool and a bytecode instrumentation tool to obtain corresponding instrumentation logs; parsing the instrumentation logs and generating a corresponding topology diagram according to the parsing information; using a pre-trained model and according to the current requirement document, the current design document written based on the current requirement document, the preset code annotations, and the topology diagram to output a text description corresponding to the topology diagram; using the text description to update the original requirement document of the system to obtain a real-time requirement document.

Description

Technical Field

[0001] The present invention relates to the technical field of computer document processing, and particularly relates to a method, device, equipment and medium for real-time dynamic update of system requirement documents. Background Art

[0002] The standard application system process is that there is a requirement document for the product first, and then the application system development will be carried out according to the product-level requirement document. Therefore, at the beginning of the application system development and online launch, the product-level requirement document is consistent with the true function of the application system. However, with the continuous iteration and update of the application system, if the product-level requirement document does not continue to be updated according to the updated requirements of the application system, the product requirement document will gradually become inconsistent with the application system, making it impossible for people who want to understand the application system to understand it through the product requirement document. And it is too costly to specially arrange employees to maintain the product requirement document, and it is also very difficult to persist.

[0003] In summary, how to realize the dynamic real-time automatic update of the product requirement document of the system with the update and iteration of the system and reduce the labor cost is a technical problem to be solved in this field. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a method, device, equipment and medium for real-time dynamic update of system requirement documents, which can realize the dynamic real-time automatic update of the product requirement document of the system with the update and iteration of the system and reduce the labor cost. The specific solutions are as follows:

[0005] In the first aspect, the present application discloses a method for real-time dynamic update of system requirement documents, including:

[0006] Real-time monitor the preset code annotations after the source code of the system is updated according to the current requirement document to obtain the corresponding monitoring results; wherein, the preset code annotations are used to mark the entry functions of system function points;

[0007] When the monitoring result is that there are code changes in the methods at all levels under the preset code annotations, monitor all business classes under the target-level methods with code changes during the operation of the current system through the Java proxy tool and bytecode instrumentation tool to obtain the corresponding instrumentation logs; wherein, the instrumentation logs include the execution paths of the code in the business classes and the call relationships of the methods at all levels;

[0008] Parse the instrumentation logs to generate a corresponding topology diagram according to the parsing information;

[0009] Using a pre-trained model and based on the current requirements document, the current design document written based on the current requirements document, the preset code annotations, and the topology diagram, output a text description corresponding to the topology diagram;

[0010] Use the text description to update the original requirements document of the system to obtain a real-time requirements document.

[0011] Optionally, before the real-time monitoring annotates the preset code after the source code of the system is updated according to the current requirements document, it further includes:

[0012] When there is a system establishment requirement, analyze the system requirements at all levels of the system establishment requirement to create an original requirements document;

[0013] Write a corresponding original design document according to the original requirements document;

[0014] Build a system according to the original design document.

[0015] Optionally, the analyzing the system requirements at all levels of the system establishment requirement to create an original requirements document includes:

[0016] Analyze the system establishment requirement to obtain system requirements at all levels with associated relationships;

[0017] Encode each requirement of the system requirements at all levels to obtain encoding information corresponding in the order of requirement code, requirement name, system function point, and requirement content;

[0018] Use the encoding information to create an original requirements document.

[0019] Optionally, the real-time dynamic update method of the system requirements document further includes:

[0020] Mark the entry function of the system function point of each requirement of the system requirements at all levels through preset code annotations.

[0021] Optionally, the monitoring all business classes under the target-level method with code changes during the operation of the current system through a Java proxy tool and a bytecode instrumentation tool to obtain corresponding instrumentation logs includes:

[0022] Load the updated source code during the operation of the current system through a class loader to obtain bytecode;

[0023] Use the Java proxy tool to intercept the bytecode, and use the bytecode instrumentation tool to instrument the first line of bytecode representing the methods at all levels, so as to monitor whether the business classes under the methods at all levels have code changes and obtain corresponding instrumentation logs.

[0024] Optionally, parsing the instrumentation log to generate a corresponding topology diagram according to the parsing information includes:

[0025] Parse the instrumentation log and determine whether there are conditional branches under the parent-level method in the parsing information;

[0026] If there is no such conditional branch, generate a corresponding topology diagram according to the parsing information;

[0027] If there is such a conditional branch, process the source code corresponding to the parsing information according to the processing rule that the syntax structure of the source code is the tree structure and the structural elements of the source code are the tree nodes, so as to generate a corresponding abstract syntax tree;

[0028] Traverse the abstract syntax tree to determine the tree nodes with conditional branches according to the node type and node attributes;

[0029] Use the node information of the tree nodes as the nodes of the topology diagram and the logical relationship in the node information as the edges in the topology diagram to construct a corresponding topology diagram.

[0030] Optionally, using the pre-trained model and according to the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology diagram to output the text description corresponding to the topology diagram includes:

[0031] Create a blank association mapping table;

[0032] Using the requirement code as the key, associate and store the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology diagram according to the requirement code dimension into the blank association mapping table to obtain the content information associated with each requirement code; wherein, the content information is the associated requirement document information, the associated design document information, the code comment corresponding to the code under the associated preset code annotation, and the associated topology diagram information;

[0033] Input the content information associated with each requirement code into the pre-trained model so as to output the corresponding text description through the pre-trained model.

[0034] In a second aspect, the present application discloses a device for real-time dynamic update of a system requirement document, including:

[0035] A monitoring module, configured to monitor in real time the preset code annotation after the source code of the system is updated according to the current requirement document to obtain a corresponding monitoring result; wherein, the preset code annotation is used to mark the entry function of the system function point;

[0036] The stub logging acquisition module is used to, when the monitoring result indicates that there are code changes in the methods at all levels under the preset code annotation, monitor all business classes under the target-level methods with code changes during the current system operation through a Java proxy tool and a bytecode stubbing tool, so as to obtain corresponding stub logs; wherein, the stub logs include the execution paths of the code in the business classes and the call relationships of the methods at all levels.

[0037] The topology generation module is used to parse the stub logs to generate a corresponding topology diagram according to the parsed information.

[0038] The text generation module is used to utilize a pre-trained model and, based on the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology diagram, output a text description corresponding to the topology diagram.

[0039] The document update module is used to update the original requirement document of the system by using the text description to obtain a real-time requirement document.

[0040] In a third aspect, the present application discloses an electronic device, including:

[0041] A memory for storing a computer program;

[0042] A processor for executing the computer program to implement the steps of the method for real-time dynamic update of the system requirement document disclosed above.

[0043] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the steps of the method for real-time dynamic update of the system requirement document disclosed above are implemented.

[0044] It can be seen that the present application discloses a method for real-time dynamic update of a system requirements document, including: real-time monitoring of preset code annotations after the source code of the system is updated according to the current requirements document to obtain corresponding monitoring results; wherein, the preset code annotations are used to mark the entry functions of system function points; when the monitoring result shows that there are code changes in the methods at all levels under the preset code annotations, all business classes under the target-level methods with code changes during the operation of the current system are monitored through a Java proxy tool and a bytecode instrumentation tool to obtain corresponding instrumentation logs; wherein, the instrumentation logs include the execution paths of the code in the business classes and the call relationships of the methods at all levels; parsing the instrumentation logs to generate a corresponding topology diagram according to the parsing information; using a pre-trained model and based on the current requirements document, the current design document written based on the current requirements document, the preset code annotations, and the topology diagram to output a text description corresponding to the topology diagram; using the text description to update the original requirements document of the system to obtain a real-time requirements document. Thus, by real-time monitoring the preset code annotations after code update, it is ensured that changes in the system source code can be detected in a timely manner. When the system is iteratively updated, the requirements document will no longer be inconsistent with the actual system functions due to lack of timely follow-up, and always ensure that the requirements document can accurately reflect the current state of the system. By using preset code annotations to mark the entry functions of system function points, it is possible to specifically monitor the code parts directly related to system functions, improving the accuracy and efficiency of monitoring. By using a Java proxy tool and a bytecode instrumentation tool, only all business classes under the target-level methods with code changes are monitored, avoiding unnecessary monitoring of non-business code, reducing resource consumption, and at the same time accurately obtaining the code execution paths and method call relationships related to the business. Parsing the instrumentation logs to generate a topology diagram provides a visual representation of the complex code structure and control flow of the system. Developers and relevant personnel can more intuitively understand the logical structure of the system, which helps to quickly locate problems and optimize the system. The text description corresponding to the topology diagram output by the pre-trained model further enhances the understanding of the system. The text description can more detailedly explain each node and connection relationship in the topology diagram, enabling personnel unfamiliar with the code to understand the functions and processes of the system through the requirements document. In this way, real-time automatic update of the requirements document is achieved, eliminating the need to specially arrange personnel to manually maintain the requirements document, greatly reducing the labor cost. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0046] Figure 1 Flow chart of a method for real-time dynamic update of a system requirements document disclosed in this application;

[0047] Figure 2 Design diagram of a requirements document disclosed in this application;

[0048] Figure 3 Schematic diagram of the loading process after modifying Class bytecode using Java agent and Javassist disclosed in this application;

[0049] Figure 4 Log structure diagram disclosed in this application;

[0050] Figure 5 Topology diagram disclosed in this application;

[0051] Figure 6 Another topology diagram disclosed in this application;

[0052] Figure 7 Complete lunch-taking topology diagram disclosed in this application;

[0053] Figure 8 Complete lunch-taking text flow chart disclosed in this application;

[0054] Figure 9 Schematic diagram of the structure of a device for real-time dynamic update of a system requirements document disclosed in this application;

[0055] Figure 10 Structure diagram of an electronic device disclosed in this application. Detailed implementation manners

[0056] Next, the technical solutions in the embodiments of this application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0057] The standard application system process is that there is a requirements document for the product first, and then the application system is developed according to the product-level requirements document. Therefore, at the beginning of the application system development and launch, the product-level requirements document is consistent with the actual functions of the application system. However, with the continuous iteration and update of the application system, if the product-level requirements document does not continue to be updated following the updated requirements of the application system, the product requirements document will gradually become inconsistent with the application system, making it impossible for people who want to understand the application system to do so through the product requirements document. And it is too costly to specifically arrange employees to maintain the product requirements document, and it is also very difficult to persevere.

[0058] For this reason, the present invention provides a real-time dynamic update solution for system requirements documents, which can realize the dynamic real-time automatic update of the product requirements document of the system with the update and iteration of the system, reducing the labor cost.

[0059] Refer to Figure 1 As shown, an embodiment of the present invention discloses a method for real-time dynamic update of system requirements documents, including:

[0060] Step S11: Real-time monitor the preset code annotations after the source code of the system is updated according to the current requirements document to obtain the corresponding monitoring results; wherein, the preset code annotations are used to mark the entry functions of system function points.

[0061] In this embodiment, before the real-time monitoring of the preset code annotations after the source code of the system is updated according to the current requirements document, it further includes: when there is a system establishment requirement, analyze the system requirements at all levels of the system establishment requirement to create an original requirements document; write a corresponding original design document according to the original requirements document; establish a system according to the original design document. It can be understood that since the system establishment requirement includes the requirements of each subsystem, and each sub-requirement includes the requirements of the next-level subsystem, the system requirements at all levels are analyzed according to the system establishment requirement to create the corresponding original requirements document according to the system requirements at all levels. The original requirements document includes the following specific requirements:

[0062] Requirement overview: Briefly describe the goals, scope, and main functions of the system.

[0063] Functional requirements: List in detail the functions of the system, including function descriptions, input and output, processing flows, etc.

[0064] User requirements: Describe the requirements and usage scenarios of different user groups.

[0065] Performance requirements: Clearly define the performance indicators and requirements of the system.

[0066] Security requirements: List the security policies and measures of the system.

[0067] Maintainability and scalability requirements: Describe the maintainability and scalability requirements of the system.

[0068] Correspondingly, after the creation of the original requirements document, the corresponding original design document is prepared according to the requirements document. The original design document is an important basis for system development, which transforms requirements into specific technical solutions and design architectures.

[0069] 1. System architecture design:

[0070] Determine the overall architecture of the system, including the hierarchical structure, module division, component relationships, etc.

[0071] Select a suitable technology stack, such as programming languages, databases, servers, etc.

[0072] Design the communication mechanism and interfaces of the system to ensure effective data exchange and collaboration between different modules.

[0073] 2. Database design:

[0074] Design the database structure according to the functional requirements of the system, including table structure, field types, relationships, etc.

[0075] Consider the data storage method, index design, data backup and recovery strategies, etc.

[0076] 3. Interface design:

[0077] Design the user interface of the system, including interface layout, color matching, interaction methods, etc.

[0078] Ensure that the interface is simple, beautiful, and easy to use, meeting the user's usage habits.

[0079] 4. Algorithm and process design:

[0080] For some complex functional modules, corresponding algorithms and processing processes need to be designed.

[0081] For example, search algorithms, sorting algorithms, data processing processes, etc.

[0082] 5. Security design:

[0083] Implement the security policies and measures in the security requirements document and design the security architecture of the system.

[0084] Include user authentication and authorization mechanisms, data encryption, access control, etc.

[0085] Among them, the original design document should include the following content:

[0086] Design overview: Describe the design goals, principles, and overall architecture of the system.

[0087] System architecture diagram: Displays the hierarchical structure and module division of the system in a graphical way.

[0088] Database design: Describes in detail the structure and design scheme of the database.

[0089] Interface design: Displays the renderings of the system's user interface design and the interaction process.

[0090] Algorithm and process design: Explains the algorithms and processing flows of complex functional modules.

[0091] Security design: Elaborates on the system's security architecture and security measures.

[0092] Among them, after completing the writing of the original design document, the system is established according to the design document. This process includes the following steps:

[0093] 1. Development environment setup:

[0094] Install and configure the required development tools and software, such as the development environment of programming languages, database management systems, servers, etc.

[0095] Establish a version control tool, such as Git (Global Information Tracker, a distributed version control system) or SVN (Apache Subversion, a centralized version control system), to manage the code and enable collaborative development.

[0096] 2. Code development:

[0097] Carry out code development according to the architecture and module division in the design document. Developers write corresponding code modules according to their respective task assignments.

[0098] During the development process, follow good programming specifications and code styles to ensure the readability, maintainability, and scalability of the code.

[0099] Use code comments and documentation tools to comment and explain the code so that other developers can understand the function and logic of the code.

[0100] 3. Testing:

[0101] During code development, conduct unit testing, integration testing, and system testing. Ensure that each code module and function can work properly, and the overall performance and stability of the system meet the requirements.

[0102] Use automated testing tools and frameworks to improve testing efficiency and coverage.

[0103] 4. Deployment:

[0104] After the system passes the test, deployment is carried out. Select a suitable server and deployment environment and deploy the system to the production environment.

[0105] Perform verification and monitoring after deployment to ensure that the system can operate normally and promptly detect and resolve any potential problems.

[0106] Through the above steps, establish the system according to the original design document to achieve the functional requirements and design goals of the system. During the system establishment process, continuous verification and adjustment of requirements and design should be carried out to ensure that the system can meet the actual needs and expectations of users.

[0107] In this embodiment, the system analyzes the system requirements at all levels for establishing requirements to create an original requirements document, including: analyzing the system requirements for establishing requirements to obtain system requirements at all levels with associated relationships; performing coding processing on each requirement of the system requirements at all levels to obtain coding information corresponding in the order of requirement coding, requirement name, system function point, and requirement content; and creating an original requirements document using the coding information. It can be understood that the overall goal and main functions of the system are first clarified. For example, the goal of an online education system may be to provide a high-quality course learning platform, and the main functions include course display, online learning, assignment submission, exam evaluation, etc. The overall goal is gradually broken down into specific sub-goals and functional modules, and these sub-goals and functional modules constitute the system requirements at all levels. For example, the course display module can be further broken down into sub-functional requirements such as course list display, course details display, and course search. Further, the business process is sorted out: analyze the business processes involved in the system and determine the requirements for each link. Taking an e-commerce system as an example, the business processes include product listing, user order placement, payment settlement, logistics distribution, etc., and each link has corresponding system requirements. Consider the interaction and dependency relationships between different business processes to ensure the coordination and consistency of the system requirements at all levels. For example, after a user places an order, payment settlement is required, and logistics distribution can only be carried out after successful payment settlement. There are clear sequence and associated relationships between these requirements. For an online education system that is more dependent on different user roles, further user role analysis is carried out to determine the different user roles in the system, such as administrators, teachers, students, parents, etc. (taking an online education system as an example). Analyze the requirements and usage scenarios of each user role to determine the corresponding system functions. Consider the interaction and permission management between different user roles to ensure that the system can meet the needs of different users and ensure the security and privacy of data. For example, an administrator can perform operations such as course management and user management, a teacher can upload courses and grade assignments, and a student can study courses and submit assignments. Then, coding processing is performed on the system requirements at all levels obtained through analysis to better organize and manage requirement information. The coding processing is carried out in the order of requirement coding, requirement name, system function point, and requirement content. Specifically, requirement coding: Assign a unique code to each requirement for quick positioning and identification in the requirements document. The coding can adopt certain rules and formats, referring to Figure 2As shown, the requirement coding is in the form of "SR - year - serial number", where "SR" represents system requirements, "year" represents the year when the requirements are proposed, and "serial number" is numbered according to the order in which the requirements are proposed. The requirement coding should be readable and extensible to facilitate management during subsequent requirement changes and expansions. Requirement name: Assign a concise and clear name to each requirement, which can accurately summarize the main content of the requirement. The requirement name should be unique to avoid confusion caused by the same name requirements. For example, for the course display function in an online education system, it can be named "Course Display Requirement". System function point: Clearly define the system function point corresponding to each requirement. The system function point is a further refinement and specification of the requirement, which can help developers better understand the implementation method of the requirement. For example, for the "Course Display Requirement", the system function points can include course list display, course details display, course search, etc. Requirement content: Describe in detail the specific content and requirements of each requirement. The requirement content should include information such as the input, output, processing flow, and constraint conditions of the requirement, so that developers can accurately implement the requirement. For example, for the "Course List Display Function Point", the requirement content can include information such as the name, introduction, picture, and price of the course, support sorting according to course categories, popularity, etc., and provide a paging browsing function, etc.

[0108] Furthermore, when coding the requirement document version, it also includes: marking the entry function of the system function point of each requirement at all levels of system requirements through preset code annotations. It can be understood that when a certain system requirement is: Requirement number: SR - 2024 - 01 - 001; Requirement name: Loan disbursement; Function point: FP1; Requirement content: XXXX. Then it is necessary to mark the entry function of each system function point through annotations, and set the annotation as @FunctionPoint(name = "FP1", SR = {"SR - 2024 - 01 - 001", "SR - 2024 - 01 - 002",...}). This annotation is used to mark the method, name represents the name of this function point, corresponding to the function point names in the requirement document and design document. Since one function point may correspond to multiple requirements, SR needs to support filling in multiple. Thus, the association between the requirement document, design document, and code is completed.

[0109] In this embodiment, a corresponding system is created according to the original requirement document and the original design document proposed in the above steps. Therefore, when new requirements are added or existing requirements are updated for the system, new requirements are usually added by writing a new current requirement document instead of modifying the original requirement document, because one requirement may involve multiple systems. Thus, it is necessary to parse the requirement content related to the system through coding. When new requirements need to be added, new function points need to be created, and the method entry for the function points needs to be created. The method entry is marked with @FunctionPoint to establish the association relationship between its requirement document, design document, and code. If the original requirements are updated, the method code can be updated while the method entry remains unchanged. Therefore, the @FunctionPoint after the source code of the system is updated according to the current requirement document is monitored in real time, and the monitoring results of the @FunctionPoint during the normal operation of the system are monitored.

[0110] Step S12: When there are code changes in the methods at all levels under the preset code annotation in the monitoring result, all business classes under the target-level method with code changes during the operation of the current system are monitored through a Java proxy tool and a bytecode instrumentation tool to obtain corresponding instrumentation logs. The instrumentation logs include the execution paths of the code in the business classes and the call relationships of the methods at all levels.

[0111] In this embodiment, since the code is managed by a version control tool such as SVN, Git, etc., when it is monitored that there are code changes in all the parent and child level methods under the function point entry annotated with @FunctionPoint, the flowcharts and the flowchart description content of the relevant SR requirements in the @FunctionPoint annotation are updated. When code changes are detected, the updated source code during the operation of the current system is loaded through a class loader to obtain bytecodes. The Java proxy tool is used to intercept the bytecodes, and the bytecode instrumentation tool is used to instrument the first line of bytecodes representing the methods at all levels, so as to monitor whether there are code changes in the business classes under the methods at all levels and obtain corresponding instrumentation logs. For example Figure 3As shown in the figure, bytecode instrumentation is performed using Java agent and Javassist (a Java bytecode manipulation library) tools to monitor the execution of each method and generate logs. Java agent and Javassist will monitor all Class classes in the code that follow a specific naming rule. (Generally, the class names of business code are "com.company English abbreviation.system name abbreviation"), and only business classes with such naming rules are monitored. This can avoid unnecessary monitoring of non-business code, improve efficiency, and accurately obtain code execution information related to business. It should be noted that when generating the flowchart of the production requirements document, only the methods of business classes need to be generated. Therefore, by using the Class loader to parse the Java source code into bytecode, Java agent can intercept and obtain the bytecode before the Jvm (Java Virtual Machine) loads the bytecode into the JAR (Java Archive) package. Then, after modifying the bytecode through Javassist, it is returned to Java agent, and finally Java agent returns it to the JAR package. Through bytecode instrumentation, a topological relationship graph of the code execution process can be obtained. For example, by inserting a log at the first line of each method through bytecode instrumentation to print the method information, and then obtaining the corresponding instrumented log.

[0112] Step S13: Parse the instrumented log to generate a corresponding topology graph based on the parsed information.

[0113] In this embodiment, the stamping logs with changes in the monitoring results are parsed, and it is determined whether there are conditional branches in the parsed information. If there are no conditional branches, a corresponding topology map is directly generated according to the parsed information. If there are conditional branches, the AST (Abstract Syntax Tree) technology is used to perform judgment and parsing processing on the syntax structure of the source code corresponding to the parsed information. Specifically, parsing the stamping logs to generate a corresponding topology map according to the parsed information includes: parsing the stamping logs and determining whether there are conditional branches under the parent-level method in the parsed information; if there are no such conditional branches, generating a corresponding topology map according to the parsed information; if there are such conditional branches, processing the source code corresponding to the parsed information according to the processing rules that the syntax structure of the source code is a tree structure and the structural elements of the source code are tree nodes to generate a corresponding abstract syntax tree; traversing the abstract syntax tree to determine the tree nodes with conditional branches according to the node type and node attributes; using the node information of the tree nodes as the nodes of the topology map and the logical relationship in the node information as the edges in the topology map to construct a corresponding topology map. It can be understood that a suitable AST parsing tool is used to parse the business code of the system to generate an abstract syntax tree representation. These business codes are usually classes that are bytecode instrumented and monitored and conform to specific naming rules (such as "com.Company English abbreviation.System name abbreviation"). Perform a depth-first traversal of the generated abstract syntax tree. During the traversal process, check the type and attributes of each node to determine whether it is a node related to a branching statement. For example, in Java or other programming languages, look for nodes representing conditional judgment statements (such as if, switch, etc.). When encountering a node, determine whether it is a branching statement node according to its type and attributes. If the node type corresponds to the branching statement type in a specific programming language, such as the node types corresponding to if, else, switch, etc. statements in Java, it can be determined that this is a branching statement. For a branching statement node, further analyze its conditional expression. Extract information such as variables, constants, and operators in the conditional expression to better understand the conditions of the branch. At the same time, determine the branch body of the branching statement, that is, the AST nodes corresponding to the code blocks executed when the condition is true or false. Build the nodes in the topology map according to the information of the branching statement. Each branching statement can correspond to a node in the topology map, and the attributes of the node can include information such as the conditional expression of the branching statement, the related variable names, the type of the branch (such as if-else, switch-case, etc.). For complex branching structures, it may be necessary to merge multiple related branching statements into a higher-level node to better represent the structure of the entire branching logic. Establish connections between the nodes in the topology map according to the logical relationship of the branching statements in the code.For example, if an if statement is immediately followed by an else statement, then a connection is established between the corresponding if node and else node in the topology diagram. For a switch-case statement, each case node is connected to the switch node, and based on the logic of the code, it is determined whether there is a default branch and its connection relationships with other nodes. By establishing these connections, the control flow and logical relationships between the branching statements in the code can be clearly represented. Optimize the generated topology diagram by removing unnecessary nodes or connections to improve the readability and simplicity of the topology diagram. The layout of the topology diagram can be adjusted so that the distribution of nodes is more reasonable and the connections are clearer. Add appropriate annotations and explanations to the topology diagram to better understand the meaning of each node and connection.

[0114] Through the above steps, the AST technology can be used to accurately identify branching statements from the source code of the system and parse a topology diagram that can clearly represent the branching logic of the code, providing important visual support for subsequent requirements document updates and system understanding.

[0115] For example: When there are code changes in the class under the "eating" method in the monitoring result, the code of the printed method information is shown as:

[0116] package com.hncy58.handler;

[0117] / ** File function description: eating ** /

[0118] public class Eating {

[0119] public static void main(String[] args) {

[0120] System.out.println("Having lunch");

[0121] Person r = new Person(region: "Southern person");

[0122] HavingLunch eat = new HavingLunch(r);

[0123] eat.haveLunch();

[0124] }

[0125] }。

[0126] Correspondingly, the display result of the above code after bytecode instrumentation is as follows:

[0127] package com.hncy58.handler;

[0128] / ** File function description: Have lunch on August 14, 2024, 9:52 ** /

[0129] class HaveLunch {

[0130] Person r;

[0131] public HaveLunch(Person r) {

[0132] this.r = r;

[0133] }

[0134] public void haveLunch() {

[0135] if (r.equals("Southern person")) {

[0136] eatRice();

[0137] eatVegetables();

[0138] } else {

[0139] eatNoodles();

[0140] drinkSoup();

[0141] }

[0142] }

[0143] public void eatRice() {}{...}

[0144] public void eatNoodles() {}{...}

[0145] public void eatVegetables() {}{...}

[0146] public void drinkSoup() { System.out.println("Drink soup");}

[0147] }。

[0148] As can be seen from the above code, if the person having lunch is a Southern person, the staking log can be printed as follows:

[0149] - void com.hncy58.handler.HaveLunch#haveLunch()

[0150] -- void com.hncy58.handler.HaveLunch#eatRice()

[0151] -- void com.hncy58.handler.HaveLunch#EatVegetables().

[0152] The structure of the instrumentation log is as Figure 4 shown. From left to right, the structure is package name, class name, and method name. Taking the eating function of the above code as an example, "com.hncy58.handler" is the package name, "HaveLunch" is the class name, and "HaveLunch" is the method name.

[0153] It can be understood that according to the above-printed instrumentation log, the corresponding topology graph is obtained from the log information "HaveLunch#HaveLunch, HaveLunch#EatRice, HaveLunch#EatVegetables" parsed from the people having lunch as southerners as Figure 5 shown. And according to the above code information, if the person having lunch is not a southerner, the following instrumentation log can be printed:

[0154] - void com.hncy58.handler.HaveLunch#HaveLunch()

[0155] -- void com.hncy58.handler.HaveLunch#EatNoodles()

[0156] -- void com.hncy58.handler.HaveLunch#DrinkSoup()

[0157] Among them, the corresponding topology graph generated after parsing is as Figure 6 shown. It should be noted that it can be seen that there are two branches in having lunch, that is, there are conditional branches, so the conditional branches need to be merged to obtain the complete topology graph. The complete topology graph is as Figure 7 shown. Thus, bytecode instrumentation to obtain the topology graph is realized through Java agent and Javassist. From the Figure 7 topology graph, it can be found that there are two branches in the method "HaveLunch", which execute different logics respectively. Therefore, there must be branch statements in this method. Using AST to analyze the code, it is determined whether there are branch statements such as if-else and switch before the method in the class, so as to establish the logical relationship between each method. Thus, the call logical relationship of the methods in the system is finally established, as follows Figure 8 shown.

[0158] Step S14: Use the pre-trained model and according to the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology graph, output the text description corresponding to the topology graph.

[0159] In this embodiment, a blank association mapping table is created; using the requirement code as the key, the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology diagram are associated and stored in the blank association mapping table according to the dimension of the requirement code to obtain the content information associated with each requirement code; wherein, the content information is the associated requirement document information, the associated design document information, the code comments corresponding to the code under the associated preset code annotation, and the associated topology diagram information; the content information associated with each requirement code is input into a pre-trained model so as to output the corresponding text description through the pre-trained model. It can be understood that a data structure, such as an association mapping table, is created, with the requirement code as the key, to store the relevant current requirement document, current design document, code comment fragments, and flowchart information, because in the current requirement document, the code of each requirement is clearly marked. When organizing the content of the requirement document for input into the pre-trained model, the corresponding requirement descriptions, function points, requirement content, etc. are extracted in sequence according to the requirement code and placed in the corresponding positions in the association mapping table. For the current design document, it is also searched and extracted according to the requirement code. Ensure that the parts of the design document related to a specific requirement code, such as architecture design, module design, etc., are accurately associated with the requirement code and added to the association mapping table. In the code, the comments related to a specific requirement code are searched by scanning. For example, by searching for the code part with the "@FunctionPoint" comment with a specific requirement code, the relevant code comment content is extracted and added to the position corresponding to the requirement code in the association mapping table. For the flowchart, determine its corresponding relationship with a specific requirement code. It may be by marking the requirement code in the title, comment, or metadata of the flowchart so that the flowchart can be accurately associated with a specific requirement. The flowchart information is also added to the corresponding position in the association mapping table. Through the above steps, the requirement document, design document, code comments, and flowchart are organized in terms of the requirement code dimension, so that the relevant information of each requirement can be concentrated and accurately associated together, facilitating subsequent input into the pre-trained model for comprehensive analysis. The organized requirement document, design document, code comments, and flowchart are input into an AI (Artificial Intelligence) large model or a self-built AI middle platform. These AI large models or self-built AI middle platforms have powerful language understanding and generation capabilities and can deeply analyze the input complex information. They can understand the logical relationships among the requirements, design, and code implementation of the system based on the input content and use their powerful language processing capabilities to generate accurate and clear flowchart text descriptions. Therefore, when the above-mentioned content related to eating is input into the AI large model, the corresponding text description "1. If a person is from the south, when having lunch, only eat rice and vegetables; 2. If not from the south, only eat noodles and drink soup" is output.

[0160] Step S15: Update the original requirements document of the system using the text description to obtain a real-time requirements document.

[0161] In this embodiment, the text description of the generated flowchart is obtained from an AI large model or a self-built AI middleware platform. This description should accurately reflect the business process and control flow of the system, corresponding to the flowchart, providing detailed instructions for the update of the requirements document. Integrate the generated flowchart and its text description into the existing original requirements document. The flowchart and its text description can be added to the corresponding part of the original requirements document, or a dedicated chapter can be created to display the flowchart and explanations, ensuring that the requirements document can comprehensively and accurately reflect the current state of the system.

[0162] In this way, the real-time update of the requirements document according to the code is achieved. Whenever the system code changes, after a series of monitoring, analysis, and AI processing steps, the requirements document can reflect these changes in a timely manner, enabling people who want to understand the application system to accurately understand the functions and implementation methods of the system through the latest requirements document, avoiding the difficulty of understanding caused by the inconsistency between the requirements document and the application system.

[0163] It can be seen that the present application discloses a method for real-time dynamic update of a system requirements document, including: real-time monitoring of preset code annotations after the source code of the system is updated according to the current requirements document to obtain corresponding monitoring results; wherein, the preset code annotations are used to mark the entry functions of system function points; when the monitoring result shows that there are code changes in the methods at all levels under the preset code annotations, all business classes under the target-level methods with code changes during the operation of the current system are monitored through a Java proxy tool and a bytecode instrumentation tool to obtain corresponding instrumentation logs; wherein, the instrumentation logs include the execution paths of the code in the business classes and the call relationships of the methods at all levels; parsing the instrumentation logs to generate a corresponding topology diagram according to the parsing information; using a pre-trained model and based on the current requirements document, the current design document written based on the current requirements document, the preset code annotations, and the topology diagram to output a text description corresponding to the topology diagram; using the text description to update the original requirements document of the system to obtain a real-time requirements document. Thus, by real-time monitoring the preset code annotations after code update, it is ensured that changes in the system source code can be detected in a timely manner. When the system is iteratively updated, the requirements document will no longer be inconsistent with the actual system functions due to lack of timely follow-up, and always ensure that the requirements document can accurately reflect the current state of the system. By using preset code annotations to mark the entry functions of system function points, it is possible to specifically monitor the code parts directly related to system functions, improving the accuracy and efficiency of monitoring. By using a Java proxy tool and a bytecode instrumentation tool, only all business classes under the target-level methods with code changes are monitored, avoiding unnecessary monitoring of non-business code, reducing resource consumption, and at the same time accurately obtaining the code execution paths and method call relationships related to the business. Parsing the instrumentation logs to generate a topology diagram provides a visual representation of the complex code structure and control flow of the system. Developers and relevant personnel can more intuitively understand the logical structure of the system, which helps to quickly locate problems and optimize the system. The text description corresponding to the topology diagram output by the pre-trained model further enhances the understanding of the system. The text description can more detailedly explain each node and connection relationship in the topology diagram, enabling personnel unfamiliar with the code to understand the functions and processes of the system through the requirements document. In this way, real-time automatic update of the requirements document is achieved, eliminating the need to specially arrange personnel to manually maintain the requirements document, greatly reducing the labor cost.

[0164] As shown in Figure 9 the present invention also correspondingly discloses a device for real-time dynamic update of a system requirements document, including:

[0165] The monitoring module 11 is used to monitor in real time the preset code annotations after the source code of the system is updated according to the current requirement document, so as to obtain corresponding monitoring results; wherein, the preset code annotations are used to mark the entry functions of system function points.

[0166] The stub logging acquisition module 12 is used to, when the monitoring result indicates that there are code changes in the methods at all levels under the preset code annotations, monitor all business classes under the target-level methods with code changes during the operation of the current system through a Java proxy tool and a bytecode stubbing tool, so as to obtain corresponding stub logs; wherein, the stub logs include the execution paths of the code in the business classes and the call relationships of the methods at all levels.

[0167] The topology generation module 13 is used to parse the stub logs, so as to generate corresponding topology diagrams according to the parsing information.

[0168] The text generation module 14 is used to utilize a pre-trained model and output a text description corresponding to the topology diagram according to the current requirement document, the current design document written based on the current requirement document, the preset code annotations, and the topology diagram.

[0169] The document update module 15 is used to update the original requirement document of the system by using the text description, so as to obtain a real-time requirement document.

[0170] It can be seen that the present application discloses real-time monitoring of preset code annotations after the system source code is updated according to the current requirement document to obtain corresponding monitoring results; wherein, the preset code annotations are used to mark the entry functions of system function points; when the monitoring result indicates that there are code changes in the methods at all levels under the preset code annotations, all business classes under the target-level methods with code changes during the current system operation are monitored through a Java proxy tool and a bytecode instrumentation tool to obtain corresponding instrumentation logs; wherein, the instrumentation logs include the execution paths of the code in the business classes and the call relationships of the methods at all levels; the instrumentation logs are parsed to generate a corresponding topology diagram according to the parsed information; a pre-trained model is used and based on the current requirement document, the current design document written based on the current requirement document, the preset code annotations, and the topology diagram, a text description corresponding to the topology diagram is output; the original requirement document of the system is updated using the text description to obtain a real-time requirement document. Thus, by real-time monitoring the preset code annotations after code update, it is ensured that changes in the system source code can be detected in a timely manner. When the system is iteratively updated, the requirement document will no longer be inconsistent with the actual system functions due to lack of timely follow-up, and the requirement document can always accurately reflect the current state of the system. By marking the entry functions of system function points with preset code annotations, it is possible to specifically monitor the code parts directly related to system functions, improving the accuracy and efficiency of monitoring. Using a Java proxy tool and a bytecode instrumentation tool, only all business classes under the target-level methods with code changes are monitored, avoiding unnecessary monitoring of non-business code, reducing resource consumption, and at the same time accurately obtaining the code execution paths and method call relationships related to the business. Parsing the instrumentation logs to generate a topology diagram provides a visual representation of the complex code structure and control flow of the system. Developers and relevant personnel can more intuitively understand the logical structure of the system, which helps to quickly locate problems and optimize the system. The text description corresponding to the topology diagram output by the pre-trained model further enhances the understanding of the system. The text description can more detailedly explain each node and connection relationship in the topology diagram, enabling personnel unfamiliar with the code to understand the functions and processes of the system through the requirement document. In this way, real-time automatic update of the requirement document is achieved, eliminating the need to specially arrange personnel to manually maintain the requirement document, greatly reducing the labor cost.

[0171] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 10 It is a structural diagram of an electronic device 20 shown according to an exemplary embodiment, and the content in the figure should not be regarded as any limitation on the scope of use of the present application.

[0172] Figure 10Schematic diagram of the structure of an electronic device 20 provided by an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. Among them, the memory 22 is used to store a computer program, and the computer program is loaded and executed by the processor 21 to implement the relevant steps in the method for real-time dynamic update of the system requirements document disclosed in any of the foregoing embodiments. In addition, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0173] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of the present application, and no specific limitation is imposed on it here; the input / output interface 25 is used to obtain external input data or output data to the outside, and the specific interface type thereof can be selected according to specific application needs, and no specific limitation is made here.

[0174] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 may be implemented in at least one of the following hardware forms: DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor used to process data in the wake state, also known as the CPU (Central Processing Unit); the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may be integrated with a GPU (Graphics Processing Unit), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, and the AI processor is used to process computing operations related to machine learning.

[0175] In addition, the memory 22, as a carrier for resource storage, may be a read-only memory, a random access memory, a magnetic disk, or an optical disc, etc. The resources stored thereon may include an operating system 221, a computer program 222, etc., and the storage method may be temporary storage or permanent storage.

[0176] Among them, the operating system 221 is used to manage and control each hardware device on the electronic device 20 and the computer program 222, so as to implement the operation and processing of the massive data 223 in the memory 22 by the processor 21. It can be Windows Server, Netware, Unix, Linux, etc. In addition to the computer program that can be used to complete the real-time dynamic update method of the system requirements document executed by the electronic device 20 disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs that can be used to complete other specific tasks. In addition to the data that can include the data transmitted by the external device received by the electronic device, the data 223 may also include the data collected by its own input / output interface 25, etc.

[0177] Further, the present application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the real-time dynamic update method of the system requirements document disclosed above is implemented. For the specific steps of this method, reference can be made to the corresponding content disclosed in the foregoing embodiments, and details are not described herein again.

[0178] In this specification, the various embodiments are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same or similar parts among the various embodiments, reference can be made to each other. For the device disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple. For the relevant parts, reference can be made to the description in the method part.

[0179] Those skilled in the art may further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to their functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application. The steps of the methods or algorithms described in combination with the embodiments disclosed herein can be directly implemented by hardware, software modules executed by a processor, or a combination of the two. The software modules can be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disk, removable disk, CD-ROM (Compact Disc-Read Only Memory), or any other form of storage medium known in the art.

[0180] Finally, it should also be noted that in this text, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variation thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising a..." does not exclude the existence of additional identical elements in the process, method, article or device comprising the said element.

[0181] The above has introduced the solution provided by the present invention in detail. Specific examples are used herein to illustrate the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation on the present invention.

Claims

1. A method for real-time dynamic update of system requirements documents, characterized in that Including: Real-time monitor the preset code annotations after updating the system source code according to the current requirements document to obtain corresponding monitoring results; wherein, the preset code annotations are used to mark the entry functions of system function points. When the monitoring result indicates that there are code changes in the methods at all levels under the preset code annotations, monitor all business classes under the target-level methods with code changes during the operation of the current system through a Java proxy tool and a bytecode instrumentation tool to obtain corresponding instrumentation logs; wherein, the instrumentation logs contain the execution paths of the code in the business classes and the call relationships of the methods at all levels. Parse the instrumentation logs to generate a corresponding topology graph according to the parsing information. Utilize a pre-trained model and, based on the current requirements document, the current design document written based on the current requirements document, the preset code annotations, and the topology graph, output a text description corresponding to the topology graph. Update the original requirements document of the system using the text description to obtain a real-time requirements document. The parsing of the instrumentation logs to generate a corresponding topology graph according to the parsing information includes: Parse the instrumentation logs and determine whether there are conditional branches under the parent-level methods in the parsing information; if there are no such conditional branches, generate a corresponding topology graph according to the parsing information; if there are conditional branches, process the source code corresponding to the parsing information according to the processing rules where the syntax structure of the source code is a tree structure and the structural elements of the source code are tree nodes to generate a corresponding abstract syntax tree; traverse the abstract syntax tree to determine the tree nodes with conditional branches according to the node type and node attributes; use the node information of the tree nodes as the nodes of the topology graph and the logical relationships in the node information as the edges in the topology graph to construct a corresponding topology graph. The utilizing of a pre-trained model and, based on the current requirements document, the current design document written based on the current requirements document, the preset code annotations, and the topology graph, outputting a text description corresponding to the topology graph includes: Create a blank association mapping table; using the requirement code as the key, store the current requirements document, the current design document written based on the current requirements document, the preset code annotations, and the topology graph in the blank association mapping table according to the requirement code dimension to obtain the content information associated with each requirement code; wherein, the content information is the associated requirements document information, the associated design document information, the code comments corresponding to the code under the associated preset code annotations, and the associated topology graph information; input the content information associated with each requirement code into the pre-trained model to output the corresponding text description through the pre-trained model.

2. The real-time dynamic update method for the system requirements document according to claim 1, characterized in that Before the real-time monitoring of the preset code annotations after updating the system source code according to the current requirements document, it further includes: When there is a system establishment requirement, analyze the system requirements at all levels of the system establishment requirement to create an original requirements document. Write a corresponding original design document according to the original requirements document. Establish a system according to the original design document.

3. The real-time dynamic update method for the system requirements document according to claim 2, characterized in that The system analyzes the established requirements at all levels of system requirements to create an original requirements document, including: The system analyzes the established requirements to obtain system requirements at all levels with associated relationships; Each requirement of the system requirements at all levels is encoded to obtain encoded information corresponding in the order of requirement code, requirement name, system function point, and requirement content; The original requirements document is created using the encoded information.

4. The real-time dynamic update method for the system requirements document according to claim 3, characterized in that It also includes: The entry function of the system function point of each requirement of the system requirements at all levels is marked through a preset code annotation.

5. The real-time dynamic update method for the system requirements document according to claim 1, characterized in that All business classes under the target-level method with code changes during the operation of the current system are monitored through a Java proxy tool and a bytecode instrumentation tool to obtain corresponding instrumentation logs, including: The updated source code during the operation of the current system is loaded through a class loader to obtain bytecode; The Java proxy tool is used to intercept the bytecode, and the bytecode instrumentation tool is used to instrument the first line of bytecode representing methods at all levels, so as to monitor whether there are code changes in the business classes under methods at all levels and obtain corresponding instrumentation logs.

6. A real-time dynamic update device for a system requirements document, characterized in that, It includes: A monitoring module for real-time monitoring of the preset code annotation after the source code of the system is updated according to the current requirements document to obtain corresponding monitoring results; wherein, the preset code annotation is used to mark the entry function of the system function point; An instrumentation log acquisition module for, when the monitoring result indicates that there are code changes in the methods at all levels under the preset code annotation, monitoring all business classes under the target-level method with code changes during the operation of the current system through a Java proxy tool and a bytecode instrumentation tool to obtain corresponding instrumentation logs; wherein, the instrumentation log contains the execution path of the code in the business class and the call relationship of methods at all levels; A topology generation module for parsing the instrumentation log to generate a corresponding topology diagram according to the parsing information; A text generation module for using a pre-trained model and outputting a text description corresponding to the topology diagram based on the current requirements document, the current design document written based on the current requirements document, the preset code annotation, and the topology diagram; A document update module for using the text description to update the original requirements document of the system to obtain a real-time requirements document; The topology generation module is specifically used to parse the instrumentation log and determine whether there is a conditional branch under the parent-level method in the parsing information; if there is no such conditional branch, a corresponding topology diagram is generated according to the parsing information; if there is a conditional branch, the source code corresponding to the parsing information is processed according to the processing rule that the syntax structure of the source code is a tree structure and the structural elements of the source code are tree nodes to generate a corresponding abstract syntax tree; traverse the abstract syntax tree to determine the tree nodes with conditional branches according to the node type and node attributes; use the node information of the tree nodes as the nodes of the topology diagram and the logical relationship in the node information as the edges in the topology diagram to construct a corresponding topology diagram; The text generation module is specifically configured to create a blank association mapping table; using the requirement code as the key, associatively store the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology diagram according to the requirement code dimension into the blank association mapping table to obtain the content information associated with each requirement code; wherein the content information is the associated requirement document information, the associated design document information, the code comments corresponding to the codes under the associated preset code annotation, and the associated topology diagram information; input the content information associated with each requirement code into a pre-trained model so as to output corresponding text descriptions through the pre-trained model.

7. An electronic device, characterized in that, including: a memory for storing a computer program; a processor for executing the computer program to implement the steps of the system requirement document real-time dynamic update method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, for storing a computer program; wherein when the computer program is executed by the processor, the steps of the system requirement document real-time dynamic update method according to any one of claims 1 to 5 are implemented.

Images