One of the buzz concepts in the world of today’s software engineering is Business Intelligence (BI). Well, what does it really mean?

Gartner, one of the world’s leading companies in research and advisory, offers a comprehensive definition of BI:

 “A broad category of applications and technologies for gathering, storing, analysing, sharing and providing access to data in order to help enterprise users make better business decisions.”

It is a known fact that, when we hear BI, we think about analytics. Thus, it is important that I define this word before proceeding further.

The famous author of Analytics at Work - How to Make Better Decisions and Get Better Results, Thomas Davenport, defined this term as being "a subset of BI, based on statistics, prediction and optimisation." 

Using this definition, it is easy to conclude that analytics is not the same as reporting, dashboarding or even Online Analytical Processing (OLAP). Let’s just say that analytics is more like an engine applying data mining and predictive algorithms to the data in order to enable things like sales forecasts, customer segmentation or cash flow optimization.

From a technical point of view, an analytical model is like an Extract-Transform-Load (ETL) mapping that adds "intelligence" to the raw data. From a functional point of view, analytics enables organizations to define and answer questions like: Why is this happening?, What will happen? and What should we do to make it happen?.

Traditional BI solutions only focus on what has happened and is currently happening. By applying BI solutions, the return on investment can be significant provided that it enables organisations to "sense" and "anticipate". Therefore, it is no wonder why SAS (a leading company in business analytics software and services) reports a 26% growth in income related to business analytics. It also explains why IBM invested over 16 billion in BI acquisitions and still heavily invests in this area.

 Analytics is getting big so watch out!

But enough theory–let’s deep dive into starting out a BI project.

When you start your BI project, gathering the functional business requirements is the first step you need to take. What are the reports that are needed?, Which measures need to be shown and against what dimensions do people want to analyze these measures?

Of course, you might just ask each stakeholder these questions, but chances are that stakeholders find it hard to define what they exactly need. This again might result in stakeholders not asking all they need, or stakeholders asking more than they really need.

So, without further ado, here are the 5 tips I recommend you to try for better requirements engineering:

1. Organise one-to-one discussions. If you have good listening and synthesizing skills, there is nothing better. Send out your interview questions in advance so people can think about their answers before you get there so you get better, more thoughtful responses. Make sure you ask the right questions. Don't ask, What data do you need? or What do you want the report to look like?. Rather ask, What are you trying to accomplish?, What actions will you take if you have this information?, What are your goals?, What are your incentives?.
2. Send out surveys. Believe it or not, surveys are a great way to capture solid feedback. During a meeting, most users are put on the spot (unless they are dutifully prepared). A survey gives them time to look at the questions and think about their answers before they submit them.
3. Visualise workflows through process mapping. Ultimately, a BI solution is a vehicle to shed light on one or more business processes. So find out what those processes are. Understand the flow of data through each process, and how the availability of data can streamline them.
4. Reverse engineer. You can probably obtain 60-80% of the metrics, attributes, and dimensions for a new report or dashboard in existing reports or operational systems. There is often no need to reinvent the wheel, just extend the concept a bit.
5. Build prototypes. A great way to refine your requirements is by creating a prototype based on actual data if possible (fictional data if not), so users can see and interact with a system before it goes into production. A picture is worth a thousand words.

This is not a complete requirements engineering methodology, but these options will definitely get you going. As you move on to implementation, new requirements will arise, so the important thing is that you stay agile and willing to learn.