Software generation method, apparatus, and electronic device

Abstract

The present disclosure relates to the technical field of computers, and provides a software generation method and device and electronic equipment. The method comprises: parsing a plurality of software requirement documents of a target software to be generated to obtain requirement information corresponding to each of a plurality of software modules of the target software, the plurality of software requirement documents corresponding one-to-one to the plurality of software modules; generating, based on the requirement information corresponding to each of the plurality of software modules, a to-be-delivered file corresponding to each of the plurality of software modules through an intelligent agent corresponding to each of the plurality of software modules; and generating, based on the to-be-delivered file corresponding to each of the plurality of software modules, a delivery file of the target software. The present scheme effectively avoids understanding deviation of manual requirement analysis, inefficiency of manual coding, and compatibility problem of manual module integration in software development, significantly improves the automation degree and overall development efficiency of software development, and ensures high consistency between software requirements and actual implementation.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a software generation method, apparatus and electronic device. Background Technology

[0002] In the actual development of software systems, end-to-end automated generation capability is the core standard for measuring the advancement of software development tools.

[0003] However, current development methods cannot automatically generate a complete, working system from natural language, resulting in long development cycles and a disconnect between standards and code. Alternatively, low-code platforms may be used to shorten the cycle, but these solutions are limited in functionality, can only generate code snippets, and still require a lot of manual work for architecture design and module integration, resulting in poor system scalability, difficulty in guaranteeing quality, and high development costs, making it difficult to balance development efficiency and system quality. Summary of the Invention

[0004] To address the aforementioned technical problems, this disclosure provides a software generation method, apparatus, and electronic device to achieve automated development of target software, improve development efficiency, and reduce development costs.

[0005] The first aspect of this disclosure provides a software generation method, comprising: The multiple software requirement documents of the target software to be generated are parsed to obtain the requirement information corresponding to each of the multiple software modules of the target software. The multiple software requirement documents correspond one-to-one with the multiple software modules. Based on the requirement information corresponding to each of the multiple software modules, the corresponding intelligent agents of each software module generate the delivery files corresponding to each software module. Based on the deliverable files corresponding to each of the multiple software modules, the delivery files for the target software are generated.

[0006] A second aspect of this disclosure provides a software generation apparatus, comprising: The parsing module is used to parse multiple software requirement documents of the target software to be generated, and obtain the requirement information corresponding to each of the multiple software modules of the target software. The multiple software requirement documents correspond one-to-one with the multiple software modules. The information processing module is used to generate deliverable files for each of the multiple software modules based on their respective requirements information and through the intelligent agents of each software module. The delivery document determination module is used to generate the delivery document of the target software based on the delivery documents corresponding to each of the multiple software modules.

[0007] A third aspect of this disclosure provides a computer-readable storage medium storing a computer program for performing the software generation method described in the first aspect.

[0008] A fourth aspect of this disclosure provides an electronic device including a processor; a memory for storing processor-executable instructions; and a processor for reading executable instructions from the memory and executing the executable instructions to implement the software generation method proposed in the first aspect.

[0009] The software generation method disclosed herein first parses multiple software requirement documents of the target software to be generated to obtain the requirement information corresponding to each software module. Then, it generates corresponding deliverable files through intelligent agents dedicated to each software module. Finally, it integrates the deliverable files to generate the delivery file of the target software. This approach effectively avoids the misunderstanding of requirements due to manual parsing, the inefficiency of manual coding, and the compatibility issues of manual module integration in software development. It significantly improves the automation level and overall development efficiency of software development, while ensuring a high degree of consistency between software requirements and actual implementation. Attached Figure Description

[0010] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0011] Figure 1 This is a structural block diagram of a software generation system provided in an exemplary embodiment of the present disclosure; Figure 2 This is a flowchart illustrating a software generation method provided in an exemplary embodiment of this disclosure; Figure 3 This is a flowchart illustrating a method for generating a document to be delivered, provided in an exemplary embodiment of this disclosure. Figure 4 This is a flowchart illustrating a method for generating delivery documents provided in an exemplary embodiment of this disclosure; Figure 5 This is a flowchart illustrating a mapping relationship determination method provided in an exemplary embodiment of this disclosure; Figure 6 This is a flowchart illustrating a software generation method provided in another exemplary embodiment of this disclosure; Figure 7 This is a flowchart illustrating a method for generating delivery documents provided in another exemplary embodiment of this disclosure; Figure 8 This is a flowchart illustrating a method for obtaining demand information provided in an exemplary embodiment of this disclosure; Figure 9 This is a schematic diagram of the structure of a software generation apparatus provided in an exemplary embodiment of the present disclosure; Figure 10 This is a structural diagram of an electronic device provided by an exemplary embodiment of the present disclosure. Detailed Implementation

[0012] Hereinafter, exemplary embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present disclosure, and not all embodiments of the present disclosure, and it should be understood that the present disclosure is not limited to the exemplary embodiments described herein.

[0013] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0014] Application Overview With the development of software development technology, the rapid and automated generation of software systems has become the key to improving development efficiency and adapting to market demands. Especially in enterprise-level system development and smart device supporting software R&D, high development efficiency requires end-to-end automation from requirements to a working system in order to quickly respond to changes in business needs.

[0015] Currently, mainstream software development solutions such as traditional manual development and low-code platforms all have significant limitations: traditional development has long cycles and requires a lot of manual intervention, which can easily lead to misunderstandings of requirements and a disconnect between specifications and code; low-code platforms have limited functionality and insufficient versatility, making it difficult to handle complex business scenarios. On the other hand, investing a large number of professionals to manually complete coding and integration can lead to high development costs and low coordination efficiency, making it difficult to balance the efficiency, quality, and cost of software development.

[0016] To address the aforementioned technical issues, this disclosure provides a software generation method, apparatus, and electronic device. This method parses software requirement documents that correspond one-to-one with software modules, extracts the requirement information for each software module, and generates corresponding deliverable files through intelligent agents specific to each software module based on this requirement information. Finally, it integrates these deliverable files to generate the target software's delivery file. This solution eliminates human misunderstanding bias through standardized requirement parsing, achieves parallel and automated generation of each software module through intelligent agents, and combines this with the automated integration of deliverable files to realize end-to-end automated generation from software requirement documents to a complete, runnable software system. Without requiring a large number of professional developers, it significantly shortens the development cycle, lowers the development threshold, ensures consistency between software implementation and requirement specifications, balances development efficiency, quality, and cost, and is adaptable to the development needs of software systems in different fields and with different architectures.

[0017] Exemplary System Figure 1 This is a structural block diagram of a software generation system provided by an exemplary embodiment of the present disclosure.

[0018] like Figure 1 As shown, the software generation system 10 includes a memory 101 and a processor 102.

[0019] The memory 101 is used to store program instructions that can be executed by the processor 102. The processor 102 can load and execute the program instructions in the memory 101 to implement the software generation method.

[0020] The memory 101 is also used to store data, such as software requirements documents, deliverables corresponding to each of the multiple software modules of the target software, intelligent agents corresponding to each of the multiple software modules, and delivery documents of the target software.

[0021] In some embodiments, memory 101 may include volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), etc.; it may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, etc.

[0022] Processor 102 is configured to execute instructions stored in memory 101 to perform the following operations: The process involves parsing multiple software requirement documents for the target software to be generated, obtaining the requirement information for each of the multiple software modules, with each software requirement document corresponding to a specific software module. Based on the requirement information for each software module, and through the intelligent agents corresponding to each software module, a deliverable file for each software module is generated. Finally, based on the deliverable files for each software module, the delivery file for the target software is generated.

[0023] The software generation system of this disclosure involves a processor executing executable instructions in memory to parse multiple software requirement documents for the target software to be generated, obtaining requirement information corresponding to each software module. Then, each software module's dedicated intelligent agent generates a corresponding deliverable file, and finally, all deliverable files are integrated to generate the target software's delivery file. This approach effectively avoids the misunderstandings caused by manual requirement parsing, the inefficiency of manual coding, and the compatibility issues of manual module integration in traditional software development. It significantly improves the automation level and overall development efficiency of software development, greatly shortens the software development cycle, and ensures a high degree of consistency between software requirements and actual implementation.

[0024] Exemplary methods Figure 2 This is a schematic flowchart illustrating a software generation method provided in an exemplary embodiment of this disclosure. This embodiment can be applied to electronic devices, such as... Figure 2 As shown, the method includes the following steps: Step S100: Parse the multiple software requirement documents of the target software to be generated to obtain the requirement information corresponding to each of the multiple software modules of the target software.

[0025] Multiple software requirements documents correspond one-to-one with multiple software modules.

[0026] The target software is a fully functional software system to be developed. For example, the target software is an intelligent AI software system with AI intelligent decision-making, dynamic interaction and logical self-evolution capabilities.

[0027] A software requirements document (QR) is a standardized document that describes the functional, performance, architecture, interfaces, business processes, and other requirements of a target software. QRs are written in structured natural language and can use formats such as Markdown, reStructuredText, or AsciiDoc, with content organized hierarchically.

[0028] Parsing refers to extracting key information (such as software module names, descriptions of software module responsibilities, input / output interfaces, and dependencies between software modules) from software requirements documents using natural language processing techniques, regular expression matching, or named entity recognition, and converting it into structured data that can be directly used by intelligent agents.

[0029] A software module refers to a component of target software that has independent functions and can be developed or deployed independently. For example, multiple software modules may include a front-end module (providing the user interface), a back-end module (executing business logic and data access), a logic rule module (defining processing flow and rules), and a software architecture module (determining directory structure and naming conventions), etc.

[0030] Requirements information refers to the specific descriptions extracted from software requirements documents that guide the generation of software modules, including the functional requirements, data interface formats, business process constraints, performance indicators, etc. of the corresponding software modules.

[0031] This step involves parsing multiple software requirement documents for the target software to be generated. The extracted information is then organized into structured data, serving as the requirement information for that module. This step transforms the content of the software requirement documents, written in natural language, into machine-readable and processable structured requirement information, providing explicit input for the subsequent automated generation of intelligent agents.

[0032] Step S200: Based on the requirement information corresponding to each of the multiple software modules, generate the delivery files corresponding to each of the multiple software modules through the intelligent agents corresponding to each of the multiple software modules.

[0033] Intelligent agents refer to automated program instances built based on large language models or other artificial intelligence algorithms, capable of reading requirement information and generating corresponding deliverables. Different intelligent agents can be assigned different module generation tasks and support parallel execution.

[0034] Deliverables refer to the procedural outputs generated by the intelligent agent based on the requirements information, including but not limited to source code files (such as server.js, index.html) and configuration files (such as package.json).

[0035] This approach utilizes the specific requirements of each software module to match a corresponding intelligent agent for each module. Each intelligent agent then generates the deliverables for its respective software module, thereby automating and standardizing the construction of each software module of the target software and obtaining the deliverables.

[0036] In one feasible approach, the process of generating deliverables for each of the multiple software modules based on their respective requirement information and through their respective intelligent agents may also include the following steps: Based on the inter-module dependencies described in the requirements information for each software module (e.g., front-end modules depend on API interfaces provided by back-end modules, and back-end modules depend on the directory structure defined by the software architecture module), a Directed Acyclic Graph (DAG) is constructed. Based on the DAG, a topological sorting algorithm is used to determine the construction order of each software module, ensuring that dependent software modules are constructed before their dependent counterparts. Simultaneously, the DAG identifies a set of software modules without mutual dependencies, and these modules are marked as modules that can be constructed in parallel. For example, nodes in the DAG represent software modules, and directed edges represent dependencies between modules.

[0037] Based on the complexity of each software module (e.g., module size, number of interfaces, business logic complexity) and the dependencies between modules, the generation tasks of each software module are dynamically allocated to intelligent agents. For example, the task allocation strategy can include two methods: static allocation and dynamic allocation. Static allocation assigns specific types of modules (e.g., software architecture modules) to designated intelligent agents according to predefined allocation rules. Dynamic allocation assigns tasks to intelligent agents with lighter current loads based on their real-time load conditions.

[0038] Manage the lifecycle of multiple smart agents using containerization technologies (such as Kubernetes and Docker). For example, idle smart agents are destroyed to release resources after a task is completed, and the running status of each smart agent (such as CPU utilization, memory usage, and task processing progress) is monitored in real time.

[0039] For example, multiple smart agents can access their respective requirement information. This requirement information, along with the corresponding software requirement documents, can be stored in a shared file system, supporting concurrent reading and ensuring consistency in the smart agents' understanding of the requirements. For example, smart agents can exchange data through predefined data interfaces (such as input.json and output.json, where the interface definition includes field names, data types, and value ranges). When any smart agent completes its preset critical task (such as generating software architecture files or backend service code), it sends a notification to other smart agents via message queues or other means to trigger the execution of subsequent dependent tasks.

[0040] For example, the execution progress of each smart agent can be monitored in real time.

[0041] This implementation method can make full use of computing resources, realize the parallel construction of multiple software modules, significantly shorten the generation cycle of the target software, and ensure the high availability and stability of the construction process.

[0042] Step S300: Generate the delivery file of the target software based on the delivery files corresponding to each of the multiple software modules.

[0043] Deliverables refer to the complete set of technical documents for the target software that can be directly deployed, run, and maintained, formed after integrating all the deliverables of the software modules. It is the final complete product of the target software.

[0044] This step involves the unified integration and verification of all deliverable files for all software modules, ultimately resulting in a complete, deployable, and runnable delivery package for the target software. This step achieves automated, integrated integration of software modules, eliminating issues such as incompatible interfaces and conflicting dependencies that arise with manual integration, thus ensuring system integrity.

[0045] The technical solution of this disclosure first parses multiple software requirement documents of the target software to be generated, extracting the requirement information corresponding to each of the multiple software modules of the target software. Then, based on the requirement information corresponding to each software module, a corresponding deliverable file is generated through a dedicated intelligent agent for each software module. Finally, all deliverable files are integrated to generate the delivery file of the target software. This solution achieves end-to-end automated generation from software requirement documents to complete delivery files, significantly improving software development efficiency, ensuring a high degree of consistency between requirements and implementation, and enhancing the standardization and scalability of the generated software.

[0046] Figure 3 This is a flowchart illustrating a method for generating a deliverable document according to an exemplary embodiment of this disclosure.

[0047] like Figure 3 As shown, in one implementation, the multiple requirement information includes first requirement information corresponding to the software architecture module and second requirement information corresponding to multiple first software modules other than the software architecture module. The first requirement information can refer to the requirement descriptions related to the system architecture parsed from the software requirement document (hereinafter referred to as the architecture requirement document) corresponding to the software architecture module. It can include the overall architecture design of the target software, file organization, naming conventions, storage rules, etc.

[0048] A software architecture module is a module in the target software that is responsible for the overall structural design. This module does not directly generate business function code, but defines the organizational specifications of the entire software project, including directory structure, file naming conventions, and the storage location of each module file.

[0049] The second requirement information refers to the requirement descriptions related to the implementation of specific functions, which are parsed from the requirement documents corresponding to each first software module. For example, the page layout and interaction methods of the front-end module; the API interface definition and data model of the back-end module; and the intent classification rules and main loop logic of the logic rules module.

[0050] Based on this, step S200, which generates deliverable files for each of the multiple software modules based on their respective requirement information and through the intelligent agents corresponding to each software module, may include the following steps: Step S210: Based on the first requirement information, generate the software architecture file corresponding to the software architecture module through the first intelligent agent corresponding to the software architecture module.

[0051] The first intelligent agent refers to an intelligent agent instance specifically assigned to handle software architecture module generation tasks. This agent possesses system design capabilities, understands overall architecture requirements, and outputs software architecture documents.

[0052] The software architecture file refers to the structured output file generated by the first intelligent agent. It defines the directory structure (such as the hierarchical relationship between directories like claude / skills / , ui / , data / , etc.), file naming conventions (such as naming front-end pages as index.html and back-end services as server.js), and file storage rules (such as which directory API interface files should be stored in and what format configuration files should follow). This file serves as the common basis for the generation of all first software modules.

[0053] This approach, based on the initial requirements information, uses a first intelligent agent to automate and standardize the generation of software architecture specifications. This generates software architecture documents that serve as the basis for the development of each initial software module, laying the foundation for standardized development and seamless integration of all modules.

[0054] Step S220: Based on the second requirement information and software architecture file corresponding to each of the multiple first software modules, generate the deliverable files corresponding to each of the multiple first software modules through the second intelligent agent corresponding to each of the multiple first software modules.

[0055] The second intelligent agent refers to an intelligent agent dedicated to each first software module. It has the ability to develop and generate code for the corresponding software module and can generate compliant deliverables based on the second requirement information and in accordance with the unified specifications of the software architecture documents.

[0056] In one example, the plurality of first software modules include at least a front-end module for providing a user interface, a back-end module for executing business logic, data access and processing interface requests, and a logic rule module for determining the processing flow and rules of the target software.

[0057] A front-end module refers to the software module in the target software responsible for user interface presentation and interaction. This module runs on the client side (such as a browser or mobile application), and its main functions may include rendering the user interface (page layout, control display), capturing user input (text input, voice commands, etc.), communicating with the back-end module (sending requests, receiving responses), and dynamically updating interface content. For example, during the generation of the front-end module, the second intelligent agent generates front-end code files such as HTML, CSS, and JavaScript based on the corresponding software requirements document (hereinafter referred to as the front-end requirements document) and software architecture file.

[0058] A backend module refers to a software module within the target software responsible for server-side business logic processing, data access management, and API request / response. This module can run on the server side, and its main functions may include receiving and parsing HTTP requests (such as POST / input, GET / output) from the frontend or other clients, and executing business logic such as data validation and computation. For example, during the generation of the backend module, the second intelligent agent can generate server-side code (such as Express.js or Spring Boot framework applications) and configuration files based on the corresponding software requirements document (hereinafter referred to as the backend requirements document).

[0059] The logic rules module refers to a software module within the target software that specifically implements artificial intelligence processing capabilities and defines software processing flows and decision rules. This module uses a document-as-code architecture to generate AI logic documentation, and the deliverable file corresponding to the logic rules module can be a SKILL document. For example, the format specification of this document can include three parts: metadata (YAML frontmatter), business logic (Markdown body), and references (references directory). This file can be directly parsed and executed by the AI ​​runtime engine. This module is used to define the execution flow of the intelligent agent (such as the main loop, intent recognition, and branch jump), decision rules (such as the conditional judgment "if the user intent is system feedback, then execute the self-evolution logic"), loop control (such as "repeatedly poll until there is new input"), and the self-evolution mechanism (dynamically updating the strategy document based on user feedback). For example, the software requirements document (hereinafter referred to as the logic requirements document) corresponding to the logic rules module is a standardized document written in natural language, whose content can include descriptions of requirements such as intent classification rules, main loop logic, and self-evolution mechanism.

[0060] For example, if the target software is an intelligent cockpit system, the logic rules module can define intent classification rules (distinguishing between "cockpit requests", "system feedback", and "irrelevant topics"), main loop logic (polling input, processing requests, and outputting results), and self-evolution mechanism (dynamically updating interaction strategies based on user feedback), etc.

[0061] Using this approach, the second intelligent agent corresponding to each first software module uses the second requirement information of its own module as the basis for functional implementation, while strictly following the specifications defined in the software architecture document, and autonomously generates the corresponding deliverable file for the first software module. This ensures that the generated file meets the business function requirements, and that the files of all software modules are consistent in terms of naming, storage location, and format, reducing the difficulty and cost of integrating the deliverable files of subsequent software modules.

[0062] The technical solution of this disclosure firstly generates a software architecture file based on a first requirement, using a first intelligent agent corresponding to each software architecture module. Then, based on the second requirement information corresponding to each of the multiple first software modules and the software architecture file, it generates deliverable files corresponding to each of the multiple first software modules using a second intelligent agent dedicated to each module. This ensures that the overall structure of the software system and the generation process of its various components are seamlessly integrated, preserving the efficiency advantages of multi-agent parallelism while guaranteeing consistency and standardization during final integration. This fundamentally avoids architecture compatibility issues during integration and reduces manual modification costs. Through refined classification of requirement information, both the software architecture module and the intelligent agent corresponding to each first software module receive dedicated requirement input, ensuring that the architecture specifications and functional implementations are highly consistent with the original requirements.

[0063] Figure 4 This is a flowchart illustrating a method for generating delivery documents provided in an exemplary embodiment of this disclosure.

[0064] like Figure 4 As shown, in one implementation, based on the foregoing embodiments, step S300: generating a delivery file for the target software based on the delivery files corresponding to each of the multiple software modules, may include the following steps: Step S310: Based on the correspondence between multiple software modules and their respective software requirement documents, determine the mapping relationship between the deliverables of each software module and the software requirement documents.

[0065] The correspondence refers to the one-to-one mapping between software modules and software requirements documents. For example, the front-end module corresponds to the front-end requirements document, the back-end module corresponds to the back-end requirements document, and the logic rules module corresponds to the logic requirements document.

[0066] A mapping relationship refers to a bidirectional association between a software module's deliverable file and the software requirements document, established based on the correspondence between software modules and software requirements documents. This mapping relationship records the software requirements document from which a specific deliverable file is generated and its exact location, as well as how the generated deliverable file can be located from a specific section of the software requirements document. The mapping relationship includes forward indexes (locating the deliverable file from a section of the software requirements document) and reverse indexes (tracing back from the deliverable file to a section of the software requirements document). For example, if the deliverable file is a code file, the mapping relationship is established by adding comments or metadata (such as " / / Generated from: docs / specs / backend-spec.md Section 4.2") to the generated code file, identifying the corresponding section location in the software requirements document for that code module.

[0067] By adopting the implementation method of this step, based on the one-to-one correspondence between software modules and software requirement documents, the mapping relationship between the deliverables corresponding to each of the multiple software modules and the software requirement documents is determined, forming a two-way binding relationship between software requirement documents and deliverables, providing a basis for building index files.

[0068] Step S320: Construct the index file corresponding to the mapping relationship.

[0069] An index file is a record file independent of code files and software requirements documents, used to centrally store and maintain all mapping relationships. The index file can be in Markdown (e.g., traceability.md), JSON, XML, or other structured formats. This file records metadata such as specification chapter paths, paths to files to be delivered, generation time, version number, and author, forming a complete mapping table for easy subsequent querying, tracing, and incremental updates.

[0070] Using the method described in this step, an index file corresponding to the mapping relationships is constructed, forming a unified, easy-to-query, and easy-to-maintain mapping index. The index file serves as a complete list of mapping relationships, facilitating rapid retrieval and parsing by the system.

[0071] Step S330: Generate the delivery file of the target software based on the delivery files and index files corresponding to each of the multiple software modules.

[0072] In this embodiment of the disclosure, the delivery documents include not only all files to be delivered (source code, configuration files, SKILL documentation, etc.), but also an index file. The index file, as part of the delivery documents, is delivered along with the code, providing support for later maintenance, change tracking, and problem localization.

[0073] For example, the delivery documents may also include the runtime environment configuration of the target software.

[0074] For example, organize the index files according to the directory structure defined in the software architecture file, ensuring that the index files are placed in a preset location (such as the docs / or traceability / directory under the project root directory).

[0075] Using this approach, the deliverables for each of the multiple software modules are incorporated into the deliverables along with the index file, forming a complete, directly deployable and runnable target software delivery file. This delivery file includes both executable code and configuration, as well as an index file for traceability and maintenance.

[0076] The technical solution of this disclosure, based on the generation of the file to be delivered, integrates the file to be delivered into a delivery file by establishing a mapping relationship, constructing an index file for traceability, and integrating the delivery process. This ensures that the target software has high traceability, maintainability, and version management capabilities while possessing functional integrity.

[0077] Figure 5 This is a flowchart illustrating a mapping relationship determination method provided by an exemplary embodiment of this disclosure.

[0078] like Figure 5 As shown, in one implementation, step S310: determining the mapping relationship between the deliverables and the software requirement documents corresponding to each of the multiple software modules based on the correspondence between the multiple software modules and their respective software requirement documents may include the following steps: Step S3110: Based on the correspondence between multiple software modules and their respective software requirement documents, add identification information to the deliverables corresponding to each of the multiple software modules.

[0079] Identification information is used to indicate the location of the requirements content on which the deliverables are based within the corresponding software requirements document. Identification information can be standardized comments or metadata added to the deliverables, and it must at least include the path identifier of the corresponding software requirements document and its location information within that document (such as chapter number, line number range, or title path).

[0080] By adopting the implementation method of this step, standardized identification information is added to the deliverables of each software module, so that the deliverables come with traceability identification (identification information), making the basis of requirements explicit, refined and standardized, providing a concrete information foundation that can be directly extracted and parsed for determining mapping relationships, and eliminating the reliance on manual sorting.

[0081] For example, when the intelligent agent generates code based on the content of a certain chapter of the software requirements document, it inserts annotation-style identification information at the corresponding position in the generated code file (such as the file header or above the function definition). This identification information records the path of the software requirements document from which the code segment originated and the specific chapter position.

[0082] Step S3120: Based on the identification information, determine the mapping relationship between the deliverable files and software requirement documents corresponding to each of the multiple software modules.

[0083] Using the implementation method of this step, the identification information added to each deliverable document is extracted. Based on this identification information, the association between the deliverable document and the corresponding software requirement document is established, forming a standardized and traceable mapping relationship.

[0084] The technical solution of this disclosure first adds identification information to each document to be delivered. Then, based on the identification information scattered in each document to be delivered, it collects and parses the information to finally determine the mapping relationship between the document to be delivered and the software requirement document, thereby realizing refined and automated traceability from the document to be delivered to the software requirement document.

[0085] Figure 6 This is a flowchart illustrating a software generation method provided in another exemplary embodiment of this disclosure.

[0086] like Figure 6 As shown, in one implementation, based on the aforementioned embodiments, after step S330: generating the delivery file of the target software based on the delivery files and index files corresponding to each of the multiple software modules, the method further includes: Step S400: When at least one software requirement document is detected to have changed, the original deliverable document corresponding to the change information in the software requirement document is determined based on the index file.

[0087] Change information refers to the specific changes made to the software requirements document. Change information can include the type of change (addition, modification, deletion), the location of the change (chapter number, line number, title path), the content before the change, and the content after the change.

[0088] Original deliverables refer to the original software modules that were generated based on the original requirements information before the software requirements document was changed, and which have a mapping relationship with the changed parts of the software requirements document.

[0089] Using this approach, when a change is detected in the software requirements document, the index file is retrieved. By parsing the mapping relationships in the index file, the original deliverable file that corresponds to the change information is accurately located, the scope of the incremental update is clarified, and the invalid processing of irrelevant files is avoided.

[0090] Step S500: Parse the change information to obtain change requirement information.

[0091] Change request information refers to the structured requirement adjustment information obtained after standardizing and parsing change information.

[0092] This step involves parsing the change information in the software requirements document, transforming the natural language descriptions of the changes into structured change requirement information, with the format consistent with the original requirements. This step standardizes and structures the change information, generating change requirement information that can be directly invoked by the intelligent agent, ensuring that incrementally generated files meet the requirements of the change requests.

[0093] Step S600: Based on the change requirement information, generate the first deliverable file through the intelligent agent that generates the original deliverable file.

[0094] The first deliverable file refers to the incremental update file generated by the intelligent agent based on the change requirement information, which is used to replace the original deliverable file and conforms to the unified specifications specified in the software architecture document.

[0095] Using the implementation method in this step, the intelligent agent that generates the original file to be delivered is invoked. Based on the changed requirement information, the intelligent agent generates an incremental update file that meets the requirements of the changed requirements and can directly replace the original file.

[0096] Step S700: Replace the original deliverable file based on the first deliverable file.

[0097] For example, the specific implementation of the replacement operation may include deleting the original file to be delivered. The first file to be delivered is then written to the original path of the original file. If an index file exists, the mapping records associated with that file in the index file are updated (e.g., updating the generation time, version number, etc.).

[0098] Using this method, the generated first deliverable file replaces the original deliverable file, achieving automated and precise file replacement. This ensures that the file structure and dependencies of the software are not affected after the replacement, and that the updated file matches the requirements of the change in requirements.

[0099] The technical solution of this disclosure, when a change is detected in at least one software requirement document, determines the original deliverable file corresponding to the change information in the software requirement document based on an index file, thereby achieving automated and precise positioning of the scope of the change's impact. Subsequently, the change information is parsed to obtain changed requirement information. Based on this information, a first deliverable file is generated by creating an intelligent proxy for the original deliverable file, and then the first deliverable file replaces the original deliverable file, ensuring the standardization and consistency between the first and original deliverable files. This solution achieves precise incremental updates of the software after requirement changes, processing only the affected original deliverable files, avoiding full reconstruction, significantly saving computing resources, and improving software iteration efficiency.

[0100] Figure 7 This is a flowchart illustrating a method for generating delivery documents provided in another exemplary embodiment of this disclosure.

[0101] like Figure 7 As shown, in one implementation, based on the aforementioned embodiments, step S300: generating a delivery file for the target software based on the delivery files corresponding to each of the multiple software modules, including the following steps: Step S340: The intelligent agents corresponding to each of the multiple software modules perform quality specification checks on the documents to be delivered generated by each module.

[0102] Quality specification inspection refers to the automated process of checking deliverable documents to verify whether they meet predefined quality standards. For example, quality specification inspection can include various types of checks, such as interface format specification checks (e.g., verifying whether the request and response formats of API interfaces conform to definitions), code style specification checks (e.g., verifying naming conventions, commenting conventions, etc.), performance metric specification checks (e.g., verifying whether response time meets requirements), and security specification checks (e.g., verifying whether input validation, output encoding, etc. meet security requirements).

[0103] Using this approach, each software module's dedicated intelligent agent performs quality control checks on the deliverables it generates. This step enables self-checking of the deliverables, with the intelligent agent that generated them performing the checks, ensuring the relevance and accuracy of the checks.

[0104] Step S350: If the quality specifications of the deliverables corresponding to each of the multiple software modules have passed the inspection, the deliverables of the target software are generated based on the multiple deliverables.

[0105] Passing all quality specification tests means that all deliverables corresponding to all software modules have passed their respective quality specification tests. Of course, the content of the quality specification tests can be set according to the actual situation of the target software, and the standards for passing the quality specification tests can also be set according to the actual situation; no specific limitations are made here.

[0106] For example, in cases of non-compliance, corresponding actions can be taken. For common problems (such as format errors, non-standard naming, etc.), automatic repair can be performed. For problems that cannot be automatically repaired, the relevant modules can be triggered to regenerate, or an error report can be generated for manual intervention.

[0107] In one feasible approach, quality specification testing can employ a tiered verification strategy: First, rapid verification is performed, including encoding format checks, syntax error detection, and structural integrity verification, to quickly eliminate obvious errors. After rapid verification passes, full verification is then performed, including interface consistency verification, functional integrity verification, performance indicator verification, and security specification verification.

[0108] This step, assuming all deliverables for all software modules have passed quality specification checks, integrates the deliverables and index files to generate the target software delivery file. This step ensures that, with quality compliance as a prerequisite, a compliant and directly deployable target software delivery file is generated. It guarantees that the final delivery file consists of all qualified deliverables, thus ensuring the stability and operability of the deliverable.

[0109] The technical solution of this disclosure embodiment uses intelligent agents corresponding to multiple software modules to perform quality specification checks on the deliverable files generated by each module. If all deliverable files pass the quality check, a delivery file for the target software is generated based on these files. This solution introduces automated quality verification into the delivery file generation process, ensuring that the final generated target software delivery file meets quality standards and can operate normally.

[0110] Figure 8 This is a flowchart illustrating a method for obtaining demand information provided in an exemplary embodiment of this disclosure.

[0111] like Figure 8 As shown, in one implementation, based on the aforementioned embodiments, step S100: parsing multiple software requirement documents of the target software to be generated to obtain the requirement information corresponding to each of the multiple software modules of the target software, including the following steps: Step S110: Determine the parsing rules corresponding to each of the multiple software requirement documents for the target software.

[0112] Parsing rules refer to standardized parsing strategies pre-defined for different software requirement documents based on their format type, structural characteristics, and module attributes. For example, parsing rules can include document structure identification rules (such as identifying chapter levels based on the number of Markdown heading levels "#", or identifying element structure based on XML tags); information extraction rules (such as matching interface definition patterns using regular expressions, or extracting software module names and responsibility descriptions using named entity recognition rules); and dependency analysis rules (such as identifying keywords like "dependency," "reference," and "call" in the document to determine dependencies between software modules). Different types of software requirement documents (such as architecture requirement documents, backend requirement documents, frontend requirement documents, and logic requirement documents) can employ different parsing rules to adapt to their respective document structures and content characteristics.

[0113] This approach involves identifying the type and format characteristics of each software requirement document before parsing it (e.g., whether it contains API interface definitions, interface layout descriptions, etc.). Based on the identification results, the most suitable parsing rule is assigned or selected for each document. This step ensures that the most suitable parsing method is matched for different types of software requirement documents, guaranteeing the accuracy and completeness of the requirement information extracted from each document and avoiding information omissions or parsing errors due to inappropriate parsing rules.

[0114] Step S120: Based on multiple parsing rules, parse the software requirement documents corresponding to each of the multiple parsing rules to obtain the requirement information corresponding to each of the multiple software modules of the target software.

[0115] By adopting the implementation method of this step, the requirement documents are structured and parsed according to the specific parsing rules corresponding to each requirement document, and the requirement information corresponding to each software module is extracted, so as to achieve standardization, completeness and accuracy of requirement information extraction.

[0116] The technical solution of this disclosure first determines the parsing rules corresponding to each of the multiple software requirement documents for the target software. Then, based on the multiple parsing rules, the corresponding software requirement documents are parsed to complete the standardized parsing of multiple types of software requirement documents, adapt to software requirement documents of different formats and modules, and realize the accurate and complete extraction of requirement information, providing a stable and reliable requirement foundation for automated software generation.

[0117] The solutions disclosed herein are not limited to the embodiments mentioned above.

[0118] Exemplary device The software generation method provided by the embodiments of this disclosure has been described above. It is understood that the software generation apparatus, in order to implement the various functions of the software generation method, may include corresponding hardware and software for implementing the hardware functions.

[0119] Those skilled in the art will readily recognize that the steps of the software generation method described in conjunction with the embodiments of this disclosure can be implemented in hardware or in a combination of software-driven hardware. Whether a function is implemented in hardware or software-driven hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0120] The beneficial technical effects corresponding to the exemplary embodiments of this device can be found in the corresponding beneficial technical effects of the exemplary method section above, and will not be repeated here.

[0121] Figure 9 This is a schematic diagram of the structure of a software generation apparatus provided in an exemplary embodiment of the present disclosure.

[0122] like Figure 9 As shown, in one embodiment, the software generation apparatus 900 includes: The parsing module 910 is used to parse multiple software requirement documents of the target software to be generated, and obtain the requirement information corresponding to each of the multiple software modules of the target software. The multiple software requirement documents correspond one-to-one with the multiple software modules. The information processing module 920 is used to generate the delivery documents corresponding to each of the multiple software modules based on the requirement information corresponding to each of the multiple software modules, through the intelligent agents corresponding to each of the multiple software modules. The delivery document determination module 930 is used to generate the delivery documents of the target software based on the delivery documents corresponding to each of the multiple software modules.

[0123] The software generation apparatus of this disclosure parses multiple software requirement documents of the target software to be generated to obtain the requirement information corresponding to each software module. Then, it generates corresponding deliverable files through intelligent agents dedicated to each software module, and finally integrates the deliverable files to generate the delivery file of the target software. This approach effectively avoids the misunderstanding of requirements due to manual parsing, the inefficiency of manual coding, and the compatibility issues of manual module integration in traditional software development. It significantly improves the automation level and overall development efficiency of software development, greatly shortens the software development cycle, and ensures a high degree of consistency between software requirements and actual implementation.

[0124] In one possible implementation, the multiple requirement information includes first requirement information corresponding to the software architecture module and second requirement information corresponding to multiple first software modules other than the software architecture module. The information processing module 920 is also used for: Based on the first requirement information, a software architecture file corresponding to the software architecture module is generated through the first intelligent agent corresponding to the software architecture module. The software architecture file is used to determine the directory structure, file naming conventions, and file storage rules. Based on the second requirement information and software architecture file corresponding to each of the multiple first software modules, a deliverable file corresponding to each of the multiple first software modules is generated through the second intelligent agent corresponding to each of the multiple first software modules.

[0125] In one possible implementation, the plurality of first software modules include at least a front-end module for providing a user interface, a back-end module for executing business logic, data access and processing interface requests, and a logic rule module for determining the processing flow and rules of the software.

[0126] In one possible implementation, the delivery document determination module 930 is further configured to: Based on the correspondence between multiple software modules and their corresponding software requirement documents, the mapping relationship between the deliverables of each software module and the software requirement documents is determined; an index file corresponding to the mapping relationship is constructed; and based on the deliverables of each software module and the index file, the deliverables of the target software are generated.

[0127] In one possible implementation, the delivery document determination module 930 is further configured to: Based on the correspondence between multiple software modules and their respective software requirement documents, identification information is added to the deliverables corresponding to each of the multiple software modules. The identification information is used to indicate the position of the requirement content on which the deliverables are based in the corresponding software requirement document. Based on the identification information, the mapping relationship between the deliverables corresponding to each of the multiple software modules and the software requirement document is determined.

[0128] In one possible implementation, the apparatus further includes: The replacement module is used to determine the original deliverable file corresponding to the change information in the software requirement document based on the index file when at least one software requirement document change is detected; parse the change information to obtain the change requirement information; generate a first deliverable file based on the change requirement information by generating an intelligent proxy for the original deliverable file; and replace the original deliverable file based on the first deliverable file.

[0129] In one possible implementation, the delivery document determination module is also used for: Each of the multiple software modules uses its own intelligent agent to perform quality specification checks on the deliverables generated by each module. If the quality specification checks on the deliverables of each of the multiple software modules are all qualified, the deliverables of the target software are generated based on the multiple deliverables.

[0130] In one possible implementation, the parsing module 910 is also used for: Determine the parsing rules corresponding to each of the multiple software requirement documents for the target software; based on the multiple parsing rules, parse the software requirement documents corresponding to each of the multiple parsing rules to obtain the requirement information corresponding to each of the multiple software modules of the target software.

[0131] Exemplary electronic devices Figure 10 A structural diagram of an electronic device provided as an exemplary embodiment of this disclosure, such as... Figure 10 As shown, the electronic device 1000 includes at least one processor 1100 and a memory 1200.

[0132] The processor 1100 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 1000 to perform desired functions.

[0133] The memory 1200 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 1100 may execute one or more computer program instructions to implement the software generation methods and / or other desired functions of the various embodiments of this disclosure described above.

[0134] In one example, the electronic device 1000 may also include an input device 1300 and an output device 1400, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0135] The input device 1300 may also include, for example, a keyboard, a mouse, etc.

[0136] The output device 1400 can output various information to the outside, including, for example, a display, a speaker, a printer, a communication network and its connected remote output devices, etc.

[0137] Of course, for the sake of simplicity, Figure 10 Only some of the components of the electronic device 1000 relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device 1000 may include any other suitable components depending on the specific application.

[0138] Exemplary computer program products and computer-readable storage media In addition to the methods and apparatus described above, embodiments of this disclosure may also provide a computer program product, including computer program instructions that, when executed by a processor, cause the processor to perform the steps of the software generation methods of the various embodiments of this disclosure described in the "Exemplary Methods" section above.

[0139] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0140] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps in the software generation methods of the various embodiments of this disclosure described in the "Exemplary Methods" section above.

[0141] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may include, but is not limited to, systems, apparatuses, or devices that are electrical, magnetic, optical, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0142] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0143] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0144] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.

[0145] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0146] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A software generation method, comprising: The multiple software requirement documents of the target software to be generated are parsed to obtain the requirement information corresponding to each of the multiple software modules of the target software, and the multiple software requirement documents correspond one-to-one with the multiple software modules; Based on the requirement information corresponding to each of the multiple software modules, the corresponding intelligent agents of each of the multiple software modules generate the delivery files corresponding to each of the multiple software modules. Based on the deliverable files corresponding to each of the multiple software modules, the delivery file of the target software is generated.

2. The software generation method according to claim 1, wherein, The multiple requirement information includes first requirement information corresponding to the software architecture module and second requirement information corresponding to multiple first software modules other than the software architecture module; The step of generating deliverable files for each of the multiple software modules based on their respective requirement information and through their respective intelligent agents includes: Based on the first requirement information, a software architecture file corresponding to the software architecture module is generated through the first intelligent agent corresponding to the software architecture module. The software architecture file is used to determine the directory structure, file naming conventions, and file storage rules. Based on the second requirement information corresponding to each of the plurality of first software modules and the software architecture file, the deliverable files corresponding to each of the plurality of first software modules are generated through the second intelligent agent corresponding to each of the plurality of first software modules.

3. The software generation method according to claim 2, wherein, The plurality of first software modules include at least a front-end module for providing a user interface, a back-end module for executing business logic, data access and processing interface requests, and a logic rule module for determining the processing flow and rules of the target software.

4. The software generation method according to claim 1, wherein, The step of generating the delivery file of the target software based on the delivery files corresponding to each of the plurality of software modules includes: Based on the correspondence between the multiple software modules and their respective software requirement documents, the mapping relationship between the deliverable files corresponding to each of the multiple software modules and the software requirement documents is determined. Construct the index file corresponding to the mapping relationship; Based on the deliverable files corresponding to each of the multiple software modules and the index file, the delivery file of the target software is generated.

5. The software generation method according to claim 4, wherein, The step of determining the mapping relationship between the deliverable files corresponding to each of the multiple software modules and their respective software requirement documents, based on the correspondence between the multiple software modules and their respective software requirement documents, includes: Based on the correspondence between the multiple software modules and their respective software requirement documents, identification information is added to the deliverables corresponding to each of the multiple software modules. The identification information is used to indicate the position of the requirement content on which the deliverables are based in the corresponding software requirement document. Based on the identification information, the mapping relationship between the deliverable files and software requirement documents corresponding to each of the multiple software modules is determined.

6. The software generation method according to claim 4, wherein, After generating the delivery file of the target software based on the delivery files corresponding to each of the plurality of software modules and the index file, the method further includes: When at least one software requirement document is detected to have changed, the original deliverable document corresponding to the change information in the software requirement document is determined based on the index file. The change information is parsed to obtain the change requirement information; Based on the change request information, a first deliverable file is generated by the intelligent agent that generates the original deliverable file; Replace the original deliverable file with the first deliverable file.

7. The software generation method according to claim 1, wherein, The step of generating the delivery file of the target software based on the delivery files corresponding to each of the plurality of software modules includes: The system uses intelligent agents corresponding to each of the multiple software modules to perform quality specification checks on the documents to be delivered generated by each module. If the quality specifications of the deliverables corresponding to each of the multiple software modules are all qualified, the deliverables of the target software are generated based on the multiple deliverables.

8. The software generation method according to claim 1, wherein, The process involves parsing multiple software requirement documents of the target software to be generated, obtaining requirement information corresponding to each of the multiple software modules of the target software, including: Determine the parsing rules corresponding to each of the multiple software requirements documents for the target software; Based on the multiple parsing rules, the software requirement documents corresponding to each of the multiple parsing rules are parsed to obtain the requirement information corresponding to each of the multiple software modules of the target software.

9. A software generation apparatus, wherein, The device includes: The parsing module is used to parse multiple software requirement documents of the target software to be generated, and obtain the requirement information corresponding to each of the multiple software modules of the target software. The multiple software requirement documents correspond one-to-one with the multiple software modules. The information processing module is used to generate the deliverable files corresponding to each of the multiple software modules based on the requirement information corresponding to each of the multiple software modules and through the intelligent agents corresponding to each of the multiple software modules. The delivery document determination module is used to generate the delivery document of the target software based on the delivery documents corresponding to each of the plurality of software modules.

10. A computer-readable storage medium storing a computer program for performing the software generation method according to any one of claims 1-8.

11. An electronic device, the electronic device comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the software generation method according to any one of claims 1-8.

Images