CN-122018858-A - Software demand dismantling method, device, equipment and medium based on multi-source demand
Abstract
The application belongs to the technical field of software development, and relates to a method, a device, equipment and a medium for disassembling software requirements based on multi-source requirements. The method comprises the steps of obtaining a multi-source demand text of a full life cycle of software development, carrying out demand source identification to obtain a demand source label, a corresponding confidence coefficient and a first context, carrying out demand type judgment to obtain a demand type label, a corresponding confidence coefficient and a second context, carrying out prompt 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, outputting a clarified demand representation, carrying out atomization disassembly to generate a sub-demand list, carrying out verification according to the sub-demand list, and outputting a structured result to realize software demand disassembly. The application can adapt to the structural difference of multi-source requirements and improve the efficiency and accuracy of software development.
Inventors
- ZHANG XUNHUI
- ZHAO JIALIN
- WANG TAO
- DING BO
- ZHANG YANG
- YANG CHENG
- FU XIANG
- YAO SIMENG
- WANG HUAIMIN
Assignees
- 中国人民解放军国防科技大学
Dates
- Publication Date
- 20260512
- Application Date
- 20260413
Claims (10)
- 1. The software demand disassembling method based on the multi-source demand is characterized by comprising the following steps: Acquiring a multi-source demand text of a full life cycle of software development, carrying out demand source identification to obtain a demand source label and a confidence coefficient of the demand source label; According to the first context, judging the demand type to obtain a demand type label and the confidence of the demand type label; obtaining a second context according to the first context, the requirement type label and the confidence level of the requirement type label; According to the second context, the task target template, the key element set, the output format template and the constraint rule template are obtained, and a third context is obtained; clarifying according to the third context until convergence criterion is met, and outputting clarified demand representation; according to the requirement type label and the clarified requirement representation, carrying out atomization disassembly to generate a sub-requirement list so that each sub-requirement meets single intention, has clear boundary, can be explicitly expressed, can be independently realized and can be verified; and executing verification according to the sub-requirement list, and outputting a structural result to realize software requirement disassembly.
- 2. The method of claim 1, wherein the steps of obtaining a multi-source demand text of a full lifecycle of a software development, performing demand source identification to obtain a demand source tag and a confidence level of the demand source tag, and obtaining a first context according to the multi-source demand text, the demand source tag and the confidence level of the demand source tag comprise: acquiring a multi-source demand text of a full life cycle of software development; Performing text preprocessing on the multisource demand text to avoid interference of non-natural language fragments on source judgment and form standard representation text in a natural language form which can be used for source judgment, performing multi-feature extraction and fusion on the standard representation text to form judgment features required by source judgment, performing source judgment on the judgment features to obtain demand source labels and confidence of the demand source labels so as to distinguish multisource demands from a demand analysis stage, a design development stage or an operation and maintenance stage; In the standard representation text, the demand source label and the confidence of the demand source label are subjected to explicit semantic identification to form a first context.
- 3. The method for software demand dismantling based on multi-source demand according to claim 2, wherein the step of determining the demand type according to the first context to obtain the demand type label and the confidence of the demand type label, and the step of obtaining the second context according to the first context, the demand type label and the confidence of the demand type label comprises the steps of: The demand source label is used as a priori constraint and feature enhancement signal, type identification is carried out on the first context, and the demand type label and the confidence coefficient of the demand type label are obtained so as to distinguish whether the multi-source demand belongs to the functional demand or the non-functional demand; in the first context, the requirement type label and the confidence of the requirement type label are subjected to explicit semantic identification to form a second context.
- 4. The method for decomposing software requirements based on multi-source requirements according to any one of claims 1 to 3, wherein performing prompt word construction according to a second context to obtain a task target template, a key element set, an output format template and a constraint rule template, obtaining a third context according to the second context, the task target template, the key element set, the output format template and the constraint rule template, comprises: Setting corresponding templates of a second context according to the demand source tags and the demand type tags and combining to obtain a plurality of task target initial templates, selecting among the plurality of task target initial templates according to the confidence coefficient of the demand source tags and the confidence coefficient of the demand type tags to obtain task target templates; And forming a third context according to the second context, the task target template, the key element set, the output format template and the constraint rule template.
- 5. A method of multi-source demand based software demand dismantling according to any one of claims 1 to 3, wherein clarification is performed according to a third context until a convergence criterion is met, outputting a clarified demand representation, comprising: Carrying out missing information identification according to the key element set in the third context, judging whether the current requirement is complete on the key element, and obtaining a to-be-clarified slot; generating a clarification problem set according to the to-be-clarified tank and the third context; obtaining answers of a user to clarification questions, obtaining answer records, and generating initial clarification context according to the to-be-clarified tank position, the state of the to-be-clarified tank position, the clarification question set, the answer records of historical clarification rounds and the current clarification rounds; Performing convergence judgment on the initial clarification context, and writing a judgment conclusion of whether to converge into the initial clarification context to form a clarification state context; and outputting the clarified demand representation according to the clarified state context until convergence criteria are met.
- 6. A method of multi-source demand-based software demand dismantling according to any one of claims 1 to 3, wherein the step of atomically dismantling according to demand type labels and clarified demand representations to generate a sub-demand list such that each sub-demand meets a single intent, is clear-bordered, explicitly expressible, independently implementable and verifiable comprises: Selecting a disassembly view angle according to the demand type label; expressed in terms of post-clarification requirements, as a standardized input context for disassembly; according to the disassembly view angle and the standardized input context facing the disassembly, under the condition of meeting the atomicity judgment constraint, the structural constraint and the legal constraint, a large language model is called to generate a sub-requirement list, so that each sub-requirement meets single intention, the boundary is clear, the dependency relationship can be expressed explicitly, and the sub-requirement can be independently realized and verified in the minimum feasible realization sense.
- 7. A method of multi-source demand based software demand dismantling according to any one of claims 1 to 3, wherein performing a verification based on the sub-demand list and outputting a structured result to effect software demand dismantling comprises: executing key value verification on the sub-demand list; if the verification is passed, outputting a structured disassembly result; If the verification is not passed, triggering a correction mechanism; If the retry times still cannot pass the verification within a preset range, outputting a structural degradation result; And according to the structural disassembly result or the structural degradation result, realizing software demand disassembly.
- 8. Software demand disassembling device based on multisource demand, characterized by comprising: The system comprises a first module, a first context, a second module, a third module, a fourth module, a fifth module, a sixth module and a seventh module, wherein the first module is used for acquiring a multi-source demand text of a full life cycle of software development, carrying out demand source identification to obtain a demand source label and the confidence coefficient of the demand source label; The second module is used for judging the demand type according to the first context to obtain a demand type label and the confidence coefficient of the demand type label; The third module is used for constructing a prompt word according to the second context to obtain a task target template, a key element set, an output format template and a constraint rule template; a fourth module, configured to clarify according to the third context until a convergence criterion is satisfied, and output a clarified demand representation; a fifth module, configured to perform atomization disassembly according to the requirement type tag and the clarified requirement representation, and generate a sub-requirement list, so that each sub-requirement satisfies a single intention, has a clear boundary, can be explicitly expressed, can be independently implemented, and can be verified; And the sixth module is used for executing verification according to the sub-requirement list and outputting a structural result so as to realize software requirement disassembly.
- 9. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the steps of the method of any of claims 1 to 7 when the computer program is executed.
- 10. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 7.
Description
Software demand dismantling method, device, equipment and medium based on multi-source demand Technical Field The application relates to the technical field of software development, in particular to a method, a device, equipment and a medium for disassembling software requirements based on multi-source requirements. Background As the scale of software systems continues to expand and the delivery pace continues to accelerate, software development gradually changes from "single delivery" to "continuous evolution". In the process, the software requirement serves as a starting point and core constraint of software development, and key links such as requirement acquisition, requirement analysis, requirement specification, requirement verification and requirement management are penetrated. In the software development life cycle, the software demand source presents multi-source heterogeneous characteristics, namely, in the demand analysis stage, the demand is usually from the texts such as contracts, bidding documents, business regulations and the like, and the software demand source is characterized by strong clauseization, implicit constraint, prominent acceptance and compliance requirements, and relates to a main body mainly as a client and a product manager. The requirements formed by different sources and different subjects have significant differences in expression purposes, attention dimensions and expression modes, such as contract text bias clause constraint and acceptance caliber, research and development task bias realization targets and interface boundaries, operation and maintenance feedback and log bias phenomenon description and context clues. In order to support the continuous growth and evolution of software, the requirements generated in the requirement analysis stage, the design development stage and the operation and maintenance stage are usually clarified and normalized, and further converted into executable and verifiable research and development requirement workpieces (such as definite functional points, nonfunctional constraints, priorities and acceptance criteria), and atomized disassembly and task assignment are performed on the basis, otherwise, the follow-up development, test and iteration flows are difficult to effectively enter. However, software requirements are commonly expressed in natural language, and problems such as spoken language, context deficiency, inconsistent granularity, implicit constraint, high noise and the like exist. In a known software engineering requirement classification system, software requirements can be divided into two major categories, namely functional requirements and non-functional requirements. The functional requirements mainly describe business functions, interaction flows and business rules which the system should provide, and can be generally abstracted into factors such as roles, behaviors, objects, conditions, results and the like, while the non-functional requirements describe quality attributes and constraints of the system, such as performance, reliability, availability, safety, compatibility, compliance and the like, and are generally unfolded around an index-range-scene-acceptance criterion, and the expression of the functional requirements often has implications and ambiguity and needs to be further supplemented with quantitative indexes, application ranges and acceptance criteria. In the prior art, the modes of structuring a demand template, analyzing use cases, describing user stories, sceneries, evaluating demands and the like are widely adopted, a product manager or a demand engineer is relied on to communicate with a user for multiple times, a demand document or a demand item is finally formed, and the version and tracking relation of the demands are maintained. However, the following drawbacks still exist in the prior art when clarifying and dismantling software requirements: (1) It is difficult to accommodate the structural differences in multi-source requirements, and a unified processing framework is lacking. The existing demand processing method only pays attention to the software demand of a single source, and generally needs manual pretreatment, merging and rewriting when facing the demand texts with obvious differences such as contract style, research and development task type, operation and maintenance feedback type and the like, so that the flow is discontinuous and the reusability is poor. (2) The clarification of the requirements is highly dependent on manual multi-round communication, and has long period, high cost and difficult scale. For the demands with unclear expression, missing boundary conditions or hidden nonfunctional constraints, the traditional method relies on repeated communication confirmation between product managers/research and development and users, and has the problems of large labor investment, long feedback period and difficult sedimentation and multiplexing in the clarification process, and is difficu