Feature Overview

.Forecast services based on existing information

Goals

As a cost-management user, I want to predict next month's costs so that I can make better planning decisions.

Problem:

Our customers want to understand what is going to be the expenses at the end of the month, as accurate as possible, and be able to compare it with the current data.

Why is this important?:

Being capable of predicting costs accurately as soon as possible allows the customer to take action and increases the chances that any corrective changes has a real impact on the account governance.

Examples

• As a user, I want to predict costs for the end of the month based on historical resource usage consumption, so I can know plan my budgets
• As a user, I want to predict costs for the end of the quarter based on historical resource usage consumption, so I can know plan my budgets
• As a user, I want to predict costs for the end of the year based on historical resource usage consumption, so I can know plan my budgets

Requirements

• Implement forecasting as a separate API endpoint. (e.g. /report/forecast )
• The endpoint should return only forecast values.
• Implementation must support the same time parameters as the other reporting endpoints.
• Implementation should add a new parameter to specify whether the returned forecast is N-days or N-months.
• The forecast itself should always use daily data as input for calculating the forecast, regardless of output.
• The forecast data should be stored in the DB and retained. (New table is preferred over extending an existing table.)
• The forecast endpoint should support querying for both current and past forecasts.
• Stored forecast data should be versioned to support future cases where the forecast may need to be recalculated. e.g. If a cost model changes, the forecast will also need to change.
• API response should return three elements - forecast value(s), confidence intervals, p-value(s)