Product requirement closed-loop management method based on product function baseline and electronic device

Abstract

The application discloses a product demand closed-loop management method based on a product function baseline and electronic equipment, and comprises the following steps: establishing a product function baseline knowledge base according to a product function classification framework; obtaining source code of a target product, performing reverse analysis on the source code, and completing initialization of the product function baseline knowledge base; extracting demand characteristic information, searching the product function baseline knowledge base, and determining a function node and a function path corresponding to a target demand; when a corresponding function node is not searched, generating baseline gap information; generating a structured demand document; and performing incremental updating on a corresponding function node in the product function baseline knowledge base according to function change content corresponding to the demand document. The application makes the product function baseline run through the whole process of demand analysis, technical design, software development and version iteration, provides a unified data basis for influence range analysis, module boundary determination and interface relationship analysis, and improves the utilization efficiency of product knowledge in the whole software development process.

Description

Technical Field

[0001] This invention relates to the fields of software development process management and software engineering technology, and in particular to a product requirement closed-loop management method and electronic device based on product functional baseline knowledge management, code reverse analysis and intelligent requirement generation. Background Technology

[0002] In the software product development process, the Product Requirements Document (PRD) is a crucial document connecting business requirements analysis, technical design, software development, and testing. The PRD not only describes the business logic and interaction rules of new features but also serves as a vital basis for the development team to design technical solutions, analyze the scope of impact, and implement the project. Therefore, the completeness, accuracy, and consistency with the existing system of the PRD directly affect software development efficiency and quality.

[0003] As software systems continue to evolve and the number of product features increases, the dependencies between system modules become increasingly complex. When writing requirements documents, product managers typically need to consult various sources, including historical requirements documents, product design materials, interface documents, development specifications, and code implementations, to determine the functional module to which the requirement belongs, the scope of the system involved, and the relevant development teams. However, this information is usually scattered across different data sources, lacking a unified organizational structure and relationships. Product managers must rely on manual retrieval, analysis, and organization to complete the requirements document, which is not only inefficient but also prone to incomplete requirements descriptions due to information omissions or misunderstandings.

[0004] On the other hand, to ensure the long-term accumulation of product knowledge, some R&D teams establish product functional baseline documents to record the product's functional structure, business rules, and module divisions. However, existing product functional baselines typically rely on manual maintenance, requiring manual review of a large number of existing functions and significant initialization work. As software versions iterate, the code implementation continuously changes, while baseline document updates usually depend on proactive maintenance by R&D or product personnel. Due to the lack of an effective update trigger mechanism, the product functional baseline gradually becomes disconnected from the actual system implementation, making it difficult to maintain consistency and thus reducing the reference value of the baseline document.

[0005] Furthermore, after the requirements are written, new features and changes are usually only reflected in the requirements document and code implementation, and are not automatically reflected in the product functional baseline, making it difficult for product knowledge to accumulate and evolve continuously. Subsequent requirements writing still requires repeated analysis of existing system functions, resulting in a large amount of repetitive work. It also makes it difficult for developers to quickly obtain accurate module boundaries, interface relationships, and historical evolution information when carrying out technical design, increasing the costs of requirements communication and technical design.

[0006] While existing technologies utilize AI models to assist in generating requirement documents or code analysis techniques to aid in understanding program structure, these solutions typically optimize individual stages such as requirement generation or code analysis. They lack a unified mechanism for organizing, continuously maintaining, and recycling product functional knowledge, and have not yet formed a closed-loop management process that links product functional baseline initialization, requirement generation, baseline updates, and technical design. Therefore, establishing a system that can automatically construct product functional baselines based on the actual implementation of the software system, continuously consume, monitor, and update these baselines during the requirement generation process, thereby maintaining consistency between product knowledge and system implementation and achieving a knowledge closed loop throughout the entire product requirement management process, has become a pressing technical problem in this field. Summary of the Invention

[0007] To address the problems in existing technologies, such as reliance on manual maintenance of product functional knowledge, high initialization costs of product functional baselines, easy disconnect between product functional baselines and software system implementation, lack of unified knowledge support during requirement document writing, and difficulty in continuously accumulating product knowledge, this invention provides a closed-loop management method for product requirements based on product functional baselines. Using a product functional baseline knowledge base as a unified knowledge carrier, the method achieves automatic initialization of product functional baselines through code reverse engineering and continuously updates the product functional baselines during requirement writing and product iteration. This allows product functional knowledge to continuously evolve with the software system, providing unified and accurate data support for requirement writing, technical design, and impact scope analysis.

[0008] To achieve the above objectives, the present invention adopts the following technical solution.

[0009] A closed-loop management method for product requirements based on product functional baselines includes: S1. Establish a product function baseline knowledge base based on the product function classification framework. The product function baseline knowledge base adopts a tree-like hierarchical structure to organize multiple functional nodes. Each functional node is associated with at least the implementation logic, business rules, interface conventions and historical change information of the corresponding function. S2. Obtain the source code of the target product, reverse analyze the source code, generate implementation information corresponding to each functional node based on the analysis results, and write it into the product functional baseline knowledge base to complete the initialization of the product functional baseline knowledge base. S3. Obtain the requirement description information of the requirement to be processed, extract the requirement features from the requirement description, search the product function baseline knowledge base according to the requirement features, and determine the functional node and its functional path corresponding to the target requirement; when no corresponding functional node is found, generate baseline gap information. S4. Generate a structured requirements document based on the determined functional nodes and content; S5. After the requirements are completed, based on the functional changes in the requirements document, perform incremental updates on the corresponding functional nodes in the product functional baseline knowledge base, so that the updated product functional baseline knowledge base can serve as the data source for subsequent requirements writing and technical design.

[0010] Furthermore, the product function baseline knowledge base adopts a tree-like hierarchical structure to organize product functions, including first-level functional domains, second-level functional modules, and third-level functional nodes. Each functional node includes at least product-related implementation logic, business rules, interface agreements, and historical change records.

[0011] Furthermore, the step of establishing a product function baseline knowledge base based on the product function classification framework includes: establishing a function module tree based on the function classification results of the product system; determining the hierarchical relationship between each function node based on the function module tree; and using the hierarchical relationship as the target structure for reverse parsing of the source code to organize and store the implementation information corresponding to each function node.

[0012] Furthermore, the reverse analysis of the source code includes: identifying the program module corresponding to the target functional node in the source code; extracting the implementation logic, business rules, and interface information corresponding to the program module; generating data records for the corresponding functional node according to the data structure of the product functional baseline knowledge base, and writing them into the product functional baseline knowledge base.

[0013] Furthermore, the structured requirements document includes at least one of the following: information on the functional module affiliation, the application systems involved, the associated R&D teams, functional descriptions, interaction instructions, and acceptance criteria.

[0014] Furthermore, updating the product function baseline knowledge base based on the function change content corresponding to the requirement document includes: determining the target function node corresponding to the requirement document; extracting the function change information corresponding to the requirement document; incrementally writing the function change information into the data record corresponding to the target function node, and maintaining consistency with the data organization format generated during initialization.

[0015] Furthermore, the updated product feature baseline knowledge base is used for retrieving corresponding feature nodes and generating requirement documents during subsequent requirement processing, and serves as a data source for obtaining module boundaries, interface conventions, and module dependencies in the subsequent technical design phase.

[0016] Furthermore, each functional node in the product functional baseline knowledge base records the relationship between it and other functional nodes. During the technical design process, the scope of influence of the target function is determined based on the relationship between the target functional node and other functional nodes in order to obtain information on related modules, dependent modules, and downstream systems.

[0017] Compared with the prior art, the present invention has at least the following beneficial effects: (1) The present invention adopts a product function baseline knowledge base to uniformly organize software product function knowledge, and uses source code as the data source for initializing product function baseline, so that product function baseline can truly reflect the current implementation status of software system and improve the consistency between product function baseline and actual software system.

[0018] (2) In the process of requirement generation, the present invention completes requirement positioning and function path determination based on the product function baseline, so that the requirement document can be directly associated with the existing product function structure, improve the efficiency of requirement document generation, and reduce information omissions caused by manual determination of function attribution.

[0019] (3) In the process of demand processing, the present invention can automatically detect missing functions in the product function baseline and complete the incremental update of the product function baseline in conjunction with the demand archiving process, so that the product function knowledge can be continuously improved with the continuous iteration of the product and realize the automatic evolution of product function knowledge.

[0020] (4) This invention enables the product functional baseline to run through the entire process of requirements analysis, technical design, software development and version iteration, providing a unified data foundation for impact scope analysis, module boundary determination and interface relationship analysis, and improving the utilization efficiency of product knowledge throughout the software development process.

[0021] (5) The present invention establishes a product knowledge closed-loop management mechanism that combines product function baseline initialization, demand consumption, gap detection and incremental update, so that product function knowledge can be continuously accumulated and recycled, reducing the long-term maintenance cost of product function knowledge. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of the overall process of the product demand closed-loop management method in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the three-stage lifecycle management process of the baseline knowledge base in this embodiment of the invention. Figure 3 This is a flowchart of baseline gap exposure and incremental mechanism update in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the closed-loop knowledge transfer process in an embodiment of the present invention. Detailed Implementation

[0024] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. Those skilled in the art should understand that the following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention. Equivalent substitutions or combinations of technical features in the embodiments without departing from the concept of the present invention should all fall within the scope of protection of the present invention.

[0025] This embodiment provides a closed-loop management method for product requirements based on product functional baselines, and its overall process is as follows: Figure 1 As shown, the process includes stages such as establishing a product function baseline knowledge base, code reverse engineering initialization, requirement identification and requirement document generation, baseline incremental updates, and continuous evolution. This embodiment first describes the establishment and initialization process of the product function baseline knowledge base.

[0026] S101. Establish a product function baseline knowledge base. The product functional baseline knowledge base is used to store the functional structure of the software product and the corresponding implementation information of each function. As a unified knowledge carrier throughout the entire requirement closed-loop management process, it provides a data foundation for subsequent requirement identification, requirement document generation, technical design, and continuous baseline updates. In this embodiment, the product functional baseline knowledge base is established according to the product functional classification framework. The knowledge base uses a tree-like hierarchical structure to organize multiple functional nodes, and each functional node is associated with at least the implementation logic, business rules, interface agreements, and historical change information of the corresponding function.

[0027] Specifically, establishing a product function baseline knowledge base based on the product function classification framework includes: building a functional module tree based on the product system's function classification results; determining the hierarchical relationship between functional nodes based on the functional module tree; and using the hierarchical relationship as the target structure for reverse engineering of the source code to organize and store the implementation information corresponding to each functional node. In this embodiment, the tree-like hierarchical structure includes first-level functional domains, second-level functional modules, and third-level functional nodes. Of course, in other embodiments, more levels can be set or other hierarchical division methods can be adopted according to the product scale, as long as the subordinate relationship between each functional node can be uniquely determined.

[0028] Each functional node corresponds to a minimal business unit within the product, describing a function that the system can independently perform. In one implementation, the functional node may correspond to a page function, business service, interface service, business process node, configuration unit, or other software functional unit with independent business semantics. This invention does not limit this specific implementation.

[0029] To ensure the continuous accumulation of product functional knowledge, a corresponding functional node data record is established for each functional node. The functional node data record includes at least the following information: (1) Functional identification information, used to uniquely identify the corresponding functional node; (2) Functional path information, used to indicate the hierarchical position of the current functional node in the product functional tree; (3) Implementation logic information, used to describe the software implementation logic corresponding to this function; (4) Business rule information, which describes the business processing rules corresponding to the function; (5) Interface agreement information, used to describe the data interfaces, service interfaces or calling relationships involved in the function; (6) Historical change information, used to record the evolution process and historical versions of functional nodes.

[0030] The above information collectively forms the functional node data structure in the product functional baseline knowledge base. Each functional node is stored according to a unified data organization method, thereby ensuring that the entire product functional baseline knowledge base has a unified data format, providing a foundation for subsequent automatic updates and continuous maintenance. Each functional node in the product functional baseline knowledge base records the relationships between other functional nodes. During the technical design process, the scope of influence of the target function is determined based on the relationships between the target functional node and other functional nodes, in order to obtain information on related modules, dependent modules, and downstream systems.

[0031] It should be noted that the product functional baseline knowledge base in this embodiment is not a traditional product specification document, but rather a structured knowledge set used to describe the functional structure of the software system and its implementation relationships. Since all functional nodes are organized using a unified data structure, it can support subsequent operations such as functional retrieval, path location, knowledge updates, and impact scope analysis.

[0032] S102. Initialize the product function baseline knowledge base based on code reverse analysis. After establishing the product functional baseline knowledge base, initialize it.

[0033] Unlike traditional product function baselines that rely on manual analysis, this embodiment uses software source code as the source of product function facts. It performs reverse analysis on the source code corresponding to the target product, generates implementation information for each function node from the analysis results, and writes it into the product function baseline knowledge base to complete the initialization of the product function baseline knowledge base.

[0034] Specifically, the system first obtains the source code corresponding to the target product. In one implementation, the source code may come from a code repository or from a code version in a continuous integration platform; this invention does not limit this.

[0035] Subsequently, static analysis is performed on the acquired source code to identify the program modules corresponding to the target functional nodes, and to extract the implementation logic, business rules, and interface information of the program modules. During static analysis, information such as the program directory structure, naming conventions, interface declarations, comments, and configuration files can be combined to comprehensively analyze the business functions implemented by the corresponding program modules.

[0036] After static parsing is completed, the parsed program modules are mapped to corresponding functional nodes according to the product function classification framework established in step S101. Specifically, for each program module, the system determines its functional domain, functional module, and functional node location, and establishes the correspondence between program modules and functional nodes.

[0037] After establishing the mapping relationship, further extract the implementation information related to the functional node, including the corresponding functional implementation logic, business rules, interface conventions, and dependencies between modules, and generate data records for the corresponding functional node according to the data structure preset in the product functional baseline knowledge base.

[0038] When multiple program modules work together to implement the same functional node, the implementation information of the multiple program modules can be associated with the same functional node; when the same program module involves multiple functional nodes, the association between the same program module and multiple functional nodes is established to ensure that the product's functional structure can accurately reflect the actual software implementation.

[0039] Finally, the data records of each functional node are uniformly written into the product functional baseline knowledge base, and the entire product functional tree is organized according to the product functional classification framework to form the initial version of the product functional baseline knowledge base.

[0040] In this embodiment, the product function baseline knowledge base is initialized by reverse engineering the source code. Compared with manually compiling product function documents, this not only reduces the initialization workload, but also maintains consistency between the product function baseline and the system implementation because the baseline content comes from the actual implementation of the software system. This provides a reliable data foundation for subsequent requirement positioning, requirement document generation, and continuous baseline evolution.

[0041] S103, Requirements positioning based on product functional baseline After the product functional baseline knowledge base is initialized, when new business requirements arise for the product, the system uses the product functional baseline knowledge base to locate the requirements, thereby determining the functional module to which the requirements belong and the corresponding software implementation scope.

[0042] Specifically, the system first obtains the requirement description information corresponding to the requirement to be processed. The requirement description information may come from the requirement input interface, product planning documents, business specification documents, or other text input methods, and this invention does not limit it.

[0043] Subsequently, the requirement description information is preprocessed to obtain requirement information that can characterize the requirement features. In one embodiment, the preprocessing includes text segmentation, terminology normalization, business entity identification, functional behavior identification, and keyword extraction, etc., to eliminate semantic differences caused by different requirement description methods and improve the accuracy of subsequent functional node retrieval.

[0044] After obtaining the requirements characteristics, the system searches the product function baseline knowledge base based on the requirements characteristics.

[0045] It should be noted that the retrieval objects in this embodiment are not limited to function names, but rather comprehensively utilize multi-dimensional data such as function node identifiers, function paths, implementation logic, business rules, and historical change information for matching, thereby improving the accuracy of target function node location.

[0046] When a unique target functional node is found, the system reads the data record of the corresponding functional node and determines the functional path corresponding to the target requirement. For example, it can determine that the target requirement belongs to the complete hierarchical path of "first-level functional domain → second-level functional module → third-level functional node", and at the same time obtain the implementation logic, interface conventions and historical change information corresponding to the functional node.

[0047] If multiple candidate functional nodes are found, the target functional node can be determined by combining the functional path to which each candidate node belongs, the node hierarchy, and historical change records, so as to avoid mislocation due to similar functional descriptions in different modules.

[0048] On the other hand, when no target function node meeting the matching conditions exists in the product function baseline knowledge base, it indicates that the new function involved in the current requirement has not yet been included in the product function baseline. In this case, the system generates a corresponding baseline gap record, which includes at least a requirement identifier, requirement characteristic information, a description of the missing function, and suggested locations for supplementation, and adds the baseline gap record to the supplementation queue. The process of baseline gap exposure and incremental mechanism updates is as follows: Figure 3 As shown.

[0049] It should be noted that the baseline gap record in this embodiment does not directly modify the product function baseline knowledge base, but serves as the data source for subsequent incremental updates of the product function baseline, realizing a gap detection mechanism in the process of continuous improvement of the product function baseline.

[0050] Therefore, in this embodiment, the product function baseline not only serves as a data source for requirement localization but also functions as a product knowledge integrity checker. When a requirement cannot be mapped to an existing functional node, the missing parts in the product function baseline can be automatically identified, thus triggering the continuous evolution of the product function baseline.

[0051] S104. Generate structured requirements documents based on the product functional baseline. After identifying the target functional nodes, the system generates a structured requirements document based on the information associated with the corresponding functional nodes in the product functional baseline knowledge base.

[0052] Specifically, the system reads the implementation logic, business rules, interface agreements, and historical change information associated with the target functional node, and generates a draft requirement document in combination with the current requirement description information.

[0053] In one implementation, the generated structured requirements document includes at least the following: functional module affiliation information, involved application systems, functional descriptions, interaction instructions, acceptance criteria, and related R&D information. Specifically, the functional module affiliation information is directly obtained from the functional path determined in step S103; the involved application systems are generated based on the system information associated with the functional nodes; the functional descriptions are generated by combining the requirements description information with the existing functional implementation logic; the interaction instructions are generated by combining the page or business process information associated with the target functional nodes; and the acceptance criteria are automatically generated based on functional behavior and business rules.

[0054] Because the requirements document directly references structured information from the product functional baseline knowledge base, the generated requirements document can maintain consistency with the existing functional structure of the product, avoiding problems such as incorrect module attribution, missing interfaces, or missing scope of impact caused by human misunderstanding.

[0055] On the other hand, since the requirements document already contains the product function path corresponding to the target function, the developers can quickly locate the corresponding function node based on the path, and further obtain the interface conventions, implementation logic and historical change information of the corresponding module, providing a unified data foundation for subsequent technical design.

[0056] Once the draft is completed, it usually needs to be reviewed and approved by the product manager, including confirming the functional boundaries, module affiliation, and priority determination, in order to prevent errors in the large model from affecting the accuracy and usability of the requirements document.

[0057] After the requirements document is generated, it can be output to the target document management system according to actual business needs, and a relationship with the project management system can be established to support subsequent R&D process management.

[0058] It should be noted that the platform on which the requirements document is output is not the focus of this invention. The target document system in this embodiment can be any platform that supports document storage and version management, and this invention does not limit it.

[0059] S105, Incremental Update of Product Function Baseline Knowledge Base Once the requirements have been developed and confirmed to be in the archiving stage, the corresponding functional nodes in the product functional baseline knowledge base are incrementally updated based on the functional changes in the requirements document. This updated product functional baseline knowledge base serves as the data source for subsequent requirements writing and technical design.

[0060] Specifically, the system first obtains the completed and archived requirements documents and identifies the target functional nodes corresponding to the requirements documents. Then, it extracts functional change information corresponding to the requirements documents, such as newly added functions, function modifications, business rule adjustments, interface changes, and module dependency changes.

[0061] For existing functional nodes, the system incrementally writes functional change information into the data record corresponding to the target functional node, maintaining consistency with the data organization format generated during initialization, while also updating the corresponding historical change record.

[0062] For the baseline gap record generated in step S103, the system establishes new functional nodes based on the archived requirements document, determines the functional path to which they belong, and then generates corresponding node data records according to the unified data structure of the product functional baseline knowledge base to complete the supplementation of the new functional nodes.

[0063] After the functional nodes are updated, the system re-establishes the relationship between the new nodes and the existing nodes, so that the product functional baseline always maintains a complete functional tree structure.

[0064] To ensure data consistency in the product function baseline knowledge base, in this embodiment, both newly added and updated nodes are stored using the same data organization method as in the initialization phase, thereby ensuring that the product function baseline knowledge base maintains a unified data format and data organization rules during the initialization and continuous evolution phases.

[0065] The updated product feature baseline knowledge base is used for retrieving corresponding feature nodes and generating requirement documents during subsequent requirement processing, and serves as a data source for obtaining module boundaries, interface conventions, and module dependencies in the subsequent technical design phase.

[0066] In a preferred embodiment, the code reverse initialization module, the requirement location module, and the baseline update module can be implemented by a code reverse agent, a requirement document agent, and an archiving agent, respectively. The three-stage lifecycle management process of the baseline knowledge base, jointly completed by these agents and humans, is as follows: Figure 2 As shown.

[0067] S106. Continuous Evolution of Product Function Baseline and Knowledge Loop After completing the incremental update of the product function baseline knowledge base as described in step S105, the updated product function baseline knowledge base is used again as the data basis for the subsequent requirement processing process to participate in the next round of requirement positioning and requirement document generation, thereby forming a continuous evolution process of the product function baseline.

[0068] In this embodiment, the product functional baseline knowledge base is not established once and remains unchanged for a long time. Instead, it continuously receives information on new functions and function changes during the continuous iteration of the software product, so that the product functional baseline can always reflect the current actual implementation status of the software system.

[0069] Specifically, when new requirements enter the system, the requirements are first identified based on the current version's product feature baseline knowledge base. After the requirements are developed and archived, the new feature information is written back into the product feature baseline knowledge base. Then, the updated product feature baseline knowledge base continues to participate in the next round of requirement processing. As product versions continue to iterate, the product feature baseline knowledge base continuously adds new feature nodes, updates existing feature nodes, and accumulates historical change records, thus forming a continuously evolving product knowledge system.

[0070] Because the product functional baseline knowledge base maintains a consistent data organization method, the functional nodes generated during the initialization phase and the functional nodes added during the continuous update phase have the same data structure. This allows the product functional baseline knowledge base to maintain a consistent data format and functional organization method over the long term, avoiding the gradual invalidation of product knowledge due to changes in naming methods, description granularity, or organizational structure during manual maintenance.

[0071] Furthermore, since the product functional baseline knowledge base stores the hierarchical relationships, interface conventions, and dependencies between functional nodes, when R&D personnel carry out technical design, they can quickly locate the corresponding functional nodes based on the functional paths recorded in the requirements document and obtain the functional information associated with the target functional node.

[0072] For example, when the target requirement involves a certain functional module, the R&D personnel can further obtain the parent module, the lower-level functional nodes, and the related modules that have calling or dependency relationships with that functional module. Based on this, they can analyze the system scope that the functional modification may affect, and provide a unified data basis for technical solution design, impact assessment, and R&D review.

[0073] Therefore, the product functional baseline knowledge base in this invention not only serves as a knowledge source during the requirements generation phase, but also permeates the entire process of requirements analysis, technical design, functional development, and subsequent version iterations, enabling the continuous accumulation and cyclical utilization of product knowledge throughout the entire software development lifecycle. Figure 4 As shown.

[0074] Corresponding to the above method embodiments, the present invention also provides a product requirement closed-loop management system based on product functional baseline.

[0075] The system includes: The product function baseline establishment module is used to establish a product function baseline knowledge base based on the product function classification framework and generate a product function tree structure. The code reverse initialization module is used to obtain the source code of the target product, perform reverse parsing on the source code, and generate initial data for the product functional baseline knowledge base; The requirement positioning module is used to determine the target functional node corresponding to the requirement based on the requirement description information, and to complete the product function path positioning. The requirements document generation module is used to generate structured requirements documents based on the information associated with the target functional nodes; The baseline update module is used to update the product function baseline knowledge base based on the archived requirements documents, and to create new function nodes or update existing function nodes. The knowledge loop module is used to enable the updated product feature baseline knowledge base to participate in subsequent requirement positioning and requirement document generation, thereby forming a continuous evolution process of product feature knowledge.

[0076] The above modules can be implemented in software or in a combination of software and hardware; this invention does not limit the implementation in this regard.

[0077] The present invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and executable by the processor. When the processor executes the computer program, it implements the product requirement closed-loop management method based on product functional baseline described in any of the above embodiments.

[0078] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the method described in any of the above embodiments.

[0079] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A closed-loop management method for product requirements based on product functional baselines, characterized in that, include: S1. Establish a product function baseline knowledge base based on the product function classification framework. The product function baseline knowledge base adopts a tree-like hierarchical structure to organize multiple functional nodes. Each functional node is associated with at least the implementation logic, business rules, interface conventions and historical change information of the corresponding function. S2. Obtain the source code of the target product, reverse analyze the source code, generate implementation information corresponding to each functional node based on the analysis results, and write it into the product functional baseline knowledge base to complete the initialization of the product functional baseline knowledge base. S3. Obtain the requirement description information of the requirement to be processed, extract the requirement features from the requirement description, search the product function baseline knowledge base according to the requirement features, and determine the functional node and its functional path corresponding to the target requirement; when no corresponding functional node is found, generate baseline gap information. S4. Generate a structured requirements document based on the determined functional nodes and content; S5. After the requirements are completed, based on the functional changes in the requirements document, perform incremental updates on the corresponding functional nodes in the product functional baseline knowledge base, so that the updated product functional baseline knowledge base can serve as the data source for subsequent requirements writing and technical design.

2. The product demand closed-loop management method according to claim 1, characterized in that, The product function baseline knowledge base is organized in a tree-like hierarchical structure, which includes first-level functional domains, second-level functional modules, and third-level functional nodes.

3. The product demand closed-loop management method according to claim 2, characterized in that, The functional nodes include at least the product-related implementation logic, business rules, interface agreements, and historical change records.

4. The product demand closed-loop management method according to claim 1, characterized in that, The establishment of a product function baseline knowledge base based on the product function classification framework includes: Establish a functional module tree based on the functional classification results of the product system; The hierarchical relationship between functional nodes is determined based on the functional module tree; Using the aforementioned hierarchical relationship as the target structure for reverse engineering of the source code, the implementation information corresponding to each functional node is organized and stored.

5. The product demand closed-loop management method according to claim 1, characterized in that, The reverse engineering of the source code includes: identifying the program module corresponding to the target functional node in the source code; extracting the implementation logic, business rules and interface information corresponding to the program module; generating data records for the corresponding functional node according to the data structure of the product functional baseline knowledge base, and writing them into the product functional baseline knowledge base.

6. The product demand closed-loop management method according to claim 1, characterized in that, The structured requirements document includes at least one of the following: information on the functional modules, the application systems involved, the associated R&D teams, functional descriptions, interaction instructions, and acceptance criteria.

7. The product demand closed-loop management method according to claim 1, characterized in that, The process of updating the product feature baseline knowledge base based on the feature change content corresponding to the requirements document includes: Identify the target functional nodes corresponding to the requirements document; Extract the feature change information corresponding to the requirements document; The incremental function change information is written into the data record corresponding to the target function node, and the data organization format is kept consistent with the data generated during initialization.

8. The product demand closed-loop management method according to claim 7, characterized in that, The updated product feature baseline knowledge base is used for retrieving corresponding feature nodes and generating requirement documents during subsequent requirement processing, and serves as a data source for obtaining module boundaries, interface conventions, and module dependencies in the subsequent technical design phase.

9. The product demand closed-loop management method according to claim 1, characterized in that, Each functional node in the product functional baseline knowledge base records the relationship between it and other functional nodes. During the technical design process, the scope of influence of the target function is determined based on the relationship between the target functional node and other functional nodes in order to obtain information on related modules, dependent modules, and downstream systems.

10. An electronic device, characterized in that, The method includes a processor, a memory, and a computer program stored in the memory and executable by the processor. When the processor executes the computer program, it implements the product demand closed-loop management method according to any one of claims 1 to 9.

Images