Project demand analysis method and device, equipment and storage medium

Abstract

The invention discloses a project demand analysis method, device and equipment and a storage medium, and relates to the technical field of project management, and the project demand analysis method comprises the steps that training multi-source project data is acquired, and the training multi-source project data comprises product data, historical index data and system feature data; analyzing the unstructured data of the training multi-source project data to obtain a function implementation process, and converting the function implementation process into a function feature vector; performing normalization processing on the structured data of the training multi-source project data to obtain standard numerical data; and performing function identification training, case identification training and risk weighting training according to the function feature vector and / or the standard numerical data to obtain a demand analysis model, and performing project demand analysis according to the demand analysis model.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of project management, and particularly relates to a project requirement analysis method and device, equipment and a storage medium. BACKGROUND

[0002] In the software development and testing process, project evaluation is always a key link that affects whether the project can be efficiently promoted, and the estimation of testing manpower and workload is one of the core tasks. Accurate evaluation results can not only provide data support for formulating reasonable progress plans and resource allocation for the project, but also identify potential risks in the early stage of the project to avoid schedule delays caused by insufficient resources or improper allocation.

[0003] In existing practices, traditional project evaluation usually summarizes manpower requirements item by item through task decomposition, or relies on experienced personnel for subjective judgment, or uses quantitative methods based on function points or use case points and other index models. However, these methods generally have the limitation of relying on information completeness or experience accumulation, and it is difficult to provide reliable conclusions in the early stage of the project.

[0004] The above content is only used to assist in understanding the technical solutions of the present application and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0005] The main purpose of the present application is to provide a project requirement analysis method, device, equipment and storage medium, aiming to solve the technical problem of how to analyze project requirements based on only requirement information in the early stage of the project.

[0006] To achieve the above purpose, the present application provides a project requirement analysis method, which comprises:

[0007] Obtaining training multi-source project data, wherein the training multi-source project data comprises product data, historical index data and system feature data;

[0008] Analyzing the unstructured data of the training multi-source project data to obtain a function implementation process, and converting the function implementation process into a function feature vector;

[0009] Normalizing the structured data of the training multi-source project data to obtain standard numerical data;

[0010] According to the function feature vector and / or the standard numerical data, function recognition training, case recognition training and risk weighting training are performed to obtain a requirement analysis model, so as to analyze project requirements according to the requirement analysis model.

[0011] In an embodiment, the step of performing function identification training, case identification training and risk weighting training according to the function feature vector and / or the standard numerical data to obtain a requirement analysis model comprises:

[0012] performing function identification training according to the function feature vector and historical function point data of the standard numerical data to obtain a function point prediction correlation;

[0013] performing case identification training according to the function point prediction correlation and historical case data of the standard numerical data to obtain a case function correlation;

[0014] performing risk weighting training according to the case function correlation and the standard numerical data to obtain a risk weighting training result;

[0015] determining a requirement analysis model according to the function point prediction correlation, the case function correlation and the risk weighting training result.

[0016] In an embodiment, the step of performing function identification training according to the function feature vector and historical function point data of the standard numerical data to obtain a function point prediction correlation comprises:

[0017] obtaining a preset weight matrix and determining a predicted function point number according to the standard numerical data;

[0018] analyzing historical function point data of the standard numerical data to obtain an initial project process, and constructing a retrieval enhancement generation database according to the initial project process;

[0019] identifying a target project process in the retrieval enhancement generation database according to the function feature vector, wherein the target project process represents a project process associated with the function feature vector, and the number of the target project processes is a preset number of associated processes;

[0020] performing weighted calculation on the target project processes according to the preset weight matrix to obtain a target function point number;

[0021] determining a function point prediction correlation according to the predicted function point number and the target function point number.

[0022] In an embodiment, the step of performing risk weighting training according to the case function correlation and the standard numerical data to obtain a risk weighting training result comprises:

[0023] obtaining a system characteristic factor, a project design factor, a project execution factor and a project management factor according to the standard numerical data;

[0024] classifying the standard numerical data to obtain a target category and determining a risk score of the target category;

[0025] calculating a test design time according to the project design factor, the case function correlation, the system characteristic factor, and the risk score;

[0026] calculating a test execution time according to the project execution factor, the case function correlation, the system characteristic factor, and the risk score;

[0027] calculating a test management time according to the project management factor, the case function correlation, the system characteristic factor, and the risk score;

[0028] performing risk weighted training according to the case function correlation and the standard numerical data to obtain a risk weighted training result.

[0029] In an embodiment, the step of classifying the standard numerical data to obtain a target category and determining a risk score of the target category comprises:

[0030] obtaining historical data of project risk correlation according to the standard numerical data, wherein the historical data comprises high-risk function records, project importance annotations, change impact range statistics, cross-system interaction information, personnel configuration data, and risk response measure records;

[0031] classifying the historical data to obtain risk data, target attention data, change impact range data, and cross-system data;

[0032] performing risk scoring on the risk data, the target attention data, the change impact range data, and the cross-system data to obtain risk data scores, target attention data scores, change impact range data scores, and cross-system data scores;

[0033] classifying the historical data according to the risk data scores, the target attention data scores, the change impact range data scores, and the cross-system data scores to obtain a target category and determining a risk score of the target category.

[0034] In an embodiment, the step of parsing the unstructured data of the training multi-source project data to obtain a function implementation process and converting the function implementation process into a function feature vector comprises:

[0035] performing effective content extraction on the unstructured data of the training multi-source project data to obtain project requirement data, wherein the unstructured data comprises requirement documents and development detailed design documents;

[0036] identifying a function implementation process of the project requirement data;

[0037] converting the function implementation process into a function feature vector according to a paragraph vector algorithm.

[0038] In an embodiment, the step of obtaining the training multi-source project data comprises:

[0039] obtaining requirement document data, detailed design data, function point data, actual manpower data, case data, function point size data, historical evaluation data, system complexity factors, and project risk factor scores;

[0040] determining product profile data according to the requirement document data, the detailed design data, and the function point data;

[0041] determining historical index data according to the actual manpower data, the case data, the function point size data, and the historical evaluation data;

[0042] determining system feature data according to the system complexity factors and the project risk factors;

[0043] determining the training multi-source project data according to the product profile data, the historical index data, and the system feature data.

[0044] In addition, to achieve the above object, the present application further provides a project requirement analysis device, which comprises a data obtaining module for obtaining training multi-source project data, wherein the training multi-source project data comprises product profile data, historical index data, and system feature data;

[0045] a data analysis module for analyzing unstructured data of the training multi-source project data to obtain a function implementation process, and converting the function implementation process into a function feature vector;

[0046] a data normalization module for normalizing structured data of the training multi-source project data to obtain standard numerical data;

[0047] a model training module for performing function identification training, case identification training, and risk weighting training according to the function feature vector and / or the standard numerical data to obtain a requirement analysis model, so as to perform project requirement analysis according to the requirement analysis model.

[0048] In addition, to achieve the above object, the present application further provides a project requirement analysis device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the project requirement analysis method as described above.

[0049] In addition, to achieve the above object, the present application also provides a storage medium, which is a computer readable storage medium, and a computer program is stored on the storage medium, and the computer program is executed by a processor to implement the steps of the project requirement analysis method.

[0050] In addition, to achieve the above object, the present application also provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the project requirement analysis method.

[0051] The one or more technical solutions provided by the present application have at least the following technical effects:

[0052] Since the training multi-source project data containing product material data, historical index data and system characteristic data is acquired, the functional implementation process of the unstructured data is parsed to obtain a functional feature vector and converted, the structured data is normalized to obtain standard numerical data, and the functional recognition training, case recognition training and risk weighting training are performed based on the functional feature vector and / or the standard numerical data to construct the requirement analysis model. Through the integration of multi-source data, the problems of the task decomposition method in the prior art, such as dependence on detailed task lists and time-consuming, strong subjectivity of the experience judgment method and high risk when there is no historical data support, and information missing in the initial stage of the index model method are solved. At the same time, the defect of the prior art that the multi-source data is not effectively integrated to cause the evaluation dimension to be single is solved. Through the extraction and vector conversion of the functional implementation process of the unstructured data and the normalization processing of the structured data, the problem of the prior art that the data formats are not unified and are difficult to be jointly analyzed is solved. Finally, the requirement analysis model is constructed through the three types of training of functional recognition, case recognition and risk weighting, and the problems of the prior art, such as lack of quantitative consideration of project risks, poor measurability of evaluation results and dependence on artificial experience, are solved. Compared with the prior art, the technical means realizes the diversification and standardization of the data sources of the project requirement analysis, reduces the dependence on artificial experience, improves the scientificity of the construction of the requirement analysis model, and further makes the subsequent project requirement analysis based on the model more objective and accurate. BRIEF DESCRIPTION OF DRAWINGS

[0053] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments consistent with the present application and serve to explain the principles of the present application together with the specification.

[0054] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without creative labor.

[0055] Figure 1 A flowchart provided by the project requirement analysis method embodiment one of the present application is provided.

[0056] Figure 2 A training flowchart provided by the project requirement analysis method embodiment one of the present application is provided.

[0057] Figure 3 A requirement document analysis flowchart provided by the project requirement analysis method embodiment one of the present application is provided.

[0058] Figure 4 A flowchart provided by the project requirement analysis method embodiment two of the present application is provided.

[0059] Figure 5 A module structure diagram of the project requirement analysis device of the present application embodiment is provided.

[0060] Figure 6 A device structure diagram of the hardware running environment involved in the project requirement analysis method of the present application embodiment is provided.

[0061] The object implementation, functional features and advantages of the present application will be further described with reference to the accompanying drawings in conjunction with the embodiments. DETAILED DESCRIPTION

[0062] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application, and are not used to limit the present application.

[0063] In order to better understand the technical solutions of the present application, the following will be described in detail in conjunction with the drawings and specific embodiments of the specification.

[0064] The main solution of the present application embodiment is: obtaining training multi-source project data, wherein the training multi-source project data includes product data, historical index data and system feature data; analyzing the unstructured data of the training multi-source project data to obtain a function implementation process, and converting the function implementation process into a function feature vector; normalizing the structured data of the training multi-source project data to obtain standard numerical data; performing function recognition training, case recognition training and risk weighting training according to the function feature vector and / or the standard numerical data to obtain a requirement analysis model, so as to perform project requirement analysis according to the requirement analysis model.

[0065] In the present embodiment, for convenience of description, the following describes the identification project requirement analysis device as the execution subject.

[0066] Since existing technologies struggle to perform project requirements analysis in the early stages based solely on requirement information, this application offers a solution. This solution employs a multi-source project data acquisition approach, which includes product data, historical indicator data, and system characteristic data. Unstructured data is parsed to extract the functional implementation process and converted into functional feature vectors. Structured data is normalized to obtain standard numerical data. Then, functional identification training, case identification training, and risk-weighted training are conducted based on the functional feature vectors and / or standard numerical data to construct a requirements analysis model. By integrating multi-source data, this approach addresses the shortcomings of existing technologies: task decomposition methods rely on detailed task lists and are time-consuming; experience-based judgment methods are subjective and risky without historical data support; and indicator model methods suffer from information gaps in the initial stages. This approach addresses the shortcomings of existing technologies, such as the lack of effective integration of multi-source data leading to a single evaluation dimension. By extracting and transforming the functional implementation process of unstructured data into vectors, and normalizing structured data, it solves the problem of inconsistent data formats hindering joint analysis in existing technologies. Finally, by constructing a requirements analysis model through three types of training—functional identification, case identification, and risk weighting—it addresses the issues of existing technologies lacking quantitative consideration of project risks, having poor measurability of evaluation results, and relying on human experience. Compared with existing technologies, this approach diversifies and standardizes the data sources for project requirements analysis, reduces reliance on human experience, and enhances the scientific rigor of the requirements analysis model construction, thereby making subsequent project requirements analysis based on this model more objective and accurate.

[0067] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or project requirements analysis device capable of performing the above functions. The following description uses a project requirements analysis device as an example to illustrate this embodiment and the subsequent embodiments.

[0068] Based on this, the embodiments of this application provide a project requirements analysis method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the requirements analysis method for this application.

[0069] In this embodiment, the project requirements analysis method includes steps S10 to S40:

[0070] Step S10: Obtain training multi-source project data, wherein the training multi-source project data includes product information data, historical indicator data, and system feature data;

[0071] It should be noted that the multi-source project data used for training is the basic dataset for building the requirements analysis model. It comes from multiple different information channels and covers various types of data related to project requirements analysis. By integrating this data, comprehensive and diverse information support can be provided for subsequent model training, ensuring the accuracy and reliability of model training.

[0072] In addition, product data is the basic document data related to software product development, including requirements documents, development details, and function point libraries. These data record in detail the functional requirements, development design ideas, and defined functional module information of the software product, and are the key basis for understanding the functional architecture and development logic of the software product.

[0073] In addition, historical metrics data are quantitative data generated during the execution of previously completed software projects. These mainly include actual man-days invested, number of cases, feature scale, and historical evaluation data. These data reflect the resource investment, test coverage, and project size of past projects, and can provide historical reference for the requirements analysis of new projects.

[0074] In addition, system characteristic data is used to describe the system characteristics and potential risks involved in the software project. It includes system complexity factor and project risk factor score. The system complexity factor reflects the complexity of the system architecture and technical implementation, while the project risk factor score quantifies the degree of risk that the project may face during execution. Together, they provide data support for risk consideration and difficulty assessment in project requirements analysis.

[0075] Understandably, these three types of data are collected from corresponding data sources. Product data can be retrieved from the product asset library, covering requirement documents, development details, and feature point libraries. Historical indicator data can be extracted from the project database or work log records, including actual man-days invested, number of cases, feature point scale, and historical evaluation data. System characteristic data can be obtained from project risk assessment reports or system complexity analysis documents, including system complexity factors and project risk factor scores. Finally, the collected three types of data are initially processed to ensure data completeness and validity, forming multi-source project data for subsequent model training.

[0076] In one feasible implementation, step S10 may include steps S11 to S15:

[0077] Step S11: Obtain requirement document data, detailed design data, functional point data, actual manpower data, case data, functional point scale data, historical evaluation data, system complexity factors, and project risk factor scores.

[0078] It should be noted that requirements document data is text data that records the requirements related to a software project. It includes information such as users' specific requirements for software functions, descriptions of business scenarios, and definitions of functional boundaries. It is the core basis for clarifying the development goals and scope of the software project and can be used to analyze the source of software function requirements in subsequent analysis.

[0079] In addition, detailed design data describes the details of the software project's functional implementation. It covers the code design logic of functional modules, the interaction process between modules, the data storage structure, and the interface definition. It is used to guide developers in implementing the software functions and is also an important reference for subsequent identification of the functional implementation process.

[0080] In addition, function point data is data that defines and describes independent functional units in a software project. Each function point corresponds to a specific function of the software and includes function name, function description, function input and output, and business data related to the function. It can be used to build a training data foundation related to the function.

[0081] In addition, actual human resource data refers to the actual human resources invested during the execution of past software projects. It is usually measured in person-days and records the actual number of human resources invested in each stage of the project, such as the number of person-days actually invested in the testing phase. This data can provide historical data for reference when training subsequent human resource assessment models.

[0082] Additionally, case data consists of test case-related data generated during past software project testing. This includes test case numbers, test objectives, test steps, expected results, and actual results, reflecting the project's test coverage and execution status. It is key data for case identification and training.

[0083] In addition, function point scale data is data obtained by statistically analyzing the number of function points contained in a software project. It reflects the overall size of the project by quantifying the total number of functions in the software project and is an important indicator for measuring the project size in function recognition training.

[0084] In addition, historical evaluation data is the evaluation record data generated during the requirements analysis, manpower estimation and time planning of past software projects. It includes the predicted manpower input, project cycle, functional point scale and deviation analysis between the evaluation results and the actual results, which can be used to optimize the accuracy of the evaluation model.

[0085] In addition, the system complexity factor is a quantitative indicator used to measure the system architecture, technical implementation difficulty, and module interaction complexity involved in a software project. It is determined based on factors such as the number of modules contained in the system, the dependencies between modules, and the difficulty of the technology stack, and can reflect the impact of the complexity of system implementation on the project.

[0086] In addition, the project risk factor score is a score obtained by quantitatively assessing various risks that a software project may face during execution. Each risk type corresponds to a score, such as the risk score for cross-team collaboration losses and the risk score for environmental stability. The scores are summarized to reflect the overall risk level of the project.

[0087] Step S12: Determine product information data based on the requirements document data, the detailed design data, and the function point data;

[0088] It is understandable that product data comprises requirement document data, detailed design data, and functional point data. Next, these three types of data are linked and integrated. Each functional requirement in the requirement document data is matched with its corresponding functional implementation details in the detailed design data. For example, the requirement description for "user login function" in the requirement document is associated with the design content of "login module interface logic" in the detailed design data. Then, the linked requirement-design data is bound to the corresponding functional points in the functional point data. For example, the requirement design data for the user login function is bound to functional points such as sending mobile phone verification codes and account password verification. Finally, the integrated three types of data undergo format standardization and content validation, eliminating duplicate functional descriptions and contradictory design logic to form product data with a clear structure and consistent content.

[0089] Step S13: Determine historical indicator data based on the actual manpower data, the case data, the functional point scale data, and the historical evaluation data;

[0090] It is understandable that historical indicator data consists of actual manpower data, case data, feature point scale data, and historical evaluation data. These four types of data are linked along time and project dimensions. Actual manpower data, case data, feature point scale data, and historical evaluation data for the same historical project are bound together by project number. For example, the actual manpower data during the testing phase of a historical project, the test case data, feature point scale data, and evaluation deviation data for that project are linked to the same project number. Then, the linked data from different projects are sorted chronologically. Outlier handling is then performed, such as removing outliers in the actual manpower data that far exceed the average level of similar projects and revising logically flawed test step descriptions in the case data, resulting in accurate and orderly historical indicator data.

[0091] Step S14: Determine system characteristic data based on the system complexity factor and the project risk factor;

[0092] It is understandable that the system characteristic data consists of system complexity factors and project risk factors. The two types of data are then integrated and correlated along risk dimensions. System complexity factors are linked to technical implementation risk factors within project risk factors; for example, a higher system complexity factor score typically corresponds to a higher level of risk in the corresponding technical implementation risk factor. Furthermore, all project risk factors, such as requirement change risk factors, environmental instability risk factors, and cross-team collaboration risk factors, are categorized by their risk impact area, such as technical risks and management risks, forming a risk classification system. The integrated system complexity factors and project risk factors are then quantitatively analyzed to ensure that each factor has a clear quantitative indicator or score, resulting in structured and accurate system characteristic data.

[0093] Step S15: Determine training multi-source project data based on the product information data, the historical indicator data, and the system feature data.

[0094] It is understandable that the multi-source training project data consists of product information data, historical indicator data, and system feature data. These three types of data are uniformly linked along the project dimension. Product information data, historical indicator data, and system feature data for the same project are bound together by project number. For example, function-related information from a project's product information data, human resources and case information from historical indicator data, and complexity and risk information from system feature data are linked to the same project number, ensuring that multi-dimensional data for the same project can be matched. The linked data is then comprehensively validated and formatted, eliminating logical inconsistencies, such as discrepancies between the number of function points in product information data and the scale of function points in historical indicator data. After correction, a complete and consistent multi-source training project data set is formed.

[0095] Step S20: Parse the unstructured data of the training multi-source project data to obtain the function implementation process, and convert the function implementation process into a function feature vector;

[0096] It should be noted that unstructured data refers to data types in multi-source project data that do not have a fixed data format. In this embodiment, it mainly refers to requirement documents and development details in product information data. This type of data usually exists in the form of natural language text and cannot be directly analyzed and utilized through traditional structured data processing methods.

[0097] The function implementation process is a procedural description of how specific functions in a software product are implemented. It is extracted from key content in the requirements document and development details, and includes the steps of function execution, the business data operations involved, and the goals to be achieved. It can clearly show the operational logic of the software function.

[0098] Furthermore, the functional feature vector is a vector-form data obtained by numerically converting the functional implementation process.

[0099] Understandably, unstructured data, namely requirement documents and development details, is selected from the multi-source project data used for training. Parsing code is written to process this unstructured data, extracting key content related to functionality, such as business process descriptions, functional operation instructions, and business data interaction rules. Next, a large model is used to further process the extracted key content, identifying standard functional implementation processes based on the definition of basic functional processes, verb and noun combination requirements, operational requirements for business data, and relevant examples. Finally, each identified functional implementation process is converted into a functional feature vector, completing the transformation from unstructured data to numerical data and providing standardized data input for subsequent model training.

[0100] Step S30: Normalize the structured data of the training multi-source project data to obtain standard numerical data;

[0101] It is understood that structured data refers to data with a fixed data format and a clear data type in the training multi-source project data. In this embodiment, it mainly includes the actual input per person / day, number of cases, functional point scale, and historical evaluation data in historical indicator data, as well as system complexity factors and project risk factor scores in system characteristic data.

[0102] It should be noted that standard numerical data is obtained by normalizing the structured data in the multi-source project data for training. Its values ​​are all within the range of [0, 1], and the differences in the units of the original data are eliminated. This standardized data format can provide a unified data input standard for subsequent functional recognition training, case recognition training and risk-weighted training, and ensure the consistency and accuracy of data processing during model training.

[0103] Understandably, structured data is selected from the multi-source project data used for training. This primarily includes actual personnel / days of input, number of cases, functional point scale, historical evaluation data, system complexity factors, and project risk factor scores. Then, the original numerical range for each type of structured data is determined, i.e., the maximum and minimum values ​​for each data type are identified. Next, the min-max normalization method is used to normalize each type of structured data, transforming each data value to the [0,1] interval using the formula (original data value - original minimum value) / (original maximum value - original minimum value). All normalized structured data is then integrated to form standard numerical data, providing a unified data format for subsequent model training.

[0104] It should be understood that normalizing the structured data in the multi-source project training data to obtain standard numerical data can eliminate the influence of differences in units and numerical ranges between different structured data. For example, the numerical range of actual input per person per day may be much larger than the numerical range of the number of cases. Without normalization, the model may be overly biased towards data with a large numerical range during training, ignoring the influence of data with a small numerical range. After normalization, all data are within the [0, 1] interval, have the same magnitude and comparability, and can ensure that the model can perform fair and accurate analysis of different types of structured data during training, improving the effectiveness of model training and the reliability of subsequent demand analysis results.

[0105] Step S40: Perform function identification training, case identification training, and risk-weighted training based on the functional feature vector and / or the standard numerical data to obtain a requirements analysis model, and then perform project requirements analysis based on the requirements analysis model.

[0106] It should be noted that the function recognition training is a model training process based on the function feature vector and historical function point data in the standard numerical data. Its purpose is to build a model module that can predict the number of function points based on the function feature vector by analyzing the correlation between the function feature vector and the number of function points in the historical data, so as to provide support for the estimation of function point scale in subsequent project requirements analysis.

[0107] In addition, case recognition training is model training based on function recognition training, combined with historical case data in standard numerical data. Its core is to explore the inherent pattern between the number of function points and the number of test cases, and to establish a model module that corresponds the number of function points and the number of test cases, so as to estimate the number of test cases based on the predicted number of function points.

[0108] In addition, risk-weighted training combines the results of functional identification training and case identification training with system feature data in standard numerical data to carry out model training. By quantitatively analyzing the impact of project risk factors on test time, a model module that correlates risk and test time is constructed, enabling the model to estimate time while taking risk factors into account.

[0109] In addition, the requirements analysis model is a comprehensive model formed by integrating function identification training, case identification training, and risk weighting training. This model can receive project requirement-related data and output project requirements analysis results through internal modules such as function point prediction, case number estimation, and risk weighting time calculation, providing a scientific basis for project requirements analysis.

[0110] Understandably, the process involves functional identification training. This involves inputting functional feature vectors and historical functional point data from standard numerical data into the training model. Multiple basic processes are identified from historical project requirement documents and development detail documents. These basic processes, parsed from the functional point library, are used as the retrieval enhancement generation database (RAG database). The identified basic processes are then input, and the top K most relevant segments (K being an adjustable parameter) are identified. Combined with a weight matrix, the corresponding number of functional points and the total number of functional points in the project are calculated, training to obtain the predicted correlation between functional points. Next, case identification training is performed. Assuming a correlation between the total number of cases and the number of functional points, the predicted correlation between functional points obtained from the functional identification training and historical case data from standard numerical data are input into the model to train and determine the correspondence between the number of cases and the number of functional points. Then, risk-weighted training is conducted. Risk factors such as whether high-risk functions are included and project importance are scored according to a level, and the total rating score is obtained. The risk ratings and scores of historical projects are weighted and normalized to obtain risk scoring factors. These factors are combined with system characteristic factors and preset logic to train relevant parameters in the calculation of test design time, test execution time, and test management time, resulting in risk-time correlation rules. Finally, by integrating the results of functional recognition training, case recognition training, and risk-weighted training, a requirements analysis model capable of performing project requirements analysis is formed, which can then be used to analyze project requirements.

[0111] In one feasible implementation, step S40 may include steps S41 to S44:

[0112] Step S41: Perform function recognition training based on the historical function point data of the functional feature vector and the standard numerical data to obtain the function point prediction association relationship;

[0113] It should be noted that historical function point data is an important component of standard numerical data. It comes from the statistical records of function points in past software projects and includes quantitative information such as the total number of actual function points in historical projects and the number of function points corresponding to each functional module. It can reflect the functional scale of past projects and provide historical reference for function recognition training.

[0114] Furthermore, the function point prediction correlation is the output of function recognition training. It is the correspondence rule or mapping relationship between the function feature vector and the predicted number of function points. Subsequently, based on this relationship, the function feature vector corresponding to the new requirement can be input to directly obtain the predicted number of function points of the new requirement, providing a basis for estimating the functional scale of the project.

[0115] Understandably, historical function point data is extracted from standard numerical data to clarify the total number of actual function points in past projects and the number of function points in each functional module. Simultaneously, the function feature vectors obtained from the initial processing are organized to ensure that each function feature vector corresponds to a specific function implementation process in past projects. The basic historical function processes in the historical function point data are parsed and imported into a retrieval enhancement generation database to construct the database foundation for semantic matching. Then, the function implementation process corresponding to the function feature vector is used as input to the retrieval enhancement generation database. A semantic matching algorithm identifies the Top K most relevant historical basic function processes for each function implementation process, where K is an adjustable parameter. Next, a preset weight matrix is ​​introduced, and the Top K most relevant historical basic function processes for each function implementation process are weighted according to the weight matrix to obtain the predicted number of function points for each function implementation process. The predicted number of function points for all function implementation processes is summarized, and combined with the actual total function point data of historical projects, the weight matrix parameters are adjusted to control the error between the predicted number of function points and the actual historical function point data within a preset range. Based on the adjusted parameters, a stable correspondence rule between the function feature vector and the predicted number of function points is determined, forming a function point prediction correlation relationship.

[0116] Step S42: Perform case recognition training based on the predicted functional point association and historical case data of the standard numerical data to obtain the case functional association.

[0117] It should be noted that the case function association is the output of case recognition training. It is the corresponding rule or mapping relationship between the predicted number of function points and the estimated number of test cases. Subsequently, based on this relationship and the predicted number of function points for new requirements, the estimated number of test cases for new requirements can be directly obtained, providing a basis for test resource allocation and test schedule planning.

[0118] Understandably, algorithms such as linear regression are used to analyze the changing patterns between the predicted number of feature points and the number of historical test cases. For example, the ratio coefficient or fitting function between the number of test cases and the predicted number of feature points is calculated. Based on the algorithm analysis results, a stable correspondence rule between the predicted number of feature points and the estimated number of test cases is determined, forming a case-function correlation relationship.

[0119] In one feasible implementation, step S42 may include steps S421 to S425:

[0120] Step S421: Obtain the preset weight matrix and determine the number of predicted function points based on the standard numerical data;

[0121] It should be noted that the preset weight matrix is ​​the basic matrix used for subsequent weighted calculations of the target project processes. Its internal elements are the weight coefficients corresponding to different project processes. These weight coefficients are preset based on the actual contribution of each process to the number of function points in historical projects.

[0122] Furthermore, the predicted number of function points is a preliminary estimate based on historical function point data from standard numerical data. This estimation process references the average function point size of historical projects and statistical values ​​of function point sizes for similar projects.

[0123] Understandably, a pre-configured weight matrix is ​​retrieved from the pre-configured parameter storage area. The dimensions of this matrix match the number of categories in common project processes, and each element corresponds to the initial weight of a specific project process. The rules for adjusting this matrix based on actual calculation results are also clearly defined. Next, historical function point data is extracted from the standard numerical data, including the total number of actual function points in different past projects, the number of function points corresponding to each functional module, and auxiliary information such as the functional type of the project's business domain. Then, based on the business attributes of the current project, historical projects in the same business domain and functional type as the current project are selected from the standard numerical data, and statistical indicators such as the average and median of the total number of actual function points in these historical projects are calculated. Finally, considering the differences between the number of functional modules and business complexity of the current project and the selected historical projects, the statistical indicators are adjusted to obtain the predicted number of function points.

[0124] Step S422: parse the historical function point data of the standard numerical data to obtain the initial project process, and construct a retrieval enhancement generation database based on the initial project process;

[0125] It should be noted that the initial project process is obtained by parsing historical functional point data and is an independent process that reflects the specific workflow of functional implementation. Each initial project process corresponds to the implementation steps of one or more functional points and must meet the expression requirements of a verb-noun combination, including operations on business data.

[0126] Furthermore, the retrieval-enhanced generative database is a dedicated database for storing and retrieving initial project processes. This database receives queries, quickly locates and returns the initial project processes most relevant to the query content using semantic matching algorithms, providing efficient data retrieval support for accurately identifying target project processes from a large number of initial project processes, ensuring the accuracy and efficiency of the retrieval process.

[0127] Understandably, extracting complete historical function point data from standard numerical data, including a list of function points for each historical project and corresponding business process documents and development design specifications, ensures that the extracted data fully covers the entire process of function implementation without missing any critical steps. Parsing code is written to process the extracted historical function point data. The code automatically extracts business process steps, function operation descriptions, and business data interaction rules from the data. Then, based on the definition of the basic functional process—that is, including operations on business data and expressed using a combination of verbs and nouns—multiple independent initial project processes are identified and broken down. For example, from the historical function point data of the order payment function, the initial project processes such as payment amount verification, payment channel selection, payment request sending, and payment result receiving can be parsed. Each broken-down initial project process is structured, supplementing metadata such as the number of function points associated with the corresponding historical project's business domain and functional module, forming standardized initial project process records. All standardized initial project processes and their corresponding metadata are imported into a retrieval enhancement generation database, and semantic matching algorithms, such as word vector-based similarity calculation algorithms, are configured to complete the database construction.

[0128] Step S423: Identify target project processes in the retrieval enhancement generation database according to the functional feature vector, wherein the target project process represents a project process associated with the functional feature vector, and the number of target project processes is a preset number of associated processes;

[0129] It should be noted that the target project process is the initial project process retrieved from the retrieval-enhanced database that has the highest semantic relevance to the functional feature vector. Its core functional logic is consistent with or highly similar to the current project's functional implementation process corresponding to the functional feature vector, providing direct and relevant historical reference for calculating the number of functional points in the current project.

[0130] Furthermore, the preset number of associated processes is a pre-defined number of processes retrieved from the search enhancement generation database for the target project. This number is typically determined based on the richness of historical project data and the complexity of the current project's functionality.

[0131] Understandably, the functional feature vectors are preprocessed to check if their vector dimensions and numerical formats are consistent with the requirements of the semantic matching algorithm in the retrieval enhancement generation database. If the vector dimensions do not match, a dimension transformation algorithm is used to adjust the functional feature vectors to the dimensions required by the algorithm; if the numerical format does not meet the requirements, standardization is performed to ensure that the functional feature vectors can be processed normally by the semantic matching algorithm. Next, the preprocessed functional feature vectors are input into the retrieval enhancement generation database, triggering the semantic matching algorithm in the database. This algorithm calculates the similarity between the functional feature vectors and the vectors corresponding to each initial project process in the database (which have been converted to vectors when the initial project processes are entered into the database), such as cosine similarity. The higher the similarity value, the higher the semantic correlation between the two. Then, all initial project processes are sorted in descending order of similarity, and those with the highest similarity values ​​and values ​​greater than a preset threshold are selected. The number of selected initial project processes is counted. If the number is exactly equal to the preset number of associated processes, these processes are directly identified as target project processes; if the number is greater than the preset number of associated processes, the preset number of processes with the highest similarity are selected as target project processes.

[0132] Step S424: Perform a weighted calculation on the target project process according to the preset weight matrix to obtain the target function points;

[0133] It should be noted that the target function point count is the number of function points obtained by weighting the historical function points corresponding to all target project processes, combined with the weighting coefficients in the preset weight matrix. This value comprehensively reflects the contribution of each target project process to the current project's function point scale, and is key data for subsequent comparative analysis with the predicted function point count, thereby determining the correlation between function point predictions and actual function point counts.

[0134] Understandably, it's crucial to ensure that each target project process has a corresponding weight coefficient within the preset weight matrix. If a mismatch exists between the target project process type and the matrix row category, the process type is reclassified and adjusted. From the historical function point data of the standard numerical data, the actual number of function points corresponding to each target project process in historical projects is extracted, ensuring a complete correspondence between the extracted historical function point counts and the target project processes, without data misalignment or confusion. Then, based on the type of each target project process, the corresponding weight coefficient is retrieved from the preset weight matrix. The historical actual function point count for each target project process is multiplied by the corresponding weight coefficient to obtain the weighted function point count for each target project process. Finally, the weighted function point counts of all target project processes are summed to obtain the target function point count corresponding to the current project function.

[0135] In this embodiment, the basic process is used as input, and the relationship between the basic process for identifying the Top K most relevant segments and the retrieval enhancement database is: A = M(B1, B2, ..., B k Let M be the weight matrix; then the number of function points corresponding to A is: C A =U*M(B1,B2...B k U is the weight matrix. The formula for calculating the target function points is as follows:

[0136]

[0137] In the formula, C1 represents the target function points; C A Indicates the number of function points; B1, B2, ..., B k This indicates that the content in the enhanced database is retrieved.

[0138] Step S425: Determine the function point prediction correlation based on the predicted function point count and the target function point count.

[0139] Understandably, the error between the predicted and target function points is calculated by dividing the absolute value of the difference between the predicted and target function points by the target function points, resulting in the error rate. Next, it is determined whether the calculated error rate is less than a preset error threshold. If the error rate is less than the preset threshold, it indicates a small difference between the predicted and target function points, and the preliminary estimation based on historical statistical data is highly consistent with the precise calculation based on specific historical processes. In this case, the correspondence between the function feature vector and the target function points can be directly identified as the core content of the function point prediction correlation. If the error rate is greater than or equal to the preset error threshold, it indicates a significant difference between the two calculation results. The cause of the difference needs to be analyzed, such as whether the business differences between the current project and historical projects have not been fully considered, or whether the preset weight matrix coefficients are unreasonable. Based on the analysis results, the correction rules for the predicted function points or the coefficients of the preset weight matrix should be adjusted, and the predicted or target function points should be recalculated until the error rate is less than the preset error threshold. The rules for matching the adjusted functional feature vectors with the corresponding number of functional points are organized into standardized functional point prediction associations to ensure that the associations have clear input-output logic and repeatability.

[0140] Step S43: Perform risk-weighted training based on the functional relationship of the case and the standard numerical data to obtain the risk-weighted training result;

[0141] It should be noted that the risk-weighted training result is the output of the risk-weighted training, which includes specific calculation rules for test design time, test execution time, and test management time. These rules fully incorporate the impact of system complexity factors and project risk factors. Subsequently, the test time for new requirements can be calculated based on these rules, providing risk-considered time data for project schedule planning.

[0142] Understandably, determining the product relationship and corresponding coefficients between test design time, estimated number of test cases, system complexity factor, and project risk factor score, and similarly analyzing the relationship between test execution time, test management time, and various influencing factors, allows for the determination of specific calculation rules for test design time, test execution time, and test management time, resulting in risk-weighted training results.

[0143] Step S44: Determine the demand analysis model based on the predicted correlation of the functional points, the correlation of the case functions, and the risk-weighted training results.

[0144] Understandably, the core components of the requirements analysis model are clearly defined, including a function size estimation module, a test case quantity estimation module, and a test time calculation module, corresponding to the predicted function point relationships, test case function relationships, and risk-weighted training results, respectively. Next, the data flow interaction logic between modules is constructed: the output of the function size estimation module is used as the input of the test case quantity estimation module, ensuring that the test case quantity estimation is based on function size data; simultaneously, the outputs of both the function size estimation and test case quantity estimation modules are used as inputs to the test time calculation module, combined with the system complexity factor and risk factor scores of the new requirements, to support the test time calculation. Compatibility checks are performed, such as checking whether the predicted function point quantity output of the function point prediction relationship meets the format requirements of the test case function relationship for input data, and whether the calculation rules of the risk-weighted training results are compatible with the output data of the first two modules. If incompatibility issues exist, the module rules are adjusted until they are compatible. Finally, the three validated modules and the interaction logic between them are integrated and encapsulated to form a complete requirements analysis model, ensuring that the model can receive input data from new requirements.

[0145] In one feasible implementation, step S43 may include steps S431 to S436:

[0146] Step S431: Obtain system characteristic factors, project design factors, project execution factors, and project management factors based on the standard numerical data;

[0147] Understandably, the system characteristic factor is an indicator used to quantitatively characterize the technical characteristics of the system involved in a software project. It is determined based on information such as system architecture complexity, technology stack difficulty, and inter-module dependencies. The larger the value, the higher the complexity of the system's technical aspects, and the greater the impact on the time of each stage of testing. It is a core technical dimension parameter that needs to be considered when calculating test time.

[0148] In addition, the project design factor is a quantitative indicator that reflects the characteristics of the test design phase of a software project. It is determined based on information such as the complexity of the test design document, the granularity of the test case design, and the frequency of design reviews. The value is positively correlated with the difficulty and workload of the test design work, and directly affects the calculation result of the test design time.

[0149] In addition, the project execution factor is a quantitative indicator that reflects the key characteristics of the software project test execution process. It is determined based on information such as the stability of the test environment, the difficulty of test data preparation, and the efficiency of defect repair. The higher the value, the more interference there may be or the greater the execution difficulty during the test execution process, and the more time needs to be invested to complete the test execution.

[0150] In addition, the project management factor is a quantitative indicator that measures the characteristics of the test management process in a software project. It is determined based on information such as project team size, frequency of cross-team collaboration, and schedule control requirements. The value reflects the complexity of test management work and has a direct impact on the estimation of test management time.

[0151] Step S432: Classify the standard numerical data to obtain target categories, and determine the risk score of the target categories;

[0152] It should be noted that the risk score is a quantitative score assigned to each target category according to its risk impact. The higher the score, the greater the impact of the risk corresponding to that category on the project testing time. It is a key step in transforming risk factors into quantifiable indicators that can be used for calculation, and provides a basis for adjusting the risk dimension for subsequent testing time.

[0153] The target category is a category formed by dividing risk-related data in standard numerical data according to risk type. Each category corresponds to a specific risk scenario.

[0154] Understandably, risk-related data is extracted from standard numerical data, including information such as whether high-risk functions are included, project importance rating, the proportion of functions involved in the restructuring, and the number of cross-system interactions, to ensure coverage of all potential risk dimensions throughout the project process. Next, the extracted data is categorized according to risk impact dimensions: "Whether high-risk functions are included" is divided into "Includes high-risk functions" and "Does not include high-risk functions"; "Project importance" is divided into three categories: "Projects of concern to bank leadership," "Key KPI projects for business departments," and "Ordinary projects"; "Scope of impact of changes" is divided into three categories: "Restructuring function proportion > 50%," "20% ≤ Restructuring function proportion ≤ 50%," and "Restructuring function proportion < 20%"; similar rules are applied to risk dimensions such as "Cross-system interactions" and "Personnel allocation" to form target categories. Then, a base score is assigned to each target category, with higher-risk impact categories having higher base scores than low-risk impact categories. For example, the base score for "Includes high-risk functions" is 0.8, and the base score for "Does not include high-risk functions" is 0.2. Finally, by combining the actual risk impact data of historical projects in the standard numerical data, such as the average test time of projects under the "containing high-risk functions" category being extended by 20%, the base score is adjusted to obtain the final risk score for each target category.

[0155] Step S433: Calculate the test design time based on the project design factors, the case function relationships, the system characteristic factors, and the risk score;

[0156] It should be noted that test design time is the time required to complete the test design work for the project, including the time spent on test plan development, test case design, test solution review, and other stages. Its calculation results directly provide the time basis for the design stage of the project test schedule planning.

[0157] Understandably, the test design time calculation formula is as follows:

[0158] T1 = x4 * V * i * j

[0159] In the formula, T1 is the test design time; x4 is the project design factor; V is the functional relationship of the case; j is the system characteristic factor; and i is the system characteristic factor.

[0160] Step S434: Calculate the test execution time based on the project execution factor, the case function relationship, the system characteristic factor, and the risk score;

[0161] It should be noted that test execution time is the time required to complete the execution of all test cases and defect verification in the project. It is a key time parameter in the execution phase of the project test schedule planning and directly affects the overall test cycle of the project.

[0162] Understandably, the test execution time is calculated as follows:

[0163] T2=x5*V*i*j

[0164] In the formula, T2 is the test execution time; x5 is the project execution factor; V is the case function relationship; j is the system characteristic factor; and i is the system characteristic factor.

[0165] Step S435: Calculate the test management time based on the project management factors, the case function relationships, the system characteristic factors, and the risk score;

[0166] It should be noted that test management time is the time required to complete management tasks such as project test plan development, team coordination, progress tracking, and risk control. It is a key time parameter in the management phase of project test schedule planning to ensure the orderly progress of testing.

[0167] Understandably, the formula for calculating test management time is as follows:

[0168] T3=x6*C*i*j

[0169] In the formula, T3 is the test management time; x6 is the project management factor; C is the case function relationship; j is the system characteristic factor; and i is the system characteristic factor.

[0170] Step S436: Determine the risk-weighted training result based on the test design time, the test execution time, and the test management time.

[0171] Understandably, the test design time, test execution time, and test management time obtained from steps S433, S434, and S435 are summarized, for example, 1.6 days, 2.0 days, and 0.8 days respectively. The total project testing time T = T1 + T2 + T3 is then calculated to form a time result set. Next, the calculation rules for the three types of time are organized, including the corresponding calculation formulas, basic coefficients, and parameter sources for each time, ensuring that the calculation rules are complete and traceable. Then, the time results and calculation rules are verified to confirm that the time values ​​are reasonable and that the calculation rules are logically consistent. The time result set and calculation rules are integrated to form a risk-weighted training result. This result includes both the specific testing time of the current project and general calculation logic that can be used for time estimation of new requirements.

[0172] Reference Figure 2 , Figure 2 This is a schematic diagram of the training process for the first embodiment of the requirements analysis method for this application.

[0173] like Figure 2As shown, the process starts from the beginning node and is divided into three parallel paths, processing historical requirement documents, historical detailed design documents, and historical feature point libraries, respectively. Each path first performs document parsing, converting unstructured data into structured data. In the path processing historical requirement documents, the parsed data is used for basic process identification, and then RAG retrieval is used to identify segments semantically related to the basic processes in the historical feature point library. In the path processing historical detailed design documents, the parsed data also undergoes RAG retrieval. The path processing the historical feature point library directly performs word vector conversion. All paths converge after RAG retrieval or word vector conversion and enter the mapping training stage. This stage uses historical project data to train relevant parameters to predict the number of feature points. Finally, all information is aggregated at the end node, completing the entire process. This flowchart echoes the technical solution described in the technical disclosure document, especially the multi-source data aggregation module and the multi-layer training module. Through steps such as parsing, identification, conversion, and training, they integrate multi-source heterogeneous data to improve the accuracy and efficiency of software requirement analysis and human assessment.

[0174] In one feasible implementation, step S432 may include: obtaining historical data related to project risks based on the standard numerical data, the historical data including high-risk function records, project importance markings, change impact scope statistics, cross-system interaction information, personnel configuration data, and risk response measure records; classifying the historical data to obtain risk data, target concern data, change impact scope data, and cross-system data; performing risk scoring on the risk data, target concern data, change impact scope data, and cross-system data to obtain risk data scores, target concern data scores, change impact scope data scores, and cross-system data scores; classifying the historical data based on the risk data scores, target concern data scores, change impact scope data scores, and cross-system data scores to obtain target categories, and determining the risk score for the target category.

[0175] It is understandable that the paragraph vector algorithm, also known as the document-to-vector (Doc2Vec) algorithm, processes each identified function implementation process, captures the overall semantic information of each function implementation process, and converts it into an m-dimensional (m is an adjustable parameter) function feature vector. This transforms the unstructured function implementation process text into a standardized numerical vector that can be used for subsequent function recognition training, ensuring that each function implementation process can participate in model training in a uniform numerical format, and providing structured data support for function point prediction based on historical data.

[0176] In one feasible implementation, after step S40, the following steps may be included: calling the requirements analysis model to identify the functional implementation process corresponding to the current requirements document; converting the functional implementation process of the current requirements document into a functional feature vector, inputting it into the functional point prediction association in the requirements analysis model to obtain the predicted number of functional points for the current requirement; calculating the predicted number of cases for the current requirement based on the predicted number of functional points for the current requirement, combined with the correspondence between the number of cases and the number of functional points in the requirements analysis model; conducting a risk factor assessment on the current requirement to determine the corresponding risk category and degree of impact, and calculating the test design time, test execution time, and test management time for the current requirement respectively, combined with the time calculation rules under the risk impact in the requirements analysis model; summarizing the predicted number of functional points, predicted number of cases, test design time, test execution time, test management time, and total time for the current requirement to form the project requirements analysis results.

[0177] Understandably, after obtaining the requirements analysis model, the model is first called to identify the functional implementation process corresponding to the current requirements document. Then, the functional implementation process is converted into a functional feature vector and input into the model's functional point prediction correlation to obtain the predicted number of functional points for the current requirements. Next, the predicted number of cases is calculated based on the correspondence between the number of cases and the number of functional points in the model. Subsequently, a risk factor assessment is performed on the current requirements to determine the risk category and degree of impact. Combined with the time calculation rules under the risk impact in the model, the test design time, test execution time, and test management time are calculated respectively. Finally, the predicted number of functional points, the predicted number of cases, and the three types of test times and the total time are summarized to form the project requirements analysis results.

[0178] Reference Figure 3 , Figure 3 This is a schematic diagram of the requirements document analysis process for the first embodiment of the requirements analysis method for this application project.

[0179] like Figure 3 As shown, the process begins with document parsing, which involves understanding and analyzing the requirements document. Next, basic process identification is performed, identifying the basic functional processes within the software requirements through document parsing. Then, feature size calculation is performed, estimating the number of functional points involved in the requirements; feature points are a way to measure software size. Following this, test case calculation is performed, predicting the number of test cases that may be needed in the requirements. After that, time calculation is performed, estimating the time required to complete the requirements. Finally, output is provided, showing the results of the calculations and offering a basis for software project planning and resource allocation.

[0180] This embodiment provides a project requirements analysis method. By acquiring and integrating multi-source project data, including product information data, historical indicator data, and system feature data, unstructured data parsing and structured data normalization processing are performed. Then, these data are used for function recognition training, case recognition training, and risk-weighted training. This solves the technical problems of insufficient accuracy and low efficiency in software requirements analysis and human assessment in the prior art, and achieves the beneficial effects of improving assessment accuracy, enhancing assessment measurability, reducing dependence on personnel, and improving assessment efficiency.

[0181] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 Step S20 of the project requirements analysis method includes steps S21 to S23:

[0182] Step S21: Effective content extraction is performed on the unstructured data of the training multi-source project data to obtain project requirement data, wherein the unstructured data includes requirement documents and detailed development design documents;

[0183] It should be understood that effective content extraction is the process of screening, organizing, and refining requirements documents and detailed development design documents from unstructured data. It focuses on retaining key information related to project requirements and functional implementation, while eliminating redundant descriptions, formatting instructions, irrelevant notes, and other invalid content to ensure that the extracted information focuses on core requirements and technical requirements.

[0184] It should be noted that the project requirement data is a structured information set obtained by extracting effective content. It includes the software project's function list, function description, technical implementation requirements, business data rules, etc. It can clearly reflect the project's requirement boundaries and implementation goals, and serves as a direct basis for subsequent identification of the function implementation process.

[0185] Furthermore, the detailed design document is a document that describes the technical details of the software project's functional implementation. It covers the code design logic of functional modules, the data interaction process between modules, the data storage structure, the definition of interface parameters, the exception handling mechanism, etc., and is used to clarify the technical path and specifications for functional implementation.

[0186] In addition, the requirements document is the core document that records the user requirements, business requirements and functional requirements of the software project. It includes the user's specific requirements for the software functions, description of business scenarios, functional input and output rules, functional boundary definitions and other content, which directly reflects the user and business goals that the project needs to meet.

[0187] Understandably, the focus of the extraction process for the requirements document is on business process descriptions, functional requirements, and functional input / output requirements. For the detailed development design document, the focus is on extracting the implementation logic of functional modules, data interaction rules between modules, and interface parameter definitions. Then, the parsing code is run to batch process the requirements and detailed development design documents, automatically filtering and extracting valid content according to the extraction rules. Simultaneously, the extracted content undergoes preliminary validation, correcting ambiguous or logically contradictory information. Finally, the extracted and validated valid content is organized according to functional modules, requirement descriptions, and technical requirements to form structured project requirement data.

[0188] Step S22: Identify the functional implementation process of the project requirement data;

[0189] It should be noted that the function implementation process is a complete description of the entire process of a single function in a software project from triggering to completion. It can clearly show the execution steps, logical relationships and data interactions of the function, and is the core object for subsequent conversion into function feature vectors.

[0190] Understandably, project requirement data is structured and broken down into multiple functional units, each corresponding to an independent software function. Next, a large model is used to process the requirement data for each functional unit. Based on the defined rules of the function implementation process, the function implementation process is extracted and identified from the requirement data. For example, from the requirement data for user registration (entering a mobile phone number, obtaining a verification code, entering the verification code, setting a password, verifying the mobile phone number format, verifying the verification code validity, and storing user information), the function implementation process of entering the user's mobile phone number, obtaining the mobile phone verification code, entering the verification code, setting the user's password, verifying the mobile phone number format, verifying the verification code validity, and storing user information is identified. The identified function implementation processes are verified to ensure that each process conforms to the standardized description, includes business data operations, and has no missing core functional steps. The verified function implementation processes are then categorized and stored by functional unit, forming a set of function implementation processes.

[0191] Step S23: Convert the function implementation process into a function feature vector according to the paragraph vector algorithm.

[0192] It should be noted that the paragraph vector algorithm, also known as the document-to-vector (Doc2Vec) algorithm, is a machine learning algorithm used to convert unstructured text paragraphs into low-dimensional dense numerical vectors. This algorithm can capture the overall semantic information of text paragraphs. Through training on a large amount of text data, it maps semantically similar paragraphs to vectors that are close in distance in the vector space, realizing the numerical representation of text information, which is convenient for subsequent analysis and calculation through the algorithm model.

[0193] Understandably, all identified functional implementation processes undergo text preprocessing to remove special symbols and standardize the formatting, ensuring consistent text formatting for each process and meeting the input requirements of the paragraph vector algorithm. Next, the paragraph vector algorithm model is initialized, setting parameters such as vector dimension *m*, number of training iterations, and learning rate. The preprocessed text of the functional implementation processes is then used as the training corpus input to the model. The model is then trained: it learns the semantic associations between the functional implementation process texts, generating a unique *m*-dimensional numerical vector—the functional feature vector—for each process. During training, the model's prediction error is calculated, and the parameters are continuously adjusted until the model converges and the vector representation accuracy meets the requirements. Finally, the functional feature vectors corresponding to all functional implementation processes are output and stored according to functional units, providing standardized numerical data for constructing the predictive relationships of functional points in subsequent functional recognition training.

[0194] This embodiment provides a project requirements analysis method. By effectively extracting key project requirements information from unstructured data, identifying the functional implementation process, and using the paragraph vector algorithm to convert these processes into functional feature vectors, it solves the technical problem of accurately parsing and quantifying software requirements documents and design documents in traditional methods. This achieves the beneficial effects of improving the automation level of software requirements analysis, enhancing the accuracy of functional point prediction, and improving the overall evaluation efficiency.

[0195] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the requirements analysis method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0196] This application also provides a project requirements analysis device, please refer to... Figure 5 The project requirements analysis device includes:

[0197] The data acquisition module 10 is used to acquire training multi-source project data, wherein the training multi-source project data includes product information data, historical indicator data, and system feature data;

[0198] Data parsing module 20 is used to parse the unstructured data of the training multi-source project data to obtain the function implementation process, and convert the function implementation process into a function feature vector;

[0199] The data normalization module 30 normalizes the structured data of the training multi-source project data to obtain standard numerical data.

[0200] The model training module 40 is used to perform function recognition training, case recognition training, and risk-weighted training based on the functional feature vector and / or the standard numerical data to obtain a requirements analysis model, so as to perform project requirements analysis based on the requirements analysis model.

[0201] The project requirements analysis apparatus provided in this application, employing the project requirements analysis method described in the above embodiments, can solve the technical problem of how to conduct project requirements analysis based solely on requirements information in the early stages of a project. Compared with the prior art, the beneficial effects of the project requirements analysis apparatus provided in this application are the same as those of the project requirements analysis method provided in the above embodiments, and other technical features in the project requirements analysis apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0202] In one embodiment, the model training module 40 is further configured to perform function recognition training based on the functional feature vector and historical function point data of the standard numerical data to obtain function point prediction correlation; perform case recognition training based on the function point prediction correlation and historical case data of the standard numerical data to obtain case function correlation; perform risk-weighted training based on the case function correlation and the standard numerical data to obtain risk-weighted training results; and determine the requirements analysis model based on the function point prediction correlation, the case function correlation, and the risk-weighted training results.

[0203] In one embodiment, the model training module 40 is further configured to: acquire a preset weight matrix; determine the number of predicted function points based on the standard numerical data; parse the historical function point data of the standard numerical data to obtain an initial project process; construct a retrieval enhancement generation database based on the initial project process; identify a target project process in the retrieval enhancement generation database based on the function feature vector, wherein the target project process represents a project process associated with the function feature vector, and the number of target project processes is a preset number of associated processes; perform a weighted calculation on the target project process based on the preset weight matrix to obtain the number of target function points; and determine the function point prediction association relationship based on the number of predicted function points and the number of target function points.

[0204] In one embodiment, the model training module 40 is further configured to: acquire system characteristic factors, project design factors, project execution factors, and project management factors based on the standard numerical data; classify the standard numerical data to obtain target categories and determine the risk score of the target categories; calculate the test design time based on the project design factors, the case function relationships, the system characteristic factors, and the risk score; calculate the test execution time based on the project execution factors, the case function relationships, the system characteristic factors, and the risk score; calculate the test management time based on the project management factors, the case function relationships, the system characteristic factors, and the risk score; and perform risk-weighted training based on the case function relationships and the standard numerical data to obtain risk-weighted training results.

[0205] In one embodiment, the model training module 40 is further configured to acquire historical data related to project risks based on the standard numerical data. The historical data includes high-risk function records, project importance markings, statistics on the scope of impact of changes, cross-system interaction information, personnel configuration data, and risk response measures records. The historical data is then categorized to obtain risk data, target concern data, change impact scope data, and cross-system data. Risk scores are then applied to the risk data, target concern data, change impact scope data, and cross-system data to obtain risk data scores, target concern data scores, change impact scope data scores, and cross-system data scores. Based on the risk data scores, target concern data scores, change impact scope data scores, and cross-system data scores, the historical data is categorized to obtain target categories, and a risk score for each target category is determined.

[0206] In one embodiment, the data parsing module 20 is further configured to extract effective content from the unstructured data of the training multi-source project data to obtain project requirement data, wherein the unstructured data includes requirement documents and detailed development design documents; identify the functional implementation process of the project requirement data; and convert the functional implementation process into functional feature vectors according to the paragraph vector algorithm.

[0207] In one embodiment, the data acquisition module 10 is further configured to acquire requirement document data, detailed design data, function point data, actual manpower data, case data, function point scale data, historical evaluation data, system complexity factor, and project risk factor scores; determine product information data based on the requirement document data, the detailed design data, and the function point data; determine historical indicator data based on the actual manpower data, the case data, the function point scale data, and the historical evaluation data; determine system characteristic data based on the system complexity factor and the project risk factor; and determine training multi-source project data based on the product information data, the historical indicator data, and the system characteristic data.

[0208] This application provides a project requirements analysis device, which includes: 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, which are executed by the at least one processor to enable the at least one processor to perform the project requirements analysis method in Embodiment 1 above.

[0209] The following is for reference. Figure 6 The diagram illustrates a structural schematic of a project requirements analysis device suitable for implementing embodiments of this application. The project requirements analysis device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The project requirements analysis equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0210] like Figure 6As shown, the project requirements analysis device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the project requirements analysis device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the project requirements analysis equipment to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a project requirements analysis equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0211] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0212] The project requirements analysis device provided in this application, employing the project requirements analysis method described in the above embodiments, can solve the technical problem of how to conduct project requirements analysis based solely on requirements information in the early stages of a project. Compared with the prior art, the beneficial effects of the project requirements analysis device provided in this application are the same as those of the project requirements analysis method provided in the above embodiments, and other technical features of the project requirements analysis device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0213] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0214] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0215] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the project requirements analysis method described in the above embodiments.

[0216] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), Erasable Programmable Read Only Memory (EPROM), optical fiber, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0217] The aforementioned computer-readable storage medium may be included in the project requirements analysis equipment; or it may exist independently and not be assembled into the project requirements analysis equipment.

[0218] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the project requirements analysis device, the project requirements analysis device performs the following actions: acquires training multi-source project data, wherein the training multi-source project data includes product information data, historical indicator data, and system characteristic data; parses the unstructured data of the training multi-source project data to obtain a functional implementation process, and converts the functional implementation process into a functional feature vector; normalizes the structured data of the training multi-source project data to obtain standard numerical data; and performs functional identification training, case identification training, and risk-weighted training based on the functional feature vector and / or the standard numerical data to obtain a requirements analysis model, and performs project requirements analysis based on the requirements analysis model.

[0219] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0220] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0221] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0222] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described project requirements analysis method. This solves the technical problem of how to conduct project requirements analysis based solely on requirements information in the early stages of a project. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the project requirements analysis method provided in the above embodiments, and will not be elaborated upon here.

[0223] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the project requirements analysis method described above.

[0224] The computer program product provided in this application can solve the technical problem of how to conduct project requirements analysis based solely on requirements information in the early stages of a project. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the project requirements analysis method provided in the above embodiments, and will not be repeated here.

[0225] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A project requirements analysis method, characterized in that, The method includes: Acquire training multi-source project data, wherein the training multi-source project data includes product information data, historical indicator data, and system feature data; The unstructured data of the training multi-source project data is parsed to obtain the functional implementation process, and the functional implementation process is converted into a functional feature vector; The structured data of the training multi-source project data is normalized to obtain standard numerical data; Based on the functional feature vector and / or the standard numerical data, functional identification training, case identification training, and risk-weighted training are performed to obtain a requirements analysis model, which is then used to perform project requirements analysis.

2. The method as described in claim 1, characterized in that, The steps of performing functional identification training, case identification training, and risk-weighted training based on the functional feature vector and / or the standard numerical data to obtain the requirements analysis model include: Based on the functional feature vector and the historical functional point data of the standard numerical data, functional recognition training is performed to obtain the functional point prediction association relationship; Based on the predicted correlation of the functional points and the historical case data of the standard numerical data, case recognition training is performed to obtain the functional correlation of the cases. Risk-weighted training is performed based on the functional relationships of the cases and the standard numerical data to obtain the risk-weighted training results. The requirement analysis model is determined based on the predicted correlation of the functional points, the correlation of the case functions, and the risk-weighted training results.

3. The method as described in claim 2, characterized in that, The step of performing function recognition training based on the functional feature vector and historical function point data of the standard numerical data to obtain the function point prediction association includes: Obtain the preset weight matrix and determine the number of predicted function points based on the standard numerical data; The historical function point data of the standard numerical data is parsed to obtain the initial project process, and a retrieval enhancement generation database is constructed based on the initial project process; Based on the functional feature vector, target project processes are identified in the retrieval enhancement generation database, wherein the target project process represents a project process associated with the functional feature vector, and the number of target project processes is a preset number of associated processes; The target project process is weighted and calculated according to the preset weight matrix to obtain the target function points; The function point prediction correlation is determined based on the predicted function point count and the target function point count.

4. The method as described in claim 2, characterized in that, The step of performing risk-weighted training based on the functional relationships of the cases and the standard numerical data to obtain the risk-weighted training result includes: Based on the aforementioned standard numerical data, obtain system characteristic factors, project design factors, project execution factors, and project management factors; The standard numerical data is classified to obtain target categories, and the risk score of the target category is determined. The test design time is calculated based on the project design factors, the case function relationships, the system characteristic factors, and the risk score. The test execution time is calculated based on the project execution factors, the case function relationships, the system characteristic factors, and the risk score. The test management time is calculated based on the project management factors, the case function relationships, the system characteristic factors, and the risk score. The risk-weighted training results are determined based on the test design time, the test execution time, and the test management time.

5. The method as described in claim 4, characterized in that, The steps of classifying the standard numerical data to obtain target categories and determining the risk score of the target categories include: Historical data related to project risks are obtained based on the standard numerical data. The historical data includes records of high-risk functions, project importance markings, statistics on the scope of impact of changes, cross-system interaction information, personnel configuration data, and records of risk response measures. The historical data is categorized to obtain risk data, target concern data, data on the scope of impact of changes, and cross-system data; Risk scores are performed on the risk data, the target concern data, the scope of impact data of the changes, and the cross-system data to obtain risk data scores, target concern data scores, scope of impact data scores, and cross-system data scores. The historical data is classified according to the risk data score, the target focus data score, the scope of impact of the change data score, and the cross-system data score to obtain the target category, and the risk score of the target category is determined.

6. The method as described in claim 1, characterized in that, The steps of parsing the unstructured data of the training multi-source project data to obtain the function implementation process and converting the function implementation process into a function feature vector include: Effective content extraction is performed on the unstructured data of the training multi-source project data to obtain project requirement data, wherein the unstructured data includes requirement documents and detailed development design documents; The process of implementing the function to identify the project requirement data; The functional implementation process is converted into a functional feature vector using the paragraph vector algorithm.

7. The method as described in claim 1, characterized in that, The steps for obtaining training multi-source project data include: Obtain data from requirements documents, detailed design data, functional point data, actual manpower data, case data, functional point scale data, historical evaluation data, system complexity factors, and project risk factor scores; Product data is determined based on the requirements document data, the detailed design data, and the functional point data. Historical indicator data are determined based on the actual human resources data, the case data, the functional point scale data, and the historical evaluation data. Determine system characteristic data based on the system complexity factor and the project risk factor; Training multi-source project data is determined based on the product information data, the historical indicator data, and the system feature data.

8. A project requirements analysis device, characterized in that, The device includes: The data acquisition module is used to acquire training multi-source project data, wherein the training multi-source project data includes product information data, historical indicator data, and system feature data; The data parsing module is used to parse the unstructured data of the training multi-source project data to obtain the function implementation process, and convert the function implementation process into a function feature vector; The data normalization module is used to normalize the structured data of the training multi-source project data to obtain standard numerical data. The model training module is used to perform function recognition training, case recognition training, and risk-weighted training based on the functional feature vector and / or the standard numerical data to obtain a requirements analysis model, so as to perform project requirements analysis based on the requirements analysis model.

9. A project requirements analysis device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the project requirements analysis method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the project requirements analysis method as described in any one of claims 1 to 7.

Images