A demand workload evaluation method, device, equipment and medium

Abstract

This invention relates to the field of artificial intelligence technology and discloses a method, apparatus, device, and medium for evaluating software development workload. The method includes: responding to a received requirements document by calling a pre-built standardized business knowledge index system to parse the requirements document and generate structured requirements data; based on the structured requirements data, performing task decomposition and code modification point analysis to generate initial code modification point data; iteratively optimizing the initial code modification point data until it meets preset acceptance criteria to obtain final code modification point data; and evaluating workload based on the final code modification point data and preset multi-dimensional evaluation factors to generate a workload evaluation result. This invention can be applied to fintech and healthcare scenarios, achieving the technical effect of accurately and efficiently evaluating software development workload.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence technology and natural language processing technology, and in particular to a method, apparatus, device and medium for assessing workload requirements. Background Technology

[0002] In the field of software development, accurate assessment of requirements workload is a core aspect of project management and cost control. Its complexity lies in the fact that requirements documents often contain a large amount of unstructured information, and the actual development process involves the intertwined influence of multiple dimensions such as business logic, code dependencies, and technology stack.

[0003] Currently, mainstream assessment methods mainly rely on two paths: one is manual estimation by project managers or technical leads based on their personal experience, and the other is the introduction of traditional measurement models such as function point analysis or lines of code estimation. However, manual estimation is highly dependent on individual knowledge and judgment; differences in understanding of the same requirement among different assessors often lead to significant discrepancies in results, and repeated communication and review consume a lot of time. While traditional measurement models attempt to quantify, their application still requires manual analysis of requirements and identification of functional boundaries, and they cannot effectively utilize tacit knowledge accumulated from past projects, resulting in a lack of reusable standardized basis for the assessment process.

[0004] Furthermore, the aforementioned issues are particularly pronounced in industries with stringent requirements for software reliability and development efficiency, such as fintech and healthcare. For example, the compliance requirements of financial transaction systems or the data flow logic of medical image analysis systems amplify the subjective flaws and time-consuming nature of manual assessments. Due to the lack of a unified knowledge carrier to record and invoke key contextual information such as business rules and module dependencies, assessors often have to spend considerable effort filling in missing details, and experience from past cases is difficult to transfer across teams. Summary of the Invention

[0005] The present invention provides a method, apparatus, device and medium for evaluating the workload of software development requirements, in order to solve the technical problem of: how to provide a solution that can accurately and efficiently evaluate the workload of software development requirements.

[0006] Firstly, a method for assessing the workload of requirements is provided, including: In response to receiving a requirement document, the pre-built standardized business knowledge index system is invoked to parse the requirement document and generate structured requirement data; Based on the structured requirement data, task breakdown and code change point analysis are performed to generate initial code change point data; The initial code change point data is iteratively optimized until it meets the preset acceptance criteria, thus obtaining the final code change point data. Based on the final code change data and preset multi-dimensional evaluation factors, workload assessment is performed, and workload assessment results are generated.

[0007] Secondly, a demand workload assessment device is provided, comprising: The parsing unit is used to respond to the received requirement document by calling a pre-built standardized business knowledge index system to parse the requirement document and generate structured requirement data. The analysis unit is used to perform task breakdown and code change point analysis based on the structured requirement data, and generate initial code change point data; An optimization unit is used to iteratively optimize the initial code change point data until the initial code change point data meets the preset acceptance criteria, thereby obtaining the final code change point data. The evaluation unit is used to evaluate the workload based on the final code modification data and preset multi-dimensional evaluation factors, and generate the workload evaluation results.

[0008] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described workload assessment method.

[0009] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-mentioned workload assessment method.

[0010] In the aforementioned solution implemented by the requirement workload assessment method, apparatus, computer equipment, and storage medium, upon receiving a requirement document, a pre-built standardized business knowledge index system is invoked for parsing, generating structured requirement data. This transforms unstructured requirements into machine-processable structured information, thus solving the problem of weak assessment foundation caused by missing requirement information. Based on the structured requirement data, task decomposition and code change point analysis are performed to generate initial code change point data, refining the requirements into quantifiable change points, thus changing the traditional coarse-grained estimation method. By iteratively optimizing the initial code change point data until it meets the preset acceptance criteria, the final code change point data is obtained, ensuring the consistency between the assessment basis and expected requirements, and avoiding invalid estimations due to misunderstandings of requirements. Based on the final code change point data and preset multi-dimensional assessment factors, workload assessment is performed to generate workload assessment results. This allows for comprehensive multi-dimensional information quantification, reducing the bias of single-dimensional estimation, thereby providing a solution for accurate and efficient assessment of software development requirement workload. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of an application environment for a requirement workload assessment method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a method for assessing workload requirements according to an embodiment of the present invention; Figure 3 yes Figure 2 A flowchart illustrating a specific implementation method of step S1; Figure 4 yes Figure 2 A flowchart illustrating a specific implementation method of step S2; Figure 5 yes Figure 2 A flowchart illustrating a specific implementation method of step S3; Figure 6 yes Figure 2 A flowchart illustrating a specific implementation of step S4; Figure 7 This is a schematic diagram of a demand workload assessment device according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 9 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] The requirement workload assessment method provided in this embodiment of the invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. Specifically, the client sends a requirement document to be evaluated to the server; the server receives the requirement document, calls a pre-built standardized business knowledge index system to parse the requirement document, and generates structured requirement data; based on the structured requirement data, the server performs task decomposition and code change point analysis to generate initial code change point data; the server iteratively optimizes the initial code change point data until it meets preset acceptance criteria, obtaining final code change point data; based on the final code change point data and preset multi-dimensional evaluation factors, the server performs workload evaluation and generates workload evaluation results; finally, the server feeds back the workload evaluation results to the client. In this invention, for the requirement workload evaluation scenario in the software development field, a standardized business knowledge index system and AI technology can be used to effectively replace the traditional manual experience estimation mode through automated parsing, task decomposition, code location, iterative optimization, and multi-dimensional evaluation, greatly improving the accuracy and efficiency of the evaluation and reducing project risks. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will now be described in detail through specific embodiments.

[0015] Please see Figure 2 , Figure 2 This is a flowchart illustrating a requirement workload assessment method provided in an embodiment of the present invention. This method automates and intelligently processes the process from requirement documents to workload assessment by constructing and using a standardized business knowledge index. Specifically, the method includes the following steps S1 to S4: S1, in response to receiving the requirement document, invokes a pre-built standardized business knowledge index system to parse the requirement document and generate structured requirement data.

[0016] In practical implementation, the first step is to construct a standardized business knowledge index system. This step provides a unified and reusable knowledge foundation for all subsequent analysis steps. Specifically, front-end and back-end business knowledge is systematically mined from the company's historical project documents, technical specifications, code repositories, and the experience of business experts. Front-end business knowledge includes user interface interaction logic, page flow rules, and front-end component dependencies; back-end business knowledge includes business rules, data models, interface definitions, and module dependencies, etc., which are not specifically limited in this invention. Furthermore, based on the mined front-end and back-end business knowledge, a multi-dimensional business knowledge index is constructed. This multi-dimensional business knowledge index supports rapid retrieval and positioning by multiple dimensions such as business domain, functional module, and technology stack. For example, a business rule about "e-commerce order payment" can be accurately located through combinations of multiple dimensions such as "business domain - e-commerce," "functional module - payment," and "technology stack - Java." Furthermore, the system collects and structurally stores development records, problems, and solutions from past projects, forming a historical case library as a basis for assessing complexity and risk. Furthermore, the multi-dimensional business knowledge index and historical cases are integrated to form a unified, machine-accessible, standardized business knowledge index system, which is essentially an enterprise-level, structured knowledge graph.

[0017] Furthermore, the system receives requirement documents and generates structured requirement data. When a user inputs a requirement document, the system receives it. Then, it uses a pre-built standardized business knowledge index system to intelligently parse the requirement document. This parsing process includes: using natural language processing technology to identify preset key information from the requirement document, including business scenarios, functionalities, data objects, and operational processes. For example, from a description, it identifies "user submits an order" as a functionality, and "order object" and "product object" as data objects. Further, based on the identified key information and the standardized business knowledge index system, the system automatically completes the missing contextual information in the requirement document, including a complete description of the business scenario, the module boundaries to which the function belongs, and the flow of data between different modules in the system. For example, if the requirement document only mentions "user places an order," but the knowledge index reveals that the "order placement" operation usually also involves the "payment" and "inventory" modules, the system will automatically complete these related modules and their interactions as contextual information. Finally, the identified key information and the completed contextual information are integrated to generate a structured, machine-readable requirement data. This data is typically output in a standardized format such as JSON or XML, clearly describing the business logic of the requirements, the data entities involved, module boundaries, and data flow paths.

[0018] In some preferred embodiments, see Figure 3The step of calling a pre-built standardized business knowledge index system to parse the requirement document and generate structured requirement data includes steps S11 to S13: S11, Identify preset key information from the requirements document; S12, Based on the key information and the standardized business knowledge index system, automatically complete the missing context information in the requirement document; S13, the identified key information is fused with the completed context information to generate the structured requirement data.

[0019] In practice, the first step is to identify pre-defined key information from the requirements document. The purpose of this step is to extract structured key elements from the original unstructured requirements document. This key information includes business scenarios, functionalities, data objects, and operational processes, which are not specifically limited in this invention. For example, using a pre-trained named entity recognition model, from a requirement text "A user initiates a payment; the system needs to verify the account balance. If the balance is sufficient, the balance is deducted and a payment record is generated," the system can extract "payment" as a functionality, "user," "account," and "balance" as data objects, and "verify," "deduct," and "generate" as operational processes. This information forms the smallest atomic unit for constructing the business model.

[0020] Furthermore, based on key information and a standardized business knowledge index system, the system automatically completes the missing contextual information in the requirements document. The purpose of this step is to make tacit knowledge explicit. This contextual information includes business scenarios, module boundaries, and data flow. For example, if the requirements document only mentions "user placing an order," but the knowledge index reveals that the "order placement" operation usually also involves the "payment" and "inventory" modules, the system will automatically complete the information by including "payment" and "inventory" as relevant module boundaries. Simultaneously, based on the "order" data model defined in the knowledge index, the system automatically completes the complete path of "order data" flowing from the "front-end application" to the "back-end order service" and then to the "order database."

[0021] Furthermore, the identified key information is fused with the supplemented contextual information to generate structured requirement data. The purpose of this step is to output a complete, machine-readable structured requirement data set. This data is output in a standardized format such as JSON or XML, clearly describing the business logic of the requirement, the data objects involved, module boundaries, and data flow paths. For example, it might contain a node named "Order Creation," which is associated with data objects such as "User" and "Product," and points to the two dependent modules, "Payment Service" and "Inventory Service."

[0022] This embodiment solves the problems of "misreading" or "omission" caused by missing information when manually analyzing requirements in traditional methods by using intelligent recognition and auto-completion mechanisms. The automatically completed contextual information, such as module boundaries and data flow, is crucial for subsequent task breakdown and code modification location. For example, if the context that "placing an order" requires calling the "payment" module is omitted, the generated code modification points may only focus on the front-end page while ignoring the back-end payment interface development, leading to seriously inaccurate evaluation results. Furthermore, this embodiment makes this tacit knowledge, which usually relies on the experience of senior developers, explicit and automated, ensuring the completeness and accuracy of the evaluation results. This advantage is particularly prominent in fields with complex business logic and close inter-module interactions, such as fintech and healthcare.

[0023] In some preferred embodiments, the method for constructing the standardized business knowledge index system includes the following steps: mining front-end business knowledge and back-end business knowledge; constructing a multi-dimensional business knowledge index based on the mined front-end business knowledge and back-end business knowledge; accumulating historical cases; and integrating the multi-dimensional business knowledge index and the historical cases to obtain the standardized business knowledge index system.

[0024] In practice, the first step is to mine front-end and back-end business knowledge. This includes business rules, data models, interface definitions, and module dependencies. The purpose of this step is to digitally extract and annotate unstructured knowledge scattered from different sources. Specifically, business rules are extracted from requirements specifications, design documents, and code comments; data models are extracted from database design documents (such as ER diagrams); interface definitions are extracted from API interface documents (such as Swagger); and module dependencies are extracted from system architecture diagrams. Through this step, a raw knowledge set is formed, providing raw materials for subsequent index construction.

[0025] Furthermore, based on the mined front-end and back-end business knowledge, a multi-dimensional business knowledge index is constructed. The purpose of this step is to establish an index system that supports retrieval by business domain, functional module, and technology stack. Since traditional linear or single-dimensional storage methods cannot handle complex business queries, this step achieves multi-dimensional cross-retrieval by associating each knowledge unit with tags related to dimensions such as "business domain," "functional module," and "technology stack." For example, a business rule about "e-commerce payment" can be quickly located through associations with tags such as "business domain - payment," "functional module - settlement," and "technology stack - Java."

[0026] Furthermore, historical case studies are accumulated. The purpose of this step is to create a structured, reusable historical case study library. Completed development tasks, bug fix logs, and actual work time data from past projects are stored and tagged according to the same dimensions as the knowledge index. These cases, as a repository of experience, are of significant reference value for assessing complexity and risk. For example, a seemingly simple function might have taken far longer than expected in historical cases due to special database locking mechanisms; such cases can then serve as a risk reference in subsequent assessments.

[0027] Furthermore, the multi-dimensional business knowledge index and historical cases are integrated to obtain a standardized business knowledge index system. The purpose of this step is to form a two-layered knowledge system: the upper layer is an index supporting multi-dimensional retrieval, and the lower layer is a historical case library rich in experience. Combined, the index provides the path "where to find," while the case library provides the basis "what experience to refer to after finding." For example, when searching for "payment module," the index can quickly locate relevant rules, while the case library can show the risk of high-concurrency lock conflicts in historical projects related to the "payment module," thus automatically increasing the risk weight during evaluation.

[0028] This embodiment systematically mines and integrates business knowledge scattered across different documents and code repositories, constructing a structured, machine-readable knowledge index system. This system supports multi-dimensional retrieval by business domain, functional module, and technology stack, significantly improving the efficiency and accuracy of knowledge retrieval compared to traditional knowledge management methods that rely on human memory. Furthermore, by incorporating historical cases into the knowledge system, the system achieves the accumulation and reuse of enterprise-level knowledge assets. Even if key personnel leave, their experience can be preserved in data form, reducing reliance on individual experience. This two-layer knowledge architecture allows the system to not only "look up information" but also "refer to experience" during evaluation, thereby improving the consistency and traceability of the evaluation.

[0029] In some preferred embodiments, constructing a multi-dimensional business knowledge index includes: parsing the front-end business knowledge and back-end business knowledge, identifying multiple business concepts in the front-end business knowledge and back-end business knowledge; analyzing the semantic relationships between the multiple business concepts; and establishing a structured association between the front-end business knowledge and back-end business knowledge based on the analyzed semantic relationships, thereby forming the multi-dimensional business knowledge index.

[0030] In practice, the first step is to analyze both front-end and back-end business knowledge, identifying multiple business concepts within them. The purpose of this step is to extract discrete business concepts with clear meanings from the original business knowledge. For example, in the document for the "user login" business scenario, multiple independent concepts such as "user," "account," "password," "verification code," "login failed," and "locked" are extracted. These concepts are the basic units for constructing semantic relationships.

[0031] Furthermore, the semantic relationships between multiple business concepts are analyzed. The purpose of this step is to establish a logical relationship network between concepts. These semantic relationships include "inclusion" relationships (e.g., "user" includes "account"), "cause" relationships (e.g., "login failure" causes "lock"), and "dependency" relationships (e.g., "deduct inventory" depends on "query inventory"). For example, through dependency parsing, the "cause" relationship between "login failure" and "lock" can be extracted from the sentence "After login failure, the system will lock the user account." Understanding these relationships is fundamental to the system's intelligent reasoning.

[0032] Furthermore, based on the semantic relationships obtained from the analysis, a structured association is established between front-end and back-end business knowledge, forming a multi-dimensional business knowledge index. The purpose of this step is to create a knowledge graph index with relational edges. For example, based on the causal relationship between "login failure" and "locked," a "cause" relational edge is established in the index, pointing from the "login failure" node to the "locked" node. Through this structured association, when the system retrieves "login failure," it can automatically infer the "locked" rule that needs attention through the relational edge, thereby achieving intelligent retrieval from "point" to "surface."

[0033] This embodiment constructs a knowledge index with semantic understanding capabilities by identifying business concepts and their semantic relationships. Compared to simple indexes based solely on keyword matching, this semantic index can understand the inherent logical relationships between business concepts, such as causality, inclusion, and parallelism. This endows the system with deeper reasoning capabilities. For example, when the requirements document mentions "after a user fails to log in, the system should prompt that the account has been locked," the system can not only identify the two independent points of "login failure" and "lock," but also understand through semantic relationships that "login failure" is the triggering condition for "lock." Therefore, in subsequent code modification analysis, the system can more accurately locate the relevant modules handling login failure logic and account locking logic, avoiding analysis omissions caused by fragmented understanding and significantly improving the completeness and accuracy of the analysis results.

[0034] S2, based on the structured requirement data, perform task breakdown and code modification point analysis to generate initial code modification point data.

[0035] In practice, initial code change point data is generated based on structured requirement data. This step transforms business requirements into specific, executable development tasks. The system first identifies requirement boundaries from the structured requirement data, including functional boundaries and module boundaries. For example, by analyzing the "business scenario" and "operation process" in the structured data, it can clearly distinguish which functions belong to "order creation" and which belong to "order payment." Based on the identified requirement boundaries, the system breaks down the overall requirement corresponding to the structured requirement data into multiple user stories. Each user story is an independent and verifiable functional unit, such as "As a user, I want to be able to submit an order to complete a purchase." Each user story contains clear acceptance criteria, preconditions, postconditions, and data flow information to ensure its independence and testability. Furthermore, for each user story, the system combines a standardized business knowledge index system and the existing codebase to conduct code change point analysis. This analysis process combines static code analysis and dependency analysis techniques: static code analysis locates the affected functions and methods, and dependency analysis identifies the database tables that need to be modified and their relationships. The identified code change points are pinpointed to specific code files, classes, methods, and database tables, such as the `createOrder()` method in `OrderController.java` and the `orders` table. Furthermore, all identified code change points are compiled to generate an initial code change point database, which records the location, type of change, and preliminary complexity assessment for each change point.

[0036] In some preferred embodiments, see Figure 4 The step of performing task decomposition and code change point analysis based on the structured requirement data to generate initial code change point data includes steps S21 to S24: S21, Identify the requirement boundaries from the structured requirement data; S22, based on the identified demand boundaries, the overall demand corresponding to the structured demand data is split into multiple user stories; S23, for each user story, locate the code modification points by combining the standardized business knowledge index system and the existing code library; S24, organize the located code modification points into the initial code modification point data.

[0037] In practice, the first step is to identify the requirement boundaries from the structured requirement data. This step aims to "decouple" the complex system. By analyzing the "business scenarios" and "operational processes" in the structured data, different functional boundaries such as "order creation," "order payment," and "order query" can be clearly defined, and their respective module boundaries, such as the "order module" and "payment module," can be determined. Only by clearly defining these boundaries can large requirements be broken down into independent smaller tasks.

[0038] Furthermore, based on the identified requirement boundaries, the overall requirement corresponding to the structured requirement data is broken down into multiple user stories. The purpose of this step is to generate a set of independent, verifiable user stories. Each user story is an independent, verifiable functional unit, such as "As a user, I want to be able to submit an order to complete a purchase." Each user story includes its own acceptance criteria, preconditions, postconditions, and data flow information. This decomposition method aligns with agile development principles, enabling each task to be developed, tested, and verified independently.

[0039] Furthermore, for each user story, the system uses a standardized business knowledge indexing system and existing codebase to pinpoint code change points. The purpose of this step is to output a precise list of code change points. Specifically, for the "Submit Order" user story, the system uses the knowledge index to find the interface definitions of the "Order Module" and "Product Module," and uses static analysis of the codebase to find the controller, service layer methods, and corresponding database tables responsible for handling order submissions. The identified code change points are precise down to specific code files, classes, methods, and database tables, such as the `createOrder()` method in `OrderController.java` and the `status` field in the `orders` table.

[0040] Furthermore, the located code change points are organized into initial code change point data. The purpose of this step is to generate formatted initial code change point data. This data includes a complete description of each change point, such as the change point location (file path, class name, method name), change type (add, modify, delete), and associated data table.

[0041] This embodiment achieves refined management of complex requirements by automatically identifying requirement boundaries from structured requirement data and breaking them down into independent, measurable user stories. Each user story includes acceptance criteria, providing a clear "bullseye" for subsequent iterative optimization. Furthermore, by combining user stories with knowledge indexes and existing codebases, it achieves precise location of code change points, rather than traditional coarse-grained module estimation. For example, it can pinpoint which specific method or table needs modification. This granularity improves workload assessment from "may require 5 person-days" to "modifying method A will take about 1 hour, modifying table B will take about 2 hours," greatly enhancing the granularity, accuracy, and feasibility of the assessment.

[0042] S3, iteratively optimize the initial code change point data until the initial code change point data meets the preset acceptance criteria, and obtain the final code change point data.

[0043] In practice, the initial code modification data is iteratively optimized. To ensure the accuracy of the evaluation, this embodiment introduces a multi-round iterative optimization mechanism. The system reads the initial code modification data and compares it with preset acceptance criteria. The preset acceptance criteria are a set of rules generated based on project requirements or historical data, such as requiring that all exception handling paths corresponding to user stories must be included in the modification points. Further, the system determines whether the initial code modification data meets the preset acceptance criteria. If not, it identifies the differences between the initial code modification data and the preset acceptance criteria, such as identifying that the initial code modification points omit the handling logic for the "insufficient account balance" exception. Based on the differences, the system automatically generates optimization suggestions, such as "It is recommended to add a code block to handle the insufficient balance exception in the PaymentService class." Further, the system updates the initial code modification data according to the optimization suggestions and returns to the step of comparing the initial code modification data with the preset acceptance criteria, forming a closed loop. If the initial code modification data meets the preset acceptance criteria, the data is determined as the final code modification data and output.

[0044] In some preferred embodiments, see Figure 5 The iterative optimization of the initial code change point data until the initial code change point data meets the preset acceptance criteria, to obtain the final code change point data, includes steps S31 to S34: S31, Read the initial code modification point data and compare the initial code modification point data with the preset acceptance criteria; S32, determine whether the initial code modification point data meets the preset acceptance criteria; S33, if the initial code modification point data does not meet the preset acceptance standard, then identify the differences between the initial code modification point data and the preset acceptance standard, generate optimization suggestions based on the differences, update the initial code modification point data according to the optimization suggestions, and return to the step of comparing the initial code modification point data with the preset acceptance standard; S34, if the initial code modification point data meets the preset acceptance criteria, then the current initial code modification point data is determined as the final code modification point data output.

[0045] In practice, the initial code modification data is first read and compared in a structured manner with preset acceptance criteria. These preset acceptance criteria are not simple text rules, but a structured set of acceptance rules organized hierarchically. For example, the root node is "functional acceptance," which includes sub-nodes such as "normal process acceptance," "abnormal process acceptance," and "boundary condition acceptance," each further subdivided into several specific acceptance items. Furthermore, each acceptance item defines the specific content to be checked, the expected results, and the judgment method. The system iterates through each modification point in the initial code modification data, comparing it item by item with each acceptance item in the acceptance rule set. The comparison process is not a simple text matching, but a deep comparison based on semantic understanding and structured analysis. For example, for a user story involving "user placing an order," the corresponding acceptance items might include "when a user submits an order, the system should generate an order record," "when inventory is insufficient, the system should prompt that inventory is insufficient," and "when a user is not logged in, the system should redirect to the login page," etc. The system analyzes the business semantics of each change point in the initial code change point data. For example, if the description of a change point is "add an order creation function to the order processing module", the system identifies that its corresponding business function is "order creation" and then compares it with the acceptance items related to "order creation" in the acceptance rule set to determine whether the change point can meet the expected results of the corresponding acceptance item.

[0046] Furthermore, it is determined whether the initial code modification point data meets the preset acceptance criteria. This determination is based on the comparison results mentioned above. If all modification points in the initial code modification point data can completely cover all acceptance items, that is, for each acceptance item, there is at least one modification point that can achieve the expected result described in that item, then the initial code modification point data is determined to meet the preset acceptance criteria. Conversely, if at least one acceptance item is not covered by any modification point, or if the implementation method of a certain modification point deviates from the expected result of the acceptance item, then the initial code modification point data is determined to not meet the preset acceptance criteria. For example, the acceptance rule set requires that "when inventory is insufficient, the system should prompt that inventory is insufficient," but the initial code modification point data only includes the modification point for "order creation," omitting the logic related to "inventory check," then it is determined to not meet the criteria.

[0047] Furthermore, when the initial code change data does not meet the preset acceptance criteria, the system initiates a discrepancy identification and optimization suggestion generation process. Specifically, the system first locates the specific acceptance item that was omitted or has a deviation. Taking the aforementioned "insufficient inventory prompt" as an example, the system identifies that this acceptance item is not covered by any change points in the initial code change data. To more accurately locate the problem, the system further analyzes the business semantics and code implementation context corresponding to the omitted acceptance item. For example, the system uses a knowledge index to find that "insufficient inventory" is usually related to the "inventory check" function in the "inventory management module," and the expected output of this function should include an identifier or status of "insufficient inventory anomaly." Based on this analysis, the system generates a discrepancy record, clearly indicating that "the code change point for handling insufficient inventory anomalies is missing," and marking the module and method to which the change point should belong.

[0048] Furthermore, the system generates specific optimization suggestions based on the differences. The generation of these suggestions follows the principle of "precise repair," rather than a general "supplementation of missing functions." For the aforementioned differences in the "insufficient inventory alert," the system generates the following optimization suggestion: "In the inventory check method of the inventory management module, add logic to determine the inventory quantity. When the inventory quantity is lower than the requested quantity, trigger an insufficient inventory exception; in the order creation method of the order processing module, add logic to capture and handle insufficient inventory exceptions, and return an insufficient inventory alert message when the exception is captured." This optimization suggestion clearly defines the modules and methods that need to be modified, the specific logical content of the modifications, and the expected behavior after the modifications, and can be directly executed by the subsequent automatic update module.

[0049] Furthermore, the system updates the initial code change point data based on optimization suggestions. The update operation is not simply appending optimization suggestions as text to the data, but rather performing a structured, incremental modification of the initial code change point data. The system parses the optimization suggestions, extracting new code change points (such as new modifications to the inventory management module) and corrections to existing changes (such as modifying the order creation method in the order processing module). The system then merges these new or modified changes into the initial code change point data, forming a new, complete set of initial code change point data. After the update is complete, the system automatically returns to the step of comparing the initial code change point data with the preset acceptance criteria, entering the next loop. This loop continues until the initial code change point data fully meets the preset acceptance criteria. When all acceptance items are covered and error-free, the system determines the current initial code change point data as the final code change point data and outputs it.

[0050] This embodiment achieves automated quality verification and correction of code change point data by establishing a rigorous structured comparison and iterative optimization mechanism. Specifically, this method transforms unstructured acceptance criteria into a set of rules that can be understood and executed by machines, making the comparison process evidence-based and objectively quantifiable. Furthermore, through item-by-item comparison and precise positioning, the system can accurately identify specific omissions or deviations from acceptance criteria in the code change point data, avoiding the ambiguity caused by general judgments. Furthermore, the difference point identification and optimization suggestion generation stages demonstrate the system's intelligence; the generated optimization suggestions not only point out the problems but also provide directly executable modification schemes at the module and method levels, giving subsequent automatic update operations clear goals and paths. This closed-loop mechanism of "identification-positioning-suggestion-repair" significantly improves the efficiency and accuracy of iterative optimization, ensuring that the final output code change point data meets project acceptance criteria in terms of both functional completeness and accuracy, thus providing a solid and reliable data foundation for subsequent workload assessment.

[0051] S4. Based on the final code modification data and preset multi-dimensional evaluation factors, perform workload evaluation and generate workload evaluation results.

[0052] In specific implementation, workload assessment is performed based on the final code change data and preset multi-dimensional evaluation factors. This step completes the final work hour calculation. Based on the final code change data, the system calculates the number of lines of code to be added, modified, and deleted, and assesses code complexity, such as cyclomatic complexity or cognitive complexity. Further, preset multi-dimensional evaluation factors are obtained, specifically including assessor qualifications (e.g., technical level, years of experience), assessing technical difficulty (e.g., the degree of challenge in technical implementation), and assessing risk factors (e.g., project uncertainty, technology stack maturity). This invention does not specifically limit these factors. Further, the number of lines of code, code complexity, assessor qualifications, assessing technical difficulty, and assessing risk factors are input into a pre-trained work hour calculation model. This work hour calculation model is a multi-factor regression model or neural network model trained based on historical project data, capable of predicting the most likely workload based on multiple input features. For example, inputting 100 lines of code, high complexity, and junior engineer characteristics, the model might output 10 hours. The model output is a comprehensive multi-dimensional work hour conversion result. Finally, based on the multi-dimensional work hour conversion results, a work hour assessment result containing detailed workload analysis and estimated work hours is generated.

[0053] This embodiment constructs a standardized business knowledge index system, providing a unified knowledge foundation for subsequent requirement analysis and task analysis, thus solving the problem of incomparable evaluation results caused by knowledge dispersion and inconsistent standards in traditional assessments. Furthermore, by employing automated requirement analysis and completion technology, the system can identify and complete the business rules, boundary conditions, and exception handling paths implicit in the requirement documents, significantly reducing the risk of misunderstanding due to missing contextual information compared to traditional manual reading of requirement documents. Furthermore, by automatically breaking down requirements into user stories and locating code change points at the file and method levels, a fine-grained mapping from business requirements to specific code modification tasks is achieved, solving the problem of traditional methods only being able to perform coarse-grained module estimation, refining the evaluation granularity from the "man-day" level to the "hour" level. Furthermore, the introduced iterative optimization mechanism, through multiple rounds of comparison with preset acceptance criteria, ensures that the final output code change point data is highly consistent with the acceptance criteria, avoiding invalid work caused by misunderstandings of requirements, thereby improving the reliability and accuracy of the evaluation results.

[0054] In some preferred embodiments, see Figure 6 The step of evaluating workload based on the final code modification data and preset multi-dimensional evaluation factors, and generating workload evaluation results, includes steps S41 to S44: S41, Based on the final code change point data, calculate the number of lines of code and evaluate the code complexity; S42, Obtain assessment personnel qualifications, assessment technical difficulty, and assessment risk factors; S43, take the number of lines of code, the code complexity, the qualifications of the evaluators, the difficulty of the evaluation technology, and the evaluation risk factor as the multi-dimensional evaluation factors, input them into the working hour calculation model, and obtain the multi-dimensional working hour conversion result; S44. Based on the multi-dimensional working time conversion results, generate the workload assessment results.

[0055] In practice, the first step is to calculate the number of lines of code and assess code complexity based on the final code modification data. This step aims to obtain quantitative indicators for both the "quantity" and "quality" of the code. The number of lines of code includes newly added, modified, and deleted lines. Code complexity can be assessed using metrics such as cyclomatic complexity (measuring the complexity of program logic, such as the number of branches and loops) or cognitive complexity (measuring the difficulty of understanding the code). For example, a method containing multiple nested if-else statements and loops has a much higher cyclomatic complexity than a method that executes sequentially. Both the number of lines and complexity are considered because the number of lines represents "quantity," while complexity represents "quality," and both together determine the development difficulty.

[0056] Further, this involves obtaining assessment personnel qualifications, evaluating technical difficulty, and assessing risk factors. The purpose of this step is to obtain environmental factors relevant to the current task. Assessment personnel qualifications include technical level (e.g., junior, intermediate, senior), years of experience, and proficient technology stack. Assessing technical difficulty refers to the degree of challenge in technical implementation, such as whether it involves new frameworks, complex algorithms, or external system integration. Assessing risk factors includes project uncertainty (e.g., whether requirements are stable), the maturity of the technology stack (e.g., using unverified third-party libraries), and the complexity of team collaboration. These factors reflect that the development workload depends not only on the code itself but also on "who, in what environment, and what they are doing."

[0057] Furthermore, the number of lines of code, code complexity, evaluator qualifications, assessment technical difficulty, and assessment risk factors are used as multi-dimensional evaluation factors and input into the work-hour calculation model to obtain multi-dimensional work-hour conversion results. The purpose of this step is to use a model trained on historical data for comprehensive prediction. The work-hour calculation model is a multi-factor regression model or neural network model trained on historical project data, capable of predicting the most likely work hours based on multiple input features. For example, inputting 100 lines of code, high complexity, junior engineer, high difficulty, and high risk features, the model may output 15 hours; while inputting the same number of lines of code but assessed as low complexity, senior engineer, low difficulty, and low risk, the model may output 3 hours. The reason for using this model is that it can learn the complex non-linear relationship between multiple factors in historical data and the final work hours, which is more accurate than simple weighted summation.

[0058] Furthermore, based on the multi-dimensional work hour conversion results, a workload assessment result is generated. The purpose of this step is to output a structured workload assessment report. This report details each input factor, the predicted work hour range of the model, and confidence level information, for use by project managers or administrators in decision-making.

[0059] This embodiment achieves a refined and objective assessment of workload by comprehensively considering multiple dimensions, including lines of code, complexity, personnel qualifications, technical difficulty, and risk factors. Compared to traditional methods that rely solely on lines of code or human experience, this multi-dimensional integrated model more accurately reflects actual development costs. For example, a piece of code with few lines but extremely complex logic is far more difficult to develop than code with many lines but simple logic. This embodiment's model can identify this difference, thus outputting a more realistic workload assessment. Furthermore, by introducing personnel qualification factors, the assessment results can be adapted to different team compositions, improving the flexibility and applicability of the assessment. With the accumulation of historical data, the model can be continuously optimized through a feedback mechanism, forming a virtuous cycle of "becoming more accurate with use," significantly improving the accuracy and reliability of the assessment.

[0060] In a specific embodiment of the present invention, the working time calculation model adopts a neural network architecture based on a multilayer perceptron. The basic components of the model include: an input layer, used to receive five normalized evaluation factors: number of lines of code, code complexity, evaluator qualifications, evaluation technical difficulty, and evaluation risk factor; the input layer may contain 5 neurons, each neuron corresponding to one of the evaluation factors; a first hidden layer, which may contain 128 neurons, connected to the input layer in a fully connected manner, and performs a nonlinear mapping on the linear transformation result through the ReLU activation function. The mathematical expression of the ReLU activation function is f(x)=max(0,x), which can alleviate the gradient vanishing problem while introducing nonlinearity; a second hidden layer, which may contain 64 neurons, connected to the first hidden layer in a fully connected manner, and also performs a nonlinear transformation using the ReLU activation function; and an output layer, containing 1 neuron, connected to the second hidden layer in a fully connected manner, and directly outputs the predicted working time value without using an activation function or using a linear activation function. A dropout layer is also provided between the first hidden layer and the second hidden layer, with a dropout rate set to 0.2, which is used to randomly drop some of the outputs of neurons during training to prevent the model from overfitting to the training data.

[0061] Furthermore, the training method of the work time calculation model includes the following steps. First, feature data and corresponding actual work time data of completed development tasks in historical projects are collected to construct a training dataset. Each training sample contains five input features and one label value: the five input features are the number of lines of code for the task, the code complexity score, the qualification level of the developer performing the task, the technical difficulty rating of the task, and the risk rating; the label value is the actual work time consumed by the task. The training dataset contains no less than 500 samples to ensure that the model can learn a stable mapping relationship between each evaluation factor and work time. All input features in the sample data are normalized by maximum and minimum values ​​before being input into the model, linearly mapping each feature value to the [0,1] interval to eliminate the adverse effects of differences in the units of measurement between different features on model training.

[0062] Furthermore, the training dataset is randomly divided into a training set and a validation set in an 8:2 ratio. The training set is used for learning and updating model parameters, while the validation set is used to evaluate the model's generalization ability during training and to provide monitoring metrics for the early stopping mechanism. Mini-batch gradient descent is used during training, with a batch size of 32, meaning that 32 samples are randomly selected from the training set each time to calculate the gradient and update the model parameters.

[0063] Furthermore, during training, mean squared error is used as the loss function to measure the deviation between the predicted and actual working hours. The Adam optimizer is used to update the model parameters. The Adam optimizer can adaptively adjust the learning rate of each parameter, offering advantages such as fast convergence and insensitivity to hyperparameter selection. The initial learning rate is set to 0.001, the exponential decay rate β1 for first-order moment estimation is set to 0.9, the exponential decay rate β2 for second-order moment estimation is set to 0.999, and the numerical stability constant ε is set to 10. -8 The maximum number of training epochs is set to 200. An early stopping mechanism is employed: after each training epoch, the loss function value of the model on the validation set is calculated. If this loss function value does not decrease for 10 consecutive epochs, training is terminated early, and the model parameters with the lowest loss on the validation set are saved as the final model. This early stopping mechanism effectively prevents the model from overfitting on the training set and improves its generalization ability on unseen samples.

[0064] Furthermore, the training data sources include: historical development task records exported from enterprise project management systems (such as Jira, ZenTao, etc.). Each record contains basic information such as the task's unique identifier, task description, project, actual working hours, involved code files, and the number of lines modified. The number of lines of code is obtained through commit records from version control systems (such as Git), specifically the sum of newly added, modified, and deleted lines of code. Code complexity is obtained through static analysis of the modified source code files, using cyclomatic complexity as the evaluation metric, automatically calculated by static code analysis tools (such as SonarQube). Developer qualification levels are determined based on the developer's technical title, years of experience, and historical performance evaluations, and can be divided into three levels: junior, intermediate, and senior. Technical difficulty ratings are assessed by the task's technical lead after completion based on the level of technical challenge, and can be divided into three levels: low, medium, and high. Risk ratings are assessed by the project manager after project completion based on factors such as the stability of the requirements involved, the maturity of the technology stack, and the complexity of external dependencies, and can be divided into three levels: low, medium, and high. All data has been anonymized after export, removing personally identifiable or trade secret information such as developer names and project names, retaining only numerical features and labels used for model training.

[0065] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0066] The method provided in this invention has significant application value in the fintech field. Taking a fintech company developing a new generation of intelligent risk control system as an example, this system needs to implement functions such as real-time transaction monitoring, abnormal behavior identification, and risk warning. In traditional development models, the requirements document for risk control systems typically contains a large number of complex business rules, such as professional terminology and logic related to anti-money laundering, anti-fraud, and compliance review, and these rules often have complex dependencies. Developers need to spend a lot of time communicating with business experts to understand the details of the requirements, and human misunderstanding may lead to errors in the design of the risk control model, causing serious economic losses and compliance risks. After adopting the technical solution of this invention, the system first constructs a standardized financial business knowledge index system, which includes core knowledge such as risk control business rules, account data models, external data interface definitions, and module dependencies. Furthermore, upon receiving a requirements document for "adding real-time transaction monitoring function," the system automatically calls this knowledge index for parsing, identifies key information such as transaction flow monitoring, rule engine triggering, and risk decision output, and automatically completes missing contextual information, such as the relationship between risk control rules and the account system, and the path of abnormal transaction data flow to the compliance reporting module. Furthermore, the system then breaks down the overall requirements into multiple user stories, such as "transaction feature extraction," "rule matching and execution," and "risk score calculation." For each user story, it precisely identifies the code modification points, down to the rule configuration class in the risk control engine, the methods in the risk scoring service, and the transaction log database tables. Through multiple rounds of iterative optimization, the system ensures that the final output code modifications fully cover the preset acceptance criteria, such as all compliance rules being correctly processed. Finally, combining factors such as the qualifications of assessment personnel, the technical difficulty of risk control business, and system migration risks, the system outputs workload assessment results through a work-hour calculation model, providing an objective basis for project scheduling and resource allocation. This solution effectively addresses the pain points of complex business rules, strict compliance requirements, and reliance on expert experience in the fintech field.

[0067] Furthermore, the method provided in this invention also has significant application value in the medical and health field. Taking the development of a new generation electronic medical record system by a tertiary hospital as an example, this system needs to achieve full-process digital management of patient diagnosis and treatment information, covering modules such as outpatient registration, inpatient registration, medical order issuance, return of examination and test results, and medical record quality control. Under the traditional development model, medical information systems face multiple challenges such as poor standardization of requirement documents, complex business process logic, and inconsistent data standards. Moreover, special compliance requirements such as the protection of patient privacy data are involved, leading to a heavy reliance on the experience and judgment of senior technical personnel for workload assessment, resulting in a high rate of assessment bias and affecting project progress and quality. After adopting the technical solution of this invention, the system first constructs a standardized medical business knowledge index system, which includes core knowledge such as clinical pathway rules, HL7 data exchange standards, medical data models, and inter-system interface definitions. Furthermore, upon receiving the requirement document for "Adding Inpatient Electronic Medical Record Quality Control Function," the system automatically calls the knowledge index for parsing, identifying key information such as medical record content integrity verification, timeliness monitoring, and diagnostic coding standardization checks. It also automatically completes missing contextual information, such as the data flow relationships between the quality control module and the hospital information system, laboratory information system, and radiology information system. The system further breaks down the overall requirement into multiple user stories, such as "medical record content extraction," "quality control rule engine execution," and "violation record generation," and, combined with the existing codebase of the medical information system, accurately locates code modification points, down to the methods of the quality control service layer, the medical record database table structure, and the field definitions of the data exchange interface. Furthermore, through multiple rounds of iterative optimization, the system ensures that the final output code modification points comply with medical quality control standards and privacy protection specifications. Finally, by comprehensively evaluating multiple dimensions such as personnel qualifications, the technical difficulty of medical business, and system integration risks, the system outputs workload assessment results through a work-hour calculation model, providing a scientific basis for the work-hour budget and resource scheduling of hospital information projects. This solution effectively improves the accuracy of software development assessments and project transparency in the healthcare field, reducing the risk of rework due to misunderstandings of requirements.

[0068] In one embodiment, a workload assessment device 60 is provided, which corresponds one-to-one with the workload assessment methods described in the above embodiments. For example... Figure 7 As shown, the workload assessment device 60 includes: The parsing unit 61 is used to respond to the received requirement document by calling a pre-built standardized business knowledge index system to parse the requirement document and generate structured requirement data. Analysis unit 62 is used to perform task decomposition and code change point analysis based on the structured requirement data, and generate initial code change point data; The optimization unit 63 is used to iteratively optimize the initial code change point data until the initial code change point data meets the preset acceptance criteria, and obtain the final code change point data. Evaluation unit 64 is used to evaluate workload based on the final code modification point data and preset multi-dimensional evaluation factors, and generate workload evaluation results.

[0069] In some preferred embodiments, the method for constructing the standardized business knowledge index system includes the following steps: Explore front-end and back-end business knowledge; Based on the front-end and back-end business knowledge obtained through mining, a multi-dimensional business knowledge index is constructed. Accumulate historical cases; The multi-dimensional business knowledge index and the historical cases are integrated to obtain the standardized business knowledge index system.

[0070] In some preferred embodiments, constructing a multi-dimensional business knowledge index includes: Analyze the front-end business knowledge and back-end business knowledge, and identify multiple business concepts in the front-end business knowledge and back-end business knowledge; Analyze the semantic relationships between the multiple business concepts; Based on the semantic relationships obtained from the analysis, a structured association is established between the front-end business knowledge and the back-end business knowledge to form the multi-dimensional business knowledge index.

[0071] In some preferred embodiments, the step of invoking a pre-built standardized business knowledge index system to parse the requirement document and generate structured requirement data includes: Identify the pre-defined key information from the requirements document; Based on the key information and the standardized business knowledge index system, the missing context information in the requirement document is automatically completed; The identified key information is fused with the supplemented context information to generate the structured requirement data.

[0072] In some preferred embodiments, the step of performing task decomposition and code change point analysis based on the structured requirements data to generate initial code change point data includes: Identify demand boundaries from the structured demand data; Based on the identified demand boundaries, the overall demand corresponding to the structured demand data is broken down into multiple user stories; For each user story, the code modification points are located by combining the standardized business knowledge index system and the existing code library; The located code modification points are organized into the initial code modification point data.

[0073] In some preferred embodiments, the iterative optimization of the initial code change point data until the initial code change point data meets a preset acceptance criterion to obtain the final code change point data includes: Read the initial code modification point data and compare the initial code modification point data with the preset acceptance criteria; Determine whether the initial code modification data meets the preset acceptance criteria; If the initial code change point data does not meet the preset acceptance criteria, then the differences between the initial code change point data and the preset acceptance criteria are identified, optimization suggestions are generated based on the differences, and the initial code change point data is updated according to the optimization suggestions. Then, the process returns to the step of comparing the initial code change point data with the preset acceptance criteria. If the initial code change point data meets the preset acceptance criteria, then the current initial code change point data is determined as the final code change point data output.

[0074] In some preferred embodiments, the step of evaluating workload based on the final code change point data and preset multi-dimensional evaluation factors, and generating workload evaluation results, includes: Based on the final code change data, calculate the number of lines of code and evaluate the code complexity; Obtain the qualifications of the assessors, the technical difficulty of the assessment, and the risk factors of the assessment; The number of lines of code, the code complexity, the qualifications of the evaluators, the difficulty of the evaluation technology, and the evaluation risk factors are used as the multi-dimensional evaluation factors and input into the working hour calculation model to obtain the multi-dimensional working hour conversion results. Based on the multi-dimensional work hour conversion results, the workload assessment results are generated.

[0075] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a demand workload assessment method on the server side.

[0076] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 9 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements the functions or steps of a client-side requirement workload assessment method. In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of a requirement workload assessment method provided in any of the above embodiments.

[0077] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of a requirement workload assessment method provided in any of the above embodiments.

[0078] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

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

[0080] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0081] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0082] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for assessing workload requirements, characterized in that, include: In response to receiving a requirement document, the pre-built standardized business knowledge index system is invoked to parse the requirement document and generate structured requirement data; Based on the structured requirement data, task breakdown and code change point analysis are performed to generate initial code change point data; The initial code change point data is iteratively optimized until it meets the preset acceptance criteria, thus obtaining the final code change point data. Based on the final code change data and preset multi-dimensional evaluation factors, workload assessment is performed, and workload assessment results are generated.

2. The method for assessing workload according to claim 1, characterized in that, The method for constructing the standardized business knowledge index system includes the following steps: Explore front-end and back-end business knowledge; Based on the front-end and back-end business knowledge obtained through mining, a multi-dimensional business knowledge index is constructed. Accumulate historical cases; The multi-dimensional business knowledge index and the historical cases are integrated to obtain the standardized business knowledge index system.

3. The method for assessing workload according to claim 2, characterized in that, The construction of the multi-dimensional business knowledge index includes: Analyze the front-end business knowledge and back-end business knowledge, and identify multiple business concepts in the front-end business knowledge and back-end business knowledge; Analyze the semantic relationships between the multiple business concepts; Based on the semantic relationships obtained from the analysis, a structured association is established between the front-end business knowledge and the back-end business knowledge to form the multi-dimensional business knowledge index.

4. The method for assessing workload according to claim 1, characterized in that, The process of parsing the requirement document using a pre-built standardized business knowledge index system to generate structured requirement data includes: Identify the pre-defined key information from the requirements document; Based on the key information and the standardized business knowledge index system, the missing context information in the requirement document is automatically completed; The identified key information is fused with the supplemented context information to generate the structured requirement data.

5. The method for assessing workload according to claim 1, characterized in that, Based on the structured requirements data, task decomposition and code modification point analysis are performed to generate initial code modification point data, including: Identify demand boundaries from the structured demand data; Based on the identified demand boundaries, the overall demand corresponding to the structured demand data is broken down into multiple user stories; For each user story, the code modification points are located by combining the standardized business knowledge index system and the existing code library; The located code modification points are organized into the initial code modification point data.

6. The method for assessing workload according to claim 1, characterized in that, The iterative optimization of the initial code change point data until the initial code change point data meets the preset acceptance criteria, to obtain the final code change point data, includes: Read the initial code modification point data and compare the initial code modification point data with the preset acceptance criteria; Determine whether the initial code modification data meets the preset acceptance criteria; If the initial code change point data does not meet the preset acceptance criteria, then the differences between the initial code change point data and the preset acceptance criteria are identified, optimization suggestions are generated based on the differences, and the initial code change point data is updated according to the optimization suggestions. Then, the process returns to the step of comparing the initial code change point data with the preset acceptance criteria. If the initial code change point data meets the preset acceptance criteria, then the current initial code change point data is determined as the final code change point data output.

7. The method for assessing workload according to claim 1, characterized in that, The workload assessment is performed based on the final code change data and preset multi-dimensional evaluation factors, generating a workload assessment result, including: Based on the final code change data, calculate the number of lines of code and evaluate the code complexity; Obtain the qualifications of the assessors, the technical difficulty of the assessment, and the risk factors of the assessment; The number of lines of code, the code complexity, the qualifications of the evaluators, the difficulty of the evaluation technology, and the evaluation risk factors are used as the multi-dimensional evaluation factors and input into the working hour calculation model to obtain the multi-dimensional working hour conversion results. Based on the multi-dimensional work hour conversion results, the workload assessment results are generated.

8. A demand workload assessment device, characterized in that, include: The parsing unit is used to respond to the received requirement document by calling a pre-built standardized business knowledge index system to parse the requirement document and generate structured requirement data. The analysis unit is used to perform task breakdown and code change point analysis based on the structured requirement data, and generate initial code change point data; An optimization unit is used to iteratively optimize the initial code change point data until the initial code change point data meets the preset acceptance criteria, thereby obtaining the final code change point data. The evaluation unit is used to evaluate the workload based on the final code modification data and preset multi-dimensional evaluation factors, and generate the workload evaluation results.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the requirement workload assessment method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the requirement workload assessment method as described in any one of claims 1 to 7.

Images