System function demand quantity prediction method and device, equipment and program product
By training the time series prediction model and comprehensively considering factors such as the number of working days and the number of employees, the problem of low accuracy in predicting the number of system functional requirements in existing technologies is solved, higher prediction accuracy and rationality of resource planning are achieved, and software system optimization and iteration are supported.
Patent Information
- Application Number
- CN202510703158.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-28
- Publication Date
- 2025-09-26
AI Technical Summary
In existing technologies, when predicting the number of system function requirements for software systems, enterprises can usually only make predictions based on the average value of historical demand quantity data. This results in a single data dimension being considered and ignores various actual factors such as the number of working days and the number of employees. This leads to low prediction accuracy, affecting the rationality of resource planning and the iterative process of software system optimization.
By training a time series forecasting model, comprehensively considering multi-dimensional factors such as the number of working days and the number of employees, and using the time series model to analyze data change trends, we can generate demand quantity forecast results, including historical trend charts, monthly seasonality charts, working day quantity relationship charts, and employee quantity relationship charts, and optimize model parameters to improve forecast accuracy.
It improves the accuracy of the prediction of the number of system functional requirements, helps enterprises to arrange resources rationally, and ensures the smooth completion of the software system optimization and iteration process.
Smart Images

Figure CN120706744A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data analysis technology, and in particular to a method, device, electronic device, computer program product, and computer-readable storage medium for predicting the number of system function requirements. Background Art
[0002] For frequently used software systems within an enterprise, such as office systems, internal management systems, or business systems, a certain number of system function requirements are periodically submitted to the digitalization department, which then implements the corresponding functions. To better formulate resource plans, the digitalization department sometimes needs to forecast the number of system function requirements for future time periods. However, currently, this forecast is typically based only on the average of historical demand data, considering a single data dimension. This results in low accuracy in system function requirement forecasts, making it difficult to formulate reasonable resource plans, and ultimately hindering the optimization and iteration process of these software systems. Summary of the Invention
[0003] In view of this, the embodiments of the present application provide a method, device, electronic device, computer program product and computer-readable storage medium for predicting the number of system function requirements, which can improve the accuracy of predicting the number of system function requirements, so as to formulate reasonable resource planning and ensure the smooth completion of the software system optimization iterative process.
[0004] A first aspect of an embodiment of the present application provides a method for predicting the number of system function requirements, including:
[0005] Determine the projected number of workdays and projected number of employees for the future time period;
[0006] The expected number of working days and the expected number of employees are input into the trained demand quantity prediction model for processing to obtain the forecast results of the system function demand quantity in the future time period; among which, the demand quantity prediction model is a time series prediction model trained based on the historical number of working days, historical number of employees and historical number of system function demands in the historical time period, and is used to predict the system function demand quantity.
[0007] In the technical solution of the embodiment of the present application, the number of historical working days, the number of historical employees, and the number of historical system function requirements for a historical time period are collected in advance, and a time series prediction model for predicting the number of system function requirements is trained based on these data as a demand quantity prediction model; after determining the expected number of working days and the expected number of employees for the future time period, the expected number of working days and the expected number of employees are input into the demand quantity prediction model for processing, and the prediction result of the number of system function requirements for the future time period can be predicted. Since the demand quantity prediction model comprehensively considers the actual impact of multi-dimensional factors such as the number of working days and the number of employees on the number of system function requirements, and the use of a time series model can accurately analyze the changing trend of the number of system function requirements, it can effectively improve the accuracy of predicting the number of system function requirements, thereby facilitating the formulation of reasonable resource planning and ensuring the smooth completion of the software system optimization iteration process.
[0008] In one implementation of the embodiment of the present application, the method further includes:
[0009] Perform data visualization analysis on historical time periods, historical number of working days, historical number of employees, and historical number of system function requirements, and generate visualization charts to represent the changing characteristics of the number of system function requirements.
[0010] In one implementation of the embodiment of the present application, the visualization chart includes a historical trend chart, a monthly seasonality chart, a workday quantity relationship chart, and an employee quantity relationship chart; the historical trend chart is used to represent the trend of the number of historical system function requirements changing over the historical time period; the monthly seasonality chart is used to analyze the average number of system function requirements in each month and identify the monthly seasonality pattern; the workday quantity relationship chart is used to represent the trend of the number of historical system function requirements changing over the number of historical workdays; and the employee quantity relationship chart is used to represent the trend of the number of historical system function requirements changing over the number of historical employees; generating a visualization chart for characterizing the characteristics of the change in the number of system function requirements includes:
[0011] Generate historical trend charts and monthly seasonal charts based on historical time periods and historical system function requirements;
[0012] Generate a working day quantity relationship graph based on historical time periods, historical system function requirements, and historical working day quantities;
[0013] Generate an employee quantity relationship diagram based on historical time periods, historical system function requirements, and historical employee numbers.
[0014] In one implementation of the embodiment of the present application, the demand quantity prediction model is trained and obtained by:
[0015] Read historical time periods, historical number of working days, historical number of employees, and historical number of system function requirements;
[0016] Convert historical time periods into corresponding date data;
[0017] Identify date data, historical number of working days, historical number of employees, and historical number of system function requirements as historical data sets;
[0018] Based on the historical data set, a demand quantity prediction model is trained.
[0019] In one implementation of the embodiment of the present application, a demand quantity prediction model is trained based on a historical data set, including:
[0020] Determine the optimal model parameter combination of the initial time series forecasting model based on the historical data set;
[0021] Use the optimal model parameter combination to configure the initial time series forecasting model;
[0022] Add the number of working days and the number of employees as external regressors to the initial time series forecasting model;
[0023] The initial time series forecasting model is optimized and trained based on the historical data set to obtain the final time series forecasting model, and the final time series forecasting model is determined as the trained demand quantity forecasting model.
[0024] In one implementation of the embodiment of the present application, determining the optimal model parameter combination of the initial time series prediction model based on the historical data set includes:
[0025] Obtaining multiple preset sets of initial model parameter combinations;
[0026] Use historical data sets to cross-validate multiple sets of initial model parameter combinations and determine the prediction error corresponding to each set of initial model parameter combinations;
[0027] The initial model parameter combination with the smallest corresponding prediction error is determined as the optimal model parameter combination.
[0028] In one implementation of an embodiment of the present application, each set of initial model parameter combinations includes its own seasonal prior scale and change point prior scale. The seasonal prior scale is a parameter that controls the model's sensitivity to seasonal changes, and the change point prior scale is a parameter that controls the model's flexibility to trend change points.
[0029] In one implementation of the embodiment of the present application, configuring an initial time series prediction model includes:
[0030] Configure the model parameters of the initial time series forecasting model using the growth and seasonality patterns.
[0031] In one implementation of the embodiment of the present application, after obtaining the prediction result of the number of system function requirements in the future time period, the method further includes:
[0032] Based on the forecast results of the number of system function requirements in the future time period, a comprehensive forecast chart, a forecast value table and a seasonal component chart are generated; among them, the comprehensive forecast chart displays the forecast results of the number of system function requirements in the future time period in the form of a graphic, the forecast value table displays the forecast results of the number of system function requirements in the future time period in the form of a table, and the seasonal component chart is used to analyze the seasonal impact of different months on the number of system function requirements.
[0033] In one implementation of the embodiment of the present application, the method further includes:
[0034] Based on the demand quantity forecasting model, the system function demand quantity forecast results for the historical time period are obtained;
[0035] The performance of the demand quantity prediction model is evaluated based on the historical system function demand quantity and the system function demand quantity prediction results of the historical time period.
[0036] In one implementation of the embodiment of the present application, determining the expected number of working days and the expected number of employees in a future time period includes:
[0037] Obtain administrative planning information and human resource indicator information corresponding to future time periods;
[0038] Determine the expected number of working days based on administrative planning information;
[0039] Determine the expected number of employees based on human resource indicator information.
[0040] A second aspect of an embodiment of the present application provides a device for predicting the number of system function requirements, including:
[0041] A data determination module for determining the expected number of working days and the expected number of employees for a future time period;
[0042] The demand quantity prediction module is used to input the expected number of working days and the expected number of employees into the trained demand quantity prediction model for processing to obtain the prediction results of the system function demand quantity in the future time period; wherein, the demand quantity prediction model is a time series prediction model trained based on the historical number of working days, historical number of employees and historical system function demand quantity in the historical time period, and is used to predict the system function demand quantity.
[0043] A third aspect of an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the method for predicting the number of system function requirements as provided in the first aspect of the embodiment of the present application is implemented.
[0044] A fourth aspect of the embodiments of the present application provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes the method for predicting the number of system function requirements provided by the first aspect of the embodiments of the present application.
[0045] The fifth aspect of the embodiments of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the method for predicting the number of system function requirements as provided in the first aspect of the embodiments of the present application.
[0046] It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS
[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0048] Figure 1 This is a flowchart of a method for predicting the number of system function requirements provided by an embodiment of the present application;
[0049] Figure 2 This is a schematic diagram of a welcome interface of a demand quantity forecasting system provided in an embodiment of the present application;
[0050] Figure 3 This is a partial data diagram of a historical data file read by a demand quantity forecasting system provided in an embodiment of the present application;
[0051] Figure 4 This is a schematic diagram of a visual chart interface of a demand quantity forecasting system provided by an embodiment of the present application;
[0052] Figure 5 This is a schematic diagram of a forecast setting interface of a demand quantity forecasting system provided in an embodiment of the present application;
[0053] Figure 6 This is a schematic diagram of a forecast result interface of a demand quantity forecasting system provided in an embodiment of the present application;
[0054] Figure 7 This is a schematic diagram of a model performance evaluation interface of a demand quantity forecasting system provided in an embodiment of the present application;
[0055] Figure 8 This is a schematic diagram of the structure of a device for predicting the number of system function requirements provided by an embodiment of the present application;
[0056] Figure 9 This is a schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0057] In the following description, for the purpose of illustration rather than limitation, specific details such as specific system structures and technologies are provided to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obstructing the description of the present application with unnecessary details. In addition, in the description of the present application specification and the appended claims, the terms "first," "second," "third," etc. are only used to distinguish descriptions and are not to be understood as indicating or implying relative importance.
[0058] Accurately forecasting the number of system function requirements is crucial within enterprises. However, current forecasts are typically based on the average of historical demand data. For example, this approach simply calculates the average number of system function requirements over the past six or twelve months as a forecast for future requirements. This approach considers a single data dimension and ignores the impact of various real-world factors, such as the number of workdays and the number of employees, on the number of system function requirements. Consequently, forecast accuracy is low.
[0059] To address the above issues, embodiments of the present application propose a method, apparatus, electronic device, computer program product, and computer-readable storage medium for predicting the number of system function requirements. By considering the actual impact of multi-dimensional data such as the number of workdays and the number of employees on the number of system function requirements, and analyzing data change trends using a time series model, the accuracy of predicting the number of system function requirements can be effectively improved. For more specific technical implementation details of the embodiments of the present application, please refer to the various method embodiments described below.
[0060] It should be understood that the execution subjects of the various method embodiments proposed in the present application can be various types of electronic devices, such as mobile phones, tablet computers, desktop computers, wearable devices, augmented reality (AR) / virtual reality (VR) devices, laptop computers, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), large-screen TVs, etc. The embodiments of the present application do not impose any restrictions on the specific types of the electronic devices.
[0061] See also Figure 1 , shows a method for predicting the number of system function requirements provided by an embodiment of the present application, including:
[0062] 101. Determine the expected number of working days and the expected number of employees for the future period;
[0063] The purpose of the technical solution of the embodiment of the present application is to achieve high-accuracy prediction of the number of system function requirements for various common software systems such as office systems, internal management systems or business systems. This will enable the development department to arrange human and material resources more reasonably, so that these software systems can smoothly complete the optimization and iteration process. The specific technical implementation content is described below.
[0064] The embodiment of the present application comprehensively considers the actual impact of multi-dimensional data such as the number of working days and the number of employees on the number of system function requirements. When predicting the number of system function requirements for a future time period, it is necessary to first determine the expected number of working days and the expected number of employees for the future time period. Among them, the future time period can be one or more time periods of any time interval in the future, such as the next month, the next year, every week in the next month, every month in the next year, every quarter in the next year, every year in the next 10 years, and so on. The embodiment of the present application does not impose any restrictions on this. If there are multiple future time periods that need to be predicted, then for each future time period, it is necessary to determine the corresponding expected number of working days and expected number of employees respectively. For example, assuming that it is necessary to predict the number of system function requirements for each month in the next 6 months, it is necessary to determine the expected number of working days and expected number of employees corresponding to each month in the next 6 months, and so on.
[0065] Typically, the projected number of workdays and employees for future time periods can be determined and entered manually through internal company assessments. For example, the projected number of employees for each future time period can be estimated and entered by human resources personnel, and the projected number of workdays for each future time period can be entered by administrative personnel after confirming the workday schedule. Alternatively, the projected number of workdays and employees for future time periods can be automatically determined by electronic devices through data analysis. For example, the projected number of employees for each future time period can be determined by analyzing the company's current employee count and development plan data; the projected number of workdays for each future time period can be determined by analyzing statutory holidays and the company's historical workday schedule, and so on.
[0066] In one implementation of the embodiment of the present application, determining the expected number of working days and the expected number of employees in a future time period includes:
[0067] (1) Obtain administrative planning information and human resource indicator information corresponding to the future time period;
[0068] (2) Determine the estimated number of working days based on administrative planning information;
[0069] (3) Determine the expected number of employees based on human resource indicator information.
[0070] After determining the future time period that needs to be predicted, the administrative planning information and human resource index information corresponding to the future time period are obtained. The expected number of working days can be automatically determined based on the administrative planning information, and the expected number of employees can be automatically determined based on the human resource index information. Specifically, the administrative planning information usually includes the workday arrangements for each future time period, based on which the corresponding expected number of working days can be determined. For example, the expected number of working days for April to September are 22, 19, 20, 23, 21, and 23 respectively. Human resource index information usually includes employee demand indicators for each future time period, based on which the corresponding expected number of employees can be determined. For example, the expected number of employees for April to September are 336, 343, 350, 326, 333, and 339 respectively. Through this setting, the expected number of working days and the expected number of employees can be obtained conveniently and more accurately, thereby improving the degree of automation of demand quantity forecasting.
[0071] 102. Input the estimated number of working days and the estimated number of employees into the trained demand quantity prediction model for processing to obtain the forecast results of the system function demand quantity in the future time period. The technical solution of the embodiment of the present application uses a time series model to analyze the data change trend. It is necessary to pre-train a time series prediction model as a demand quantity prediction model to predict the system function demand quantity. The time series prediction model can be various types of models such as a Prophet model, an ARIMA / SARIMA model, an LSTM / GRU model or an XGBoost model. For example, the Prophet model can be selected, which can automatically identify seasonal characteristics and is suitable for prediction tasks with multiple seasonal and special event impacts.
[0072] Before training the model, you need to obtain historical data related to the demand quantity. This historical data usually includes the historical number of working days, historical number of employees, and historical number of system function requirements in each historical time period. For example, the number of working days, number of employees on the job, and number of system function requirements in each month in the past year.
[0073] In practice, a demand quantity forecasting system can be developed that, when run in an electronic device, first demonstrates Figure 2 The welcome interface shown is used to introduce the system functions and uses to users, and includes information such as the system title, trademark, and introduction text. Figure 2 The interface shown illustrates how the system uses the advanced Prophet algorithm, combining historical data patterns with multi-dimensional influencing factors, to provide users with accurate demand quantity forecasts. After clicking "Get Started" on the welcome screen, users can select a historical data file in a specified format (e.g., CSV or XLS) to read. The system then parses the data and performs basic validation. It also automatically calculates and displays basic data statistics, such as the number of rows and columns, time range, and key forecast indicators.
[0074] As an example, Figure 3 It is a schematic diagram of part of the data of a historical data file that has been read. Figure 3The historical data shown includes four key fields: application_date, workdays_count, staff_num, and request_count. Application_date is the month identifier, such as 2022-08 (August 2022) or 2022-09 (September 2022). Workdays_count is the number of workdays in the month, typically ranging from 18 to 23. Staff_num is the number of employees on staff that month, representing the number of people who may request system functionality. Request_count is the number of system functionality requests submitted that month. These fields form the basic input data for the demand quantity forecasting model, with request_count serving as the forecast target and the other fields as auxiliary forecasting factors.
[0075] After reading historical data files, the system can preprocess the data. For example, it can convert the string identifying the month in application_date into the beginning of the month in datatime format to ensure the consistency and coherence of the time series. It can also extract key fields and convert them into the data format required by time series forecasting models such as Prophet. In addition, the number of workdays (workdays_count) and the number of employees (staff_num) are key regression variables and can be retained directly during the data preprocessing stage.
[0076] The collected historical data files can be used to generate corresponding visualization charts to characterize the changing characteristics of the number of system function requirements, and can also be used to train the above-mentioned demand quantity prediction model, which are explained in detail below.
[0077] In one implementation of the embodiment of the present application, the method further includes:
[0078] Perform data visualization analysis on historical time periods, historical number of working days, historical number of employees, and historical number of system function requirements, and generate visualization charts to represent the changing characteristics of the number of system function requirements.
[0079] By visually analyzing historical data such as historical time periods, historical number of working days, historical number of employees, and historical number of system function requirements, corresponding visualization charts can be generated and displayed through the system software interface. In this way, users can intuitively view the historical change trend of the number of system function requirements and understand the actual impact of the number of working days and the number of employees on the number of system function requirements.
[0080] In one implementation of the embodiment of the present application, the visualization chart includes a historical trend chart, a monthly seasonality chart, a workday quantity relationship chart, and an employee quantity relationship chart; the historical trend chart is used to represent the trend of the number of historical system function requirements changing over the historical time period; the monthly seasonality chart is used to analyze the average number of system function requirements in each month and identify the monthly seasonality pattern; the workday quantity relationship chart is used to represent the trend of the number of historical system function requirements changing over the number of historical workdays; and the employee quantity relationship chart is used to represent the trend of the number of historical system function requirements changing over the number of historical employees; generating a visualization chart for characterizing the characteristics of the change in the number of system function requirements includes:
[0081] (1) Generate historical trend charts and monthly seasonal charts based on historical time periods and historical system function requirements;
[0082] (2) Generate a working day quantity relationship diagram based on the historical time period, the number of historical system function requirements, and the number of historical working days;
[0083] (3) Generate an employee quantity relationship diagram based on the historical time period, the number of historical system function requirements and the historical number of employees.
[0084] Visualization charts may include historical trend charts, monthly seasonality charts, working day quantity relationship charts, and employee quantity relationship charts. Among them, the historical trend chart is used to represent the trend of the number of historical system function requirements changing with the historical time period. It can be generated based on the historical time period and the number of historical system function requirements. Its horizontal axis is time and the vertical axis is the number of system function requirements. Through the historical trend chart, users can intuitively view the long-term trend, seasonal fluctuations and outliers of the number of system function requirements changing with time. The monthly seasonality chart is used to analyze the average number of system function requirements in each month and identify monthly seasonal patterns. It can be generated based on the historical time period and the number of historical system function requirements. Its horizontal axis is month (January-December) and the vertical axis is the average number of system function requirements in each month. Through the monthly seasonality chart, users can analyze monthly seasonal patterns, such as whether there are regular peaks in the number of requirements at the beginning or middle of the year. The Workday Quantity Relationship Chart is used to show how the number of historical system function requirements changes over the number of historical workdays. It can be generated based on the historical time period, the historical number of system function requirements, and the historical number of workdays. The horizontal axis represents the number of workdays, and the vertical axis represents the number of system function requirements. Using the Workday Quantity Relationship Chart, users can analyze the impact of workday factors on the number of system function requirements. Generally, a greater number of workdays indicates a greater number of system function requirements. The Employee Quantity Relationship Chart is used to show how the number of historical system function requirements changes over the number of historical employees. It can be generated based on the historical time period, the historical number of system function requirements, and the historical number of employees. The horizontal axis represents the number of employees, and the vertical axis represents the number of system function requirements. Using the Employee Quantity Relationship Chart, users can analyze the impact of the number of employees on the number of system function requirements. Generally, a greater number of employees indicates a greater number of system function requirements. Additionally, the Workday Quantity Relationship Chart and the Employee Quantity Relationship Chart can generate optimal trend lines using polynomial fitting, intuitively displaying linear or nonlinear relationships between variables without manual adjustment. These visualization charts integrate visual analysis of four dimensions: time trends, seasonal cycles, workday impacts, and manpower impacts. They can form a complete decision support system, seamlessly integrate data visualization with the interactive interface, and support users to zoom in, out, and interactively explore data.
[0085] As an example, Figure 4 This is an interface diagram of the four types of visualization charts provided in the embodiments of this application. Figure 4 The upper left corner is a historical trend chart. The fluctuation curve of the historical trend chart shows the trend of the number of system function requirements changing over time. Figure 4 The upper right corner is the monthly seasonality chart, which shows the average number of system function requirements in different months; Figure 4 The lower left corner is the employee quantity relationship graph. Through the scatter points and trend lines of the employee quantity relationship graph, we can see the relationship between the number of employees and the number of system function requirements; Figure 4 The lower right corner shows a graph of the number of workdays. The scatter plots and trend lines in this graph show the relationship between the number of workdays and the number of system functional requirements. These visualizations help users understand data relationships and provide important intuition for subsequent forecasting models, guiding the selection of model parameters.
[0086] Next, the configuration and training process of the demand quantity forecasting model is described. The core of the process is to obtain the best forecasting model through cross-validation and parameter optimization.
[0087] In one implementation of the embodiment of the present application, the demand quantity prediction model is trained and obtained by:
[0088] (1) Read historical time periods, historical number of working days, historical number of employees, and historical number of system function requirements;
[0089] (2) Convert the historical time period into the corresponding date data;
[0090] (3) Determine date data, historical number of working days, historical number of employees, and historical number of system function requirements as the historical data set;
[0091] (4) Based on the historical data set, a demand quantity prediction model is trained.
[0092] By reading historical data files, we can obtain the historical number of workdays, historical employee numbers, and historical system function requirements for each time period. To ensure the consistency and coherence of the time series, during the data preprocessing phase, we convert the historical time periods into corresponding date data. For example, as described above, we convert the month identifiers into the corresponding first-of-month dates. Then, we define the date data, historical number of workdays, historical number of employees, and historical system function requirements as a historical dataset. Based on this historical dataset, we train a time series forecasting model to serve as the demand quantity forecasting model.
[0093] In one implementation of the embodiment of the present application, a demand quantity prediction model is trained based on a historical data set, including:
[0094] (1) Determine the optimal model parameter combination of the initial time series forecasting model based on the historical data set;
[0095] (2) Use the optimal model parameter combination to configure the initial time series forecasting model;
[0096] (3) Add the number of working days and the number of employees as external regressors to the initial time series forecasting model;
[0097] (4) Optimize and train the initial time series prediction model based on the historical data set to obtain the final time series prediction model, and determine the final time series prediction model as the trained demand quantity prediction model.
[0098] In order to obtain the best forecasting model, an initial time series forecasting model can be set up first. Based on the above historical data set, the optimal model parameter combination of the initial time series forecasting model can be determined. Here, a cross-validation method can be used to test the model performance corresponding to different model parameter combinations to find the optimal configuration. Then, the model parameters of the initial time series forecasting model are configured using the determined optimal model parameter combination. Considering that the number of working days and the number of employees are important factors affecting the number of system functional requirements, the number of working days and the number of employees are added as external regression variables to the forecasting model to achieve multi-factor collaborative forecasting, which can improve the accuracy of the forecast. Finally, the initial time series forecasting model is optimized and trained based on the above historical data set until a final time series forecasting model with performance that meets the requirements is obtained, which is used as the trained demand quantity forecasting model.
[0099] In one implementation of the embodiment of the present application, determining the optimal model parameter combination of the initial time series prediction model based on the historical data set includes:
[0100] (1) Obtaining multiple preset sets of initial model parameter combinations;
[0101] (2) Use historical data sets to cross-validate multiple sets of initial model parameter combinations and determine the prediction error corresponding to each set of initial model parameter combinations;
[0102] (3) The initial model parameter combination with the smallest corresponding prediction error is determined as the optimal model parameter combination.
[0103] When searching for the optimal model parameter combination through cross-validation, a parameter grid is first defined, obtaining multiple preset initial model parameter combinations. The system then tests these initial model parameter combinations, configures cross-validation parameters, sets the initial training period, validation period, and prediction range, and performs cross-validation using the historical dataset. This system then determines the prediction error for each initial model parameter combination. The prediction error can be expressed as mean absolute error, root mean square error, or mean absolute percentage error, among other criteria. For example, if the prediction model parameters are adjusted to initial model parameter combination A, the prediction error of the prediction model evaluated based on the historical dataset is X. If the prediction model parameters are adjusted to initial model parameter combination B, the prediction error of the prediction model evaluated based on the historical dataset is Y. Then, the prediction error corresponding to initial model parameter combination A is X, the prediction error corresponding to initial model parameter combination B is Y, and so on. Finally, the initial model parameter combination with the smallest prediction error is selected as the optimal model parameter combination. This process involves a grid search approach to finding the optimal parameter combination, which can also be replaced by a random search. Furthermore, the optimal model parameter combination and its performance metrics are displayed on the system's software interface for user review. It can be seen that cross-validation can easily find the optimal model parameter combination without the need for time-consuming and labor-intensive manual parameter adjustment, thereby greatly improving the training efficiency of the prediction model.
[0104] In one implementation of an embodiment of the present application, each set of initial model parameter combinations includes its own seasonal prior scale and change point prior scale. The seasonal prior scale is a parameter that controls the model's sensitivity to seasonal changes, and the change point prior scale is a parameter that controls the model's flexibility to trend change points.
[0105] The optimal model parameters found in the embodiments of the present application may include a seasonal prior scale and a change point prior scale. The seasonal prior scale is a parameter that controls the model's sensitivity to seasonal changes; the larger its value, the more sensitive the model is to seasonal changes; the change point prior scale is a parameter that controls the model's flexibility to trend change points; the larger its value, the easier it is for the trend line to generate change points in historical data; the smaller its value, the smoother the trend line. Each set of initial model parameter combinations is made to include its own seasonal prior scale and change point prior scale. In this way, after determining the optimal model parameter combination, the optimal seasonal prior scale and change point prior scale can be obtained.
[0106] As an example, one could define the following parameter grid:
[0107] param_grid = {
[0108] 'seasonality_prior_scale':[0.1, 1.0, 5.0],
[0109] 'changepoint_prior_scale':[0.01, 0.05, 0.1]}
[0110] Here, "seasonality_prior_scale" represents the seasonality prior scale, with possible values of 0.1, 1.0, and 5.0; "changepoint_prior_scale" represents the changepoint prior scale, with possible values of 0.01, 0.05, and 0.1, resulting in a total of nine parameter combinations. The system uses historical datasets for cross-validation, testing the forecast errors corresponding to each of these nine parameter combinations to identify the one with the lowest forecast error: "seasonality_prior_scale = 5.0, changepoint_prior_scale = 0.05." Choosing a higher value of 5.0 for the seasonality prior scale allows the forecast model to more sensitively capture seasonal patterns in the data, improving model performance and forecast accuracy. Choosing a moderate value of 0.05 for the changepoint prior scale strikes a balance between flexibility and stability in trend capture.
[0111] In one implementation of the embodiment of the present application, configuring an initial time series prediction model includes:
[0112] Configure the model parameters of the initial time series forecasting model using the growth and seasonality patterns.
[0113] When configuring a forecasting model, you can configure the growth and seasonality patterns used by its model parameters. The growth pattern can be configured as linear or logistic. Linear growth assumes data grows at a constant rate, with no upper limit. This appears in the forecasting model as a straight line with a constant slope. Logistic growth does not grow at a constant rate; it has an upper limit. The seasonal pattern can be configured as multiplicative or additive. Multiplicative seasonality is a pattern in which the seasonal effect is proportional to the overall trend level. In this pattern, as the underlying trend increases, the amplitude of seasonal fluctuations also increases. This is suitable for scenarios where seasonal fluctuations are positively correlated with the underlying level. Additive seasonality is a pattern in which the seasonal effect is independent of the underlying trend. In this pattern, the amplitude of seasonal fluctuations remains constant and does not change with changes in the underlying trend. This is suitable for scenarios where the amplitude of seasonal fluctuations is stable. By properly configuring the growth and seasonality patterns of the forecasting model, you can enhance the flexibility and generalizability of the forecasting model.
[0114] The following is the code implementation for configuring and training a Prophet forecasting model:
[0115] final_model = Prophet(
[0116] growth='linear',#Configure linear growth mode
[0117] seasonality_mode = 'multiplicative', #Configures the multiplicative seasonality mode
[0118] yearly_seasonality=True,
[0119] weekly_seasonality=False,
[0120] daily_seasonality=False,
[0121] seasonality_prior_scale=best_params['seasonality_prior_scale'],
[0122] changepoint_prior_scale=best_params['changepoint_prior_scale'] )
[0124] #Add regression variables, including the number of working days and the number of employees
[0125] final_model.add_regressor('workdays_count')
[0126] final_model.add_regressor('staff_num')
[0127] #fit model
[0128] final_model.fit(prophet_df)
[0129] The parameter optimization process for the Prophet forecasting model described above is automated, eliminating the need for manual verification of model performance for different parameters. The system cross-validates different combinations of seasonality_prior_scale and changepoint_prior_scale values to find the most optimal parameter combination for the current data forecast, thereby improving the model's forecast accuracy. Furthermore, during model training, the system updates the training progress bar and log in real time, allowing users to track the model's training progress.
[0130] Before performing demand quantity forecasting, users can complete the forecast settings through the software interface of the demand quantity forecasting system described above. As an example, Figure 5 This is a diagram of a forecast setting interface of a demand quantity forecasting system provided by an embodiment of the present application. Figure 5 In the interface shown, users can perform operations such as cross-validation settings, forecast period settings, and future data input. Cross-validation settings can set the initial training period (e.g., 730 days), validation period range (e.g., 180 days), model growth type (e.g., linear growth), and seasonality (e.g., multiplicative seasonality). Forecast period settings allow users to select the number of future time periods they wish to forecast, such as 1-6 months. Future data input is a table interface, where users can enter the expected number of workdays and employees for each future time period (e.g., each month) within the forecast period.
[0131] After completing the forecast setup, train and run the demand quantity forecasting model to obtain forecast results for system function demand quantities for each future time period within the forecast period. These system function demand quantity forecasts typically include the predicted value, upper and lower bounds of the forecast interval, data trend, and seasonality. Generating a confidence interval (e.g., 90%) for the forecast value provides risk assessment and uncertainty quantification for decision-making, enhancing the practicality of the forecast results.
[0132] In one implementation of the embodiment of the present application, after obtaining the prediction result of the number of system function requirements in the future time period, the method further includes:
[0133] Based on the forecast results of the number of system function requirements in the future time period, a comprehensive forecast chart, a forecast value table and a seasonal component chart are generated; among them, the comprehensive forecast chart displays the forecast results of the number of system function requirements in the future time period in the form of a graphic, the forecast value table displays the forecast results of the number of system function requirements in the future time period in the form of a table, and the seasonal component chart is used to analyze the seasonal impact of different months on the number of system function requirements.
[0134] The demand quantity forecasting system can provide functions such as forecast result visualization and data export. For forecast result visualization, a comprehensive forecast chart, forecast value table, and seasonal component chart can be generated based on the forecast results of the system function demand quantity for future time periods. Among them, the comprehensive forecast chart, also known as the main forecast chart, records the demand quantity forecast values corresponding to each future time period and can include scatter plots and trend lines. The forecast value table displays the demand quantity forecast values corresponding to each future time period in tabular form, and can specifically include fields such as the forecast date, demand quantity forecast value, lowest possible value (90% confidence interval lower limit), and highest possible value (90% confidence interval upper limit). The seasonal component chart displays the annual seasonal pattern, indicating the seasonal impact of different months on the system function demand quantity, which can help understand the cyclical changes in demand quantity. For data export, the system provides forecast result export functions in different data formats. For example, the forecast results can be exported as a csv file, or various forecast charts can be exported as image files such as png.
[0135] As an example, Figure 6 This is a schematic diagram of the forecast result interface of a demand quantity forecasting system provided in an embodiment of the present application. Figure 6 Above is the comprehensive forecast chart, the black scatter points represent various historical data points, the solid line represents the trend line of the model fitting, the vertical dotted line represents the forecast starting line, that is, the left side of the vertical dotted line is the historical data, and the right side is the forecast result data, the horizontal dotted line represents the mean baseline of the demand quantity, and the gray area represents the forecast confidence interval. Figure 6 The lower left corner is the forecast value table, which records the forecast value of demand quantity, the lowest possible value and the highest possible value for 6 different forecast dates. Figure 6 The lower right corner is the seasonal component graph, which reveals the seasonal impact of different months on the number of system function requirements. It can be seen that there are peaks in the number of requirements in February-March and August-September.
[0136] In addition, the demand quantity forecasting system also has a model evaluation function, which can provide a comprehensive forecasting model performance analysis so that users can understand the credibility of the model prediction results.
[0137] In one implementation of the embodiment of the present application, the method further includes:
[0138] (1) Based on the demand quantity forecasting model, the system function demand quantity forecast results for the historical time period are obtained;
[0139] (2) Based on the historical system function demand quantity and the system function demand quantity prediction results of the historical time period, the performance of the demand quantity prediction model is evaluated.
[0140] By using the trained demand quantity prediction model to predict historical data, the number of system function requirements for the historical time period predicted by the model can be obtained. Then, the number of system function requirements for the historical time period predicted by the model is compared with the actual number of system function requirements in the historical period, and the error between the two is calculated to determine the prediction accuracy of the demand quantity prediction model, thereby completing the corresponding model performance evaluation. Specifically, the performance indicators for evaluation may include: mean absolute error, root mean square error, mean absolute percentage error, and determination coefficient. Among them, the mean absolute error is the average of the absolute difference between the predicted value and the actual value. This indicator directly reflects the average degree to which the prediction deviates from the actual value. The unit is consistent with the original data, which is convenient for understanding the prediction accuracy; the root mean square error is the square root of the average value of the prediction error. This indicator gives higher weight to large errors and can better reflect the impact of abnormal predictions. It is often used to evaluate the overall performance of the prediction model; the mean absolute percentage error is the average percentage of the prediction error to the actual value. This indicator expresses the relative accuracy of the prediction in the form of a percentage, is not affected by the magnitude of the original data, and is convenient for comparison across data sets; the determination coefficient (R 2 , R-squared) is a statistical indicator that measures the model's ability to explain data variation. Its value ranges from 0 to 1. This value indicates the proportion of dependent variable variation that the model can explain. The closer the value is to 1, the higher the degree of model fit and the stronger the predictive ability. In addition to calculating the above four performance indicators, the system can also generate and display scatter plots and residual analysis graphs of actual and predicted values. The scatter plots intuitively show the comparison between the model's predicted values and the actual values, and the residual analysis graphs show the distribution of prediction residuals (the difference between the actual and predicted values) over time. Through such settings, a complete model evaluation framework with multiple performance indicators can be constructed to comprehensively evaluate the performance of the prediction model from different angles. Moreover, through the dual visualization of scatter plots and residual analysis graphs, the temporal pattern and numerical distribution characteristics of the prediction error can be revealed.
[0141] As an example, Figure 7 This is a schematic diagram of a model performance evaluation interface of a demand quantity forecasting system provided in an embodiment of the present application. Figure 7The top of the chart shows the values of four performance indicators: (1) mean absolute error of 4.26; (2) root mean square error of 5.83; (3) mean absolute percentage error of 29.74%; and (4) coefficient of determination of 0.8194. These performance indicators comprehensively reflect the fitting quality and prediction accuracy of the prediction model on historical data. The lower left corner of the performance indicator display area is a scatter plot of actual values and predicted values, with the horizontal axis being the actual value and the vertical axis being the predicted value. The diagonal dotted line is the perfect prediction line where the actual value = predicted value. The lower right corner of the performance indicator display area is a trend line comparison chart of actual values and predicted values. The degree of fit between the two trend lines intuitively reflects the model's ability to fit historical data and the size of the prediction accuracy. Through these two comparison charts, the comparison between the model's predicted value and the actual value can be intuitively displayed. Figure 7 At the bottom is the residual analysis chart, where the horizontal axis is time and the vertical axis is the residual value (actual value - predicted value). The horizontal dotted line is the perfect prediction line with residual value = 0. Through this residual analysis chart, we can intuitively observe the trend of prediction residual changes over time, thereby revealing the systematic deviation of the prediction model and providing help for further optimization of model performance.
[0142] In the technical solution of the embodiment of the present application, the number of historical working days, the number of historical employees, and the number of historical system function requirements for a historical time period are collected in advance, and a time series prediction model for predicting the number of system function requirements is trained based on these data as a demand quantity prediction model; after determining the expected number of working days and the expected number of employees for the future time period, the expected number of working days and the expected number of employees are input into the demand quantity prediction model for processing, and the prediction result of the number of system function requirements for the future time period can be predicted. Since the demand quantity prediction model comprehensively considers the actual impact of multi-dimensional factors such as the number of working days and the number of employees on the number of system function requirements, and the use of a time series model can accurately analyze the changing trend of the number of system function requirements, it can effectively improve the accuracy of predicting the number of system function requirements, thereby facilitating the formulation of reasonable resource planning and ensuring the smooth completion of the software system optimization iteration process.
[0143] In summary, the embodiments of this application provide a method that integrates multi-dimensional features such as time, number of employees, and number of workdays, and combines them with a time series analysis algorithm. By using a machine learning model to analyze historical data on the number of system function requirements within an enterprise, future demand trends can be predicted. Furthermore, an interactive visual interface can be used to display the entire prediction process, achieving accurate predictions of system function requirements and providing corresponding technical support for development resource planning.
[0144] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0145] The above mainly describes a method for predicting the number of system function requirements. The following will describe a device for predicting the number of system function requirements.
[0146] See also Figure 8 , shows a device for predicting the number of system function requirements provided by an embodiment of the present application, including:
[0147] The data determination module 801 is used to determine the expected number of working days and the expected number of employees in a future time period;
[0148] The demand quantity prediction module 802 is used to input the expected number of working days and the expected number of employees into the trained demand quantity prediction model for processing to obtain the system function demand quantity prediction results for the future time period; wherein the demand quantity prediction model is a time series prediction model trained based on the historical number of working days, historical number of employees and historical system function demand quantity in the historical time period, and is used to predict the system function demand quantity.
[0149] In one implementation of the embodiment of the present application, the device for predicting the number of system function requirements further includes:
[0150] The visualization chart generation module is used to perform data visualization analysis on historical time periods, historical number of working days, historical number of employees and historical number of system function requirements, and generate visualization charts to represent the changing characteristics of the number of system function requirements.
[0151] In one implementation of the embodiment of the present application, the visualization chart includes a historical trend chart, a monthly seasonality chart, a workday quantity relationship chart, and an employee quantity relationship chart; the historical trend chart is used to represent the trend of the number of historical system function requirements changing with the historical time period; the monthly seasonality chart is used to analyze the average number of system function requirements in each month and identify the monthly seasonal pattern; the workday quantity relationship chart is used to represent the trend of the number of historical system function requirements changing with the number of historical workdays; the employee quantity relationship chart is used to represent the trend of the number of historical system function requirements changing with the number of historical employees; the visualization chart generation module includes:
[0152] A first chart generating unit is configured to generate a historical trend chart and a monthly seasonal chart based on a historical time period and a historical number of system function requirements;
[0153] The second chart generating unit is used to generate a working day quantity relationship chart based on the historical time period, the historical system function requirement quantity and the historical working day quantity;
[0154] The third chart generating unit is used to generate an employee quantity relationship chart based on the historical time period, the historical system function requirement quantity and the historical employee quantity.
[0155] In one implementation of the embodiment of the present application, the device for predicting the number of system function requirements further includes:
[0156] Data reading module, used to read historical time periods, historical number of working days, historical number of employees, and historical number of system function requirements;
[0157] Data conversion module, used to convert historical time periods into corresponding date data;
[0158] A historical data determination module is used to determine date data, historical working day numbers, historical employee numbers, and historical system function requirement numbers as a historical data set;
[0159] The model training module is used to train a demand quantity prediction model based on historical data sets.
[0160] In one implementation of the embodiment of the present application, the model training module includes:
[0161] An optimal parameter determination unit, used to determine the optimal model parameter combination of the initial time series prediction model based on the historical data set;
[0162] A model configuration unit is used to configure the initial time series forecasting model using the optimal model parameter combination;
[0163] The regressor adding unit is used to add the number of working days and the number of employees as external regressors to the initial time series forecasting model;
[0164] The model training unit is used to optimize and train the initial time series forecasting model based on the historical data set to obtain the final time series forecasting model, and determine the final time series forecasting model as the trained demand quantity forecasting model.
[0165] In one implementation of the embodiment of the present application, the optimal parameter determination unit includes:
[0166] A parameter combination acquisition subunit is used to obtain multiple preset groups of initial model parameter combinations;
[0167] A cross-validation subunit is used to cross-validate multiple groups of initial model parameter combinations using historical data sets to determine the prediction error corresponding to each group of initial model parameter combinations;
[0168] The optimal parameter determination subunit is used to determine the initial model parameter combination with the smallest corresponding prediction error as the optimal model parameter combination.
[0169] In one implementation of an embodiment of the present application, each set of initial model parameter combinations includes its own seasonal prior scale and change point prior scale. The seasonal prior scale is a parameter that controls the model's sensitivity to seasonal changes, and the change point prior scale is a parameter that controls the model's flexibility to trend change points.
[0170] In one implementation of the embodiment of the present application, the model configuration unit includes:
[0171] The mode configuration subunit is used to configure the growth mode and seasonal mode used by the model parameters of the initial time series forecasting model.
[0172] In one implementation of the embodiment of the present application, the device for predicting the number of system function requirements further includes:
[0173] The forecast result visualization module is used to generate a comprehensive forecast chart, a forecast value table and a seasonal component chart based on the forecast results of the number of system function requirements in the future time period; among them, the comprehensive forecast chart displays the forecast results of the number of system function requirements in the future time period in the form of an image, the forecast value table displays the forecast results of the number of system function requirements in the future time period in the form of a table, and the seasonal component chart is used to analyze the seasonal impact of different months on the number of system function requirements.
[0174] In one implementation of the embodiment of the present application, the device for predicting the number of system function requirements further includes:
[0175] The model prediction module is used to predict the system function demand quantity forecast results for the historical time period based on the demand quantity forecast model;
[0176] The model evaluation module is used to evaluate the performance of the demand quantity prediction model based on the historical system function demand quantity and the system function demand quantity prediction results of the historical time period.
[0177] In one implementation of the embodiment of the present application, the data determination module includes:
[0178] An information acquisition unit, used to acquire administrative planning information and human resource indicator information corresponding to a future time period;
[0179] A working day quantity determination unit is used to determine the expected number of working days based on administrative planning information;
[0180] The employee quantity determination unit is used to determine the expected number of employees based on human resource indicator information.
[0181] An embodiment of the present application further provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the method for predicting the number of system function requirements described in any of the above embodiments is implemented.
[0182] An embodiment of the present application further provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes the method for predicting the number of system function requirements as described in any of the above embodiments.
[0183] Figure 9 Schematic diagram of an electronic device provided by an embodiment of the present application. Figure 9 As shown, the electronic device 9 of this embodiment includes: a processor 90, a memory 91, and a computer program 92 stored in the memory 91 and executable on the processor 90. When the processor 90 executes the computer program 92, the steps of the above-mentioned method for predicting the number of system function requirements are implemented, such as Figure 1 Alternatively, when the processor 90 executes the computer program 92, the functions of the modules / units in the above-mentioned device embodiments are realized, for example, Figure 8 Functions of modules 801 and 802 of the illustrated apparatus.
[0184] The computer program 92 may be divided into one or more modules / units, which are stored in the memory 91 and executed by the processor 90 to implement the present application. The one or more modules / units may be a series of computer program instruction segments capable of implementing specific functions, and the instruction segments are used to describe the execution process of the computer program 92 in the electronic device 9.
[0185] The processor 90 may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.
[0186] The memory 91 may be an internal storage unit of the electronic device 9, such as a hard disk or memory of the electronic device 9. The memory 91 may also be an external storage device of the electronic device 9, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 9. Furthermore, the memory 91 may include both an internal storage unit of the electronic device 9 and an external storage device. The memory 91 is used to store the computer program and other programs and data required by the electronic device. The memory 91 may also be used to temporarily store data that has been output or is about to be output.
[0187] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.
[0188] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0189] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.
[0190] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0191] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the system embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0192] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of the present application.
[0193] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.
[0194] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by the processor, it can implement the steps of the above-mentioned various method embodiments. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.
[0195] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.
Claims
1. A method for predicting the number of system function requirements, characterized in that: include: Determine the projected number of workdays and projected number of employees for the future time period; The expected number of working days and the expected number of employees are input into the trained demand quantity prediction model for processing to obtain the system function demand quantity prediction result for the future time period; wherein, the demand quantity prediction model is a time series prediction model trained based on the historical number of working days, historical number of employees and historical system function demand quantity in the historical time period, and is used to predict the system function demand quantity.
2. The method according to claim 1, wherein Also includes: Perform data visualization analysis on the historical time period, the historical number of working days, the historical number of employees, and the historical number of system function requirements to generate a visualization chart for representing the changing characteristics of the number of system function requirements.
3. The method according to claim 2, wherein The visualization charts include a historical trend chart, a monthly seasonality chart, a workday quantity relationship chart, and an employee quantity relationship chart; the historical trend chart is used to represent the trend of the historical number of system function requirements changing with the historical time period; the monthly seasonality chart is used to analyze the average number of system function requirements in each month and identify monthly seasonal patterns; the workday quantity relationship chart is used to represent the trend of the historical number of system function requirements changing with the historical number of workdays; and the employee quantity relationship chart is used to represent the trend of the historical number of system function requirements changing with the historical number of employees; The generating of a visual chart for representing the change characteristics of the quantity of system functional requirements includes: generating the historical trend graph and the monthly seasonal graph according to the historical time period and the number of historical system function requirements; Generate a working day quantity relationship graph according to the historical time period, the historical system function requirement quantity and the historical working day quantity; The employee quantity relationship graph is generated according to the historical time period, the historical system function requirement quantity and the historical employee quantity.
4. The method according to claim 1, wherein The demand quantity prediction model is trained in the following way: Read the historical time period, the historical number of working days, the historical number of employees, and the historical number of system function requirements; Convert the historical time period into corresponding date data; Determining the date data, the historical number of working days, the historical number of employees, and the historical number of system function requirements as a historical data set; The demand quantity prediction model is trained based on the historical data set.
5. The method according to claim 4, wherein The training of the demand quantity prediction model based on the historical data set includes: Determining an optimal model parameter combination of an initial time series forecasting model based on the historical data set; Using the optimal model parameter combination, configuring the initial time series forecasting model; Add the number of working days and the number of employees as external regressors to the initial time series forecasting model; The initial time series prediction model is optimized and trained based on the historical data set to obtain a final time series prediction model, and the final time series prediction model is determined as the trained demand quantity prediction model.
6. The method according to claim 5, wherein Determining the optimal model parameter combination of the initial time series prediction model based on the historical data set includes: Obtaining multiple preset sets of initial model parameter combinations; Cross-validating the multiple groups of initial model parameter combinations using the historical data set to determine the prediction error corresponding to each group of the initial model parameter combinations; The initial model parameter combination with the smallest corresponding prediction error is determined as the optimal model parameter combination.
7. The method according to claim 6, wherein Each set of the initial model parameter combinations includes respective seasonal prior scales and change point prior scales. The seasonal prior scales are parameters for controlling the sensitivity of the model to seasonal changes, and the change point prior scales are parameters for controlling the flexibility of the model to trend change points.
8. The method according to claim 5, wherein The configuring the initial time series forecasting model includes: Configure the model parameters of the initial time series forecasting model using a growth model and a seasonality model.
9. The method according to claim 1, wherein After obtaining the forecast result of the system function requirement quantity in the future time period, the following is also included: Based on the forecast results of the number of system function requirements for the future time period, a comprehensive forecast chart, a forecast value table and a seasonal component chart are generated; wherein the comprehensive forecast chart displays the forecast results of the number of system function requirements for the future time period in the form of a graphic, the forecast value table displays the forecast results of the number of system function requirements for the future time period in the form of a table, and the seasonal component chart is used to analyze the seasonal impact of different months on the number of system function requirements.
10. The method according to claim 1, wherein Also includes: Based on the demand quantity prediction model, predict and obtain the system function demand quantity prediction result for the historical time period; The performance of the demand quantity prediction model is evaluated based on the historical system function demand quantity and the system function demand quantity prediction results of the historical time period.
11. The method according to any one of claims 1 to 10, characterized in that The determination of the expected number of working days and the expected number of employees for the future period includes: Obtaining administrative planning information and human resource indicator information corresponding to the future time period; Determining the estimated number of working days based on the administrative planning information; The estimated number of employees is determined based on the manpower indicator information.
12. A device for predicting the number of system function requirements, characterized in that: include: A data determination module for determining the expected number of working days and the expected number of employees for a future time period; The demand quantity prediction module is used to input the expected number of working days and the expected number of employees into the trained demand quantity prediction model for processing to obtain the system function demand quantity prediction result for the future time period; wherein, the demand quantity prediction model is a time series prediction model trained based on the historical number of working days, historical number of employees and historical system function demand quantity in the historical time period, and is used to predict the system function demand quantity.
13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method for predicting the required number of system functions according to any one of claims 1 to 11 is implemented.
14. A computer program product, characterized in that When the computer program product is run on an electronic device, the electronic device is enabled to execute the method for predicting the required number of system functions according to any one of claims 1 to 11.
15. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for predicting the required number of system functions according to any one of claims 1 to 11 is implemented.