Most normal people don't look at data sets just for fun. They study views of the data to make decisions about what to do, be it a decision to take some specific action or a decision to do nothing at all. The main purpose of business analytics projects is to develop systems that turn large and often highly complex data sets into meaningful information from which decisions can be made.
The decisions that people make using business analytics systems can be strategic, operational, or tactical. For example, an executive might look at his sales team's global performance dashboard to decide who to promote (tactical), which products need different marketing strategies (operational), or which products to target by markets (strategic). Generally speaking, all software systems that include an analytics component should enable users to make decisions that improve organizational performance in some dimension.
The end products of requirements development for a business analytics project will be similar to those for any other project—a set of business, user, functional, and nonfunctional requirements. Process flows, use cases, and user stories can reveal that someone needs to generate analytics results, and performance requirements describe how quickly they need results, but none of these uncovers the complex knowledge required to implement the system.
An effective elicitation strategy for business analysts (BAs) is to drive requirements specification based on the decisions that stakeholders need to make to achieve their business objectives. The following thought process is adapted from James Taylor’s “Using Decision Discovery to Manage Analytic Project Requirements”:
- Describe the business decisions that will be made using outputs of the system.
- Link those decisions to the project’s business objectives.
- Decompose the decisions to discover the questions that need to be answered, the hierarchy of precursor questions that need to be answered to feed the main questions, and what role the analytics information plays in producing the answers to those questions.
- Determine how analytics could be applied to assist in making these decisions.
Using these steps to think about the most important decisions is the foundation from which to do requirements development. The development work should be completed based upon which decisions are most important to resolve. The following figure is an overview of the process to specify requirements on an analytics projects.
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.
Once the most important decisions are identified, you can work out how the users will use information to make the decisions. For example, you need to define how they want to receive the information, how it will be formatted, and how much they want to manipulate it. The answers to these questions are some of your functional requirements. If systems are automating decision-making, then you need to define requirements for external interfaces to deliver the information.
After understanding how the information will be used, the data requirements must be specified. You need to specify what data elements are needed. As long as the data has some structure to it, entity-relationship and data dictionaries can help uncover the data requirements. Data requirements might also include data sources, storage, management, and extraction mechanisms. Also, data might not just be delivered in its original format; there might be analysis performed on the data that transform it for use.
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.
As a BA on a project, you need to work with the project's stakeholders to understand their decision processes. Use those decisions to elicit the requirements that will access the necessary data, specify the analyses to be performed, and define the data presentation. You should understand what results stakeholders expect from an analytics solution, the decisions they hope the data will help them make, and how they want to dynamically modify the analyses or their presentation. Look for opportunities to help users be more successful by envisioning solutions that they might not have imagined were even possible.
Authors: Joy Beatty is a Vice President at Seilevel. Karl Wiegers is Principal Consultant at Process Impact. Karl and Joy are co-authors of the recent book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.