Skip to main content

How to Discover Useful Requirements for Business Intelligence

“My users are asking for a report, but how do I make sure I truly understand their needs and properly convey that to the rest of the delivery team?”

Asking for a report is great, but it is a loaded word. People use the word “report” to mean many different things.

A report is a solution in search of a problem. You may know what your stakeholders want on the report, but until you identify why they want the report, you enable their solution seeking.

When you want to understand a stakeholder’s business intelligence needs completely, the following steps often prove very helpful:

  • Start with the questions stakeholders want to answer and decisions they want to make
  • Focus on value and feasibility to determine what to do next
  • Dive into detail only when you need to

Start with Questions and Decisions

When your stakeholders ask for a report, you want to know why they want that report, but you do not want to ask why. Why not?

Asking “why do you need a report?” is not going to provide you with the key insights and information you need and may make your stakeholders think you do not believe they have a need at all.

To avoid that uncomfortable situation, I have found that Socratic Questioning is a good route to go. The question I like to start off with is “What questions are you trying to answer or what decisions are you trying to make?”

When your stakeholders describe the questions/decisions, listen for phrases such as:

  • I want to know…
  • I want to decide…
  • I want to determine…

These help to identify the initial big chunks of value you can deliver in your business intelligence efforts.

Say you are working on a product to allow the audience at Olympic events to vote on the competition – say platform diving – and your stakeholders want to incorporate reporting into that product.

You talk with your stakeholders and find out that they want to know how votes can vary depending on characteristics of the audience or the competitors. That may result in the following things that you want to explore:

  • I want to know if audience members vote differently based on their gender
  • I want to know if audience members favor athletes from their country
  • I want to know if audience members evaluate athletic performances the same as judges
  • I want to know if audience member age impacts how they evaluate performances.

You can easily capture these in a user story, job story, or another template of your choice. The key is that you know what your stakeholders hope to accomplish with the reports, so you can guide the discussion to find out what your stakeholders hope to accomplish.

When you have those conversations, listen for nouns. They represent the pieces of information you need to know. Also listen for phrases such as “by gender” or by country They indicate how to organize the data, including what dimensions you may need.

In our examples above, the nouns you will most likely pick up on are audience members, athletes, and judges. The dimensions then may be audience member gender, audience country, athlete country, and audience member age.

Focus on Value and Feasibility

Once you have identified what you want to work on, you need to decide the order in which you work on it.

Start by prioritizing the questions and decisions your stakeholders are interested in based on value. Which of those questions and decisions are most vital to your stakeholders’ objectives? It may be the question/decision that provides your stakeholders the biggest lift or is most critical to address other questions and decisions.

Then, consider feasibility. Feasibility focuses on whether the data you need to address the questions and decisions is availability and organization of the available information. If the information is not readily available, consider alternative methods and their difficulty in obtaining that information.

Some pieces of data may present some substantial risks from the perspective of whether you will be able to get that data. If that data is critical to some of the more important questions/decisions, you may decide you need to tackle that data first.

Feasibility also drives the order in which your team delivers the data for a specific question/decision. As a result, you may provide overall prioritization of which questions/decisions to address in what order, and then leave it to your team to decide the order of the smaller bits of work necessary to deliver the ability to answer a given question or make a specific decision.

Dependencies play a part in considerations of feasibility. Often the answer to one question becomes an input to answer another question, so you have to consider those interdependencies when you decide the order of the questions you tackle.

Prioritization is most effective when it is a team discussion. Start with which questions you want to answer or decisions you want to make first, but then revise that order based on the feasibility involved in getting the data necessary for those questions or decisions.

Only Dive Into Detail When Needed

I noted above that you want to listen for nouns and pointers to possible dimensions. Noting what comes up during the normal course of conversation is ok, just avoid the temptation to dig too deep too soon.

You do not know which stories you are going to need to do, so you do not want to expend too much effort fully understanding stories you are not going to do. When do you dig into the details?

When you have initial conversations with your stakeholders to understand the information they seek, you may sketch out a very rudimentary report during the conversation to make sure you understand what they are asking for. Stop when you have enough information to determine what order you want to deliver those questions and decisions.

In some cases, you may need to dig a little bit if you identify a piece of data which may prove a somewhat difficult to obtain.

Wait to delve into all the details of the data (definitions, transformation rules, valid values, or other factors) until you are preparing information for a team to deliver the necessary data to answer a question or make a decision.

Business Intelligence Can Be Done Iteratively

It is possible to deliver data warehouses in an iterative, incremental fashion. The key to making that happen and work is to organize your increments around questions your stakeholders want to answer or decisions they want to make. Then consider value and feasibility to prioritize those questions/decisions, and avoid the temptation to dive too deep too soon.

What experiences do you have working on business intelligence projects? Leave your thoughts in the comments.