Demand disassembly methods and devices

Abstract

This disclosure provides a method and apparatus for requirements decomposition, relating to the field of computer technology, and particularly to the fields of large-scale model applications and software project requirements management. One specific implementation of the method includes: obtaining the original requirements of a target project and the corresponding target product function list; decomposing the original requirements to a preset level, generating preset level decomposition suggestions, and matching them with the preset levels of the target product function list to generate preset level product function matching suggestions; based on the original requirements, searching a preset risk database to generate risk warnings; based on the preset level decomposition suggestions, preset level product function matching suggestions, and risk warnings, generating a requirements matching scheme; in response to determining that the target project passes the requirements matching scheme, decomposing the preset level decomposition suggestions to a final level, generating final level decomposition suggestions, and matching them with the final levels of the target product function list to generate final level product function matching suggestions.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of large model applications and software project requirements management technology. Background Technology

[0002] In the software delivery field, especially in ToB (business-to-business) scenarios, projects are typically characterized by high complexity and numerous participating roles. The long delivery chain, coupled with complex requirements, makes it easy for discrepancies to arise between the user's initial needs, the requirements at the solution stage, and the final delivery requirements, posing challenges to project progress.

[0003] Currently, various methods for implementing software project requirements management have emerged in the industry. Some solutions rely on manual processes to complete the transmission and coordination of requirements information throughout the entire process, while others simply record the requirements status at each delivery node of the project to achieve basic auxiliary management of the requirements flow process, providing fundamental support for software project requirements control. Summary of the Invention

[0004] This disclosure provides a method, apparatus, device, storage medium, and program product for demand breakdown.

[0005] In a first aspect, embodiments of this disclosure propose a requirement decomposition method, comprising: obtaining the original requirements of a target project and a list of target product functions corresponding to the original requirements; decomposing the original requirements to a preset level, generating preset level decomposition suggestions, and matching the preset level of the target product function list to generate preset level product function matching suggestions; based on the original requirements, searching a preset risk database and generating risk warnings; based on the preset level decomposition suggestions, preset level product function matching suggestions, and risk warnings, generating a requirement matching scheme; in response to determining that the target project passes the requirement matching scheme, decomposing the preset level decomposition suggestions to a final level, generating final level decomposition suggestions, and matching the final level of the target product function list to generate final level product function matching suggestions.

[0006] Secondly, embodiments of this disclosure propose a requirement decomposition apparatus, comprising: an acquisition module configured to acquire the original requirements of a target project and a target product function list corresponding to the original requirements; a first decomposition module configured to decompose the original requirements to a preset level, generate preset level decomposition suggestions, and match the preset level of the target product function list to generate preset level product function matching suggestions; a first generation module configured to retrieve a preset risk database based on the original requirements and generate risk warnings; a second generation module configured to generate a requirement matching scheme based on the preset level decomposition suggestions, the preset level product function matching suggestions, and the risk warnings; and a second decomposition module configured to, in response to determining that the target project passes the requirement matching scheme, decompose the preset level decomposition suggestions to a final level, generate final level decomposition suggestions, and match the final level of the target product function list to generate final level product function matching suggestions.

[0007] Thirdly, embodiments of this disclosure provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method as described in the first aspect.

[0008] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the methods described in the first aspect.

[0009] Fifthly, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, implements the method described in the first aspect.

[0010] The key or essential features of the embodiments disclosed herein are not intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings. The drawings are provided for a better understanding of the invention and are not intended to limit the scope of this disclosure. Wherein: Figure 1 This is a flowchart of one embodiment of the disassembly method according to the requirements of this disclosure; Figure 2 This is a flowchart of yet another embodiment of the disassembly method according to the requirements of this disclosure; Figure 3 This is a schematic diagram of the project requirements management process; Figure 4This is a schematic diagram of the layered architecture of a requirements management system based on a large model and database. Figure 5 This is a schematic diagram of the demand risk identification process based on RAG; Figure 6 This is a schematic diagram of the process of demand breakdown and product function matching; Figure 7 This is a schematic diagram of one embodiment of the disassembly device according to the requirements of this disclosure; Figure 8 This is a block diagram of an electronic device used to implement the disassembly method of the embodiments of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0014] Demand matching solution approved Figure 1 A flow 100 of one embodiment of a requirements decomposition method according to the present disclosure is shown. The requirements decomposition method includes the following steps: Step 101: Obtain the original requirements of the target project and the list of target product functions corresponding to the original requirements.

[0015] In this embodiment, the entity executing the requirement decomposition method can obtain the original requirements of the target project and the corresponding target product feature list. The original requirements originate from user-published project requirement documents, requirement specifications, and other carriers, and may include various aspects such as functional requirements, performance indicators, deployment requirements, and security compliance. Their format may be text, JSON (JavaScript Object Notation), tables, or other formats. The target product feature list is provided by the delivery party's product team and includes all standard product features that the delivery party can provide. Each feature has a complete function path, function description, capability description, and other information, and has been categorized and organized according to a preset multi-level granularity system for easy subsequent matching operations.

[0016] In some embodiments, a four-level system of requirements and a four-level system of product function list are constructed. In the four-level system of requirements, the first level is the strategic goal level, the second level is the business function domain, the third level is the functional requirement point, and the fourth level is the implementation detail level. In the four-level system of product function list, the first level is the product domain, the second level is the functional module, the third level is the functional unit, and the fourth level is the functional element.

[0017] The four-level system of requirements is defined as follows: Strategic Goal Layer (L1): The highest level of business needs and strategic direction, with the coarsest granularity (macro), focusing on the ultimate business value of "why do it", corresponding to product strategic goals, describing business results without involving the implementation method, and directly related to indicators, such as "increase user retention rate by 30%" or "reduce operating costs by 20%".

[0018] Business Functional Domain (L2): Core functional modules defined to achieve strategic goals. Medium to coarse granularity (module level). Focuses on the functional scope and boundaries of "what to do". It is an independent functional area / module. Defines the module value and boundaries and describes the relationships between modules, such as "User Account Management System" and "Order Processing Process".

[0019] Functional Requirements (L3): Specific functional requirements and user scenarios, with a medium to fine granularity (functional point level). It focuses on the user scenarios and experience of "how to implement" and is a complete functional point that can be delivered independently. It has clear user scenarios, testability, and workload estimation basis, such as "users can register an account by mobile phone number" and "monthly sales reports can be exported from the backend".

[0020] Implementation Details Layer (L4): This layer contains the specific specifications and constraints for the technical implementation. It has the finest granularity (implementation level) and focuses on the technical details and specifications of "how to do it specifically." It includes detailed interaction logic and business rules, specific UI (User Interface) / UX (User Experience) design specifications, technical constraints and interface definitions, data fields and validation rules, etc. For example, "password length 8-20 characters, must contain letters and numbers" and "API (Application Programming Interface) response format: {code:200, data:{...}}".

[0021] The four-tier system of the product feature list is defined as follows: Product Domain / System Level (L1): The overall functional domain or independent system division of the product, with the coarsest granularity (product level). It is a complete product module or independent system with clear business boundaries and can be deployed or operated independently. It corresponds to a product line or major version, such as "e-commerce transaction system" or "data analysis backend".

[0022] Functional Modules / Subdomains (L2): Core functional modules under the product domain, with medium to coarse granularity (module level). They are a set of functions that complete specific business objectives. The modules are relatively independent and have clear value propositions, corresponding to the main objectives of an iteration cycle, such as "Order Management Module: Handling the entire lifecycle of orders" and "Payment and Settlement Module: Supporting multiple payment methods and reconciliation".

[0023] Functional Unit / Feature (L3): A specific functional point that can be delivered independently under a functional module. It has a medium-fine granularity (functional level) and is a complete functional unit that users can perceive. It contains a complete business loop and can be tested and accepted independently. It usually corresponds to a user scenario, such as "Buyer order placement function: user selects products, fills in address and completes payment" or "Search and filter function: user filters products by keywords and conditions".

[0024] Functional elements / tasks (L4): Specific operation items or technical elements under a functional unit, with the finest granularity (task level). They are indivisible atomic operations with clear inputs and outputs. The development workload can be estimated (usually ≤2 days). For example, "Add shipping address: users fill in their name, phone number, and address, and can set it as the default" and "Order status query: real-time display of 'pending payment, shipped, completed' status".

[0025] Step 102: Decompose the original requirements into preset levels, generate preset level decomposition suggestions, and match them with the preset levels of the target product function list to generate preset level product function matching suggestions.

[0026] In this embodiment, the aforementioned execution entity can break down the original requirements to a preset level, generate preset level breakdown suggestions, and match them with the preset level of the target product function list to generate preset level product function matching suggestions. The preset level can be, for example, the L3 functional requirement level in a four-level requirement system and the L3 functional unit level in a four-level product function list system. The choice of this level balances the granularity of requirement breakdown with the feasibility of subsequent delivery: if broken down to the L4 level, excessive refinement could lead to excessively high upfront costs for projects that fail to pass; if broken down to the L2 level, coarse granularity could cause subsequent mapping failures from L2 to L4, making it impossible to form a feasible delivery solution.

[0027] The generation process of the preset hierarchical decomposition suggestions must follow the principle of "completeness without excessive fragmentation" to ensure that each requirement item is an atomic requirement with a single semantic meaning. Specific decomposition rules include: decomposing multiple sub-requirements connected by preset separators such as commas and semicolons into independent items; decomposing requirements that combine functional descriptions and performance indicators into functional items and performance items; and decomposing performance / capacity requirements containing keywords such as "not less than", "not exceeding", MB (Megabyte) / GB (Gigabyte), concurrency, and QPS (Queries Per Second)" into separate performance constraint items.

[0028] The generation of preset hierarchical product function matching suggestions is based on semantic similarity and function path priority. The specific matching strategy is as follows: prioritize matching product functions with high semantic consistency; secondly, ensure that the function at the end of the function path is matched, and prohibit matching only the top-level / coarse-grained path; product functions that explicitly mention the required content in the function description are given priority over product functions whose path only contains keywords. During the matching process, the mapping relationship of synonyms and near-synonyms (such as upload = import, retrieval = search = query, etc.) should be considered. If the requirement involves multiple capabilities, multiple function paths can be matched; if no reasonable corresponding function can be found, forced matching is prohibited and the function is marked as "not matched".

[0029] Step 103: Based on the original requirements, retrieve the preset risk database and generate risk warnings.

[0030] In this embodiment, the aforementioned execution entity can retrieve a preset risk database based on the original requirements and generate risk warnings. The preset risk database is a collection of risk cases built by the delivery party based on historical project experience, divided into a general risk sub-database and an industry-specific risk sub-database: the general risk sub-database stores common risks that may be faced by ToB projects in various industries, such as exposed requirements and ambiguous requirements; the industry-specific risk sub-database stores requirement risks specific to different industries such as finance and manufacturing, such as the high-concurrency performance index risks in the financial industry.

[0031] The risk warnings are generated using the RAG (Retrieval-Augmented Generation) method. The implementing entity inputs the original requirements into a large model, which then searches a pre-defined risk database. A semantic similarity algorithm matches the original requirements with cases in the risk database to identify potential risk points in the current requirements. For each risk point, specific and actionable response suggestions are generated. For example, for open requirements, specific issues that need to be clarified with the client and the scope of product support are provided; for requirements that are not feasible in the industry, alternative solutions are suggested.

[0032] Step 104: Generate a requirement matching solution based on the preset hierarchical decomposition suggestions, preset hierarchical product function matching suggestions, and risk warnings.

[0033] In this embodiment, the aforementioned executing entity can generate a requirement matching scheme based on preset hierarchical decomposition suggestions, preset hierarchical product function matching suggestions, and risk warnings. The requirement matching scheme is a core document addressing the target project's requirements and must integrate three key pieces of information: first, preset hierarchical decomposition suggestions, clarifying the specific content and granularity of customer requirements; second, preset hierarchical product function matching suggestions, clearly dividing the standard product matching portion, customized development portion, product-to-be-developed matching portion, and unmet requirements for discussion portion, and providing a preliminary workload estimate for customized development; and third, risk warnings, clarifying potential risks in the requirements and corresponding countermeasures, allowing users to understand the controllability of project risks. After generation, the requirement matching scheme must be reviewed and approved by the project team to ensure its feasibility, completeness, and competitiveness.

[0034] Step 105: In response to the determination that the target project has passed the requirement matching scheme, the preset hierarchical decomposition suggestions are decomposed to the final level to generate the final level decomposition suggestions, and the final level of the target product function list is matched to generate the final level product function matching suggestions.

[0035] In this embodiment, if the target project passes the requirement matching scheme, the aforementioned execution entity can break down the preset hierarchical decomposition suggestions to the final level, generate the final level decomposition suggestions, and match them with the final level of the target product feature list to generate the final level product feature matching suggestions. The final level can be, for example, the L4 implementation detail layer in the four-level requirement system and the L4 functional element layer in the four-level product feature list system. L4 level requirement items are indivisible atomic operations and maintain strict logical consistency with the corresponding L3 level requirement items, ensuring the coherence of requirement refinement.

[0036] The generation of the final hierarchical decomposition suggestions requires the use of a dedicated prompt word template. The large model outputs L4 hierarchical decomposition suggestions based on the L3 hierarchical decomposition suggestions, which are then manually reviewed and modified before finalization. The final hierarchical product function matching suggestions accurately match the L4 hierarchical requirement items with the L4 hierarchical functional elements of the product function list, clarifying the product functional elements corresponding to each atomic requirement, and providing a direct basis for product development and subsequent delivery execution.

[0037] The requirement decomposition method provided in this disclosure solves the problems of chaotic granularity definition and unscientific matching in traditional requirement management by constructing a standardized multi-level granularity system. It realizes intelligent decomposition and matching of requirements based on a large model, and improves the efficiency and accuracy of requirement processing by combining RAG technology for risk identification. At the same time, the data recording and traceability of the whole process ensures the integrity, consistency and traceability of requirements from the user's submission to the final delivery, effectively improving the project delivery quality and user satisfaction.

[0038] Figure 2 A flow 200 of another embodiment of the requirements decomposition method according to this disclosure is shown. The requirements decomposition method includes the following steps: Step 201: Obtain the original requirements of the target project and the list of target product functions corresponding to the original requirements.

[0039] In this embodiment, the specific operation of step 201 has been described. Figure 1 The steps in step 101 of the illustrated embodiment are described in detail and will not be repeated here.

[0040] Step 202: Input the original requirements, target product function list and first preset prompt words into the large model, and output preset hierarchical decomposition suggestions and preset hierarchical product function matching suggestions.

[0041] In this embodiment, the aforementioned execution entity can input the original requirements, the target product function list, and the first preset prompt word into the large model, and output preset hierarchical decomposition suggestions and preset hierarchical product function matching suggestions. The first preset prompt word is a dedicated prompt word template, which is formulated by the delivery party based on requirements decomposition rules, product function matching principles, and multi-level granularity system definitions. It includes core requirements such as "identifying unmet items as the highest priority," "completely extracting all requirements," "complete requirements decomposition without excessive fragmentation," and "function matching based on semantic similarity and path priority," used to guide the large model to accurately execute requirements decomposition and matching operations.

[0042] The large-scale model used in this embodiment is an interactive general-purpose large language model. Its core function is to achieve semantic understanding, text decomposition, and semantic matching of product functions based on the guidance of the first preset prompt words. The output of the large-scale model is only a suggestion and must be manually reviewed and modified. The manual modification record will be stored in the database along with the original suggestions of the large-scale model, as feedback data for subsequent optimization of the prompt word template and model tuning.

[0043] In some embodiments, the requirement items corresponding to the original requirements are extracted; the requirement items are verified and supplemented to generate preset level decomposition suggestions; based on semantic similarity and product function path priority, the preset level decomposition suggestions are matched with the preset level of the target product function list to generate preset level product function matching suggestions.

[0044] When extracting requirement items corresponding to the original requirements, the principle of "complete extraction" must be followed to ensure that no requirement clause in the project requirements document is omitted, even if the corresponding function is not in the product feature list. After extraction, a self-check must be performed: scan the entire original requirements document in chapter order to confirm that there are no "clause paragraphs that have not been converted into requirement items"; if there are clauses that cannot be determined as software / hardware requirements, they should be listed separately as "requirements to be clarified" in the requirement item set.

[0045] The verification and supplementary breakdown of requirement items is based on extraction, and further optimized according to standardized rules to ensure that all requirement items meet the granularity requirements of the preset level, and finally form preset level breakdown suggestions; the matching operation based on semantic similarity and product function path priority aims to achieve accurate correspondence between requirements and product functions, and generate preset level product function matching suggestions including matching result classification.

[0046] In some embodiments, requirement items are decomposed into atomic requirements with single semantics; requirement items connected by preset separators are decomposed at the separator connection points; and requirement items expressed by a mixture of functional descriptions and performance indicators are decomposed into functional requirement items and performance requirement items.

[0047] The above decomposition operations must maintain the original large-module structure of the requirements and cover all modules in the project requirements document (including overall requirements, deployment requirements, security compliance, and information technology innovation requirements) to ensure the completeness of the decomposition results. Preset separators include commas, semicolons, and other symbols used to separate multiple independent sub-requirements. For example, "Supports uploading CSV, XLS, and XLSX formats, with a single file not exceeding 1GB" is decomposed into two independent items: "Supports uploading CSV, XLS, and XLSX formats" and "Uploaded single file size not exceeding 1GB." For requirements that combine functional descriptions and performance metrics, such as "Supports real-time order status push, with a response time not exceeding 1 second," it is decomposed into "Supports real-time order status push" (functional item) and "Order status push response time not exceeding 1 second" (performance item). Performance / capacity requirements containing keywords such as "not less than," "not less than," "at least," "MB / GB," "concurrency," "QPS," and "latency" must be prioritized and decomposed into independent performance constraint items to ensure the clarity and testability of the requirement description.

[0048] In some embodiments, for each requirement item in the preset hierarchical decomposition suggestion, product function items under the preset level of the target product function list are scanned one by one; the semantic similarity between each requirement item and each scanned product function item is calculated using a semantic similarity algorithm, and product function items with semantic similarity reaching a preset threshold are selected as candidate product function items; the candidate product function items are sorted according to the path level granularity, and the end product function item with the finest path level is selected; if there are candidate product function items with the same path level granularity, a secondary sort is performed according to the rule that function descriptions containing requirement keywords take precedence over paths containing only requirement keywords, and the product function item with the highest ranking is selected; a preset synonym and near-synonym mapping table is invoked, and for requirement items that have not been selected as candidate product function items, the corresponding product function items associated with the matching words in the matching mapping table are scanned to update the candidate product function items; the matching results of each requirement item in the preset hierarchical decomposition suggestion are integrated to generate a preset hierarchical product function matching suggestion.

[0049] The above matching operations must follow the priority order of "semantic closest, finest path granularity, and description priority." The semantic similarity algorithm is used to quantify the semantic relevance between requirement items and product function items. The preset threshold is set by the delivery party based on historical project experience to ensure the relevance of candidate product function items. The path hierarchy granularity sorting requires matching to the end path of the product function. For example, if the product function list contains the path "knowledge base - import - document import - format support", it is prohibited to only match the top-level path "knowledge base - import". The synonym and near-synonym mapping table contains the mapping relationship of commonly used synonyms in project delivery, such as upload = import, retrieval = search = query, training = fine-tuning, parsing = recognition = OCR (Optical Character Recognition), arrangement = process = workflow, etc. Calling this table can supplement the matching of potential matching items caused by differences in word expression, and improve the comprehensiveness of the matching.

[0050] After matching is completed, the matching results of all requirement items need to be integrated, the product function path corresponding to each requirement item needs to be clarified, and the items need to be classified into "standard product matching part, customized development part, product to be developed matching part, and requirement that cannot be met and needs to be discussed" to generate structured preset hierarchical product function matching suggestions.

[0051] Step 203: Input the target project requirements and risk database into the large model and output risk warnings.

[0052] In this embodiment, the aforementioned execution entity can input the target project requirements and risk database into the large model and output risk alerts. The risk database includes a general risk sub-database and an industry-specific risk sub-database, storing various requirement risk cases accumulated from historical projects. Each case includes information such as risk description, risk scenario, and response suggestions. The large model uses a RAG retrieval-enhanced generation method, first retrieving risk cases in the risk database that are semantically similar to the target project requirements, and then, combined with the industry characteristics of the target project, focusing on matching cases in the industry-specific risk sub-database, finally outputting risk alerts containing potential risk points and corresponding response suggestions.

[0053] The risk disclosure must clearly define the type of risk, including exposed requirements, unquantifiable requirements, requirements that are not feasible within the industry, and security risk requirements. For exposed requirements, the specific models / architectures already supported by the product must be specified, and a list of specific issues that need to be clarified with the client must be provided. For unquantifiable requirements, quantifiable alternative indicators must be provided. For security risk requirements that include uploading high-risk file types such as .exe, .sh, and .bat, security solutions such as whitelisting and sandbox isolation must be provided.

[0054] Step 204: Generate a requirement matching solution based on the preset hierarchical decomposition suggestions, preset hierarchical product function matching suggestions, and risk warnings.

[0055] In this embodiment, the specific operation of step 204 has been described. Figure 1 Step 104 in the illustrated embodiment is described in detail and will not be repeated here.

[0056] Step 205: In response to the determination that the target project has passed the demand matching scheme, input the preset hierarchical decomposition suggestions, the preset hierarchical product function matching suggestions and the second preset prompt words into the large model, and output the final hierarchical decomposition suggestions and the final hierarchical product function matching suggestions.

[0057] In this embodiment, if the target project passes the requirement matching scheme, the aforementioned execution entity can input the preset hierarchical decomposition suggestions, preset hierarchical product function matching suggestions, and the second preset prompt word into the large model, and output the final hierarchical decomposition suggestions and the final hierarchical product function matching suggestions. The second preset prompt word is a dedicated prompt word template. Compared with the first preset prompt word, this template focuses more on the logical mapping rules from the preset level to the final level, atomic-level decomposition requirements, and functional element matching standards, ensuring that the large model can accurately refine the preset level requirements to the final atomic operation level.

[0058] In the final hierarchical decomposition suggestions output by the large model, each final-level requirement item is an indivisible atomic operation, containing detailed technical specifications, constraints, interaction logic, etc., and maintaining logical consistency with the corresponding preset-level requirement items. The final-level product function matching suggestions match each final-level requirement item with the final-level functional elements of the product function list, clarifying the product function implementation details corresponding to each atomic requirement. The above output results need to be manually reviewed and modified, and after passing the review, they are transformed into project requirement clauses, serving as the direct execution basis for project delivery.

[0059] In some embodiments, the large model can be iteratively optimized, with the following specific steps: First, training samples are generated based on the original requirements, the target product feature list, the final hierarchical decomposition suggestions, and the final hierarchical product feature matching suggestions.

[0060] Next, feedback results are obtained on the final-level decomposition suggestions and the final-level product function matching suggestions. The feedback results are submitted by the relevant roles during the review or delivery verification stage, and include the feedback person's identity, feedback time, feedback content (such as decomposition logic correction, matching relationship adjustment, risk point supplement, etc.). All feedback operations are recorded in the operation log to retain traceability evidence.

[0061] Then, based on the feedback results, the training samples are labeled with positive or negative sample labels. If the feedback result is "acceptance of disassembly suggestions and matching relationships", it is labeled as a positive sample; if the feedback result is "correction of disassembly logic, adjustment of matching relationships" or other disapproval or optimization suggestions, it is labeled as a negative sample.

[0062] Finally, the large model is iteratively optimized using the labeled training samples. The large model is fine-tuned using the labeled training samples, and during the optimization process, training batch information, sample usage list, model parameter adjustment records, and performance evaluation data before and after optimization are recorded simultaneously. The optimized large model needs to be bound to a version number and associated with the training sample set version and feedback data batch to ensure that the source of training data, the basis for feedback correction, and the optimization effect of any version of the model can be traced in the future, forming a closed loop of "data-feedback-optimization-traceability".

[0063] The requirement decomposition method provided in this disclosure achieves intelligent efficiency improvement in requirement decomposition and matching through the combination of a large model and dedicated prompt word templates; it ensures the accuracy and consistency of requirement processing results through a standardized multi-level granularity system and clear decomposition and matching rules; and it enhances the comprehensiveness of risk identification and the implementability of response suggestions by introducing a risk database and applying RAG technology. This method effectively solves the pain points of requirement management in ToB software project delivery, realizing closed-loop control of the entire process from customer proposal to final delivery.

[0064] As an example, Figure 3 The diagram illustrates the project requirements management process, which spans the entire lifecycle of ToB software project delivery. It aims to achieve closed-loop control of requirements from initiation to delivery, and solve problems such as requirement distortion and omission in traditional long-chain delivery.

[0065] Step 301: User publishes requirements. Users publish their target project requirements in the form of a requirements document. The requirements cover multiple dimensions such as functionality, performance, deployment, security and compliance. There may be ambiguity or mixed semantics, which need to be further broken down and clarified later.

[0066] Step 302: Initial Risk Decomposition, Matching, and Mining. Based on the original user-submitted requirements, three core operations are performed: First, requirement decomposition: according to the pre-set L1-L4 four-level granularity system, the original requirements are decomposed down to the L3 functional requirement level, ensuring that each requirement item is a single semantic atomic requirement with testability and a basis for workload estimation; Second, product function matching: the decomposed L3 requirements are matched with the L3 functional units of the product function list, clarifying the standard product matching part, the customized development part, the product to be developed matching part, and the part of the requirement that cannot be met and needs to be discussed; Third, risk mining: relying on the pre-set risk database, potential risk points such as exposed requirements, unquantifiable requirements, and requirements that are not feasible in the industry are identified, and preliminary response strategies are outlined.

[0067] Step 303, Preliminary Review. After compiling the breakdown results, matching suggestions, and risk warnings into a preliminary plan, relevant roles are invited to participate in a manual review to ensure the feasibility, completeness, and risk controllability of the plan.

[0068] Step 304: Has the review passed? If yes, proceed to step 305; otherwise, end. The review process focuses on verifying the completeness and rationality of the requirements breakdown, the accuracy of product function matching, the comprehensiveness of risk identification, and the feasibility of response suggestions. If the review fails, the requirements advancement process for this project will be terminated.

[0069] Step 305: Develop a demand matching plan. After review, based on the breakdown results, matching suggestions, and risk warnings, integrate information such as project cost estimates and delivery cycle planning to form a formal demand matching plan.

[0070] Step 306: Has the requirement matching solution passed? If yes, proceed to step 307; otherwise, end. Determine if the requirement matching solution has passed. If it has not, the process terminates; if it has, proceed to requirement refinement.

[0071] Step 307: Final risk decomposition, matching, and identification. After project approval, the core task is to further refine the L3 level requirements to the L4 implementation detail layer, which is an indivisible atomic operation level; at the same time, match the L4 functional element level of the product feature list, supplement and identify newly added potential risks, and ensure that the results of requirement refinement and matching can directly guide delivery and execution.

[0072] Step 308, Final Review. After compiling the L4 level breakdown results, matching relationships, and risk response plans, relevant roles are invited to participate in manual review, focusing on verifying the clarity, unambiguity, and consistency with product capabilities of the requirement clauses.

[0073] Step 309: Has the review been passed? If yes, proceed to step 110; otherwise, end. If the review is not passed, the requirements and matching solutions must be optimized again until the review is passed; otherwise, the process is terminated.

[0074] Step 310: Create a requirements confirmation document. After review, the L4 level requirements breakdown results and product function matching relationships are transformed into formal requirements clauses, clarifying delivery standards and acceptance requirements.

[0075] Step 311: Sign the requirements confirmation document. Signing the requirements confirmation document is a crucial step in the transition of requirements from the planning phase to the execution phase. Once signed, the requirements terms officially take effect and serve as the legal basis for project delivery. If not signed, further negotiation and optimization of the requirements confirmation document terms are required until an agreement is reached.

[0076] Step 312, Deliver according to the requirements confirmation document. Perform the delivery work according to the requirements terms and delivery standards in the requirements confirmation document. During the delivery process, ensure the consistency and completeness of the requirements, and do not arbitrarily change the scope of the requirements.

[0077] Step 313, Requirement Change Process. If the user proposes a requirement change during the delivery process, the core process needs to be restarted. This involves breaking down, matching, and risk assessment of the changed requirements, forming a supplementary solution, passing the review, signing a supplementary agreement, and then delivering the changed portion based on the supplementary agreement.

[0078] Step 314, Deliver the overall requirements. Once all requirements stipulated in the requirements confirmation document and supplementary agreement have been delivered and accepted by the user, the project delivery process officially concludes.

[0079] As an example, Figure 4 The diagram illustrates a layered architecture for a requirement management system based on a large model and database. This architecture provides underlying technical support for the implementation of requirement decomposition methods. By adopting a layered design concept, it decouples business functions, intelligent capabilities, and data storage, ensuring the system's flexibility, scalability, and data traceability.

[0080] Original Requirements Import 401: As the system's input entry point, it supports receiving original customer requirements in various formats, including JSON, structured text, and scanned copies of tender documents. It extracts text content through technologies such as OCR and layout analysis, providing basic data for subsequent requirement breakdown, matching, and risk identification.

[0081] 402: Store core data including L3-level requirement breakdown items, L3-level matching relationships between requirements and product functions, risk identification results, response suggestions, and manual review records. This data is traceable and searchable, providing a basis for requirement refinement in the requirement confirmation stage.

[0082] The finalized requirements, matching relationships, and risks (403) store core data, including L4-level requirement breakdown items, L4-level matching relationships between requirements and product functions, new risk cases and response plans, etc., to support the execution of the delivery phase and the management of requirement changes.

[0083] 404: Detailed requirements, matching relationships, and risks during the delivery phase: Store the requirements execution data during the delivery phase, including delivery records executed according to the terms of the requirements confirmation document, supplementary requirements data corresponding to requirements changes, matching relationships after changes, and risk handling results, to ensure the traceability of the delivery process.

[0084] Large Model Capability 405: As the intelligent core of the system, it supports integration with various interactive general-purpose large language models, possessing capabilities such as semantic understanding of requirements, text decomposition, semantic similarity matching, and enhanced RAG retrieval generation. Through dedicated prompt word templates, it achieves L3 and L4 level requirement decomposition and matching suggestion generation respectively, and dynamically optimizes based on human review feedback data to improve the accuracy of intelligent processing.

[0085] Database 406: As the core of the system's data storage, it adopts a layered storage design, including a requirements data storage area, a product function list storage area, a risk database storage area, and a review record storage area. The risk database storage area contains a general risk sub-database and an industry-specific risk sub-database. The review record storage area stores manual review comments and modification records from each stage. All data supports multi-dimensional traceability and querying, providing data support for knowledge accumulation and system optimization.

[0086] As an example, Figure 5 The diagram illustrates the requirement risk identification process based on RAG. This process is the core implementation path for risk warning generation in the requirement decomposition method. Relying on RAG retrieval enhancement generation technology and a preset risk library, it realizes intelligent risk identification and response suggestions for the original requirements, ensuring that no risk points are missed and that response suggestions are feasible.

[0087] Step 501: Invoke the large model and, using RAG (Radar Algorithm) or similar formats, present the risks of the current original requirements. After the user's original requirements are imported into the system, the executing entity invokes the large model and initiates the RAG search enhancement generation process: First, the original requirements are semantically parsed to extract key information such as core requirement keywords, requirement type, and industry; then, based on this information, a preset risk database is searched. First, a general risk sub-database is searched to match common risk cases across industries, and then a specific risk sub-database for the target project's industry is searched to match industry-specific risk cases; the large model combines the semantic similarity between the retrieved risk cases and the original requirements to initially identify potential risk points in the current requirements, including exposed requirements, unquantifiable requirements, industry-unachievable requirements, and security risk requirements.

[0088] Step 502 identifies current demand risks, such as exposed demands, and provides handling suggestions. Based on the initially identified risk points and combined with experience from handling cases in the risk database, the large model generates detailed risk warnings. These warnings must clearly describe the risk point, risk type, degree of impact, and specific handling suggestions: For exposed demands, the specific compatibility range already supported by the product (e.g., model, architecture, version), specific issues requiring clarification with the client (e.g., specified model, testing environment), and key points of compatibility testing commitments must be listed; for demands that cannot be quantified, feasible quantifiable indicators and verification methods must be provided; for demands that are not feasible within the industry, alternative solutions and feasibility analyses must be provided; for security risk demands, specific security control strategies (e.g., whitelisting, sandbox isolation) must be provided. After the risk warnings are generated, they must be incorporated into the demand matching plan as an important reference to provide a basis for risk management.

[0089] As an example, Figure 6The diagram illustrates the process of demand decomposition and product function matching. This process is the core execution path for demand processing. By combining the intelligent capabilities of the large model with human review and judgment, it achieves accurate transformation of original demands into L3-level decomposition suggestions and product function matching suggestions.

[0090] Step 601: Invoke the large model and provide suggestions or judgments regarding product matching, future planning matching, non-matching customization, and non-matching risk further discussion. After the user's original requirements and product feature list are imported into the system, the system loads the requirement level and product feature level definitions (i.e., the L1-L4 four-level granularity system) and invokes the large model and dedicated prompt word templates. Based on the template requirements, the large model first breaks down the original requirements into L3-level requirement items, then matches them with the L3 level of the product feature list, and finally outputs four types of suggestions: First, product matching, i.e., functions that the current product already has and can directly meet the requirements; second, future planning matching, i.e., functions that the product is developing to meet the requirements; third, non-matching customization, i.e., requirements that can only be met through custom development; and fourth, non-matching risk further discussion, i.e., requirements that the product cannot meet and custom development is not feasible, requiring consultation and discussion with the user.

[0091] Step 602: Should the suggestion be adopted? If yes, proceed to step 603; if no, proceed to step 605. Manually review the four types of suggestions output by the large model to determine their rationality and accuracy, including the completeness of the requirement breakdown and the accuracy of the matching classification. If the suggestion is adopted, proceed to the subsequent solution improvement stage; if the suggestion is not adopted, manual optimization and adjustment are required.

[0092] Step 603: Complete the requirements proposal and participate in the review. Based on the adopted large model suggestions, supplement and improve the requirements proposal, clarify the handling methods for each part of the requirements, the preliminary workload estimate for customized development, the risk response strategy, etc. After forming a complete requirements proposal, organize a project team review meeting and invite relevant roles to participate in the review.

[0093] Step 604: Record detailed requirements, matching relationships, and risk tasks. After the requirement proposal passes review, the system records core data, including L3-level requirement breakdown items, L3-level matching relationships between requirements and product functions, risk identification results, risk tasks, and manual review comments. All data is stored in the database, supporting subsequent traceability and knowledge accumulation.

[0094] Step 605: Manual Modification. For cases where the large model's suggestions are not adopted, manual modifications are made based on the user's professional experience to the requirement breakdown results and matching classifications. This includes adjusting the way requirement items are split, correcting functional matching relationships, and supplementing the identification of risk points missed by the large model.

[0095] Step 606: Does it need to call the large model again to determine the correctness? If yes, proceed to step 601; otherwise, proceed to step 603. After manual modification, determine whether it is necessary to call the large model again to verify the rationality of the modification results. If so, re-execute step 601, and the large model will output new suggestions based on the modified content; if not, proceed directly to step 603 to complete the requirement solution and participate in the review.

[0096] Further reference Figure 7 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a demand disassembly device, which is similar to... Figure 3 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0097] like Figure 7 As shown, the requirement decomposition device 700 in this embodiment may include: an acquisition module 701, a first decomposition module 702, a first generation module 703, a second generation module 704, and a second decomposition module 705. The acquisition module 701 is configured to acquire the original requirements of the target project and the target product function list corresponding to the original requirements; the first decomposition module 702 is configured to decompose the original requirements to a preset level, generate preset level decomposition suggestions, and match the preset level of the target product function list to generate preset level product function matching suggestions; the first generation module 703 is configured to retrieve a preset risk database based on the original requirements and generate risk warnings; the second generation module 704 is configured to generate a requirement matching scheme based on the preset level decomposition suggestions, preset level product function matching suggestions, and risk warnings; the second decomposition module 705 is configured to, in response to determining that the target project passes the requirement matching scheme, decompose the preset level decomposition suggestions to a final level, generate final level decomposition suggestions, and match the final level of the target product function list to generate final level product function matching suggestions.

[0098] In this embodiment, the specific processing and technical effects of the acquisition module 701, the first dismantling module 702, the first generation module 703, the second generation module 704, and the second dismantling module 705 in the demand dismantling device 700 can be referred to respectively. Figure 3 The relevant descriptions of steps 301-305 in the corresponding embodiments will not be repeated here.

[0099] In some optional implementations of this embodiment, the first disassembly module 702 is further configured to: input the original requirements, the target product function list and the first preset prompt words into the large model, and output preset level disassembly suggestions and preset level product function matching suggestions.

[0100] In some optional implementations of this embodiment, the first disassembly module 702 is further configured to: extract the requirement items corresponding to the original requirements; verify and supplement the requirement items to generate a preset level disassembly suggestion; and match the preset level disassembly suggestion with the preset level of the target product function list based on semantic similarity and product function path priority to generate a preset level product function matching suggestion.

[0101] In some optional implementations of this embodiment, the first decomposition module 702 is further configured to: decompose the requirement item into atomic requirements with a single semantic; decompose the requirement items connected by a preset separator at the separator connection; and decompose the requirement items expressed by a mixture of functional description and performance indicators into functional requirement items and performance requirement items.

[0102] In some optional implementations of this embodiment, the first disassembly module 702 is further configured to: scan product function items under the preset level of the target product function list one by one for each requirement item in the preset level disassembly suggestion; calculate the semantic similarity between each requirement item and each scanned product function item through a semantic similarity algorithm, and select product function items whose semantic similarity reaches a preset threshold as candidate product function items; sort the candidate product function items according to the path level granularity, and select the end product function item with the finest path level; if there are candidate product function items with the same path level granularity, perform a secondary sorting according to the rule that function description containing requirement keywords takes precedence over path containing only requirement keywords, and select the product function item with the highest ranking; call the preset synonym and near-synonym mapping table, and for requirement items that have not been screened as candidate product function items, supplement the scanning of product function items associated with corresponding words in the matching mapping table, and update the candidate product function items; integrate the matching results of each requirement item in the preset level disassembly suggestion to generate a preset level product function matching suggestion.

[0103] In some optional implementations of this embodiment, the first generation module 703 is further configured to: input the target project requirements and risk library into the large model and output risk warnings.

[0104] In some optional implementations of this embodiment, the second disassembly module 705 is further configured to: input preset hierarchical disassembly suggestions, preset hierarchical product function matching suggestions, and second preset prompt words into the large model, and output the final hierarchical disassembly suggestions and the final hierarchical product function matching suggestions.

[0105] In some optional implementations of this embodiment, the requirement decomposition device 700 further includes: a construction module configured to construct a four-level system of requirements and a four-level system of product function list. The first level of the four-level system of requirements is the strategic goal layer, the second level is the business function domain, the third level is the functional requirement point, and the fourth level is the implementation detail layer. The first level of the four-level system of product function list is the product domain, the second level is the functional module, the third level is the functional unit, and the fourth level is the functional element.

[0106] In some optional implementations of this embodiment, the requirement decomposition device 700 further includes: an optimization module configured to generate training samples based on the original requirements, the target product function list, the final hierarchical decomposition suggestions, and the final hierarchical product function matching suggestions; obtain feedback results on the final hierarchical decomposition suggestions and the final hierarchical product function matching suggestions; label the training samples with positive or negative sample labels based on the feedback results; and use the labeled training samples to iteratively optimize the large model.

[0107] The collection, storage, use, processing, transmission, provision, and disclosure of any type of information, such as user personal information, in this technical solution comply with relevant laws and regulations and do not violate public order and good morals.

[0108] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0109] Figure 8 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0110] like Figure 8As shown, device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 802 or a computer program loaded from storage unit 808 into random access memory (RAM) 803. RAM 803 may also store various programs and data required for the operation of device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.

[0111] Multiple components in device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of monitors, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0112] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as the demand breakdown method. For example, in some embodiments, the demand breakdown method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the demand breakdown method described above may be performed. Alternatively, in other embodiments, the computing unit 801 may be configured to perform the demand breakdown method by any other suitable means (e.g., by means of firmware).

[0113] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0114] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0115] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0116] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0117] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0118] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, distributed system servers, or servers incorporating blockchain technology.

[0119] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution provided in this disclosure can be achieved, and this is not limited herein.

[0120] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A requirement decomposition method, comprising: Obtain the original requirements of the target project and the corresponding list of target product features; The original requirements are broken down into preset levels to generate preset level breakdown suggestions, and matched with the preset levels of the target product function list to generate preset level product function matching suggestions. Based on the original requirements, a preset risk database is retrieved, and a risk warning is generated. Based on the preset hierarchical decomposition suggestions, the preset hierarchical product function matching suggestions, and the risk warnings, a demand matching solution is generated; In response to determining that the target project passes the requirement matching scheme, the preset hierarchical decomposition suggestion is decomposed to the final level to generate the final level decomposition suggestion, and matched with the final level of the target product function list to generate the final level product function matching suggestion.

2. The method according to claim 1, wherein, The step of breaking down the original requirements into preset levels, generating preset level breakdown suggestions, and matching them with the preset levels of the target product feature list to generate preset level product feature matching suggestions includes: Input the original requirements, the target product function list, and the first preset prompt into the large model, and output the preset hierarchical decomposition suggestions and the preset hierarchical product function matching suggestions.

3. The method according to claim 2, wherein, The process of inputting the original requirements, the target product feature list, and the first preset prompt words into the large model, and outputting the preset hierarchical decomposition suggestions and the preset hierarchical product feature matching suggestions, includes: Extract the requirement entries corresponding to the original requirements; The required items are verified and supplemented to generate the preset hierarchical decomposition suggestions; Based on semantic similarity and product function path priority, the preset level decomposition suggestions are matched with the preset levels of the target product function list to generate the preset level product function matching suggestions.

4. The method according to claim 3, wherein, The step of verifying and supplementing the requirement items to generate the preset hierarchical decomposition suggestions includes: The requirement items are broken down into atomic requirements with single semantic meaning; For requirement items connected by preset separators, break them down at the separator connection points; Requirement items that are expressed by a combination of functional descriptions and performance metrics are broken down into functional requirement items and performance requirement items.

5. The method according to claim 3, wherein, The step of matching the preset hierarchical decomposition suggestions with the preset hierarchical levels of the target product function list based on semantic similarity and product function path priority to generate preset hierarchical product function matching suggestions includes: For each requirement item in the preset hierarchical decomposition suggestion, scan the product function items under the preset level of the target product function list one by one; Using a semantic similarity algorithm, the semantic similarity between each requirement item and each scanned product function item is calculated, and product function items whose semantic similarity reaches a preset threshold are selected as candidate product function items. The candidate product function items are sorted according to the path level granularity, and the end product function item with the finest path level is selected. If there are candidate product feature items at the same path level, a second sorting is performed based on the rule that features containing requirement keywords in the feature description take precedence over features containing requirement keywords only in the path, and the product feature item with the highest ranking is selected. Call the preset synonym and near-synonym mapping table, and for the requirement items that have not been filtered out as candidate product function items, scan and match the corresponding words associated with the product function items in the mapping table to update the candidate product function items; By integrating the matching results of each requirement item in the preset hierarchical decomposition suggestions, the preset hierarchical product function matching suggestions are generated.

6. The method according to any one of claims 1-5, wherein, The step of retrieving a preset risk database and generating a risk warning based on the original requirements includes: Input the target project requirements and risk database into the large model, and output the risk warning.

7. The method according to any one of claims 1-6, wherein, The step of breaking down the preset hierarchical decomposition suggestions to the final level, generating final-level decomposition suggestions, and matching them with the final level of the target product feature list to generate final-level product feature matching suggestions includes: Input the preset hierarchical decomposition suggestions, the preset hierarchical product function matching suggestions, and the second preset prompt words into the large model, and output the final hierarchical decomposition suggestions and the final hierarchical product function matching suggestions.

8. The method according to any one of claims 1-7, wherein, The method further includes: A four-level system for requirements and a four-level system for product function lists are constructed. The first level of the four-level system for requirements is the strategic goal layer, the second level is the business function domain, the third level is the functional requirement point, and the fourth level is the implementation detail layer. The first level of the four-level system for product function lists is the product domain, the second level is the functional module, the third level is the functional unit, and the fourth level is the functional element.

9. The method according to any one of claims 2-8, wherein, The method further includes: Training samples are generated based on the original requirements, the target product feature list, the final hierarchical decomposition suggestions, and the final hierarchical product feature matching suggestions. Obtain feedback results on the final-level decomposition suggestions and the final-level product function matching suggestions; Based on the feedback results, the training samples are labeled with positive or negative sample labels; The large model is iteratively optimized using labeled training samples.

10. A demand breakdown device, comprising: The acquisition module is configured to acquire the original requirements of the target project and the target product feature list corresponding to the original requirements; The first decomposition module is configured to decompose the original requirements to a preset level, generate a preset level decomposition suggestion, and match the preset level of the target product function list to generate a preset level product function matching suggestion. The first generation module is configured to retrieve a preset risk database and generate a risk warning based on the original requirements. The second generation module is configured to generate a demand matching scheme based on the preset hierarchical decomposition suggestions, the preset hierarchical product function matching suggestions, and the risk warnings. The second decomposition module is configured to, in response to determining that the target project passes the requirement matching scheme, decompose the preset level decomposition suggestion to the final level, generate the final level decomposition suggestion, and match the final level of the target product function list to generate the final level product function matching suggestion.

11. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

12. A non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-9.

13. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-9.

Images