On most types of projects, features can be prioritized by considering how they contribute to satisfying the business objectives. The same consideration is valid on analytics projects, except that there aren’t discrete “features” to prioritize. Instead, you use the business objectives to prioritize the business decisions that the solution will enable, based on how much they contribute to achieving the objectives. For example, deciding which products to sell will have a greater impact on increasing revenue than making decisions about a sales team’s vacation time. Therefore, you would likely implement the analytics and reports to determine which products to sell first.

Decisions should be stated as unambiguously as requirements. An example of a good decision statement is, “The vice president of marketing needs to decide each quarter how much marketing budget to allocate to each region based on current and targeted sales by region.” As with requirements elicitation on other software projects, it’s important to understand the underlying stakeholder need instead of just focusing on a presented solution. If stakeholders request certain data or reports, ask questions such as “Why do you need that information?” and “How will the recipient use that report?” Then work backward to identify their decisions and objectives.

Decision management techniques are available to help stakeholders identify the decisions they could or should make ([ref227]). A decision model that maps information (data) and knowledge (policies or regulations that constrain decisions) to related decisions can help organize the decisions to permit prioritization ([ref228]).

The results of complex analytics must be delivered in a usable form to the stakeholders or systems that need to act on the information. The BA must also determine how smart the system is—that is, how much of the decision making is done by a human user and how much is automated in the system. This distinction will drive the type of elicitation questions the business analyst will ask.

In one organization, the executive sales team wanted to see a dashboard report every morning showing multiple views of the data. This report had to include the previous day’s sales by product line, quarterly sales by product line, total sales compared to competitors’ sales, and sales volume by price band. They wanted 10 different filters (such as timeframe, increment, and region) that they could modify to see immediate changes in the reports. For example, if a user noticed a sales issue within a specific price band, she could change the filter to see a more precise view of the price band data by region. She could further drill down to look at another layer of detail that shows price band by region and by product line. This sort of flexibility is a common capability needed by business analytics systems.

Data forms the core of all business analytics solutions. Many organizations employ data experts to develop and maintain their data solutions for these projects. BAs can define requirements for data sources, storage, management, and extraction mechanisms, although they might engage data specialists early in the requirements efforts to help. BAs can help explore what types of data need to be collected and analyzed, the total quantity of data the organization will be dealing with, and how much data they will accumulate over time. However, the data experts will be more familiar with what data is available, where it’s located, what challenges it might present, and how it can best be exploited.

Because analytics projects often aim to discover new strategies for companies, these projects might involve identifying new data sources to analyze. It’s important to fully understand the data requirements so technical teams can design the often complex infrastructures needed to support analytics. For example, architects might have to completely redesign an existing data storage solution to meet your project’s needs.

Analysis is the computational engine of the projects described in this chapter; it transforms the data and leads to answers to the questions posed ([ref077]). A user defines a problem, receives data that he hopes will contain an answer, analyzes the data to find the answer, and decides on a solution to the problem. Or maybe the system analyzes the data to find the answer and then takes an action accordingly.

All of this is great, if you know what you are looking for. However, one challenging aspect of many business analytics projects is that the decision maker might not know just what he’s looking for in the data. He might want to have certain data objects and attributes exposed in tools that allow him to explore, running different queries to ask what-if questions about the data. He literally doesn’t know what he doesn’t know, but he’s hoping that by studying the data he’ll glean something useful to act on. This is why it’s important to start by understanding what decisions the stakeholders are trying to make. Even if he doesn’t know exactly what he’s looking for yet, a stakeholder should be able to define the type of problem he’s trying to solve. Defining the necessary data analysis involves big-picture thinking ([ref053]). A BA with good creative-thinking skills can work with stakeholders to determine what new ideas might be explored with the analysis results.

As Figure 25-2 showed, analytics results lead to decision-making capabilities ranging from descriptive to predictive. To elicit the data analysis requirements, you might ask questions such as the following ([ref053]):

These questions will help you define functional requirements that specify the analyses the system must perform. Because analytics is a completely new capability for many organizations, you might do some research to discover how other organizations are using similar data to improve decision making. A business analyst has the opportunity—perhaps even the responsibility—to help the stakeholders learn how analytics could be used in ways they hadn’t previously envisioned.

Some analysis requires sophisticated algorithms to process, filter, and organize the data ([ref182]). Suppose a retail store wants to play targeted video ads when a customer walks in the store. A camera might scan her, perhaps by using facial recognition software, and the system will combine what it can learn about the customer (gender, age, attire, where she is looking) with logic built into the system to decide which ad to play. This type of decision logic can often be represented by using decision tables or decision trees, as described in Chapter 12.

It is important to understand the implications of automated decision making and be explicitly clear when defining the desired decision-logic system behaviors. A cautionary example is provided by systems that can scan social media and make stock trade movements accordingly. In 2013, a false piece of social media news reported that the president of the United States was injured in an explosion. The algorithms built into certain automated systems triggered them to start selling stocks, which led other systems to also sell stocks when they detected the market’s decline, all within moments of the news release. Fortunately, the hoax was discovered quickly, and human decisions reversed the sudden sharp stock market drop caused by the automated trading systems. Perhaps the systems behaved exactly as intended, but maybe there was decision logic missing that could have limited the impact.

One of the most valuable aspects of business analytics systems is that they can enable future-state strategic analysis, such as exploring what-if scenarios. Consider questions such as, “If we offered our product on a new platform, what would we expect our future sales numbers to be?” or “If we offered our customers products targeted to their gender, how much more would they buy?” The system can run models and algorithms to enable these types of data extrapolations or predictions. Those models and algorithms need to be specified in the software requirements. If they are highly complex, a BA might enlist the help of data experts, statisticians, and mathematical modelers to help define them.

The analyses might require statistical or other computations to transform the data prior to it being presented to the user or delivered to a system for action. Either business rules in the organization or other industry standards could define these calculations. For instance, if analysis includes reporting gross profit margins by region, you need to specify exactly how that margin is calculated in your organization. The calculation formula requirement pattern described by [ref253] can be used to specify literally any calculation that is needed to transform the data. A specified formula should include a description of the value to be calculated, the formula itself, the variables used, and where their values come from. Also, specify any response time requirements for those calculations.