Software demand disassembling method and device based on multi-source demand, equipment and medium

Abstract

The invention belongs to the technical field of software development, and relates to a software requirement disassembling method and device based on multi-source requirements, equipment and a medium. The method comprises the steps of obtaining a multi-source demand text of a software development full life cycle, and performing demand source identification to obtain a demand source label, a corresponding confidence coefficient and a first context; performing demand type judgment to obtain a demand type label, a corresponding confidence coefficient and a second context; performing cue word construction to obtain a task target template, a key element set, an output format template, a constraint rule template and a third context; clarifying, and outputting a requirement expression after clarification; carrying out atomization disassembly to generate a sub-demand list; and executing verification according to the sub-demand list, and outputting a structured result to realize software demand disassembly. The method and the device can adapt to the structural difference of multi-source requirements and improve the efficiency and the accuracy of software development.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to methods, apparatus, devices and media for decomposing software requirements based on multi-source requirements. Background Technology

[0002] As software systems continue to grow in scale and delivery pace accelerates, software development is gradually shifting from "single delivery" to "continuous evolution." In this process, software requirements, as the starting point and core constraint of software development, permeate key stages such as requirements gathering, requirements analysis, requirements specification, requirements verification, and requirements management.

[0003] Throughout the software development lifecycle, software requirements exhibit a multi-source and heterogeneous nature: In the requirements analysis phase, requirements often originate from contracts, bidding documents, business procedures, and other texts, characterized by strong clauses, implicit constraints, and prominent acceptance and compliance requirements, primarily involving clients and product managers; in the design and development phase, requirements frequently arise from R&D tasks and change requests, characterized by clear task orientation and a focus on implementation or interface levels, primarily involving software designers and developers; in the operations and maintenance phase, requirements often come from user feedback, work order descriptions, and software system operation logs / alarm information, characterized by colloquial language, strong subjectivity, lack of context, and often including error codes, log fragments, or environment descriptions, primarily involving operations personnel, users, and the software system itself. Requirements from different sources and by different stakeholders exhibit significant differences in their purpose, focus, and expression. For example, contract texts emphasize clause constraints and acceptance criteria, R&D tasks emphasize implementation goals and interface boundaries, and operations feedback and logs emphasize symptom descriptions and contextual clues.

[0004] To support the continuous growth and evolution of software, the requirements generated during the requirements analysis, design and development, and operation and maintenance phases typically need to be clarified and standardized, and further transformed into executable and verifiable R&D requirement artifacts (such as clearly defined functional points, non-functional constraints, priorities, and acceptance criteria). These artifacts are then atomically decomposed and task assigned; otherwise, they will be difficult to effectively enter the subsequent development, testing, and iteration processes. However, software requirements are generally expressed in natural language, which suffers from problems such as colloquialism, lack of context, inconsistent granularity, implicit constraints, and high noise levels.

[0005] In the well-known software engineering requirements classification system, software requirements can be divided into two main categories: functional requirements and non-functional requirements. Functional requirements mainly describe the business functions, interaction processes, and business rules that the system should provide, and can usually be abstracted into elements such as "role-behavior-object-condition-result". Non-functional requirements describe the quality attributes and constraints of the system, such as performance, reliability, availability, security, compatibility, and compliance, and usually revolve around "indicators-scope-scenario-acceptance criteria". Their expression is often implicit and vague, and further quantitative indicators, applicable scope, and acceptance criteria need to be supplemented.

[0006] Existing technologies widely employ structured requirement templates, use case analysis, user stories, scenario-based descriptions, and requirement reviews. These methods rely on multiple rounds of communication between product managers or requirement engineers and users to ultimately form requirement documents or requirement items, and maintain requirement versions and tracking relationships.

[0007] However, existing technologies still have the following shortcomings when clarifying and breaking down software requirements: (1) It is difficult to adapt to the structural differences of multi-source needs and lacks a unified processing framework.

[0008] Existing requirements processing methods often focus only on software requirements from a single source. When faced with requirements texts that differ significantly, such as those in the form of contract terms, R&D tasks, or operation and maintenance feedback, manual preprocessing, merging, and rewriting are usually required, resulting in discontinuous processes and poor reusability.

[0009] (2) Demand clarification relies heavily on multiple rounds of manual communication, which is time-consuming, costly and difficult to scale.

[0010] For requirements that are poorly described, lack boundary conditions, or are implied by non-functional constraints, traditionally, product managers / developers rely on repeated communication with users for confirmation. This approach involves significant manpower investment, long feedback cycles, and difficulties in refining and reusing the clarification process, making it difficult to support high-frequency iterations and multi-channel requirement input scenarios.

[0011] (3) Lack of automatic identification and differentiated processing of demand types (functional / non-functional) and source characteristics.

[0012] Different types of requirements differ significantly in terms of clarification dimensions, decomposition strategies, and verification objectives; however, existing technologies often employ a unified processing logic, which can easily lead to insufficient decomposition of functional requirements, omission of non-functional constraints, or incorrect decomposition, resulting in rework and deviations in subsequent R&D and testing phases.

[0013] (4) Directly using large language models for requirement clarification and decomposition lacks controllability and stability.

[0014] Directly inputting the original requirements into a large language model to generate results can easily lead to unstable output formats, information expansion or deviation, omission of key constraints, and inconsistent results generated multiple times for the same requirement, making it difficult to form a stable capability that can be used in engineering.

[0015] (5) Lack of systematic guarantee for the atomicity and executability of the disassembly results.

[0016] The existing requirements breakdown results are often presented as coarse-grained lists, making it difficult to ensure that each sub-requirement meets a single intent, has clear boundaries, can be implemented and verified independently, and generally lacks standardized output of execution elements such as priority and dependency relationships, which affects implementation.

[0017] (6) It lacks structured output protection and automatic verification mechanisms, making it difficult to integrate with the R&D toolchain.

[0018] The output is usually a natural language description, with diverse formats and no parsing, making it difficult to directly integrate with automated processes such as requirement management, task assignment, and test case generation. At the same time, it lacks automatic verification and error correction mechanisms for field integrity, format validity, and constraint consistency, resulting in high integration costs and insufficient reliability of results. Summary of the Invention

[0019] Therefore, it is necessary to provide a software requirement decomposition method, apparatus, equipment, and medium based on multi-source requirements to address the above-mentioned technical problems. This method should be able to adapt to the structural differences of multi-source requirements, perform differentiated processing for requirements from different sources and categories, and stably output structured results that can directly support the R&D and testing process. It should also achieve adaptive clarification and atomic decomposition, improve the automation, controllability, stability, and reliability of clarification and decomposition, thereby improving the efficiency and accuracy of software development.

[0020] Software requirement decomposition methods based on multi-source requirements include: Obtain multi-source requirement texts throughout the software development lifecycle, identify the source of requirements, and obtain requirement source tags and their confidence levels; based on the multi-source requirement texts, requirement source tags, and their confidence levels, obtain the first context. Based on the first context, the requirement type is determined, and the requirement type label and the confidence level of the requirement type label are obtained; based on the first context, the requirement type label and the confidence level of the requirement type label, the second context is obtained. Based on the second context, prompt words are constructed to obtain the task objective template, key element set, output format template, and constraint rule template; based on the second context, task objective template, key element set, output format template, and constraint rule template, the third context is obtained. Based on the third context, clarification is performed until the convergence criterion is met, at which point the clarified requirement representation is output. Based on the requirement type label and the clarified requirement representation, atomic decomposition is performed to generate a list of sub-requirements, so that each sub-requirement meets the requirements of single intent, clear boundaries, explicit expression, independent implementation and verifiability. Based on the list of sub-requirements, perform validation and output structured results to achieve software requirement decomposition.

[0021] In one embodiment, multi-source requirement texts throughout the software development lifecycle are obtained, requirement sources are identified, and requirement source tags and their confidence levels are obtained. Based on the multi-source requirement texts, requirement source tags, and their confidence levels, a first context is obtained, including: Obtain multi-source requirements texts throughout the entire software development lifecycle; For multi-source requirement texts, text preprocessing is performed to avoid interference from non-natural language fragments in source determination and to form a standard representation text in natural language form that can be used for source determination; for the standard representation text, multi-feature extraction and fusion are performed to form the determination features required for source determination; for the determination features, source determination is performed to obtain requirement source labels and the confidence level of requirement source labels, so as to distinguish whether multi-source requirements come from the requirement analysis stage, design and development stage or operation and maintenance stage. In the standard representation text, the demand source label and the confidence level of the demand source label are explicitly semantically identified to form the first context.

[0022] In one embodiment, based on the first context, a requirement type determination is performed to obtain a requirement type label and a confidence level for the requirement type label; based on the first context, the requirement type label, and the confidence level of the requirement type label, a second context is obtained, including: Using demand source labels as prior constraints and feature enhancement signals, type identification is performed on the first context to obtain demand type labels and their confidence levels, in order to distinguish whether multi-source demands belong to functional or non-functional demands. In the first context, the requirement type label and the confidence level of the requirement type label are explicitly semantically identified to form the second context.

[0023] In one embodiment, based on the second context, prompt words are constructed to obtain a task objective template, a set of key elements, an output format template, and a constraint rule template; based on the second context, the task objective template, the set of key elements, the output format template, and the constraint rule template, a third context is obtained, including: Based on the requirement source label and requirement type label, set the corresponding templates for the second context and combine them to obtain multiple initial templates for task objectives; select from multiple initial templates for task objectives based on the confidence levels of the requirement source label and requirement type label to obtain task objective templates; generate a set of key elements, an output format template, and a constraint rule template based on the requirement source label, requirement type label, confidence level of the requirement source label, and confidence level of the requirement type label. The third context is formed based on the second context, the task objective template, the set of key elements, the output format template, and the constraint rule template.

[0024] In one embodiment, clarification is performed based on a third context until a convergence criterion is met, and the clarified demand representation is output, including: Based on the set of key elements in the third context, missing information is identified, and it is determined whether the current requirement is complete in terms of key elements, thus obtaining the slots to be clarified. Based on the slot to be clarified and the third context, generate a set of clarification questions; Obtain user answers to clarification questions, obtain answer records, and generate an initial clarification context based on the clarification slot, the status of the clarification slot, the set of clarification questions, the answer records of historical clarification rounds, and the current clarification round; The initial clarification context is converged, and the convergence result is written into the initial clarification context to form a clarification state context. When the convergence criterion is met, the clarification requirement representation is output according to the clarification state context.

[0025] In one embodiment, based on the requirement type label and the clarified requirement representation, atomic decomposition is performed to generate a list of sub-requirements, ensuring that each sub-requirement meets the requirements of single intent, clear boundaries, explicit expressibility, independent implementation, and verifiability, including: Select the breakdown perspective based on the demand type tag; The clarified requirements are used as a standardized input context for decomposition. Based on the decomposition perspective and the standardized input context oriented towards decomposition, and under the conditions of satisfying atomicity decision constraints, structure constraints, and legality constraints, the large language model is invoked to generate a list of sub-requirements, so that each sub-requirement satisfies the following: single intent, clear boundaries, explicit expression of dependencies, independent implementation in the sense of minimum feasible implementation, and verifiability.

[0026] In one embodiment, based on the list of sub-requirements, validation is performed and structured results are output to achieve software requirement decomposition, including: Perform key-value validation on the sub-requirement list; If the verification passes, the structured decomposition result will be output. If the verification fails, a correction mechanism will be triggered; Each time the correction mechanism is triggered, the number of retry attempts is increased by one; if the verification still fails within the preset number of retries, a structured degradation result is output. Based on the results of structured decomposition or structured degradation, software requirements are decomposed.

[0027] A software requirements decomposition device based on multi-source requirements includes: The first module is used to acquire multi-source requirement texts throughout the software development lifecycle, identify the source of requirements, obtain requirement source tags and their confidence levels, and obtain the first context based on the multi-source requirement texts, requirement source tags, and their confidence levels. The second module is used to determine the requirement type based on the first context, obtain the requirement type label and the confidence level of the requirement type label; and obtain the second context based on the first context, the requirement type label and the confidence level of the requirement type label. The third module is used to construct prompts based on the second context, and obtain the task target template, key element set, output format template and constraint rule template; and to obtain the third context based on the second context, task target template, key element set, output format template and constraint rule template. The fourth module is used to clarify the requirements based on the third context until the convergence criterion is met, and then output the clarified requirement representation. The fifth module is used to atomically decompose the requirements based on the requirement type labels and the clarified requirement representation, and generate a list of sub-requirements so that each sub-requirement meets the requirements of single intent, clear boundaries, explicit expression, independent implementation and verifiability. The sixth module is used to perform validation based on the list of sub-requirements and output structured results to achieve software requirement decomposition.

[0028] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the above-described method.

[0029] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0030] The aforementioned software requirement decomposition method, apparatus, equipment, and medium based on multi-source requirements address the problems of strong heterogeneity, incomplete information, reliance on manual clarification, and poor decomposition effect in the clarification and decomposition of multi-source natural language software requirements in existing technologies. For multi-source requirement input throughout the entire software development lifecycle, a closed-loop technical process of "requirement source identification—requirement type determination—adaptive prompt word construction—interactive iterative clarification—atomic decomposition—structured output protection and verification" is employed to achieve automatic, accurate, and executable decomposition output of requirements. This significantly reduces the cost of manual clarification and decomposition under multi-source requirement input conditions, improves requirement processing efficiency and output stability, and provides reliable technical support for requirement management and R&D efficiency improvement during the continuous evolution of software. Attached Figure Description

[0031] Figure 1 This is a flowchart illustrating a software requirement decomposition method based on multi-source requirements in one embodiment. Figure 2 This is a structural block diagram of a software requirement decomposition device based on multi-source requirements in one embodiment; Figure 3 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0033] Furthermore, the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. In the description of this application, "multiple sets" means at least two sets, such as two sets, three sets, etc., unless otherwise explicitly specified.

[0034] In this application, unless otherwise expressly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection, an electrical connection, a physical connection, or a wireless communication connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two elements or the interaction between two elements, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0035] Furthermore, the technical solutions of the various embodiments of this application can be combined with each other, but only if they are based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by this application.

[0036] This application provides a software requirements decomposition method based on multi-source requirements, such as... Figure 1 The flowchart shown, in one embodiment, includes: Step 101: Obtain multi-source requirement texts for the entire software development lifecycle, identify the source of requirements, obtain requirement source tags and their confidence levels; and obtain the first context based on the multi-source requirement texts, requirement source tags, and their confidence levels.

[0037] Specifically: Obtain multi-source requirements texts throughout the entire software development lifecycle; For multi-source requirement texts, text preprocessing is performed to avoid interference from non-natural language fragments in source determination and to form a standard representation text in natural language form that can be used for source determination. For the standard representation text, multiple features are extracted and fused to form the determination features required for source determination (the determination features exist in the form of feature vectors or feature sets). For the determination features, source determination is performed to obtain the source determination results (including: requirement source labels and the confidence level of the requirement source labels) to distinguish whether multi-source requirements come from the requirement analysis stage, the design and development stage, or the operation and maintenance stage. In the standard representation text, the demand source label and the confidence level of the demand source label are explicitly semantically identified to form the first context, so as to ensure the stability and engineering availability of the source determination result, and to enable the source determination result to play a technical role in routing and strategy selection, thereby providing controllable prior information for subsequent steps.

[0038] in: Text preprocessing includes: encoding the input uniformly, standardizing whitespace and special symbols, segmenting or truncating excessively long texts, and tokenizing structured fragments such as log segments / error codes / timestamps. It also includes text representation construction to encode the text into a semantic representation that can be used for classification. The criteria for judgment include: vocabulary and structural features (e.g., whether it contains clause-type terms such as "Party A," "Party B," "breach of contract," "acceptance," and "delivery," and whether it contains numbered clauses, point-based structures, or expressions referencing specifications), task and implementation features (e.g., whether it contains R&D task terms such as "interface," "parameter," "module," "implementation," "support," "repair," "addition," and "optimization," and whether it contains engineering elements such as version numbers, component names, and API names), and operation and feedback features (e.g., whether it contains user subjective evaluation terms such as "lag," "crash," "error," "unusable," "suggestion," and "experience," and whether it contains error codes, stack traces, and key log fields such as timestamps and level identifiers). Source determination can be achieved by directly outputting the determination result using machine learning or deep learning text classifiers (such as classification networks based on pre-trained language models); Source determination can also be achieved using rule and pattern matching (e.g., detecting clause number structure, log timestamps, level fields, key contract terms, etc.); Source determination can also be achieved using vector retrieval, which involves matching the input requirements with a pre-built library of source examples based on similarity, and using the source of the most similar example as the determination result. Source determination can also adopt a combination strategy of "rule prior + classifier determination", that is: first, use a small number of high-precision rules to quickly classify strong feature scenarios (that is: when the contract clause structure is detected, directly assign the source label of the requirement as the requirement analysis stage requirement; when the log structure is detected, directly assign the source label of the requirement as the operation and maintenance stage requirement), and then call the trained text classification model to determine the remaining uncertain samples, thereby reducing the overall computational overhead and improving stability while ensuring the accuracy of determination. The requirement source tags are two-level tags: stage tags and category tags. Stage tags include: requirements analysis stage requirements, design and development stage requirements, and operation and maintenance stage requirements. Category tags include: contract-related requirements, specification-related requirements, R&D task-related requirements, operation and maintenance feedback requirements, and operation and maintenance log-related requirements. Among them, contract-related requirements and specification-related requirements belong to the requirements analysis stage, R&D task-related requirements belong to the design and development stage, and operation and maintenance feedback requirements and operation and maintenance log-related requirements belong to the operation and maintenance stage.

[0039] In this step, demand source identification (including text preprocessing, multi-feature extraction and fusion, and source determination) can obtain demand source labels and their confidence levels. Preferably, demand source identification using a combination strategy of "rule prior + classifier determination" (text preprocessing, multi-feature extraction and fusion, and source determination using a combination strategy of "rule prior + classifier determination") can characterize the differences in demand text in terms of structural form, information completeness, noise features, and implicit constraints. It can establish a unified understanding of demand input features at the beginning of the processing chain, select matching clarification strategies and decomposition paths for demands from different sources, and avoid misjudgments or information omissions introduced by using a unified processing logic. At the same time, this demand source identification serves as the decision basis for subsequent adaptive prompt word construction and interactive clarification, technically realizing a controllable routing mechanism of "different sources → different strategies," which can avoid problems such as mismatched clarification strategies and unstable decomposition granularity in the later stages.

[0040] It should be noted that the specific methods for obtaining multi-source requirement texts throughout the software development lifecycle, performing text preprocessing, extracting and fusing multiple features, performing explicit semantic labeling, using machine learning or deep learning text classifiers, rule and pattern matching, vector retrieval methods, and text classification models are all existing technologies and will not be elaborated upon here.

[0041] Step 102: Based on the first context, determine the requirement type and obtain the requirement type label and the confidence level of the requirement type label; based on the first context, the requirement type label and the confidence level of the requirement type label, obtain the second context.

[0042] Specifically: Using requirement source labels as prior constraints and feature enhancement signals (e.g., for requirements input during the operation and maintenance phase, there is a greater tendency to identify quality attribute demands such as "performance, reliability, and availability"; for contractual or specification-based requirements, there is a greater focus on non-functional dimensions such as compliance, security, acceptance, and delivery boundaries; for R&D task-based requirements, there is a greater focus on functional descriptions, interface inputs and outputs, and scope of changes), type identification is performed on the first context to obtain type identification results (including requirement type labels and the confidence level of requirement type labels) to distinguish whether multi-source requirements belong to functional or non-functional requirements; In the first context, the requirement type label and its confidence level are explicitly semantically identified to form the second context. In the second context, the requirement type label and the requirement source label together constitute the input control parameters for subsequent adaptive prompt construction. This identification is used to constrain the clarification target and the selection of the problem template: For functional requirements, the prompt construction module will prioritize guiding the completion of roles, business processes, abnormal paths, data fields, and boundary conditions, and in the decomposition stage, it will focus on "independently achievable functional points and interface tasks"; For non-functional requirements, the prompt construction module will prioritize guiding the completion of indicator thresholds, applicable scope, load scenarios, risk constraints, and acceptance methods, and in the decomposition stage, it will focus on "verifiable quality improvement tasks, testing, and monitoring items". This allows the type identification result to play a technical role in strategy routing and constraint injection, thereby providing stable and controllable prior information for subsequent interactive clarification and atomic decomposition.

[0043] in, Type recognition can directly output results using a large language model; Type identification can also be extended by using a multi-label system (for example, further subdividing non-functional requirements into performance, reliability, security, availability, compatibility, compliance, etc.), and then mapping them back to the functional or non-functional upper-level type; Type recognition can also be achieved by using "rules + keyword dictionary + statistical features" to make lightweight type determination, such as inferring non-functional requirements based on fuzzy word detection and index word detection; Type recognition can also employ discriminative classifiers based on pre-trained language models (e.g., the bidirectional encoder representation model BERT). These classifiers are fine-tuned on demand-annotated corpora to output "functional demand or non-functional demand" and the corresponding confidence level (category probability distribution).

[0044] In this step, requirement type determination yields requirement type labels and their confidence levels. Preferably, requirement type determination employs a discriminative classifier based on a pre-trained language model. This approach can characterize the differences in semantic goals, constraint expressions, and verifiable elements within the requirement text. It establishes a distinction between "what to do" and "to what extent" at the early stages of the processing chain, preventing different types of requirements from being incorrectly processed using the same dimension during clarification and decomposition. This reduces the probability of misclassification in short texts, colloquial texts, and cases lacking context, improving the engineering stability and controllability of the determination results. For functional requirements, priority is given to supplementing business processes and boundary conditions; for non-functional requirements, priority is given to supplementing indicators, scenarios, and acceptance criteria, thereby enhancing clarification. This improves efficiency, reduces the rate of missing key constraints, and avoids issues such as incorrect clarification dimensions and unverifiable decomposition results in subsequent stages. Furthermore, the requirement type determination implements a controllable orchestration mechanism of "different types → different clarification dimensions → different decomposition strategies," which can prevent subsequent omissions of key constraints (filling in performance thresholds, stability ranges, security requirements, and compliance boundaries in non-functional requirements, avoiding a lack of verifiable targets in subsequent implementation and testing) and decomposition-oriented deviations (avoiding functional requirements being over-abstracted into quality attribute descriptions or non-functional requirements being incorrectly decomposed into a set of functional points, ensuring that the decomposition results meet atomicity and executability requirements).

[0045] It should be noted that: how to directly output results using a large language model, how to extend the judgment using a multi-label system, how to implement lightweight type judgment, and discriminative classifiers are all existing technologies and will not be elaborated here.

[0046] Step 103: Based on the second context, construct the prompt words to obtain the task target template, key element set, output format template, and constraint rule template; based on the second context, task target template, key element set, output format template, and constraint rule template, obtain the third context.

[0047] Specifically: Based on the second context, the source and type are mapped to a fixed prompt word path (i.e., different states trigger different prompt word versions) using a strategy tree or state machine approach, resulting in a task target template, a set of key elements, an output format template, and a constraint rule template, which form executable constraints on the large language model. Alternatively, based on the second context, a retrieval enhancement method can be used to retrieve the most matching prompt word template fragments from the prompt word library and combine them to generate a task target template, a set of key elements, an output format template, and a constraint rule template, so as to form executable constraints on the large language model; Alternatively, based on the second context, online learning or configurable methods can be used to dynamically adjust the weights and selection rules of prompt word fragments according to historical results, thereby obtaining task target templates, key element sets, output format templates, and constraint rule templates to form executable constraints on the large language model; Alternatively, based on the requirement source tag and requirement type tag, set corresponding templates for the second context and combine them to obtain multiple initial task target templates (each initial task target template includes the content of the second context); select from multiple initial task target templates based on the confidence levels of the requirement source tag and requirement type tag to obtain the task target template, thereby improving the robustness of the prompts in a real engineering environment; generate a set of key elements, an output format template, and a constraint rule template based on the requirement source tag, requirement type tag, the confidence level of the requirement source tag, and the confidence level of the requirement type tag. Based on the second context, task objective template, key element set, output format template, and constraint rule template, a third context is formed to create executable constraints on the large language model. This third context serves as the direct input for subsequent interactive iterative clarification and atomized decomposition, enabling the large language model to complete tasks with a consistent output structure, matching clarification dimensions, and controllable inference paths in different sources and different types of demand scenarios.

[0048] in: Based on the requirement source tags and requirement type tags, corresponding templates are set and combined to obtain multiple initial templates for task objectives, including: setting three requirement source tag templates and two requirement type tag templates based on three requirement source tags and two requirement type tags; combining the five templates to obtain six initial templates, corresponding to: functional requirements in the requirement analysis phase, non-functional requirements in the requirement analysis phase, functional requirements in the design and development phase, non-functional requirements in the design and development phase, functional requirements in the operation and maintenance phase, and non-functional requirements in the operation and maintenance phase. Based on the confidence levels of the demand source label and the demand type label, a task target template is selected from the initial task target template. This includes: when the confidence levels of the demand source label or the demand type label are not lower than a preset threshold, the task target template is selected from the initial task target template; when the confidence levels of the demand source label or the demand type label are lower than the preset threshold, the "Source and Type Confirmation" task target template is automatically activated, requiring the model to first output the uncertainty judgment of the source and type and the most critical judgment information that needs to be supplemented by the user, so that "classification correction" is completed in the clarification stage before proceeding to decomposition. Based on the requirement source tag, requirement type tag, confidence level of the requirement source tag, and confidence level of the requirement type tag, a set of key elements, an output format template, and a constraint rule template are generated. This includes: when the requirement source tag is "requirement analysis" and the requirement type tag is "non-functional requirement," slots such as "compliance clauses, acceptance criteria, constraint boundaries, responsible parties, and risk items" will be prioritized as the set of key elements, and the output will be required to include acceptance methods and traceable clause references as the output format template and constraint rule template; when the requirement source tag is "operations and maintenance" and the requirement type tag is "functional requirement," slots such as "reproducibility clauses" will be prioritized. The output should include slots such as "Components, Affected Modules, Abnormal Paths, Environmental Information, Log Clues," as a set of key elements, and should include minimum reproducible steps and expected behavior definitions, serving as output format templates and constraint rule templates. When the requirement source tag is design and development and the requirement type tag is functional requirement, slots such as "Role, Business Process, Interface Field, Permission Rules, Boundary Conditions, Exception Handling," as a set of key elements, should be used first, and the output should explicitly provide inputs, outputs, and dependencies, serving as output format templates and constraint rule templates. When the requirement source tag is requirement analysis and the requirement type tag is functional requirement, slots such as "Role, Business Process, Interface Field, Permission Rules, Boundary Conditions, Exception Handling," as a set of key elements, should be used first, and should explicitly provide inputs, outputs, and dependencies, serving as output format templates and constraint rule templates. Priority will be given to using slots such as "Business Subject, Business Action, Business Object, Triggering Condition, Processing Flow, Business Rule, Preconditions, Post-Results, and Abnormal Situations" as key element sets. The output will be required to include functional objective descriptions, business process descriptions, input / output definitions, and acceptance criteria, serving as output format templates and constraint rule templates. When the requirement source tag is "Operations and Maintenance" and the requirement type tag is "Non-functional Requirement," priority will be given to using slots such as "Performance, Stability Phenomena, Availability Impact, Security Risks, Compatibility Scope, Occurrence Frequency, Impact Scope, Operating Environment, Monitoring Indicators, and Acceptance Thresholds" as key elements. The key element set is required, and the output must include the problem phenomenon, scope of impact, quantitative indicators, applicable scenarios, and verification methods, serving as the output format template and constraint rule template. When the requirement source tag is design and development and the requirement type tag is non-functional requirement, slots such as "performance indicators, reliability targets, security constraints, concurrent capacity, response latency, resource consumption, compatible versions, deployment constraints, fault tolerance requirements, and testing criteria" will be prioritized as the key element set. The output must explicitly provide the target indicators, scope of application, constraint boundaries, dependency conditions, and verification and testing requirements, serving as the output format template and constraint rule template.

[0049] The task objective template is used to declare the task objective for this round, such as "identify missing information and raise clarification questions" or "atomize and sort the information after it is complete." The key element set is used to select different sets of clarification slots based on the source and type. For example, for contract-related or specification-related requirements, the focus is on guiding the completion of acceptance clauses, compliance constraints, delivery scope, and exceptions; for R&D task-related requirements, the focus is on guiding the completion of interface inputs and outputs, business processes, dependent modules, and version constraints; for operation and maintenance feedback-related or operation and maintenance log-related requirements, the focus is on guiding the completion of reproduction steps, environmental information, scope of impact, and differences between expected and actual behavior. The output format template is used to specify the structure fields and organization of the model output, such as requiring the output of "clarification question list, known information summary, missing information slots, and decomposed sub-requirement list (including priority and dependencies)" in structured entries. The constraint rule template is used to impose engineering constraints, such as prohibiting the introduction of assumptions outside the requirements, requiring quantifiable indicators or acceptance methods for non-functional requirements, and requiring sub-requirements to meet a single intent and be independently verifiable. Based on the second context, task objective template, key element set, output format template, and constraint rule template, a third context is generated. This includes: filling the task objective template with the second context, using the key element set as input to the large model, and using the output format template and constraint rule template as constraints for the large model to generate the third context. In this step, the prompt word construction can generate the task objective template, key element set, output format template, and constraint rule template. Preferably, the adaptive prompt word construction (including setting the initial template for the task objective, template selection, and template generation) maps "source and type" to an executable prompt word structure, transforming the structured prior information obtained in the first two steps into constraints and instructions that can be stably executed by the Large Language Model (LLM). This allows the LLM to follow a unified instruction framework when processing requirements and achieve differentiated processing on key dimensions, thereby guiding the model to complete subsequent requirement clarification and requirement decomposition with the expected clarification dimensions, interaction methods, and output formats. This achieves a bridge from "text input" to "controllable reasoning and structured output," effectively reducing the risk of model output drift and field missing, and realizing a controllable orchestration mechanism of "different sources and types → different clarification objectives and question templates → different output constraints." This improves the consistency, parsability, and reusability of model output, and avoids problems such as semantic target deviation, clarification dimension mismatch, and unstable output structure.

[0050] It should be noted that strategy trees, state machines, search enhancement, online learning, configuration methods, and how to set corresponding templates based on requirement source tags and requirement type tags are all existing technologies and will not be elaborated here.

[0051] Step 104: Clarify according to the third context until the convergence criterion is met, and output the clarified requirement representation.

[0052] Specifically: Based on the set of key elements in the third context, missing information is identified to determine whether the current requirement is complete in terms of key elements, thus obtaining the slots to be clarified (using the missing key elements as the slots to be clarified). For functional requirements, the set of key elements includes roles (users), business objectives, objects and data fields, main process steps, abnormal paths and boundary conditions, permissions and constraints, inputs and outputs, and acceptance criteria. For non-functional requirements, the set of key elements includes quality attribute categories, indicator thresholds or target ranges, applicable scenarios and load conditions, scope of impact and priority, risk constraints and compliance requirements, and acceptance methods and measurement tools. Based on the slot to be clarified and the third context, a set of clarification questions is generated, which includes multiple clarification questions; Obtain user answers to clarification questions, obtain answer records, and generate an initial clarification context based on the clarification slot, the status of the clarification slot (completed or incomplete), the set of clarification questions, the answer records of historical clarification rounds, and the current clarification round, so as to ensure the controllability and traceability of the clarification process. The initial clarification context is converged, and the convergence result is written into the initial clarification context to form a clarification state context. When the convergence criterion is met, a structured post-clarification requirement representation is output based on the clarification state context. The post-clarification requirement representation includes: the completed slot to be clarified, the clarification state context, unresolved risk warnings (such as still existing ambiguous items), and the permission identifier for entering the disassembly stage.

[0053] in: Missing information identification can be achieved by combining rule validation and large language model reasoning. Specifically, for explicit field missingness, rules can be used to quickly determine it, while for implicit constraints and ambiguities, the large language model outputs a "list of slots to be clarified and suggestions for questions" under the prompt constraints. The set of clarification questions can be generated using a combination of a pre-set question library and route selection. Matching questions are selected from the pre-set question library, and the set of clarification questions is generated. The generation of a clarification question set can also be based on the "minimum necessary questions" principle, introducing question ranking to generate the clarification question set. The "minimum necessary questions" principle means prioritizing questions that contribute most to clarification convergence, while ensuring the feasibility and verifiability of subsequent decomposition. This avoids burdening users with too many questions at once or creating inefficient interactions due to questions that don't match the source or type. Question ranking refers to: when the requirement is functional, prioritizing the completion of roles, objects, goals, and boundary conditions; when the requirement is non-functional, prioritizing the completion of quality attribute categories, indicator thresholds, and acceptance methods; when the requirement comes from operational feedback, prioritizing the completion of reproduction conditions and environmental information. The question ranking mechanism can be implemented by preset rules or by the model outputting "question priority" based on confidence levels under suggestive constraints, thereby controlling the number of clarification rounds and costs. The initial clarification context can be generated using a single-round "structured form-based completion" approach, which outputs a list of slots to be filled in at once, allowing the user to populate them. Generating the initial clarification context can also be achieved by obtaining multiple rounds of user responses to the clarification question and triggering incremental completion and consistency checks. Incremental completion refers to mapping newly acquired information to the corresponding slots and updating the known information summary. Consistency checks involve detecting whether user responses contradict existing information, whether there are unsatisfactory constraint combinations, or whether there are still obvious ambiguities. For contradictions and ambiguities, instead of directly breaking them down, targeted clarification follow-up questions are generated to promote the convergence of the demand expression. To avoid the model introducing unverified assumptions during the clarification process, a constraint of "prohibiting the completion of ungiven facts" is set in the prompt words, and the model is required to label each key conclusion as being based on either the original demand or the user's response, thereby improving the credibility and traceability of the clarification results. The initial clarification context is converged, including: writing the convergence judgment into the initial clarification context to form a clarification state context; if the judgment is that the convergence criterion is not met, interactive iterative clarification is performed (i.e., re-identifying missing information, regenerating the set of clarification questions, regenerating the initial clarification context, and re-judging) until the judgment is that the convergence criterion is met, and then a structured clarification requirement representation is output; if the convergence criterion cannot be met within the preset maximum number of rounds, a degradation strategy is triggered (i.e., outputting "the currently decomposable requirements and key issues awaiting manual confirmation", and prompting that manual intervention or additional input is needed to avoid resource waste caused by unbounded interaction), so as to achieve engineered controllability of the clarification process; Convergence criteria could be: "reaching a fixed number of rounds" or "the number of slots to be clarified meets a threshold" to reduce interaction costs; Convergence criteria can also include: the completeness of the slots to be clarified reaches a preset threshold, there are no conflicts in the core constraints, the requirements and acceptance criteria are clear or can be quantified, and the minimum information set required for decomposition is met.

[0054] In this step, clarification (including: identifying missing information, generating a set of clarification questions, generating an initial clarification context, and making judgments) enables the clarification of software requirements. Specifically, interactive iterative clarification is employed, guiding the large language model to progressively ask questions and converge around preset clarification slots under adaptive prompt constraints. This drives the large language model to perform multiple rounds of clarification, and the clarification process is engineered and controllable through determinable completeness checks and round control. Technically, this achieves a closed-loop processing flow of "information gap identification → minimum necessary questioning → incremental completion → convergence determination," realizing the convergence of "requirements from colloquial descriptions to executable and verifiable expressions." Even when requirement information is incomplete, constraints are implicit, and boundary conditions are missing, key information is gradually supplemented through controlled multi-round questioning and answering, ambiguity is eliminated, and a determinable convergence state is achieved. This ensures that requirements have clear objects, boundary conditions, and acceptance criteria before entering atomic decomposition, thereby reducing decomposition deviations caused by ambiguity and omissions, improving the executableness and verifiability of the decomposition results, and achieving controllability, traceability, and reusability of the clarification process in engineering. This provides high-quality input for subsequent atomic decomposition and avoids problems such as insufficient decomposition basis and unverifiable decomposition.

[0055] It should be noted that how to generate a set of clarified issues, how to output a structured, clarified requirement representation, how to perform rule validation, how to pre-configure an issue library, how to select routes, how to output a list of slots to be filled, core constraints, requirement objectives and acceptance criteria, and the minimum information set required for decomposition are all existing technologies and will not be elaborated here.

[0056] Step 105: Based on the requirement type label and the clarified requirement representation, perform atomic decomposition to generate a list of sub-requirements, so that each sub-requirement meets the requirements of single intent, clear boundaries, explicit expression, independent implementation, and verifiability.

[0057] Specifically: Select a breakdown perspective based on the demand type tag, which will serve as the breakdown rule; The clarified requirements are used as a standardized input context for decomposition. Based on the decomposition perspective and the standardized input context for decomposition, and under the conditions of satisfying atomicity constraints (satisfying atomicity constraints to ensure that sub-requirements satisfy atomicity; in specific implementation, the above constraints are used as input to the large language model with structured rules, and the large language model is required to output an "atomic self-check result" for each sub-requirement, that is, the model needs to explain whether the sub-requirement satisfies the single intent and verifiability; if not, the decomposition is further refined until the constraints are satisfied), structured constraints (clarifying constraints with a unified structure), and legal constraints (using the large language model to output legal structured results, ensuring that only legal JSON is output and no additional explanatory text is output), the large language model is called, and a two-level strategy of "planning first and then decomposing" is used to decompose and generate a list of sub-requirements. This ensures that each sub-requirement satisfies the single intent, clear boundaries, explicit expression of dependencies, independent implementation in the sense of minimum viable prototype, and verifiability, thereby ensuring accuracy and controllability.

[0058] in: Based on the requirement type tags, select the decomposition perspective, including: For functional requirements, the decomposition perspective should prioritize the dimensions of "business process, use case steps, and interface capabilities," breaking down the main process and critical exception paths into sub-requirements, and writing permission rules, data fields, and boundary conditions as constraints for the sub-requirements; For non-functional requirements, the decomposition perspective should prioritize the dimensions of "quality attributes - indicators - scenarios - methods," breaking down indicator definitions, implementation methods, monitoring, and verification into sub-requirements. For example, "performance improvement" can be broken down into verifiable items such as "indicator quantification and baseline measurement," "critical path optimization," "stress testing scripts and threshold alarms," ​​and "acceptance report generation." Atomicity constraints include: Single Intent constraint (each sub-requirement corresponds to only one explicit functional point or one explicit quality objective), Minimum Realizable constraint (sub-requirements should be able to be implemented and delivered as a minimum prototype by a single development unit within a controllable workload), Verifiable constraint (sub-requirements must include testable acceptance criteria or metrics), Clear Boundary constraint (sub-requirements must explicitly specify their scope of application and exclusions), and Dependency Expressibility constraint (dependencies must be explicitly declared when they depend on other sub-requirements or external conditions). The unified structure can be a unified JSON (JavaScript Object Notation) structure; the JSON should contain at least the following top-level fields: source_type (source of requirement), req_type (requirement type, functional or non-functional), clarified_summary (clarified summary), and sub_requirements (list of sub-requirements). The sub_requirements are an array structure, and each sub-requirement object should contain at least: id (number), title (sub-requirement title), description (sub-requirement description), type (functional or non-functional identifier), priority (priority), dependencies (dependency list), and acceptance (acceptance criteria or measurement method). The two-level strategy of "plan first, then decompose" includes: first generating a decomposition plan (i.e., dividing by business process dimension, by object domain dimension, by scenario dimension, by abnormal path dimension, and by quality attribute dimension), and then generating the smallest sub-requirement items that meet atomicity constraints within each dimension, thereby reducing the risk of omissions and granularity drift caused by one-time generation. The generated sub-requirement list is a structured list of sub-requirements. Each sub-requirement includes: sub-requirement number, sub-requirement description, type identifier (functional or non-functional), priority, dependencies (generated according to the decomposition plan), acceptance criteria, measurement method, and constraints and boundaries (generated according to the decomposition plan).

[0059] In this step, atomic decomposition (including: selecting a decomposition perspective, designing atomicity determination constraints, and generating a list of sub-requirements) breaks down the requirements into a set of sub-requirements that meet the engineering feasibility requirements based on the clarified convergence results and through decidable atomic constraints and decomposition strategies. It further generates priority and dependency information for these sub-requirements to support task orchestration and iterative planning, thereby significantly reducing the cost of manual secondary decomposition, improving R&D assignment efficiency and test acceptance consistency. Technically, it achieves a closed loop of "clarification and convergence → atomic task generation → executable and verifiable output," transforming the "clarified and convergent requirement expression" into "the smallest independently implementable, verifiable, and scheduleable R&D sub-requirements." This solves the problems of inconsistent granularity, mixed intents, and unclear boundaries in natural language requirements, leading to difficulties in task implementation. It also avoids the problems of unexecutable and unverifiable sub-requirements caused by simply outputting decomposition results in the form of text segments or itemized listings.

[0060] It should be noted that the methods for obtaining dependencies, acceptance criteria, measurement methods, constraints and boundaries are all existing technologies and will not be elaborated here.

[0061] Step 106: Perform validation based on the sub-requirement list and output structured results to achieve software requirement decomposition.

[0062] Specifically: Perform key-value validation on the sub-requirement list to ensure that the output fields are complete, of correct type, can be directly implemented into the R&D process (such as task order generation, scheduling and acceptance management), and can be parsed; If the verification passes, the structured decomposition result will be output. If the validation fails, a correction mechanism is triggered: missing fields, illegal fields, or structural errors are converted into explicit validation error messages, and these error messages are submitted to the large language model as feedback, requiring it to correct the JSON structure and missing fields without changing the semantic content. Each time the correction mechanism is triggered, the number of retries is increased by one. If the number of retries is within the preset range and the verification still fails, a structured degradation result is output (i.e., an error message "Unable to form a structured decomposition" is returned along with the minimum information items that the user needs to supplement), in order to avoid resource waste caused by unbounded retries. Based on the structured results (including structured decomposition results or structured degradation results), software requirements are decomposed.

[0063] in: Key key-value validation includes: syntax validation (i.e., whether the output is valid JSON), structure validation (i.e., whether the top-level field and sub-requirement fields are complete), and type validation (i.e., whether the field value conforms to the preset type constraints, such as: sub_requirements must be an array, priority is an enumeration, and dependencies is an array).

[0064] In this step, based on "forced JSON output", an output protection mechanism of "key value validation + failure correction" is designed to solidify the generative results into a stable machine-readable structure, so that the requirements decomposition results can be directly consumed by the subsequent R&D management system. This reduces the cost of manual processing and improves the overall automation level of the process, thereby reducing costs, significantly improving output stability and engineering usability, ensuring that the output of the large language model can be stably parsed and used by the subsequent system, avoiding parsing failures or manual reprocessing due to missing fields, structural fluctuations or the inclusion of free text, and thus avoiding reducing the benefits of automation.

[0065] It should be noted that methods for converting missing fields, illegal fields, or structural errors into explicit validation error messages, as well as methods for performing syntax validation, structural validation, and type validation, are all existing technologies and will not be elaborated upon here.

[0066] In this embodiment, "conversational, noisy, and incomplete multi-source requirements" are routed using a strategy of "source identification + type determination," then supplemented with key information through "iterative clarification under adaptive prompt constraints," and finally "atomically decomposed and output structured JSON," allowing the results to directly enter the R&D assignment and acceptance process. The input and output can be described as follows: (1) Input: A natural language requirement text provided by the user, which may include a description of terms, a description of R&D tasks, or a fragment of operation and maintenance feedback (operation and maintenance log).

[0067] (2) Intermediate semantic identifiers (internal): source label, type label, confidence level, results of filling slots to be clarified, convergence status, etc., which are used to drive subsequent prompts and strategy selection.

[0068] (3) Output: A standardized JSON structure, including at least: source and type of requirement, clarification summary, and list of sub-requirements (description of sub-requirements, priority, dependencies, acceptance criteria, etc.). This output is intended for use by R&D management and integration systems, and is not free text for human reading only.

[0069] The aforementioned software requirement decomposition method based on multi-source requirements addresses the problems of strong heterogeneity, incomplete information, reliance on manual clarification, and poor decomposition effect in the clarification and decomposition of multi-source natural language software requirements in existing technologies. It addresses the multi-source requirement input throughout the entire software development lifecycle by employing a closed-loop technical process of "requirement source identification—requirement type determination—adaptive prompt word construction—interactive iterative clarification—atomic decomposition—structured output protection and verification." This achieves automatic, accurate, and executable decomposition output of requirements. Under multi-source requirement input conditions, it can significantly reduce the cost of manual clarification and decomposition, improve requirement processing efficiency and output stability, and provide reliable technical support for requirement management and R&D efficiency improvement during the continuous evolution of software.

[0070] Specifically, it has the following beneficial effects: (1) A pre-gating mechanism for “multi-source requirement identification → strategy routing” for the entire software lifecycle: Compared with the existing technology, which often adopts a unified prompt or unified decomposition strategy for different source requirements (requirement analysis, design and development or operation and maintenance) and different types of requirements (functional or non-functional), this application introduces source determination at the beginning of the requirement processing link, maps the input requirements to a preset source set (such as the requirement analysis stage, design and development stage, operation and maintenance stage), and outputs the requirement source label and confidence level as a control signal for subsequent prompt word construction and clarification strategy selection, thereby realizing controllable routing of “different sources → different clarification dimensions and decomposition paths”; This application automatically identifies source characteristics and selects matching processing strategies based on the structural differences and noise characteristics of different source requirements, reducing manual preprocessing and rework costs and improving overall throughput efficiency.

[0071] (2) Type determination and differentiated processing mechanism for functional and non-functional requirements: This application distinguishes requirements into functional and non-functional requirements by determining the type of requirements (and can output confidence level), and writes the type result into the processing context to drive subsequent clarification and decomposition to adopt different completion targets and decomposition perspectives, avoid omission of key constraints (such as performance indicators, compliance boundaries, acceptance criteria, etc.), and ensure that the decomposition results are verifiable and implementable; This application identifies the type of requirements, such as functional or non-functional, and generates clarification questions and information completion paths in a differentiated manner, thereby improving the completeness of key constraint extraction and reducing the omission rate.

[0072] (3) Adaptive prompt word construction method driven by “source label + type label + confidence + context”: Compared with the existing practices that mostly use fixed templates or manually concatenated prompt words, this application does not use fixed prompt words, but automatically assembles prompt word templates (task target template, key element set, output format template and constraint rule template) based on the combination of source and type, which significantly reduces the risk of output drift and field missing in large language models and improves output stability and engineering consistency.

[0073] (4) Controlled interactive iterative clarification closed loop (missing information identification → minimum necessary questions → incremental completion → convergence judgment): Unlike one-time rewriting or one-time decomposition, this application introduces a multi-round clarification mechanism before the requirement decomposition. By maintaining the clarification state context (known information summary, slot to be clarified, round, convergence criterion, etc.), the model is driven to gradually complete the information according to the principle of "minimum necessary questions", and a determinable convergence and stopping condition is set to form a controllable clarification closed loop to reduce the propagation of ambiguity and subsequent rework. This application constructs a determinable clarification convergence mechanism to perform state management and completeness checks on the clarification process, set convergence and stopping conditions, control the number of interactive rounds and resource consumption, and realize stable convergence and traceability of requirement expression.

[0074] (5) The atomic decomposition strategy of "planning first and then decomposing" and the atomicity constraint self-checking mechanism: Existing decomposition is often an itemized enumeration, with unstable granularity and mixed intentions. This application decomposes the requirements into a two-level process: first, a high-level decomposition plan is generated (by process, object, scenario and quality attribute dimensions), then the smallest sub-requirement items are generated, and atomicity judgment constraints are introduced (single intention, minimum implementability, verifiability, clear boundaries, and expressible dependencies). The model is required to give an atomicity self-check for each sub-requirement or trigger further refinement, thereby ensuring that the decomposition results can be independently implemented and verified. Based on the requirement convergence, this application decomposes the requirements into sub-requirements that meet the atomicity requirements, and organizes the output in combination with execution elements such as priority and dependency, so as to realize atomic and executable requirement decomposition output, and improve the direct support capability for R&D task assignment and test design.

[0075] (6) Provide structured output protection and verification: By constraining structured results and using automatic verification mechanisms, improve the stability and parsability of output formats, reduce the integration costs with toolchains such as requirements management and task orchestration, thereby improving the usability and implementation effect of projects.

[0076] In summary, this application introduces a controlled closed loop of "pre-judgment—adaptive prompts—iterative clarification—atomic decomposition—structured solidification," transforming requirements from "conversational natural language" into "executable and verifiable R&D tasks," thereby creating a chain of improvements: First, by identifying the source of requirements and determining the type of requirements, strategy routing is achieved, ensuring that clarification and decomposition align the expression form and key constraints of requirements from the outset, reducing information omissions caused by clarification dimension offsets; Second, adaptive prompt word construction transforms the source and type priors into executable constraint instructions, coupled with the convergence criteria of interactive iterative clarification, ensuring that the minimum necessary information is completed and core ambiguities are eliminated before requirements enter decomposition, reducing decomposition deviations and subsequent rework from the source; Third, adopting an "plan first, decompose later" atomic decomposition strategy and introducing atomic constraint self-checking ensures that sub-requirements meet a single intent, have clear boundaries, and are verifiable, thus being directly usable for task assignment and acceptance design; Finally, through JSON structured output and key value validation, the generative results are solidified into a stable machine-readable structure, significantly reducing system integration failures and manual processing costs caused by format drift. Therefore, this application can logically achieve a chain of benefits: "reducing omissions → reducing ambiguity → stabilizing granularity → improving verifiability → improving automation integration", thereby shortening the requirement processing cycle, reducing labor costs, and improving the stability and controllability of R&D delivery.

[0077] This application addresses the real-world problem of input requirements throughout the software lifecycle. Traditional requirement decomposition methods often use uniform prompts or one-time decomposition for requirements from different sources and of different types. When input requirements come from contract terms, R&D tasks, or operation and maintenance feedback, due to significant differences in expression, implicit constraints, and noise characteristics, uniform processing directly leads to misaligned clarification dimensions and missing key information. On this basis, one-time decomposition means that the model can only rely on subjective assumptions to fill in the missing constraints, ultimately producing sub-requirements with unstable granularity, unverifiable or unassignable characteristics. Problems often only emerge during the R&D scheduling, testing, or acceptance phases, resulting in high rework costs, extended cycles, and uncontrollable quality. To address the characteristics of requirements such as colloquial language, inconsistent granularity, non-standard structure, and implicit key constraints, this application uses a technical link of "controllable clarification + atomized decomposition + structured solidification" to transform the original requirements into a set of executable, verifiable, and scheduleable R&D sub-requirements. Its significance can be deduced from an engineering practice perspective: ambiguities or omissions in the requirements phase typically only surface during development, testing, or acceptance, leading to a significant increase in rework costs. This application moves clarification and constraint completion forward, directly integrating structured outputs into the R&D management process. This ensures requirements are decidable before implementation, reducing the probability of requirement deviations propagating, minimizing manual processing and repetitive communication, and increasing the speed and consistency of requirements entering the development queue. For scenarios involving increasing requirement scale, frequent iterations, or cross-team collaboration, this application can significantly improve the scalability and quality stability of requirements processing, reduce project risks, and provide reliable automated support for efficient delivery during continuous software evolution.

[0078] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0079] In a specific embodiment, the scenario of "requirement processing and iterative planning in the software growth and evolution stage" will be used for illustration.

[0080] As software enters a continuous evolution phase, it will constantly receive new requirements and improvement requests from users, operations and maintenance, and R&D. Traditionally, product managers or developers manually analyze these requests: first determining whether it's "what function needs to be implemented" or "what quality indicators need to be achieved," then repeatedly communicating to supplement the information, and finally breaking it down into task lists. This process is time-consuming, highly subjective, and inconsistent in its handling of requests from different sources, easily leading to overlooked acceptance criteria or unstable granularity in task breakdown.

[0081] By adopting this application, the source and type of requirements can be automatically identified, and matching clarification issues can be selected for the minimum necessary iterative completion. Once the information meets the convergence criteria, an executable and verifiable list of sub-requirements is automatically generated and output according to priority, allowing the team to directly use it for scheduling, assignment, and design acceptance. This reduces manual processing and rework, and improves the speed and consistency of requirements entering the development queue.

[0082] This application is not only applicable to software development requirements clarification and decomposition scenarios, but can also be extended to other complex problems that also have "non-standard natural language descriptions, implicit goals and constraints, and the need for multi-step convergence and decomposition".

[0083] For example, in project management and work order automation scenarios, user-submitted fault tickets or improvement suggestions can be considered as input. Source identification distinguishes between "user feedback, operational alarms, and R&D changes," while type determination differentiates between "functional repairs and quality optimizations." Further iteration and clarification complete the reproduction conditions, impact scope, and acceptance indicators, ultimately breaking it down into directly dispatchable work order sub-tasks. In operations and SRE (Site Reliability Engineering) processes, alarm texts and log summaries can be used as input. Clarification mechanisms complete the environment and triggering conditions, breaking it down into atomic tasks such as "location—mitigation—repair—verification—monitoring improvement." In compliance and security requirement implementation, regulatory clauses or audit requirements can be used as input. Clarification completes the scope of application and acceptance criteria, further breaking it down into implementable control items, inspection items, and verification items. Regardless of the specific domain, the key technical points remain consistent: pre-judgment enables policy routing, controlled clarification achieves information convergence, and atomic decomposition and structured output ensure the project's feasibility and integrability, thereby reducing costly rework and communication costs later on.

[0084] This application also provides a software requirements decomposition device based on multi-source requirements, such as... Figure 2 As shown, in one embodiment, it includes: a first module 201, a second module 202, a third module 203, a fourth module 204, a fifth module 205, and a sixth module 206, wherein: The first module 201 is used to acquire multi-source requirement texts throughout the software development lifecycle, identify the source of requirements, obtain requirement source tags and their confidence levels, and obtain the first context based on the multi-source requirement texts, requirement source tags and their confidence levels. The second module 202 is used to determine the requirement type based on the first context, obtain the requirement type label and the confidence level of the requirement type label; and obtain the second context based on the first context, the requirement type label and the confidence level of the requirement type label. The third module 203 is used to construct prompt words based on the second context to obtain a task target template, a set of key elements, an output format template, and a constraint rule template; and to obtain a third context based on the second context, the task target template, the set of key elements, the output format template, and the constraint rule template. The fourth module 204 is used to clarify based on the third context until the convergence criterion is met, and then output the clarified requirement representation. Module 5, 205, is used to atomically decompose the requirements based on the requirement type label and the clarified requirement representation, and generate a list of sub-requirements so that each sub-requirement meets the requirements of single intent, clear boundaries, explicit expression, independent implementation, and verifiability. Module 6, 206, is used to perform validation based on the list of sub-requirements and output structured results to achieve software requirement decomposition.

[0085] Specific limitations regarding the software requirement decomposition device based on multi-source requirements can be found in the limitations of the software requirement decomposition method based on multi-source requirements described above, and will not be repeated here. Each module in the aforementioned device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0086] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 3As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a software requirements decomposition method based on multi-source requirements. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0087] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0088] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method described above.

[0089] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0090] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0091] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

[0092] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0093] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended application documents.

Claims

1. A software requirement decomposition method based on multi-source requirements, characterized in that, include: Obtain multi-source requirement texts throughout the entire software development lifecycle, identify the source of requirements, and obtain requirement source tags and their confidence levels. The first context is obtained based on the multi-source requirement text, requirement source tags, and the confidence level of the requirement source tags; Based on the first context, the requirement type is determined, and the requirement type label and the confidence level of the requirement type label are obtained; The second context is obtained based on the first context, the requirement type label, and the confidence level of the requirement type label; Based on the second context, prompt words are constructed to obtain the task objective template, key element set, output format template, and constraint rule template. Based on the second context, the task objective template, the set of key elements, the output format template, and the constraint rule template, the third context is obtained. Based on the third context, clarification is performed until the convergence criterion is met, at which point the clarified requirement representation is output. Based on the requirement type label and the clarified requirement representation, atomic decomposition is performed to generate a list of sub-requirements, so that each sub-requirement meets the requirements of single intent, clear boundaries, explicit expression, independent implementation and verifiability. Based on the list of sub-requirements, perform validation and output structured results to achieve software requirement decomposition.

2. The software requirement decomposition method based on multi-source requirements according to claim 1, characterized in that, Obtain multi-source requirement texts throughout the entire software development lifecycle, identify the source of requirements, and obtain requirement source tags and their confidence levels. Based on the multi-source requirement text, requirement source tags, and the confidence level of the requirement source tags, the first context is obtained, including: Obtain multi-source requirements texts throughout the entire software development lifecycle; For multi-source requirement texts, text preprocessing is performed to avoid interference from non-natural language fragments in source determination and to form a standard representation text in natural language form that can be used for source determination; for the standard representation text, multi-feature extraction and fusion are performed to form the determination features required for source determination; for the determination features, source determination is performed to obtain requirement source labels and the confidence level of requirement source labels, so as to distinguish whether multi-source requirements come from the requirement analysis stage, design and development stage or operation and maintenance stage. In the standard representation text, the demand source label and the confidence level of the demand source label are explicitly semantically identified to form the first context.

3. The software requirement decomposition method based on multi-source requirements according to claim 2, characterized in that, Based on the first context, the requirement type is determined, and the requirement type label and the confidence level of the requirement type label are obtained; Based on the first context, the requirement type label, and the confidence level of the requirement type label, the second context is obtained, including: Using demand source labels as prior constraints and feature enhancement signals, type identification is performed on the first context to obtain demand type labels and their confidence levels, in order to distinguish whether multi-source demands belong to functional or non-functional demands. In the first context, the requirement type label and the confidence level of the requirement type label are explicitly semantically identified to form the second context.

4. The software requirement decomposition method based on multi-source requirements according to any one of claims 1 to 3, characterized in that, Based on the second context, prompt words are constructed to obtain the task objective template, key element set, output format template, and constraint rule template. Based on the second context, the task objective template, the set of key elements, the output format template, and the constraint rule template, the third context is obtained, including: Based on the requirement source label and requirement type label, set the corresponding templates for the second context and combine them to obtain multiple initial templates for task objectives; select from multiple initial templates for task objectives based on the confidence levels of the requirement source label and requirement type label to obtain task objective templates; generate a set of key elements, an output format template, and a constraint rule template based on the requirement source label, requirement type label, confidence level of the requirement source label, and confidence level of the requirement type label. The third context is formed based on the second context, the task objective template, the set of key elements, the output format template, and the constraint rule template.

5. The software requirement decomposition method based on multi-source requirements according to any one of claims 1 to 3, characterized in that, Based on the third context, clarification is performed until the convergence criterion is met, at which point the clarified requirement representation is output, including: Based on the set of key elements in the third context, missing information is identified, and it is determined whether the current requirement is complete in terms of key elements, thus obtaining the slots to be clarified. Based on the slot to be clarified and the third context, generate a set of clarification questions; Obtain user answers to clarification questions, obtain answer records, and generate an initial clarification context based on the clarification slot, the status of the clarification slot, the set of clarification questions, the answer records of historical clarification rounds, and the current clarification round; The initial clarification context is converged, and the convergence result is written into the initial clarification context to form a clarification state context. When the convergence criterion is met, the clarification requirement representation is output according to the clarification state context.

6. The software requirement decomposition method based on multi-source requirements according to any one of claims 1 to 3, characterized in that, Based on the requirement type tags and the clarified requirement representation, atomic decomposition is performed to generate a list of sub-requirements. Each sub-requirement is designed to meet the following criteria: single intent, clear boundaries, explicit expressibility, independent implementation, and verifiability. These include: Select the breakdown perspective based on the demand type tag; The clarified requirements are used as a standardized input context for decomposition. Based on the decomposition perspective and the standardized input context oriented towards decomposition, and under the conditions of satisfying atomicity decision constraints, structure constraints, and legality constraints, the large language model is invoked to generate a list of sub-requirements, so that each sub-requirement satisfies the following: single intent, clear boundaries, explicit expression of dependencies, independent implementation in the sense of minimum feasible implementation, and verifiability.

7. The software requirement decomposition method based on multi-source requirements according to any one of claims 1 to 3, characterized in that, Based on the list of sub-requirements, perform validation and output structured results to achieve software requirement decomposition, including: Perform key-value validation on the sub-requirement list; If the verification passes, the structured decomposition result will be output. If the verification fails, a correction mechanism will be triggered; Each time the correction mechanism is triggered, the number of retry attempts is increased by one; if the verification still fails within the preset number of retries, a structured degradation result is output. Based on the results of structured decomposition or structured degradation, software requirements are decomposed.

8. A software requirement decomposition device based on multi-source requirements, characterized in that, include: The first module is used to acquire multi-source requirement texts throughout the software development lifecycle, identify the source of requirements, and obtain requirement source tags and the confidence level of the requirement source tags. The first context is obtained based on the multi-source requirement text, requirement source tags, and the confidence level of the requirement source tags; The second module is used to determine the requirement type based on the first context, and obtain the requirement type label and the confidence level of the requirement type label; The second context is obtained based on the first context, the requirement type label, and the confidence level of the requirement type label; The third module is used to construct prompts based on the second context, and obtain the task target template, key element set, output format template and constraint rule template. Based on the second context, the task objective template, the set of key elements, the output format template, and the constraint rule template, the third context is obtained. The fourth module is used to clarify the requirements based on the third context until the convergence criterion is met, and then output the clarified requirement representation. The fifth module is used to atomically decompose the requirements based on the requirement type labels and the clarified requirement representation, and generate a list of sub-requirements so that each sub-requirement meets the requirements of single intent, clear boundaries, explicit expression, independent implementation and verifiability. The sixth module is used to perform validation based on the list of sub-requirements and output structured results to achieve software requirement decomposition.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images