Demand analysis method, intelligent agent, electronic equipment, storage medium and program product

Abstract

The invention provides a demand analysis method, an intelligent agent, electronic equipment, a storage medium and a program product, and the method comprises the steps: inputting a to-be-analyzed business demand document into a demand function point recognition model, and obtaining a demand function point contained in the business demand document; analyzing the demand function point based on hierarchical architecture information corresponding to the demand analysis infrastructure to obtain a demand function point analysis result matched with the business demand document; and in response to determining that the demand function point analysis result passes verification, determining a demand analysis result corresponding to the business demand document based on the demand function point analysis result. The method can improve the efficiency and accuracy of demand analysis.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, specifically to the field of demand analysis technology, and in particular to a demand analysis method, intelligent agent, electronic device, readable storage medium, and computer program product. Background Technology

[0002] In the process of technology project development, project requirements analysis is a critical task. Currently, the typical approach to project requirements analysis is for the business or client side to submit a requirements document, and then the requirements analyst acts as a bridge between the technical team and the business or client side. After repeated communication, the requirements analysis is completed. This mainly relies on manual analysis and processing, which is inefficient and costly. Moreover, there is a risk that the lack of a systematic verification method may lead to the omission of important information in the analysis, affecting the accuracy of the results. Summary of the Invention

[0003] This disclosure provides a requirements analysis method, apparatus, intelligent agent, electronic device, storage medium, and program product.

[0004] In a first aspect, embodiments of this disclosure propose a requirement analysis method, comprising: inputting a business requirement document to be analyzed into a requirement function point identification model to obtain the requirement function points contained in the business requirement document; analyzing the requirement function points based on the hierarchical architecture information corresponding to the requirement analysis infrastructure to obtain the requirement function point analysis result matching the business requirement document; and, in response to determining that the requirement function point analysis result has passed verification, determining the requirement analysis result corresponding to the business requirement document based on the requirement function point analysis result.

[0005] Secondly, embodiments of this disclosure propose a requirements analysis apparatus, comprising: a processing module configured to input a business requirements document into a requirements function point recognition model to obtain the requirements function points contained in the business requirements document; an analysis module configured to analyze the requirements function points contained in the business requirements document based on the hierarchical architecture information corresponding to the requirements analysis infrastructure to obtain the requirements function point analysis results matching the business requirements document; and a determination module configured to determine the requirements analysis results corresponding to the business requirements document based on the requirements function point analysis results matching the business requirements document.

[0006] Thirdly, this disclosure proposes an intelligent agent, including an input module, a processing module, and an output module. The input module is configured to receive input information. The processing module is configured to: determine a target task based on the input information received by the input module; determine a large model based on the target task; and execute the methods mentioned in the above embodiments by calling the large model to obtain output information. The output module is configured to output the output information obtained by the processing module.

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

[0008] Fifthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions that enable a computer to implement the requirements analysis method as described in any of the implementations in the first aspect.

[0009] In a sixth aspect, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, can implement the requirements analysis method as described in any of the implementations in the first aspect.

[0010] According to the technical solution provided in this disclosure, firstly, the business requirement document is input into the requirement function point identification model to extract the requirement function points therein; then, the above requirement function points are analyzed based on the hierarchical architecture information of the requirement analysis infrastructure to obtain the requirement function point analysis results that match the business requirement document; finally, after the analysis results are verified, the requirement analysis results corresponding to the business requirement document are determined based on the requirement function point analysis results.

[0011] By using a requirement function point identification model, the analysis of business requirement documents is transformed from a time-consuming process relying on personal experience into an automated process, improving document analysis efficiency. The hierarchical architecture information of the requirement analysis infrastructure ensures the consistency of requirement function point analysis results, reducing the risk of missing or misplaced function points. Verifying the requirement function point analysis results effectively resolves errors introduced by the requirement function point identification model during the automated analysis of business requirement documents, improving the accuracy of requirement analysis.

[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0013] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is an exemplary system architecture to which this disclosure can be applied; Figure 2 A flowchart of a requirements analysis method provided in this embodiment of the disclosure; Figure 3 A flowchart of another requirement analysis method provided in this disclosure embodiment; Figure 4 A flowchart for segmenting business requirements documents is provided as an embodiment of this disclosure; Figure 5 A flowchart illustrating yet another requirement analysis method provided in this disclosure embodiment; Figure 6 This is a structural block diagram of an intelligent agent provided in an embodiment of the present disclosure; Figure 7 This is a schematic diagram of the structure of an electronic device suitable for performing a requirements analysis method, provided as an embodiment of the present disclosure. Detailed Implementation

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

[0015] This disclosure relates to the field of data processing technology, specifically to the subfield of requirements analysis technology, and is applied to complex product development scenarios such as automotive electronics and smart hardware. It is particularly suitable for scenarios that perform requirements analysis and technical document transformation on business requirements documents (such as SOR documents) based on TR technical specifications.

[0016] In the development of technology projects, requirements analysis is a crucial link connecting the business side, the client side, and the technical team. Currently, requirements analysis mainly relies on manual interpretation, classification, and organization of business requirement documents (such as SOR documents). This is not only time-consuming, labor-intensive, and costly, but also prone to problems such as omissions of functional points, inconsistent classifications, and missing analysis of important information due to differences in personnel experience or negligence. This, in turn, affects the accuracy and completeness of subsequent technical solution design. Especially in modern product development (e.g., automotive electronics, smart hardware), business requirement documents are often complex in structure, professional in content, and lengthy, making the issues of efficiency and consistency in manual processing even more prominent.

[0017] To address the aforementioned issues, this disclosure provides a demand analysis method, an intelligent agent, an electronic device, a storage medium, and a program product, aiming to solve the technical problems of high cost, low efficiency, poor consistency, and easy omissions in the prior art through intelligent and standardized technical means.

[0018] Figure 1 An exemplary system architecture 100 is shown, in which embodiments of the requirements analysis methods, smart agents, electronic devices, storage media, and program products of this disclosure can be applied.

[0019] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0020] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various applications for enabling information communication between the terminal devices 101, 102, and 103 and server 105 can be installed. These applications include requirements analysis applications, cloud storage applications, and instant messaging applications.

[0021] Terminal devices 101, 102, and 103 and server 105 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices, and can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here. When server 105 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When server 105 is software, it can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here.

[0022] Server 105 can provide various services through its built-in applications. Taking a requirements analysis application as an example, when running such an application, Server 105 can achieve the following: First, by using a built-in or invoked requirements function point identification model, it automatically analyzes the acquired business requirements document to extract multiple requirements function points, improving the efficiency of requirement function point identification and reducing the risk of missing key information due to human error. Then, based on the hierarchical architecture information corresponding to the predefined requirements analysis infrastructure, it categorizes, organizes, and structurally analyzes the extracted requirements function points, generating requirements function point analysis results. This ensures the standardization and consistency of the analysis results, resolving issues such as chaotic classification and inconsistent expression. Finally, upon receiving a confirmation and verification instruction for the analysis results, it generates the final requirements analysis results, which can be output to terminal devices or stored on the server. By introducing verification operations, it effectively controls potential errors in the automation process, ensuring the reliability of the output results.

[0023] It should be noted that, in addition to being obtained from terminal devices 101, 102, and 103 via network 104, business requirement documents can also be pre-stored locally on server 105 through various means. Therefore, when server 105 detects that this data is already stored locally (for example, by directly analyzing the locally stored business requirement documents to obtain document requirement information), it can choose to retrieve this data directly from the local storage. In this case, the exemplary system architecture 100 may not include terminal devices 101, 102, and 103 and network 104.

[0024] Since requirement analysis based on the requirement function point identification model requires significant computing resources and strong computing power, the requirement analysis methods provided in the subsequent embodiments of this disclosure are generally executed by a server 105 with strong computing power and abundant computing resources. Correspondingly, the intelligent agent is also generally located in the server 105. However, it should also be noted that when terminal devices 101, 102, and 103 also possess sufficient computing power and resources, they can also complete the aforementioned calculations performed by the server 105 through the requirement analysis application installed on them, thereby outputting the same results as the server 105. Especially when multiple terminal devices with different computing capabilities exist simultaneously, but the requirement analysis application determines that the terminal device has strong computing power and abundant remaining computing resources, the terminal device can perform the aforementioned calculations, thereby appropriately reducing the computing pressure on the server 105. Correspondingly, the intelligent agent can also be located in the terminal devices 101, 102, and 103. In this case, the exemplary system architecture 100 may also exclude the server 105 and the network 104.

[0025] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0026] Please refer to Figure 2 , Figure 2 A flowchart of a requirements analysis method provided in this disclosure embodiment, wherein process 200 includes the following steps: Step 201: Input the business requirement document to be analyzed into the requirement function point recognition model to obtain the requirement function points contained in the business requirement document.

[0027] In this embodiment, the business requirements document to be analyzed can be a System Requirements Document (SOR) used in the product development field. For example, in the field of automotive product development, the SOR document can define in detail the functional requirements, performance standards, quality requirements, quantitative indicators, and collaborative requirements of automotive parts. This document can be temporarily stored locally or uploaded to a designated cloud server through a system interface for persistent storage, for subsequent analysis and processing.

[0028] The aforementioned functional requirements include, but are not limited to: the detection range that the vehicle radar must meet, and the deployment response time that the airbags must meet; the aforementioned performance standards include, but are not limited to: the seats must be able to withstand 100,000 opening and closing cycles without failure; the aforementioned quality requirements include, but are not limited to: the tensile strength that the vehicle body steel should achieve, and the flaw detection level that the welding should achieve; the aforementioned quantitative indicators include, but are not limited to: the dimensional tolerances of the parts, the upper limit of weight, and the power parameters; the aforementioned coordination requirements include, but are not limited to: the delivery cycle, packaging specifications, and after-sales service terms.

[0029] The Requirement Function Point Recognition Model is an artificial intelligence model that can automatically analyze SOR documents. This model can be privately deployed and built based on existing artificial intelligence model architectures. It can understand and process texts with a high upper limit, such as more than 7,000 characters, and can be deeply optimized for specific technical fields. For example, through specific prompts and training processes within that field, the model can deeply understand technical language and logic, enabling it to automatically analyze input SOR documents through context awareness and semantic understanding technologies, identify and extract the requirement function points in the document.

[0030] A functional requirement point (FRP) is a discrete and independently describable unit of technical requirement. Each FRP is essentially a description of a specific technical specification, performance indicator, component requirement, or design constraint. For example, in the field of automotive electronics, FRPs might include: a cold start time of less than 3 seconds for the in-vehicle infotainment system; support for at least 8 CAN-FD bus interfaces for the autonomous driving controller; a voltage sampling accuracy of ±0.5% for the battery management system; and low-temperature (-40℃) start-up performance requirements.

[0031] It should be noted that the document format of the SOR document can be PDF, Word, PPT or Excel, etc., and there is no limitation here.

[0032] It should be noted that the aforementioned functional point recognition model can be a model with corresponding analysis and recognition capabilities obtained by training on any general model architecture. This general model architecture includes, but is not limited to, one or more combinations of models such as machine learning models, deep learning models, neural network models, large language models (LLM) for processing text data, large vision models (LVM) for processing visual data, and multimodal large models (MLM) for processing multimodal data. The specific model structures of the various general model architectures mentioned above will not be elaborated here.

[0033] It should be noted that the above description of the business requirement document, requirement function point identification model and requirement function points is merely exemplary. The business requirement document, requirement function point identification model and requirement function points protected by this application are not limited to the contents listed above. Those skilled in the art can set and plan the business requirement document, requirement function point identification model and requirement function points according to the actual situation, as long as they can achieve the technical principles of this application.

[0034] Step 202: Based on the hierarchical architecture information corresponding to the requirements analysis infrastructure, analyze the requirements functional points to obtain the requirements functional point analysis results that match the business requirements document.

[0035] In this embodiment, the requirements analysis framework is a predefined technical knowledge structure system that provides unified rules and templates for understanding and classifying requirement functional points. Hierarchical architecture information refers to the structured data representation of the requirements analysis framework, which divides the architecture into multiple levels. Each level contains a clear category name, attribute identifier, and inter-level association rules, forming a structured information system. The requirement functional point analysis results are generated after classifying, standardizing, establishing associations, and prioritizing requirement functional points based on the hierarchical architecture information.

[0036] The basic framework for requirements analysis can be a standardized architecture based on Technical Requirements (TR) specifications. This architecture pre-divides data from specific technical fields, such as automotive electronics, into multiple main chapters, including system hardware solutions, structural design solutions, and platform software solutions. Each main chapter is further subdivided into sub-chapter sections such as key component lists and system product architecture diagrams, and includes attribute identifiers such as technical specifications, functional implementation suggestions, relevance levels, and source document location information. Alternatively, the basic framework for requirements analysis can be a structured historical knowledge base. This architecture's hierarchical structure information includes, for example, main chapter names, sub-chapter names, technical specifications, recommended content, and page storage location information, stored according to a document hierarchy.

[0037] The results of the requirement function point analysis can be a structured list, with columns defined by hierarchical information such as TR chapter categories, function point names, technical specifications, function implementation suggestions, relevance levels, and source document locations. The rows represent the individual requirement function points. Alternatively, the results can be a structured document (e.g., JSON, XML) or a database record set, with each requirement function point containing a unique ID, name, technical specifications, function implementation suggestions, relevance levels, and source document locations. Finally, the results can be a knowledge graph, using function points, TR chapters, and technical terms as nodes, connected by attribute information to form a network structure.

[0038] It should be noted that the above description of the requirements analysis infrastructure, hierarchical architecture information and requirements function point analysis results is merely exemplary. The requirements analysis infrastructure, hierarchical architecture information and requirements function point analysis results protected in this application are not limited to the contents listed above. Those skilled in the art can set the requirements analysis infrastructure, hierarchical architecture information and requirements function point analysis results according to the actual situation, as long as they can achieve the technical principles of this application.

[0039] Step 203: In response to the verification of the results of the functional point analysis of the requirements, determine the requirements analysis results corresponding to the business requirements document based on the results of the functional point analysis of the requirements.

[0040] In this embodiment, the results of the functional point analysis can be verified through an interactive interface. Specifically, the results can be distributed to reviewers via the interface. Once a confirmation or correction completion instruction is received from a reviewer through the interface, the functional point analysis result is considered to have passed verification. For example, the results can be distributed to multiple reviewers, such as system engineers, software engineers, and test engineers. When all reviewers' approval comments are received through the interface, or when the approval comments reach a preset percentage (e.g., more than two-thirds), the functional point analysis result is considered to have passed verification. The interactive interface can also perform batch verification of the functional point analysis results to improve efficiency. Other batch operations can be performed, such as batch receiving, batch modification, and shortcut key operations. The functional point analysis results can also be verified according to predefined business rules, such as thresholds for the number of functional points, the completeness of key fields, and consistency comparisons with historical projects. If all rules pass verification, the functional point analysis result is considered to have passed verification. Verification can also be performed based on the confidence score output by the requirement function point identification model and the consistency score of the requirement function point analysis results. If the comprehensive score exceeds a preset threshold, it indicates that the requirement function point analysis results have passed verification. Alternatively, the requirement function point analysis results can be verified using a pre-trained verification model. This model can use historical data and TR specification features as training samples to automatically verify the input requirement function points and output a pass or fail verification result.

[0041] After confirming that the functional point analysis results have passed verification, the functional point analysis results can be organized based on preset rules or templates to obtain the functional point analysis results corresponding to the business requirement document. The functional point analysis results can be complete TR technical documents, visual reports or other deliverables in other formats (e.g., Excel spreadsheet format, Word document format, JSON data format, Markdown report, PPT presentation, etc.).

[0042] It should be noted that the above description of the verification method is merely exemplary, and the verification method protected by this application is not limited to the content listed above. Those skilled in the art can set the verification method according to the actual situation, as long as it can achieve the technical principle of this application.

[0043] By using a requirement function point identification model, the analysis of business requirement documents is transformed from a time-consuming process relying on personal experience into an automated process, improving document analysis efficiency. The hierarchical architecture information of the requirement analysis infrastructure ensures the consistency of requirement function point analysis results, reducing the risk of missing or misplaced function points. Verifying the requirement function point analysis results effectively resolves errors introduced by the requirement function point identification model during the automated analysis of business requirement documents, improving the accuracy of requirement analysis.

[0044] In some optional implementations of this disclosure, the hierarchical architecture information includes: a main chapter name, sub-chapter names, and attribute identifiers associated with the main chapter name and sub-chapter names respectively; and based on the hierarchical architecture information corresponding to the requirements analysis infrastructure, the requirements functional points contained in the business requirements document are analyzed to obtain the requirements functional point analysis results matching the business requirements document, including: classifying the requirements functional points according to the main chapter name to obtain the requirements functional point classification results corresponding to the business requirements document; assigning tags to the requirements functional points according to the main chapter name, sub-chapter name, and attribute identifiers to obtain the tag assignment results corresponding to the business requirements document; constructing the association relationship between the requirements functional points contained in the business requirements document based on the functional point classification results and the tag assignment results; and organizing the requirements functional points according to a preset structure based on the requirements functional point classification results, tag classification results, and association relationships to obtain the requirements functional point analysis results.

[0045] In this embodiment, the hierarchical structure information includes explicit category names, namely the main chapter name and the sub-chapter name, as well as attribute identifiers associated with the main chapter name and the sub-chapter name respectively.

[0046] The main chapter title refers to the top-level category of the requirements analysis infrastructure. It defines an independent and complete dimension of technical requirements analysis, which can be used to summarize technical topics or business domains. It provides a classification framework for the functional points of requirements identified from business requirements documents, such as system hardware solutions, structural design solutions, functional safety and information security solutions, manufacturing solutions, platform software solutions, electrical architecture solutions, etc.

[0047] Sub-chapter names refer to secondary categories belonging to a main chapter. They are a concretization and refinement of the technical scope of the main chapter. After a requirement or functional point is categorized into a main chapter name, the sub-chapter name is used to further clarify the specific components, documents, or technical topics involved in that requirement or functional point. For example, under the main chapter of system hardware solution, there may be sub-chapter names such as system product architecture diagram, key component list, and hardware interface definition.

[0048] The attribute identifiers associated with the main chapter name and sub-chapter name refer to a predefined set of attribute labels or fields. These attributes describe the specific characteristics and requirements of the functional points belonging to the main chapter name and / or sub-chapter name, specifying the dimensions of information that each functional point should contain. These attribute identifiers include, but are not limited to: technical specifications, functional implementation suggestions, relevance levels, and source document location information. For example, for a functional point belonging to the main chapter name "System Hardware Solution" and the sub-chapter name "Key Component List Requirement," its associated attribute identifiers may include component model, performance parameters, supplier recommendations, and compliance requirements.

[0049] The aforementioned technical specifications refer to specific quantitative or qualitative indicators characterizing the implementation standards of the required functional points, such as detection distance, processing speed, and compatible versions. The aforementioned functional implementation suggestions are based on TR knowledge base retrieval or historical requirement analysis results, adapted to the requirement analysis infrastructure, and provide targeted technical solutions for each required functional point. The aforementioned relevance level can be determined using semantic understanding algorithms, used to characterize the degree of correlation between the required functional point and hierarchical architecture information, such as highly relevant, moderately relevant, and lowly relevant. The aforementioned source document location information refers to the specific location of the original requirement content corresponding to each required functional point in the business requirement document, such as chapter, page number, etc., to facilitate traceability and verification.

[0050] The system reads the descriptions of each functional requirement regarding technical specifications, performance indicators, component requirements, or design constraints. Based on semantic understanding, it matches these descriptions with predefined main chapter names in the hierarchical architecture information to obtain the functional requirement classification results. For example, if multiple functional requirements are described as follows: vehicle-mounted LiDAR detection range ≥200m, core chip processing speed ≥2GHz, and in-vehicle infotainment system supports wireless connectivity, classifying these functional requirements according to their main chapter names would result in the following classification: functional requirements such as "vehicle-mounted LiDAR detection range ≥200m" and "core chip processing speed ≥2GHz" would be classified under the main chapter name "System Hardware Solution"; and functional requirements characterized as "in-vehicle infotainment system supports wireless connectivity" would be classified under the main chapter name "Platform Software Solution".

[0051] After completing the main chapter categorization, tags are assigned to each requirement function point based on the main chapter name, sub-chapter name, and attribute identifiers of the hierarchical structure information. For example, the tag assigned to the requirement function point characterized as "in-vehicle infotainment system supports wireless connectivity" is: Main chapter name: Platform software solution, Sub-chapter name: In-vehicle entertainment system, Attribute identifiers: ① Technical specifications: Supports wireless connectivity, ② Implementation suggestions: Adapted to ××× system, ③ Relevance level: Moderately relevant.

[0052] Based on the above classification and tag assignment results of functional requirements, semantic analysis can be used to construct the relationships between functional requirements. For example, the functional requirement "the in-vehicle infotainment system supports wireless connectivity" (its main chapter name is Platform Software Solution, and its sub-chapter name is In-vehicle Entertainment System) and the functional requirement "the in-vehicle wireless communication module supports Bluetooth" (its main chapter name is Platform Software Solution, and its sub-chapter name is Communication Module) need to work together to achieve wireless connectivity. A dependency relationship can be constructed between these functional requirements.

[0053] Based on the above classification results, tag assignment results, and relationships of the required functional points, the required functional points are organized in a structured manner according to a preset structure (e.g., a matrix template that defines table headers, grouping, and sorting rules) to obtain the analysis results of the required functional points.

[0054] By categorizing requirement function points by main chapter name, assigning tags by hierarchical structure information, and building relationships based on the function point categorization results and tag assignment results, the analysis of requirement function points becomes more standardized, improving the efficiency and accuracy of the analysis and laying the foundation for generating requirement function point analysis results.

[0055] In some optional implementations of the embodiments of this disclosure, the requirements analysis method further includes determining the correlation level between the requirement function points contained in the business requirements document and the basic function points contained in the requirements analysis infrastructure. It also includes organizing the requirement function points according to a preset structure based on the requirement function point classification results, tag classification results, and association relationships to obtain the requirement function point analysis results.

[0056] In this embodiment, the relevance level can be determined by using a semantic understanding algorithm to match and analyze the required functional points with the basic functional points included in the requirements analysis infrastructure, resulting in a rating of the degree of correlation between the two. For example, a required functional point is that the detection range of an onboard LiDAR is ≥200m. This matches the basic functional point "System Hardware Solution - Perception Module - LiDAR Parameter Requirements" in the requirements analysis infrastructure. Both focus on LiDAR performance, have the same technical scenario, and their core technical indicator is the detection range parameter. After analyzing the above content using a semantic understanding algorithm, the relevance level between this required functional point and the basic functional point can be determined to be highly correlated.

[0057] The required function point analysis results obtained from the above-mentioned classification results of required function points, tag classification results, and correlation relationships, along with the correlation level obtained from the evaluation of each required function point, can be organized according to a preset structure to obtain the required function point analysis results.

[0058] After obtaining the requirement function point analysis results based on the requirement function point classification results, tag classification results, and correlation relationships, the requirement function points can be sorted according to their relevance level under each main chapter name, placing those marked as highly relevant at the top to ensure key requirements are highlighted first. For requirement function points with the same relevance level, correlation relationships can be further combined to arrange strongly related requirement function points in adjacent positions to intuitively reflect the technical logic. Integrating all classified and sorted requirement function points generates the above requirement function point analysis results.

[0059] It should be noted that the semantic understanding algorithm mentioned above can be a model with corresponding analysis and understanding capabilities trained on any general model architecture. This general model architecture includes, but is not limited to, one or more combinations of models such as machine learning models, deep learning models, neural network models, large language models for processing text data, large visual models for processing visual data, and large multimodal models for processing multimodal data. The specific model structures of the various general model architectures mentioned above will not be elaborated here.

[0060] By determining the relevance level between required functional points and basic functional points, the importance of required functional points can be clarified, thereby improving the pertinence and efficiency of requirements analysis.

[0061] In some optional implementations of the embodiments of this disclosure, the requirements analysis method further includes determining historical requirements analysis results related to the business requirements document; inputting the historical requirements analysis results into the requirements function point identification model to obtain the historical function points contained in the historical requirements analysis results; and analyzing the requirements function points contained in the business requirements document based on the hierarchical architecture information corresponding to the requirements analysis infrastructure to obtain requirements function point analysis results matching the business requirements document, including: determining functional implementation suggestions for the requirements function points based on the hierarchical architecture information and historical function points, and obtaining requirements function point analysis results based on the functional implementation suggestions.

[0062] In this embodiment, historical requirement analysis results with reusable value can be selected from the TR knowledge base based on the application scenarios, technical fields, and core requirements of the business requirement document. During the selection process, the historical requirement analysis results should belong to the same product series or technical module as the business requirement document, and these results should have been implemented and verified to be free of technical defects. The selected historical requirement analysis results are input into the requirement function point identification model. This model can process the historical requirement analysis results through document preprocessing, semantic matching, and intelligent merging to identify historical function points and related information that conform to the requirement analysis infrastructure, such as the TR chapter to which the historical function point belongs, technical specifications, and implemented solutions.

[0063] Based on the hierarchical architecture information of the requirements analysis infrastructure, the current requirements functional points are matched with the extracted historical functional points for technical relevance. Referring to the implementation experience of historical functional points, such as technology selection, performance optimization schemes, and adaptation strategies, targeted functional implementation suggestions are generated for the current requirements functional points. These suggestions are then integrated with the technical specifications, relevance level, and source document location information of the current requirements functional points, along with the main chapter name and sub-chapter name, to obtain the requirements functional point analysis results.

[0064] By combining historical functionalities from historical requirements analysis with hierarchical architecture information, feasible functional implementation suggestions can be provided for current requirements, improving the efficiency and accuracy of requirements analysis.

[0065] Please refer to Figure 3 , Figure 3 A flowchart of another requirements analysis method provided in this disclosure embodiment, wherein process 300 includes the following steps: Step 301: Segment the business requirements document to obtain multiple document fragments.

[0066] In this embodiment, the document can be segmented according to the segmentation boundaries in the business requirements document to obtain multiple document fragments. The segmentation boundaries can include at least one of chapter boundaries and page number boundaries in the business requirements document. Chapter boundaries can include: chapter title levels, chapter numbering patterns, chapter keywords, etc. Alternatively, artificial intelligence models can be used to analyze the relationships between sentences in the business requirements document, dividing consecutive sentences revolving around the same functional requirement into a document fragment, or dividing related contexts into a document fragment. Furthermore, artificial intelligence models can be used to calculate the semantic similarity of paragraphs in the business requirements document, clustering paragraphs with similarity higher than a threshold into a document fragment.

[0067] Optionally, before splitting the business requirements document into multiple document fragments, you can also perform a format conversion, for example, converting the business requirements document from PDF format to Markdown format.

[0068] It should be noted that the above-mentioned artificial intelligence model can be a model with corresponding analysis and understanding capabilities obtained by training on any general model architecture. This general model architecture includes, but is not limited to, one or more combinations of models such as machine learning models, deep learning models, neural network models, large language models for processing text data, large visual models for processing visual data, and large multimodal models for processing multimodal data. The specific model structures of the various general model architectures mentioned above will not be elaborated here.

[0069] Step 302: Input each document fragment from multiple document fragments into the requirement function point recognition model to obtain the requirement function points contained in the document fragments.

[0070] In this embodiment, the multiple document fragments after splitting are input into the requirement function point identification model. This model can support asynchronous concurrency mechanism to preprocess multiple document fragments at the same time, such as unifying the format and cleaning up redundant information. Then, based on specific prompt words in the specific technical field, domain adaptability analysis is performed on multiple document fragments to identify the requirement function points contained in the document fragments.

[0071] Step 303: Merge the requirement function points contained in multiple document fragments to obtain the requirement function points contained in the business requirement document.

[0072] In this embodiment, functional points that differ in description but share the same core meaning across different document fragments (e.g., a vehicle-mounted LiDAR detection range ≥200m versus a LiDAR detection range requirement of ≥200m) can be identified as duplicate functional points. For these duplicate functional points, the more complete and standardized functional requirements are retained to avoid redundancy. If the technical specifications, implementation scenarios, and other attribute identifiers of the same functional requirement are scattered across multiple document fragments, semantic association analysis can be used to determine them as different attribute identifiers of the same functional requirement, and they can be merged and completed to avoid information loss. The deduplicated and completed functional requirements are then categorized and organized to obtain the functional requirements contained in the business requirement document.

[0073] By segmenting business requirement documents, the problems of semantic fragmentation and low efficiency in long document processing are solved, and the completeness and accuracy of requirement function point identification are improved.

[0074] Please refer to Figure 4 , Figure 4The flowchart for segmenting a business requirement document provided in this embodiment of the disclosure, wherein the business requirement document is segmented to obtain multiple document fragments, and process 400 may include the following steps: Step 401: Identify the segmentation boundaries of the business requirements document and determine the complete semantic blocks in the business requirements document associated with the segmentation boundaries, wherein the segmentation boundaries include at least one of chapter boundaries and document page number boundaries.

[0075] In this embodiment, the complete semantic blocks associated with the segmentation boundaries in the business requirements document can be determined by identifying segmentation boundaries such as chapter boundaries and / or page number boundaries. The aforementioned chapter boundaries are boundaries formed based on the structural logic of the business requirements document itself, such as explicit identifiers that divide chapters, like heading levels, numbering sequences, and subject keywords. The aforementioned page number boundaries are boundaries formed based on the physical page numbers of the business requirements document, such as the page number identifiers inherent in PDF, Word, and other document formats.

[0076] The complete semantic block associated with the aforementioned segmentation boundary can be the document between two segmentation boundaries. If a chapter boundary (e.g., chapter title 2.1 Powertrain Functions) is used as the segmentation boundary, the complete semantic block is the content of that chapter title and all its sub-levels, continuing until the next chapter title (e.g., chapter title 2.2 Braking System Functions) appears. If a page number boundary (e.g., page 6) is used as the segmentation boundary, and there is no chapter transition within that page number, the complete semantic block is all the content of page 6 from the top to the bottom of the document. If that page number contains a chapter boundary, the chapter boundary takes precedence to avoid cross-chapter splitting.

[0077] It should be noted that the embodiments of this disclosure do not limit the implementation method of identifying the segmentation boundaries and the complete semantic blocks associated with the segmentation boundaries in the business requirement document. For example, the business requirement document can be input into a multimodal large model, and the segmentation boundaries and the complete semantic blocks associated with the segmentation boundaries can be obtained through the multimodal large model.

[0078] Step 402: Based on the segmentation boundaries and the complete semantic blocks associated with the segmentation boundaries, the business requirement document is segmented into multiple document fragments.

[0079] After identifying the segmentation boundaries of the business requirement document and the complete semantic blocks associated with the segmentation boundaries, the business requirement document can be segmented according to the identified segmentation boundaries and the complete semantic blocks associated with the segmentation boundaries to obtain multiple document fragments of the business requirement document, where each document fragment is a complete semantic block.

[0080] By identifying the segmentation boundaries and the complete semantic blocks associated with the segmentation boundaries, the semantics of the segmented document fragments can be made coherent, reducing information omissions and improving the accuracy and efficiency of extracting subsequent functional requirements.

[0081] In some optional implementations of the embodiments of this disclosure, the requirement function point analysis result includes source text location information corresponding to the requirement function points contained in the business requirement document, wherein the source text location information is used to indicate the location of the requirement content information corresponding to the requirement function points contained in the business requirement document in the business requirement document.

[0082] In this embodiment, the source text location information refers to the specific location of the original requirement content corresponding to each requirement function point in the business requirement document. For example, the requirement function point identified from the business requirement document is "vehicle-mounted LiDAR detection distance ≥ 200m", and its corresponding source text location information is "Chapter 4 - Perception System Technical Requirements, Section 4.2 - LiDAR Parameters, Clause 3 - Page 18 in the SOR document".

[0083] By using the source document location information, we can clearly identify the specific location of the original requirement corresponding to the functional point in the business requirement document, which facilitates the subsequent tracing, verification and validation of the functional point and improves the credibility of the requirement analysis results.

[0084] In some optional implementations of the embodiments of this disclosure, the output format of the requirement function point analysis results includes at least one of the following: table format, JSON data format, lightweight markup language format, and presentation format.

[0085] In this embodiment, the output formats of the functional point analysis results include, but are not limited to: Excel spreadsheet format, JSON data format, Markdown report format (i.e., lightweight markup language format), and PowerPoint presentation format. Excel spreadsheet format can be used as the primary output format, facilitating review and batch processing; this format supports functions such as filtering, sorting, and statistics. JSON data format can be used for data exchange and interface calls between systems, maintaining data structure and programmability. Markdown report format provides a highly readable document format, facilitating technical review and version control. PowerPoint presentation format can automatically generate visual technical presentation schemes through TR knowledge base retrieval and template matching.

[0086] Taking the output format of the functional requirement analysis results as an Excel spreadsheet as an example: Several functional requirements identified from the business requirement document are: vehicle-mounted LiDAR detection distance ≥200m, core chip processing speed ≥2GHz, and in-vehicle infotainment system supporting wireless connectivity, etc. Based on the hierarchical architecture information corresponding to the basic architecture of the requirement analysis, the above functional requirements are analyzed, and the results are shown in Table 1. Table 1. Example of Requirement Function Point Analysis Results

[0087] By providing multiple output formats, the results of requirement function point analysis can be adapted to various usage scenarios, solving the problem of insufficient adaptability of a single format and improving the efficiency of using the results of requirement function point analysis.

[0088] For a deeper understanding, please refer to Figure 5 , Figure 5 A flowchart of another requirements analysis method provided in this disclosure embodiment, wherein process 500 includes the following steps: Step 501: Obtain SOR requirements and suggestions. This involves privately deploying and building a requirement function point identification model using specific prompts and training processes within the automotive electronics field. This enables the model to deeply understand the technical language and logic in the SOR document, thereby identifying and extracting the requirement function points from the SOR document.

[0089] Step 502: Obtain the TR knowledge base, which stores historical TR documents corresponding to the SOR document, to provide suggestions on the implementation of the corresponding functions of the SOR document.

[0090] Step 503: Obtain the TR architecture, that is, obtain the basic framework for requirements analysis. The hierarchical architecture information corresponding to this architecture can pre-divide the data in the field of automotive electronics into multiple main chapters such as system hardware solutions, structural design solutions, and platform software solutions. Each main chapter is further subdivided into sub-chapter chapters such as key component lists and system product architecture diagrams, and specifies attribute identifiers including technical specifications, functional implementation suggestions, relevance levels, and source document location information.

[0091] Step 504: Based on the TR knowledge base and TR architecture, analyze the functional requirements to obtain the analysis results matching the SOR document. Specifically, read the descriptions of each functional requirement regarding technical specifications, performance indicators, component requirements, or design constraints, and match them with the predefined main chapter names in the hierarchical architecture information corresponding to the TR architecture based on semantic understanding to obtain the functional requirement classification results. After completing the main chapter classification, assign tags to each functional requirement based on the main chapter name, sub-chapter name, and attribute identifier of the hierarchical architecture information. Based on the above functional requirement classification results and tag assignment results, construct the association relationship between functional requirements through semantic analysis. At the same time, after matching and analyzing the functional requirements with the basic functional points contained in the TR architecture using a semantic understanding algorithm, obtain the rating result of the degree of correlation between the two, i.e., the relevance level. Based on the application scenarios, technical fields, and core requirements of the SOR document, reusable historical requirement analysis results are selected from the TR knowledge base and input into the requirement function point identification model. This model processes the historical requirement analysis results through document preprocessing, semantic matching, and intelligent merging to identify historical function points and related information that conform to the TR architecture. Based on the hierarchical architecture information of the TR architecture, the current requirement function points are technically matched with the extracted historical function points. Referring to the implementation experience of historical function points, targeted function implementation suggestions are generated for the current requirement function points.

[0092] Step 505: Summarize and organize the main chapter name, sub-chapter name, relevance level, technical specifications, functional implementation suggestions, and the specific location of the required functional points in the SOR document (i.e., the source document location information) obtained in Step 504 to obtain the required functional point analysis results that match the SOR document.

[0093] Step 506: Verify the functional point analysis results obtained in Step 505 using multiple methods.

[0094] Step 507: After confirming the verification of the requirement function point analysis results through step 506, the results can be organized based on preset rules or templates to obtain the TR technical document corresponding to the SOR document, i.e., the requirement analysis results.

[0095] This disclosure also provides an intelligent agent. For example... Figure 6As shown, the intelligent agent 600 includes an input module 601, a processing module 602, and an output module 603. The input module 601 is configured to receive input information. The processing module 602 is configured to: determine a target task based on the input information received by the input module 601; determine a large model based on the target task; and execute the methods mentioned in the above embodiments by calling the large model to obtain output information. The output module 603 is configured to output the output information obtained by the processing module 602.

[0096] In the embodiments of this disclosure, the large model described above can be used to call the requirement function point identification model, semantic understanding algorithm and verification model mentioned in the above embodiments, and use the requirement function point identification model, semantic understanding algorithm and verification model to execute the schemes related to identifying requirement function points, the schemes related to determining relevance level and the schemes related to verifying function requirement points mentioned in the above embodiments, so as to obtain the corresponding requirement function points, relevance level and verification results, etc., which will not be elaborated here.

[0097] According to embodiments of this disclosure, this disclosure also provides an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the requirements analysis method described in any of the above embodiments when executed.

[0098] According to embodiments of this disclosure, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions that enable a computer to implement the requirements analysis method described in any of the above embodiments when executed.

[0099] For example, the computer instructions corresponding to a requirement analysis method in this embodiment can be stored on a storage medium such as an optical disc, hard disk, or USB flash drive. When the computer instructions corresponding to a requirement analysis method in the storage medium are read or executed by a computer, the requirement analysis method as described in any of the above embodiments can be implemented.

[0100] According to embodiments of this disclosure, this disclosure also provides a computer program product including a computer program that, when executed by a processor, can implement the requirements analysis method described in any of the above embodiments.

[0101] Figure 7A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device 700 proposed in the embodiments of the present disclosure includes a processor 701 and a memory 702 storing an executable computer program. The processor 701, when executing the executable computer program stored in the memory 702, implements the requirements analysis method and knowledge base construction method provided in the embodiments of the present disclosure.

[0102] In some optional implementations of the embodiments of this disclosure, the electronic device 700 may further include a communication interface 703 and a bus 704 for connecting the processor 701, the memory 702 and the communication interface 703.

[0103] In some optional implementations of the embodiments of this disclosure, bus 704 is used to connect communication interface 703, processor 701 and memory 702 to realize mutual communication between these devices.

[0104] In some optional implementations of the embodiments of this disclosure, the processor 701 may be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that, for different devices, the electronic device used to implement the function of the processor 701 may also be other, and the embodiments of this disclosure do not specifically limit it.

[0105] The aforementioned memory 702 is used to store executable computer programs and data. The executable computer program includes computer operation instructions. Memory 702 may include high-speed RAM and may also include non-volatile memory, such as at least two disk drives. In practical applications, the aforementioned memory 702 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provides executable computer programs and data to the processor.

[0106] Furthermore, the functional modules in this embodiment can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional module.

[0107] If the integrated units described above are implemented as software functional modules and not sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure embodiment, 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 storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the method of this disclosure embodiment. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0108] According to the technical solution of this disclosure, by analyzing business requirement documents, accurate business requirement information can be obtained. Relying on a target knowledge base that stores technical information according to a hierarchical document structure, target fragments are matched and target technical documents are generated based on search keywords and search dimensions, improving the efficiency and accuracy of requirement analysis. Furthermore, by structurally splitting historical technical documents into knowledge fragments and storing technical information hierarchically, scattered historical data becomes organized and easily searchable. This allows subsequent matching processes to directly locate target fragments without having to peruse the entire document, reducing the cost of searching and filtering. Simultaneously, it ensures the standardization and consistency of knowledge fragments and solves the problems of low utilization and inconvenient access to traditional historical technical data.

[0109] It should be understood that if this disclosure references any user data and personal information (including but not limited to device information, behavioral data, location information, etc.) and before applying the technical solutions described in the embodiments of this disclosure, the relevant products or services should comply with the laws and regulations concerning the protection of user data and personal information, strictly process users' personal information and data in accordance with the provisions of applicable laws and regulations throughout the entire data processing lifecycle, follow the principles of legality, legitimacy, necessity, good faith, openness, and transparency, and adopt reasonable privacy design schemes and technical measures to ensure the security of user data and personal information, protect users' legitimate rights and interests, and prevent the risks of leakage, theft, or tampering of user data and personal information.

[0110] Specifically, the company must publish and display its privacy policy in a prominent position on the user interface, clearly informing users of the types, purposes, uses, and methods of processing personal information, as well as other matters that should be disclosed as required by laws and regulations; obtain users' prior informed consent or explicit authorization regarding data processing through user-initiated interaction (such as confirmation pop-ups); process or store user data securely within the legally required timeframe; adopt a series of security technologies and management measures, including but not limited to data encryption and access control; share and transfer user data within the scope permitted by law and in a legally required manner; and process user rights, including the rights to query, access, correct, delete, withdraw authorization and consent, cancel registration, and obtain copies of personal information, within the legally required timeframe.

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

[0112] It should also be understood that expressions such as "comprising," "including," "having," "containing," and / or "comprising" are open-ended rather than closed-ended expressions in this disclosure, indicating the presence of the stated features, elements, and / or components, but not excluding the presence of one or more other features, elements, components, and / or combinations thereof. Furthermore, when expressions such as "at least one of..." appear after a list of listed features, they modify the entire list of features, not just individual elements in the list. Additionally, when describing embodiments of this disclosure, the word "may" is used to mean "one or more embodiments of this disclosure." And the term "exemplary" is intended to refer to an example or illustration.

[0113] Unless otherwise specified, all terms used herein (including engineering and technical terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It should also be understood that, unless expressly stated in this disclosure, terms as defined in common dictionaries shall be interpreted as having the meaning consistent with their meaning in the context of the relevant art, and not as having an idealized or overly formalized meaning.

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

Claims

1. A requirement analysis method, comprising: inputting a business requirement document to be analyzed into a requirement function point identification model to obtain requirement function points contained in the business requirement document; analyzing the requirement function points based on hierarchical architecture information corresponding to a requirement analysis infrastructure to obtain a requirement function point analysis result matched with the business requirement document; in response to determining that the requirement function point analysis result passes verification, determining a requirement analysis result corresponding to the business requirement document based on the requirement function point analysis result.

2. The method of claim 1, wherein, the hierarchical architecture information comprises: main chapter names, sub-chapter names, and attribute identifiers respectively associated with the main chapter names and the sub-chapter names; and the analyzing the requirement function points contained in the business requirement document based on the hierarchical architecture information corresponding to the requirement analysis infrastructure to obtain the requirement function point analysis result matched with the business requirement document comprises: classifying the requirement function points according to the main chapter names to obtain a requirement function point classification result corresponding to the business requirement document; allocating tags to the requirement function points according to the main chapter names, the sub-chapter names, and the attribute identifiers to obtain a tag allocation result corresponding to the business requirement document; based on the function point classification result and the tag allocation result, constructing an association relationship between the requirement function points contained in the business requirement document; based on the requirement function point classification result, the tag classification result, and the association relationship, arranging the requirement function points according to a preset structure to obtain the requirement function point analysis result.

3. The method of claim 2, wherein, The method further comprises: determining a correlation level between the requirement function points contained in the business requirement document and the basic function points contained in the requirement analysis infrastructure; and based on the requirement function point classification result, the tag classification result, and the association relationship, arranging the requirement function points according to a preset structure to obtain the requirement function point analysis result. The method further comprises:

4. The method of claim 1, wherein, determining a historical requirement analysis result related to the business requirement document; inputting the historical requirement analysis result into the requirement function point identification model to obtain historical function points contained in the historical requirement analysis result; and based on the hierarchical architecture information and the historical function points, determining a function implementation suggestion for the requirement function points, and obtaining the requirement function point analysis result based on the function implementation suggestion. The inputting the business requirement document into the requirement function point identification model to obtain the requirement function points contained in the business requirement document comprises: segmenting the business requirement document to obtain a plurality of document segments; 5. The method of claim 1, wherein, ​ ​ inputting each document shard in the plurality of document shards into the requirement function point identification model to obtain a requirement function point contained in the document shard; merging the requirement function points contained in the plurality of document shards to obtain a requirement function point contained in the business requirement document.

6. The method of claim 5, wherein, The splitting the business requirement document to obtain the plurality of document shards comprises: identifying a split boundary of the business requirement document and determining a complete semantic block associated with the split boundary in the business requirement document, wherein the split boundary comprises at least one of a chapter boundary and a document page boundary; splitting the business requirement document into the plurality of document shards based on the split boundary and the complete semantic block associated with the split boundary.

7. The method of claim 1, wherein, The requirement function point analysis result comprises source text position information corresponding to the requirement function point contained in the business requirement document, wherein the source text position information is used to indicate a position of requirement content information corresponding to the requirement function point contained in the business requirement document in the business requirement document.

8. The method of any one of claims 1 to 7, wherein, The output format of the requirement function point analysis result comprises at least one of the following: a table format, a JSON data format, a lightweight markup language format, and a presentation format. 9.An intelligent agent, comprising: an input module configured to receive input information; a processing module configured to determine a target task based on the input information received by the input module, determine a large model based on the target task, execute the method of any one of claims 1-8 by invoking the large model, and obtain output information; an output module configured to output the output information obtained by the processing module. 10.An electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the requirement analysis method of any one of claims 1-8. 11.A non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the requirement analysis method of any one of claims 1-8. 12.A computer program product comprising a computer program, wherein the computer program is executed by a processor to implement the steps of the requirement analysis method according to any one of claims 1-8.

Images