graph icon

Steps to Getting Good BI Requirements

Half the battle for many projects is getting started. BI projects are no different in that respect. A critical phase in realizing your BI project vision is developing thorough project requirements in clear, crisp, implementable and measurable terms.

The temptation is to rush this phase, which often produces excessive churn or even failure as unguided interpretations and showstopper issues appear during implementation or testing. It is vital that you get your BI project off to the best possible start by establishing sound requirements via rigorous steps.

KPIs to Validate Requirements

Requirements are, frankly, meaningless if their intentions and results are not measurable. Key Performance Indicators, or KPIs, are a good approach to ensuring your requirements focus on the right values. The right KPIs are often derived from current organizational metrics from which your project would presumably improve upon.

For instance, if one of the strategic goals of your BI project is to improve customer retention, then a set of relevant KPIs might include data concerning new customer acquisition, customer relationship strength, ROI on loyalty programs, repeat sales and customer attrition among other metrics.

Improvement to these metrics and additional metrics based on new insights will be directly stated within the requirements, e.g. “A 25% decrease in customer attrition rates over the next two quarters.” It is important to also state the methods by which metrics will be evaluated to ensure they are on par with existing ones.

Acquiring Requirements

One often overlooked technique in developing BI requirements is their acquisition across teams and departments who have stakes in the project. Naturally, this requires that you have a priori identified all affected stakeholders. This “reqs” collection phase can be employed at any time, but conversations are often facilitated by an existing pro forma set of requirements. First meetings should be formatted as brain storming sessions, whereas later reiterations should be tightly structured.

During requirement review meetings, new requirements and metrics will be discovered. Additionally, you may find that data relevant to your project is restricted by departmental policy or that regulatory compliance issues for particular data that must be considered. Far better to discover such issues at the requirements phase than in the development or deployment stages.

Take it for granted that you will be unable to accommodate everyone’s requirements, especially those irrelevant to the strategic vision. During the first phase of acquisition, it is possible the vision can be tweaked, but you should resist major or ongoing changes to it as much as possible.

BI Data Acquisition

During high-level requirements discovery and definition, pay attention to the nuts and bolts of how the project will acquire the project data from a technical point of view. This is especially true if databases, operating systems, file formats and applications relevant to your project are not uniform across the enterprise, which is often the case with companies still in their early stages of digital transformation.

Assign the most technically-savvy members of your team to digging out the details of how project data will be acquired, stored and managed. Expect to hit snags, but do not expect those outside the project to change mid-stream their habits or constraints. This data acquisition analysis naturally leads to another set of project requirements that must be stated up front in order to minimize surprises later in the project.


To summarize, once you have developed and vetted strategic goals for a particular BI project, it’s time to roll up your sleeves to tackle a well-defined, thorough set of measurable requirements for said project. These must encompass the viewpoints of all stakeholders up to the point that they support the project’s strategic vision.

State a set of pro forma requirements related to the business decisions supported by the proposed BI system. Use these requirements to generate detailed discussions regarding metrics, data acquisition, data sharing and regulatory compliance with all stakeholders. Iterate with stakeholders on the requirements with increasing structure to avoid heading down rabbit holes. Also, evaluate technical issues relative to obtaining data, storing data and formatting data and make sure these are reflected in the requirements also.

Always bear in mind that despite the seeming tediousness of requirements development, a thorough job pays enormous dividends in subsequent project stages through avoidance of foreseeable issues. These are far more difficult to correct in later project stages and could even spell disaster for the entire project.

If you have questions about your next BI project’s requirements, contact us today.