Requirement document generation method and device, equipment, storage medium and program product

Abstract

This application provides a method, apparatus, device, storage medium, and program product for generating requirement documents, relating to the fintech field or other related fields. The method includes: acquiring multi-source requirement information to be processed, the multi-source requirement information being business data collected based on different acquisition strategies; parsing the multi-source requirement information based on a first model to obtain a first requirement description, the first requirement description including multiple fields corresponding to business processes; determining multiple first weights based on the first requirement description, the first weights indicating the degree of correlation between the fields in the first requirement description; determining multiple sets of requirement elements in the first requirement description based on the multiple first weights, the set of requirement elements including target fields with correlation relationships among the multiple fields, and the correlation relationships between the target fields; and generating a business requirement document based on the multiple sets of requirement elements. This improves the efficiency of requirement document generation.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related fields, and in particular to a method, apparatus, device, storage medium and program product for generating requirements documents. Background Technology

[0002] In some scenarios, it is necessary to generate requirement documents based on needs. For example, in the financial sector, standardized requirement documents can be generated from collected business requirements to meet user needs.

[0003] In related technologies, requirement documents are typically generated manually. For example, when generating a requirement document for a specific business, staff need to manually collect requirement information from multiple channels such as meeting minutes and emails. Furthermore, they need to perform various processing operations, including extraction, on the collected information to obtain the required document. However, this method requires manual collection and processing of multi-source requirement information, resulting in low efficiency in requirement document generation. Summary of the Invention

[0004] This application provides a method, apparatus, device, storage medium, and program product for generating requirements documents, in order to solve the technical problem of low efficiency in generating requirements documents.

[0005] Firstly, this application provides a method for generating a requirements document, including:

[0006] Acquire multi-source demand information to be processed. Multi-source demand information is business data collected based on different collection strategies.

[0007] Based on the first model, the multi-source demand information is parsed to obtain the first demand description, which includes multiple fields corresponding to the business process.

[0008] Based on the first requirement description, multiple first weights are determined. The first weights are used to indicate the degree of correlation between the fields in the first requirement description.

[0009] Based on multiple primary weights, multiple sets of requirement elements are determined in the first requirement description. The sets of requirement elements include target fields that have relationships among multiple fields, as well as the relationships between target fields.

[0010] A business requirement document is generated based on a set of multiple requirement elements.

[0011] Secondly, this application provides a requirement document generation apparatus, comprising: an acquisition module, a parsing module, a first determination module, a second determination module, and a generation module, wherein,

[0012] The acquisition module is used to acquire multi-source demand information to be processed. The multi-source demand information is business data collected based on different acquisition strategies.

[0013] The parsing module is used to parse multi-source demand information based on the first model to obtain a first demand description, which includes multiple fields corresponding to the business process.

[0014] The first determining module is used to determine multiple first weights based on the first requirement description. The first weights are used to indicate the degree of correlation between the fields in the first requirement description.

[0015] The second determining module is used to determine multiple sets of demand elements in the first demand description based on multiple first weights. The sets of demand elements include target fields that have relationships among multiple fields, as well as the relationships between the target fields.

[0016] The generation module is used to generate business requirement documents based on a set of multiple requirement elements.

[0017] Thirdly, embodiments of this application provide a method for generating a requirements document, comprising: at least one processor and a memory; the memory storing computer-executable instructions; and at least one processor executing the computer-executable instructions stored in the memory, such that at least one processor performs the method for generating a requirements document as described in the first aspect above and any one of the first aspects.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method for generating a requirements document as described in the first aspect above and any one of the first aspects.

[0019] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method for generating requirement documents as described in the first aspect above and any one of the first aspects.

[0020] The method, apparatus, device, storage medium, and program product for generating requirement documents provided in this application, when it is necessary to generate a business requirement document, acquires multi-source requirement information to be processed. This multi-source requirement information consists of business data collected based on different acquisition strategies. Based on a first model, the multi-source requirement information is parsed to obtain a first requirement description, which includes multiple fields corresponding to the business process. Based on the first requirement description, multiple first weights are determined, which indicate the degree of correlation between the fields in the first requirement description. Based on the multiple first weights, multiple sets of requirement elements are determined in the first requirement description. These sets of requirement elements include target fields with correlation relationships among the multiple fields, and the correlation relationships between the target fields. Based on these multiple sets of requirement elements, a business requirement document is generated. In this method, electronic devices can automatically complete the structured parsing and semantic correlation analysis of requirement information based on unstructured business data acquired from multiple channels through a first model. This eliminates the need for tedious manual collection, summarization, and logical organization of multi-source information. Furthermore, by quantifying the correlation weights between fields, requirement elements can be accurately identified and extracted, automatically generating a formatted and logically clear requirement document, thus improving the automation and efficiency of requirement document generation. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0022] Figure 1 This is a schematic diagram illustrating an application scenario provided in the embodiments of this application;

[0023] Figure 2 A flowchart illustrating a method for generating a requirements document provided in an embodiment of this application;

[0024] Figure 3 A schematic diagram illustrating the process of generating a target prototype diagram as provided in the embodiments of this application;

[0025] Figure 4 A schematic diagram illustrating the verification method provided in this application embodiment;

[0026] Figure 5 A schematic diagram of a requirements document generation device provided in an embodiment of this application;

[0027] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0028] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0029] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0030] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse.

[0031] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0032] It should be noted that the method, apparatus, equipment, storage medium and program product for generating requirement documents provided in this application can be used in the field of fintech, or in any field other than fintech. The application field of the method, apparatus, equipment, storage medium and program product for generating requirement documents in this application is not limited.

[0033] To facilitate understanding, the following will be combined with... Figure 1 The application scenarios applicable to the embodiments of this application will be described.

[0034] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 This includes terminal equipment and electronic equipment.

[0035] Users can input multi-source requirement information to be processed in the terminal device. The terminal device can send the multi-source requirement information input by the user to the electronic device. The electronic device can process the multi-source requirement information. After the electronic device obtains the business requirement document corresponding to the multi-source requirement information, the electronic device sends the processing result, i.e., the business requirement document, to the terminal device.

[0036] Terminal devices can be hardware with information input and display functions, such as mobile phones, tablets, and laptops. Target applications can be set up on these devices, allowing users to input questions; for example, a target application could be a banking application. Electronic devices can be devices with on-device computing capabilities, such as servers.

[0037] In related technologies, requirement documents are typically generated manually. For example, when generating a requirement document for a specific business, staff need to manually collect requirement information from multiple channels such as meeting minutes and emails. Furthermore, they need to perform various processing operations, including extraction, on the collected information to obtain the required document. However, this method requires manual collection and processing of multi-source requirement information, resulting in low efficiency in requirement document generation.

[0038] To address the aforementioned technical issues, this application embodiment acquires multi-source business data obtained based on different acquisition strategies, parses it using a first model to generate a first requirement description containing multiple business fields, determines the association weights between each field based on this description, identifies and integrates strongly correlated target fields to form a structured set of requirement elements, and finally automatically generates a business requirement document based on multiple sets of requirement elements. In this method, the electronic device can use multi-channel, unstructured raw business data as input, automatically completing semantic parsing and structured reorganization of requirement information through the first model. It can generate standardized documents matching business intent without relying on manually preset document templates or fixed rules. Furthermore, this model can accurately identify core business entities and their relationships by quantifying the semantic associations of fields, automatically aggregating scattered requirements into multiple sets of requirement elements, adapting to the requirement structures of different business scenarios, and improving the automation and structuring level of requirement document generation. Further, the electronic device can accurately complete subsequent prototype generation based on the structured semantics indicated by the set of requirement elements, ensuring consistency between the business requirement document and the prototype, significantly enhancing the understanding and transformation capabilities of business intent, and making requirement transmission more in line with business standards and specifications. In this case, the method can adapt to the need for automated processing of multi-source, heterogeneous requirement information, and significantly improves the efficiency and accuracy of requirement document generation.

[0039] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0040] Figure 2 This is a flowchart illustrating a method for generating a requirements document according to an embodiment of this application. Please refer to [link / reference]. Figure 2 As shown, the method may include the following steps:

[0041] S201. Obtain multi-source demand information to be processed.

[0042] The execution subject of this application embodiment can be an electronic device or a requirement document generation device installed in an electronic device. The requirement document generation device can be implemented by software or by a combination of software and hardware.

[0043] Among them, multi-source demand information refers to business data collected based on different collection strategies.

[0044] Business data can be business information obtained through collection strategies and used to generate requirement documents. The form of business data can be unstructured or semi-structured data such as audio stream data, text documents, spreadsheet files, email body and attachments, and instant messaging records.

[0045] A data collection strategy can be a specific way to obtain business requirement information; that is, a data collection strategy can be a specific way to collect business data in different forms from different channels.

[0046] For example, data collection strategies can include voice collection, text collection, and email collection. Voice collection can obtain the required information by automatically recognizing and transcribing speech into text, text collection can obtain the required information by parsing document formats, and email collection can obtain the required information by extracting text from structured emails.

[0047] In some embodiments, electronic devices can automatically and in parallel acquire demand information from multiple business channels through a multi-channel acquisition mechanism, i.e., an integrated multi-channel acquisition interface, thereby achieving comprehensive access to multi-source demand information.

[0048] Specifically, for audio stream data such as voice, Automatic Speech Recognition (ASR) technology can be used for real-time transcription, converting the voice stream into parsable text data and ensuring a transcription accuracy of greater than or equal to 95%. For text documents, tables, and other data, user-uploaded PDF, Word, and other formatted documents can be read directly to extract the text content, while retaining basic formatting information such as paragraphs, headings, and lists. For email data, emails from specific business purposes or senders can be monitored, and natural language processing technology can be used to extract clear descriptions of requirements, modification suggestions, or to-do items from the email body and attachments.

[0049] This process enables automated and unified access to heterogeneous information such as voice, documents, and emails, replacing the traditional method of manually listening, reading, and recording.

[0050] In some embodiments, after collecting the raw business data, the electronic device invokes an unstructured parsing engine built on improved ParseX technology for processing. Specifically, it needs to process mixed input content (e.g., business data combining speech-to-text, document fragments, and email excerpts) to accurately decompose it into atomic elements such as text blocks, tables, and annotations, ensuring a field extraction accuracy of 99.2% and providing structured basic data support for subsequent requirement parsing.

[0051] S202. Based on the first model, the multi-source demand information is analyzed to obtain the first demand description.

[0052] The first requirement description includes multiple fields corresponding to the business process.

[0053] The first model can be a Large Language Model (LLM) for deep semantic understanding. In this embodiment, the first model can be the Qwen3-32B model.

[0054] The first requirement description can be the output information after the multi-source requirement information has been preliminarily structured and semantically organized through parsing by the first model.

[0055] Specifically, the first requirement description includes multiple fields corresponding to the business process, which may include business entities (e.g., field type, business scenario), rule constraints (e.g., constraint conditions, verification requirements), process nodes (e.g., operation steps, interaction logic), etc., which can be directly used for subsequent field association analysis and element extraction.

[0056] A business process can be the complete execution logic and operation process of a specific business. In the embodiments of this application, the goal of parsing is to identify such a process to which the requirement information belongs or is intended to be described.

[0057] In some embodiments, the electronic device may, based on a first model, parse multi-source demand information to obtain a first demand description by: acquiring a knowledge graph library; inputting multiple business rules into the first model to obtain a data-enhanced first model; and parsing multi-source demand information based on the data-enhanced first model to obtain a first demand description.

[0058] The knowledge graph library is used to store multiple business rules. That is, the knowledge graph library includes business entities (e.g., business A), entity relationships (e.g., applicability relationships), and business rules (e.g., constraints).

[0059] Business rules can be compliance requirements, operational norms, and constraints based on business scenarios, such as user authentication rules and business process specifications. They are the key basis for ensuring that the requirements analysis conforms to the actual business situation.

[0060] For example, the knowledge graph database includes business rules for various business areas. These business rules can be structured rules such as {user login, security verification, password verification} and {business processing, security verification, SMS + verification code dual verification}.

[0061] The first data-augmented model can dynamically incorporate business rules from the knowledge graph library during the LLM inference process. This retains the strong semantic understanding advantage of the original large language model while avoiding deviations from industry standards through business rule constraints.

[0062] In some embodiments, electronic devices can collect industry-standard business specifications and compliance requirements (e.g., business process documents), extract multiple business rules from them, and transform them into structured triples in the form of {entity, relation, entity} as initial data for a knowledge graph.

[0063] In some embodiments, the electronic device can use bidirectional augmentation logic of knowledge graph-LLM and LLM-knowledge graph to obtain a data-augmented first model. Specifically, the electronic device can encode the relevant business rules retrieved from the knowledge graph library into domain-specific language (DSL) statements and input them as strong constraints into the first model, so that the first model can directly call the business rules for constraint verification during semantic parsing, avoiding the generation of parsing results that do not conform to the specifications.

[0064] Furthermore, for each model parsing process, the set of effective demand elements obtained by parsing multi-source demand information through the first model (such as newly added business scenario constraints and special rule requirements) can be automatically added to the knowledge graph library after manual review and confirmation, thereby realizing the continuous iterative update of graph relationships and ensuring the comprehensiveness and timeliness of business rules.

[0065] In some embodiments, the electronic device takes atomic elements such as text blocks, tables, and annotations (i.e., multi-source demand information) split by improved ParseX technology as input data, the first model after input data enhancement, and performs deep semantic analysis on it.

[0066] Specifically, for unstructured descriptions in text blocks, core business fields (e.g., business name, login, SMS verification) are extracted, and the compliance and relevance of the fields are verified according to the rules in the knowledge graph library; for structured data in tables, they can be directly mapped to the corresponding rule constraint fields; and all identified and verified fields are organized and integrated according to the logical order of the business process, outputting the first requirement description containing three types of fields: "business entity - rule constraint - process node".

[0067] For example, if the multi-source requirement information includes the text block "Individual users apply for online account login service", the table field "Individual user - login password validity period of 90 days", and the annotation "Requires completion of mobile phone number + verification code dual verification", the data-enhanced first model will first identify the core entities "individual user" and "online account login" in the text block. By matching the business rules of {individual user, login function, online account login}, the table field "login password validity period of 90 days" will be parsed into a rule constraint field, associating it with the compliance requirements of {individual user, password validity period, 90 days}. Combined with the "mobile phone number + verification code dual verification" process field extracted from the annotation, it will be integrated to form the first requirement description.

[0068] Based on the above operations, the first requirement can be described as follows: Business entity: individual user, online account login service; Rule constraints: login password is valid for 90 days, and dual verification of mobile phone number + verification code is required; Process nodes: initiate login request, enter account and password, complete dual verification, and log in successfully.

[0069] S203. Based on the first requirement description, determine multiple first weights.

[0070] The first weight is used to indicate the degree of correlation between the fields in the first requirement description. That is, the first weight can be the semantic correlation between any two fields, and the value range is [0, 1]. The closer the value is to 1, the stronger the business logic correlation between the fields. If the semantic correlation between any two fields is greater, the first weight is greater; if the semantic correlation between any two fields is smaller, the first weight is smaller.

[0071] In some embodiments, the electronic device may determine multiple first weights based on a first requirement description by: extracting features from each field in the first requirement description to obtain multiple field features; determining the similarity between any two field features based on the multiple field features, where the similarity is used to indicate the degree of semantic matching between the fields; determining the contextual information of each field feature, and determining multiple first weights based on the multiple similarities and the contextual information of each field feature.

[0072] Field features can be vector representations of each field in the first requirement description after semantic encoding.

[0073] In some embodiments, the electronic device may invoke a text encoder based on a Contrastive Language-Image Pre-training (CLIP) model to extract features from each field in the first requirement description. This encoder can transform natural language fields into feature vectors in a high-dimensional semantic space.

[0074] Specifically, for field A and field B, corresponding feature vectors VA and VB (i.e., field features) are determined respectively, and the cosine similarity between these two vectors is calculated based on feature vectors VA and VB. In this embodiment, the preprocessed text feature vectors are usually located in the positive value region; the closer the similarity is to 1, the closer the semantics of the two fields are. For example, the similarity between the fields "personal user" and "online account login service" is 0.92, and the similarity between "personal user" and "password validity period 90 days" is 0.85.

[0075] In some embodiments, relying solely on pairwise field similarity is insufficient to accurately reflect their relevance within a specific business context. Therefore, electronic devices employ a cross-modal attention mechanism to dynamically determine the first weight. This process considers not only direct similarity between fields but also incorporates contextual information as a key computational factor. Contextual information may include other fields in the sentence containing the field, a set of relevant business concepts retrieved from the knowledge graph, etc.

[0076] Specifically, by constructing a query Q, a key K, and a value V, the feature vector of the field whose weight needs to be calculated is used as the query (Q), and the set of feature vectors of each field is used as the key (K) and value (V). Furthermore, by calculating the dot product of Q and all K values, an initial set of attention scores is obtained, reflecting the original correlation between the current field and every other element in the context. Then, by performing Softmax normalization on the initial attention scores, they are transformed into a probability distribution, which yields the first weight. This first weight not only includes the semantic similarity between fields but also incorporates global information from the entire requirement description context.

[0077] For example, in the context of "user submits login credentials through client", although "login credentials" and "password error lockout" are related in the general semantics of account security management, since the current description does not involve security policies or exception handling, the first weight calculated by the attention mechanism will be very low. Conversely, the weight between "user" and "login credentials" will be very high.

[0078] In some embodiments, the semantic similarity between fields can be used as the basic weight (e.g., weight ratio of 0.6), and the correlation coefficient corresponding to the context information can be used as the adjustment weight (e.g., weight ratio of 0.4). The context correlation coefficient is determined based on the logical correlation of the business process, the matching degree of the functional category, and the matching result of the knowledge graph rules (e.g., the correlation coefficient of fields with adjacent process order is 0.9, and the correlation coefficient of fields with the same functional category is 0.8). That is, the first weight can be calculated by the weighted summation formula (first weight = 0.6 × similarity + 0.4 × context correlation coefficient) to ensure that the first weight reflects both the semantic matching degree between fields and the actual logic of the business process.

[0079] For example, the first weight of "individual users" and "online account login service" can be calculated as follows: 0.6×0.9+0.4×0.6=0.78.

[0080] S204. Based on multiple first weights, determine multiple sets of requirement elements in the first requirement description.

[0081] The demand element set includes target fields with relationships among multiple fields, as well as the relationships between target fields.

[0082] The set of demand elements can be a structured set of demand information, usually represented in the form of a standard triple of {entity, relation, entity}.

[0083] In some embodiments, the electronic device may determine multiple sets of requirement elements in a first requirement description based on multiple first weights, including: in the first requirement description, determining fields with first weights greater than or equal to a preset threshold as target fields, and determining the association relationship between each target field; determining multiple sets of requirement elements to be completed based on multiple target fields and association relationships; and performing dialogue completion processing on the sets of requirement elements to be completed to obtain multiple sets of requirement elements.

[0084] The preset threshold is used to filter fields with strong semantic relationships. For example, if the first weight between two fields is greater than or equal to the preset threshold, it indicates that there is a strong relationship between the two fields.

[0085] The target field can be any two fields in the first requirement description whose first weight is greater than or equal to a preset threshold (e.g., 0.8), that is, the core field with strong business relevance.

[0086] The set of requirement elements to be completed can be structured business logic units that have been initially identified through target fields and their strong relationships, but may not be fully defined due to ambiguity or missing information. It is usually represented as an incomplete triple structure of {entity, relation, entity}.

[0087] In some embodiments, the electronic device traverses all fields in the first requirement description and, based on the first weight between the fields, clusters the fields whose first weight exceeds a preset threshold into a group of target fields, and then clusters the target fields according to business logic to construct an initial triplet, for example, {user login service, verification requirements, mobile phone number + verification code dual verification}.

[0088] Furthermore, due to the ambiguity or omission of information in the original requirements, the initially assembled triples may have problems such as missing entities, unclear relationships, or undefined attributes. That is, by performing integrity checks on the initial triples, triples with missing information (e.g., lack of clear relationship type), ambiguous fields (e.g., unquantified verification method), or incomplete association logic can be identified and classified as a set of requirement elements to be completed.

[0089] In some embodiments, for each set of required elements to be completed, the electronic device can use a multi-round clarification dialogue system, that is, using cue word chain technology, to design a series of coherent and guiding questions around the missing or ambiguous information points, typically completing the ambiguous required elements through 5 rounds of interaction.

[0090] For example, for the set of requirement elements to be completed {online user login service, verification limit, [empty]}, the generated prompt word chain is "What is the maximum number of verification attempts for the online user login service verification code", "If the verification fails, is it allowed to obtain the verification code again", "What is the time interval requirement for obtaining the verification code again"; and supplementary information is collected through multiple rounds of interactive dialogue, and the completion is limited to 5 rounds of interaction (for example, if it is not clear after more than 5 rounds, the industry default rule in the knowledge graph will be adopted by default).

[0091] If a user reports "Verification attempts are limited to 3 times, and you can try again after 5 minutes if you fail", the supplementary information will be integrated into the set of requirements to be completed, forming a complete triplet, namely {online user login service, verification attempts limited to 3 times, and you can try again after 5 minutes if you fail}. This completion method has a success rate of 92%, and based on the above operations, multiple complete and compliant sets of requirements can be obtained.

[0092] S205. Generate a business requirement document based on a set of multiple requirement elements.

[0093] Business requirements documents can be standardized delivery documents that conform to ISO / IEC / IEEE 29148 standards. They include three core modules: a requirements traceability matrix, quantified non-functional indicators, and complete interface definitions. They can be directly used as a unified execution basis for development, testing, and prototyping. Their core function is to transform a structured set of requirements elements into a standardized text that can be implemented in business scenarios.

[0094] In some embodiments, an electronic device may generate a business requirement document based on multiple sets of requirement elements in the following manner: obtaining a requirement document template, the configuration information of which includes business objective description, functional description, and interface definition; determining the target configuration information corresponding to each set of requirement elements based on multiple sets of requirement elements; and filling each set of requirement elements and the corresponding target configuration information into the corresponding fill positions in the requirement document template to obtain the business requirement document.

[0095] The requirements document template includes configuration information and the corresponding fill space for each field.

[0096] The requirements document template can be a pre-defined standardized document framework with built-in fixed configuration information modules and field fill positions. It is used to unify the format and content structure of requirements documents in different business scenarios, ensure the compliance and readability of the output documents, and avoid content omissions or format chaos caused by manual writing.

[0097] The target configuration information can be structured configuration content that corresponds one-to-one with the set of requirement elements. It includes three main categories: business target description, functional logic description, and interface definition. It is the core channel connecting the set of requirement elements and the document template, and can accurately map the business attributes and technical requirements of the requirement elements.

[0098] In some embodiments, the electronic device can analyze each set of requirement elements (i.e., structured triples and attributes) and, in conjunction with external knowledge sources such as knowledge graphs, determine the corresponding target configuration information in the document. Specifically, based on the entities and relationships in the triples (sets of requirement elements), it automatically traces and links to the structured business objectives, generates the corresponding row data of the requirement traceability matrix, and categorizes it as a business objective description. Furthermore, it identifies quantitative indicators (e.g., response time ≤ 200ms) from the additional attributes of the triples and categorizes them as functional logic descriptions. If the triples involve interactions between systems or modules, it automatically generates or associates specific interface definitions, including detailed information such as protocols (e.g., HTTPS), data formats (e.g., JSON), and timing, based on predefined interface rule templates, and categorizes them as interface definitions.

[0099] In some embodiments, electronic devices can accurately fill the predefined fill positions in the requirements document template with the determined target configuration information. After filling, the document rendering engine can be invoked to automatically apply the template styles (font, heading numbering, headers and footers, etc.) to generate a standardized, directly distributable business requirements document. The entire process requires no manual intervention in content arrangement and formatting, ensuring document output efficiency and standardization.

[0100] In this embodiment, multi-source business data obtained based on different acquisition strategies is acquired, and parsed using a first model to generate a first requirement description containing multiple business fields. Based on this description, the correlation weights between each field are determined, and then strongly correlated target fields are identified and integrated to form a structured set of requirement elements. Finally, a business requirement document is automatically generated based on these multiple requirement element sets. In this method, the electronic device can use multi-channel, unstructured raw business data as input. The first model automatically completes the semantic parsing and structured reorganization of requirement information, generating a standardized document matching the business intent without relying on manually preset document templates or fixed rules. Furthermore, the model can accurately identify core business entities and their relationships by quantifying the semantic association of fields, automatically aggregating scattered requirements into multiple requirement element sets. This adapts to the requirement structures of different business scenarios, improving the automation and structuring level of requirement document generation. Further, the electronic device can accurately generate subsequent prototype diagrams based on the structured semantics indicated by the requirement element sets, ensuring consistency between the business requirement document and the prototype diagram. This significantly enhances the understanding and transformation capabilities of business intent, making requirement transmission more in line with business standards and specifications. In this case, the method can adapt to the need for automated processing of multi-source, heterogeneous requirement information, and significantly improves the efficiency and accuracy of requirement document generation.

[0101] exist Figure 2 Based on the embodiments shown, the following, in conjunction with Figure 3 The process of generating a target prototype diagram after generating a business requirement document based on multiple requirement element sets is explained in detail in the above-mentioned method for generating requirement documents.

[0102] Figure 3 This is a schematic diagram illustrating the process of generating the target prototype diagram provided in this application embodiment. Please refer to... Figure 3 ,include:

[0103] S301. Based on the business requirements document, determine the first prototype diagram.

[0104] The first prototype is a visual interface for the business requirements document.

[0105] The first prototype can be an initial interface layout generated using the CLIP model based on the core functions and textual descriptions in the business requirements document. That is, the first prototype only reproduces the core functional logic and field relationships in the requirements document (e.g., the initial layout of function buttons and data display areas).

[0106] S302. Based on the preset layout rules, the first prototype image is styled to obtain the target prototype image.

[0107] Among them, the preset layout rules are used to constrain the layout design of the prototype diagram, ensuring that the content indicated by the business requirements document and the target prototype diagram is consistent.

[0108] Preset layout rules can be a set of structured rules used to guide and constrain user interface design. Preset layout rules can include: 1) Interaction logic rules, derived from business rules in knowledge graphs, used to define the behavior and state of UI elements; 2) Visual design specifications, i.e., a parameterized enterprise-level UI component library and design system, which clearly defines visual attributes such as color, font, and spacing and their usage rules; 3) Consistency mapping rules, i.e., constraints of multimodal alignment algorithms, which can ensure pixel-level semantic consistency between prototypes and documents.

[0109] The target prototype is a high-fidelity, interactive final prototype generated after systematic processing and verification according to preset layout rules. It not only meets professional design standards visually and is strictly aligned with business rules in terms of interaction logic, but also maintains a high degree of consistency with the source business requirements document, and can be directly used for design review, user testing, or development delivery.

[0110] In some embodiments, the electronic device may adopt a fusion architecture of Stable Diffusion and Figma API, taking the text description of the business requirement document as input, and establishing a pixel-level mapping between the requirement document and the prototype in the ViT feature space through CLIP guidance, ensuring that the core functional components (e.g., input boxes, login buttons) in the first prototype correspond one-to-one with the fields (e.g., account, password, login verification) in the requirement document.

[0111] Furthermore, by loading UI constraints and parameterized templates of financial design specifications from the preset layout rules, the business rules verified by the knowledge graph are transformed into UI constraints, and the component layout of the first prototype is adjusted to ensure that the UI design conforms to the business logic. In addition, by calling the parameterized templates of financial design specifications, the visual style of the first prototype is unified, including filling with compliant main colors, standardizing component sizes, unifying fonts and font sizes, and adding interface spacing specifications, so that the prototype conforms to industry visual standards.

[0112] Furthermore, the mapping effect is optimized through a multimodal alignment algorithm. Specifically, identity consistency loss (L_id) is used to ensure that the features of core elements (e.g., login button, input box) do not deviate from the requirement description, and scene consistency loss (L_scene) is used to maintain the interaction coherence between components (e.g., the associated display logic of the prompt box and the input box after input error). The influence of the two loss functions is dynamically balanced by the weight coefficients λ (λ1=0.7, λ2=0.3) to avoid the problem of style compliance but functional deviation or functional restoration but chaotic interaction.

[0113] Next, the optimized prototype data is synchronized to the visual editor via the Figma API to generate an interactive target prototype, ensuring that the target prototype is completely consistent with the functional logic and rule constraints indicated in the business requirements document, while also meeting visual specifications and interaction requirements.

[0114] In this embodiment, a first prototype image is determined based on a business requirements document, and then the first prototype image is styled according to preset layout rules to obtain a target prototype image consistent with the content of the business requirements document. The first prototype image is a visual interface of the business requirements document, and the preset layout rules constrain the layout design of the prototype image. In this method, the electronic device can automatically generate the corresponding visual interface layout based on the structured requirements elements of the business requirements document, eliminating the need for repetitive drawing and alignment operations between multiple tools, thus improving the efficiency of prototype image generation and ensuring consistency between the prototype image and the requirements description. Furthermore, based on the preset layout rules, the electronic device automatically arranges interface elements, applies styles, and adjusts interaction logic to ensure that the layout design of the prototype image conforms to human-computer interaction specifications and domain visual standards, significantly improving the semantic matching degree between the prototype image and the business requirements document. This enhances the standardization and output quality of prototype generation, while also improving the overall efficiency and accuracy of the requirements visualization process.

[0115] exist Figure 3 Based on the embodiments shown, the following, in conjunction with Figure 4 The process of verifying the first prototype image after styling it based on preset layout rules to obtain the target prototype image is explained in detail.

[0116] Figure 4 This is a schematic diagram illustrating the verification method provided in an embodiment of this application. Please refer to... Figure 4 ,include:

[0117] S401. Obtain the verification list.

[0118] The verification list includes multiple verification methods.

[0119] The verification checklist is a standardized checklist for comprehensive quality verification of business requirement documents and target prototype diagrams. It is based on nine key features for automated verification, providing a unified and actionable basis for the verification process and ensuring that the verification is thorough and unbiased.

[0120] Verification methods may include necessity verification, explicitness verification, consistency verification, integrity verification, verifiability verification, modifiability verification, traceability verification, priority verification, and stability verification.

[0121] S402. Based on multiple verification methods, the business requirement document and the target prototype diagram are verified sequentially to obtain multiple verification results.

[0122] The verification results are used to determine the degree of compliance of the business requirements document and the target prototype with each quality characteristic (necessity verification, explicitness verification, consistency verification, completeness verification, verifiability verification, modifiability verification, traceability verification, priority verification, and stability verification).

[0123] In some embodiments, electronic devices can invoke predefined ISO 29148 standard templates to perform static rule checks on the format specifications and field completeness of business requirement documents. Furthermore, based on business rules in the knowledge graph, they can verify the compliance of document content (e.g., whether it conforms to the login verification specifications of the financial industry). For target prototype diagrams, they can verify whether they follow the UI constraints and financial design specifications in the preset layout rules.

[0124] In some embodiments, electronic devices can perform dynamic reasoning verification through a rule-based self-checking engine. Specifically, business requirement documents and prototype diagrams can be input into a trained large language model for reasoning analysis. For example, it can determine whether there is a logical contradiction between the requirements "allowing anonymous users to access advanced functions" and "advanced functions require identity authentication"; or analyze whether the interaction flow of the prototype diagram is consistent with the business flow described in the document in terms of scenario. The accuracy of this dynamic reasoning reaches 92%.

[0125] S403. If any verification result is "check failed", determine that the check results of the business requirement document and the target prototype diagram are "check failed" and generate an inspection report.

[0126] The inspection report can be a structured electronic document.

[0127] In some embodiments, when any verification method returns a failure result for any check item, the electronic device needs to determine the overall check result of the business requirement document and target prototype as a failure, and automatically trigger the report generation process. That is, the generated check report lists all the failed items in detail, including their type (e.g., consistency conflict), specific problem description (e.g., the password strength hint described in the document is not found in the corresponding interface of the prototype), problem location (e.g., document chapter number, prototype page and element ID), severity, and optional remediation suggestions. Furthermore, when the check report indicates that there are problems that need to be modified in the business requirement document or target prototype, the potential impact of the above problems can be analyzed based on the pre-built requirement-element-test case association graph, and a change impact analysis report (i.e., check report) can be generated within 2.3 seconds.

[0128] In some embodiments, electronic devices can be continuously optimized through version tracking and model optimization. Specifically, by introducing a difference annotation system, that is, by adopting Git-like version control logic, the modification trajectory of each requirement item in each stage of document generation, prototype optimization and verification and rectification can be accurately located, and the modification content, modification time and operation subject can be clearly recorded, providing reliable support for version management and problem tracking.

[0129] Furthermore, by supporting editable Markdown format output, it enables bidirectional revision of configurations related to requirement documents and prototype diagrams. After manual modification and adjustment of the output content, the revision information can be automatically captured through the LoRA (Low-Rank Adaptation) adapter, triggering targeted fine-tuning of the first model. This allows the model to continuously learn the optimization logic and business preferences in the manual revisions, thereby continuously improving the accuracy of subsequent requirement analysis, document generation, and prototype matching, and achieving dynamic iterative optimization of the technical solution.

[0130] This application's embodiments can solve several technical problems. Specifically, regarding the inefficiency of unstructured information processing, it addresses the challenge of automating the parsing of unstructured inputs such as voice and email, reducing processing time from 8 hours to 30 minutes through a multimodal large model. Regarding the deficiencies in document-prototype collaboration, it overcomes the 34% disconnect rate caused by the fragmentation of traditional toolchains, achieving 100% linked updates. Regarding the lack of rule self-checking capabilities, this application fills the gap in existing solutions for business rule verification, achieving 100% coverage of regulatory clauses through knowledge graphs.

[0131] Furthermore, this application achieves comprehensive efficiency improvements and quality assurance. Specifically, in terms of efficiency, the average production cycle for a single requirement document is reduced from 4 hours to 1.2 hours, an improvement of over 70%; the synchronization time caused by requirement changes is also reduced from an average of 2 hours to 15 minutes. In terms of quality, it ensures consistency between business requirement documents and prototype diagrams, far exceeding the industry average of 66%; and the coverage rate of business rules reaches 100%, solving the blind spot problem of the average coverage rate of only 68% in the traditional model. In terms of cost optimization, the manpower input related to requirement processing is reduced by approximately 50%, and the improved requirement quality reduces the technical costs and maintenance time caused by requirement defects by 80%. Its intelligent assistance capability is reflected in its ability to automatically identify logical contradictions in requirements with an accuracy rate of no less than 92%, and it can achieve 100% compliance check coverage of regulatory provisions.

[0132] This solution significantly improves the accuracy of domain-enhanced multimodal intelligent architecture by constructing a dynamic fusion mechanism of financial knowledge graphs and large language models, reducing the illusion or error rate commonly found in general models from 28% to 7%. Furthermore, by designing a bidirectional traceability system and adopting a Git-like version control concept, it strictly binds requirement atoms to prototype components, ensuring that any modification is synchronized to all related deliverables in real time and accurately. Moreover, this method achieves an interpretable generation process by automatically attaching its decision basis and confidence score to each generated requirement point, greatly enhancing the reliability and convenience of deliverables.

[0133] In this embodiment, a checklist containing multiple verification methods is obtained. Based on this checklist, the business requirement document and the target prototype are sequentially verified. If any verification result fails, the overall check fails and an inspection report is generated. In this method, the electronic device automatically performs verification operations based on a preset checklist, eliminating the need for manual verification of the document and prototype. This not only improves the efficiency of verification work but also avoids the subjective errors of manual verification. Furthermore, by sequentially executing multi-dimensional verification methods, the electronic device can accurately locate inconsistencies between the business requirement document and the prototype. Combined with the generated inspection report, the direction for rectification can be quickly clarified, significantly improving the compliance and accuracy of the required deliverables. This effectively reduces the rework rate caused by content deviations, thereby improving the overall efficiency of business progress.

[0134] Figure 5 This is a schematic diagram of a requirements document generation apparatus provided in an embodiment of this application. Please refer to [link / reference]. Figure 5 The requirement document generation device 50 includes: an acquisition module 51, a parsing module 52, a first determination module 53, a second determination module 54, and a generation module 55, wherein...

[0135] The acquisition module 51 is used to acquire multi-source demand information to be processed. The multi-source demand information is business data collected based on different acquisition strategies.

[0136] The parsing module 52 is used to parse the multi-source demand information based on the first model to obtain a first demand description, which includes multiple fields corresponding to the business process.

[0137] The first determining module 53 is used to determine multiple first weights based on the first requirement description, wherein the first weights are used to indicate the degree of correlation between the fields in the first requirement description;

[0138] The second determining module 54 is used to determine multiple sets of demand elements in the first demand description based on multiple first weights. The sets of demand elements include target fields that have a relationship among multiple fields, and the relationship between the target fields.

[0139] The generation module 55 is used to generate business requirement documents based on a set of multiple requirement elements.

[0140] The requirement document generation device provided in this application embodiment can execute the method shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be repeated here.

[0141] In one possible implementation, the parsing module 52 is specifically used for:

[0142] Obtain the knowledge graph library, which is used to store multiple business rules;

[0143] Multiple business rules are input into the first model to obtain the data-enhanced first model;

[0144] Based on the data-enhanced first model, the multi-source demand information is analyzed to obtain the first demand description.

[0145] In one possible implementation, the first determining module 53 is specifically used for:

[0146] Feature extraction is performed on each field in the first requirement description to obtain multiple field features;

[0147] Based on multiple field features, the similarity between any two field features is determined. The similarity is used to indicate the degree of semantic matching between the fields.

[0148] Determine the contextual information of each field feature, and determine multiple first weights based on multiple similarities and the contextual information of each field feature.

[0149] In one possible implementation, the second determining module 54 is specifically used for:

[0150] In the first requirement description, fields with a first weight greater than or equal to a preset threshold are identified as target fields, and the association relationships between each target field are determined.

[0151] Based on multiple target fields and relationships, a set of multiple requirement elements to be completed was identified;

[0152] The set of requirement elements to be completed is processed through dialogue completion to obtain multiple sets of requirement elements.

[0153] In one possible implementation, the generation module 55 is specifically used for:

[0154] Obtain the requirements document template, which includes configuration information and the corresponding filler fields for each field. The configuration information includes a description of the business objectives, a description of the functions, and an interface definition.

[0155] Based on multiple sets of demand elements, determine the target configuration information corresponding to each set of demand elements;

[0156] Fill the corresponding fill spaces in the requirement document template with the set of each requirement element and the corresponding target configuration information to obtain the business requirement document.

[0157] In one possible implementation, the apparatus further includes a processing module, which is specifically used for:

[0158] Based on the business requirements document, a first prototype diagram is determined, which is a visual interface of the business requirements document.

[0159] Based on preset layout rules, the first prototype image is styled to obtain the target prototype image. The preset layout rules are used to constrain the layout design of the prototype image, and the business requirements document is consistent with the content indicated by the target prototype image.

[0160] In one possible implementation, the processing module is further configured to:

[0161] Obtain the verification list, which includes various verification methods;

[0162] Based on multiple verification methods, the business requirement document and the target prototype diagram are verified sequentially to obtain multiple verification results;

[0163] If any validation result is "failed", the validation result of the business requirements document and the target prototype diagram is determined to be "failed", and an validation report is generated.

[0164] The requirement document generation device provided in this application embodiment can execute the method shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be repeated here.

[0165] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 60 may include: a transceiver 61, a processor 62, and a memory 63.

[0166] Processor 62 executes computer execution instructions stored in memory, causing processor 62 to perform the scheme in the above embodiments. Processor 62 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0167] The memory 63 is connected to the processor 62 via the system bus and completes communication between them. The memory 23 is used to store computer program instructions.

[0168] Transceiver 61 can be used to obtain the task to be run and its configuration information.

[0169] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.

[0170] The electronic device provided in this application embodiment can be the terminal device described in the above embodiments.

[0171] This application also provides a chip for executing instructions, which is used to execute the technical solution of the requirement document generation method in the above embodiments.

[0172] This application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the technical solution of the requirement document generation method described in the above embodiments.

[0173] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When the at least one processor executes the computer program, it can implement the technical solution of the requirement document generation method in the above embodiments.

[0174] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0175] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0176] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0177] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0178] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0179] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0180] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0181] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0182] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for generating a requirements document, characterized in that, include: Obtain multi-source demand information to be processed, wherein the multi-source demand information is business data collected based on different collection strategies; Based on the first model, the multi-source demand information is parsed to obtain a first demand description, which includes multiple fields corresponding to the business process. Based on the first requirement description, multiple first weights are determined, and the first weights are used to indicate the degree of correlation between each field in the first requirement description. Based on the multiple first weights, multiple sets of demand elements are determined in the first demand description. The sets of demand elements include target fields that have a relationship among the multiple fields, and the relationship between the target fields. Based on the set of multiple requirement elements, a business requirement document is generated.

2. The method according to claim 1, characterized in that, Based on the first model, the multi-source demand information is parsed to obtain a first demand description, including: Obtain a knowledge graph library, which is used to store multiple business rules; The multiple business rules are input into the first model to obtain the data-enhanced first model. Based on the data-enhanced first model, the multi-source demand information is parsed to obtain a first demand description.

3. The method according to claim 1, characterized in that, Based on the first requirement description, several first weights are determined, including: Feature extraction is performed on each field in the first requirement description to obtain multiple field features; Based on the multiple field features, the similarity between any two field features is determined, and the similarity is used to indicate the degree of semantic matching between the fields. The contextual information of each field feature is determined, and multiple first weights are determined based on multiple similarities and the contextual information of each field feature.

4. The method according to claim 1, characterized in that, Based on the aforementioned multiple first weights, multiple sets of requirement elements are determined in the first requirement description, including: In the first requirement description, the fields whose weight is greater than or equal to a preset threshold are identified as target fields, and the association between each target field is determined. Based on multiple target fields and the aforementioned relationships, a set of multiple required elements to be completed is determined; The set of requirement elements to be completed is subjected to dialogue completion processing to obtain multiple sets of requirement elements.

5. The method according to claim 1, characterized in that, Based on the aforementioned set of multiple requirement elements, a business requirement document is generated, including: Obtain the requirements document template, which includes configuration information and fill fields for each field. The configuration information includes business objective description, function description, and interface definition. Based on the multiple sets of demand elements, determine the target configuration information corresponding to each set of demand elements; The required elements and their corresponding target configuration information are filled into the corresponding fill positions in the required document template to obtain the business requirement document.

6. The method according to claim 2, characterized in that, After generating a business requirement document based on the multiple sets of requirement elements, the method further includes: Based on the business requirements document, a first prototype diagram is determined, which is a visual interface of the business requirements document. Based on preset layout rules, the first prototype image is styled to obtain the target prototype image. The preset layout rules are used to constrain the layout design of the prototype image. The business requirements document is consistent with the content indicated by the target prototype image.

7. The method according to claim 6, characterized in that, After processing the first prototype image according to preset layout rules to obtain the target prototype image, the method further includes: Obtain the verification list, which includes multiple verification methods; Based on the aforementioned multiple verification methods, the business requirement document and the target prototype diagram are sequentially verified to obtain multiple verification results. If any verification result is "failed", the verification result of the business requirement document and the target prototype diagram is determined to be "failed", and an inspection report is generated.

8. A device for generating a requirements document, characterized in that, include: The module comprises an acquisition module, a parsing module, a first determination module, a second determination module, and a generation module, wherein, The acquisition module is used to acquire multi-source demand information to be processed, wherein the multi-source demand information is business data collected based on different acquisition strategies; The parsing module is used to parse the multi-source demand information based on the first model to obtain a first demand description, which includes multiple fields corresponding to the business process. The first determining module is used to determine multiple first weights based on the first requirement description, wherein the first weights are used to indicate the degree of correlation between each field in the first requirement description; The second determining module is used to determine, based on the plurality of first weights, a plurality of demand element sets in the first demand description, wherein the demand element sets include target fields that have a relationship among the plurality of fields, and the relationship between the target fields; The generation module is used to generate a business requirement document based on the multiple sets of requirement elements.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images