Using Decisions to Derive Requirements for Business Analytics Projects
The principal purpose of business analytics projects is to develop software systems that can turn large, highly complex data sets into displays of meaningful information. That information lets business people make tactical, operational, or strategic decisions. An executive might study 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).
For most information systems, reports represent just a small portion of the functionality implemented. However, on business analytics projects, complex reports and graphics, and the ability for users manipulate their contents, constitute the core capabilities. Business analytics projects have multiple layers, all of which might need to have software requirements defined for them. These projects must deal with the data itself, the operations performed on that data, and the formatting and distribution of the data for use.
The end products of requirements development for a business analytics project are 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. Performance requirements describe how quickly they need results. However, none of these reveals the complex knowledge required to implement the right system. Requirements elicitation for such “big data” projects is thus a bit different from that on more typical business information systems.
An effective elicitation strategy is to drive requirements specification based on the decisions that stakeholders must 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 stakeholders will make 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 must 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 provides the foundation, and strategy, for requirements development on big-data projects. Figure 1 shows an overview of the process to specify requirements on an analytics project.
Figure 1. Process flow for requirements development on business analytics projects.
Prioritize the development work based on which decisions are most important to address. 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 before implementing other capabilities.
The business analyst (BA) should state the decisions as unambiguously as they write 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 the related business objectives and corresponding decisions. You might find that some of the initially requested reports would not help the stakeholders make those key decisions.
Once you’ve identified the most important decisions, you can work out how the users will use information to make the decisions. You need to define how they want to receive the information, how it will be formatted, and in what ways they want to manipulate it. The answers to these questions will lead to many of the functional requirements.
If systems are automating the decision-making, then you also need to define requirements for external interfaces to deliver the information. Be sure to explore quality attribute requirements as well as the decision-related functionality. For instance, there may be security requirements that restrict which user classes can generate certain analyses or reports.
After understanding how the information will be used, the data requirements must be specified. You need to specify what data elements are needed to feed into the requested analyses. As long as the data has some structure to it, entity-relationship diagrams and data dictionaries can help uncover and represent the data requirements.
Data requirements might also include: data sources; processing of input data into standard formats and structures; storage, management, and extraction mechanisms; and presentation mechanisms, such as dashboards. The data in the system might not simply be output in its original format: there could well be analyses 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 up front just what he’s looking for in the data. (I’m reminded of the old software project acronym of IKIWISI: “I’ll know it when I see it.”) He might want to have certain data objects and attributes displayed 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 a stakeholder doesn’t know exactly what he’s looking for yet in the data, he should be able to define the type of problem he’s trying to solve. A skillful BA can help guide a user’s thinking through this process to clarify the objectives, questions, and decisions and hence reveal the system’s functional requirements.
As a BA on a business analytics 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 even more successful by envisioning solutions that they might not have imagined were even possible. That’s one of the many ways a business analyst adds value to a project.
For more information on requirements for business analytics projects and for dashboard reporting, see chapters 13 and 25 of Software Requirements, 3rd Edition.
If you’re interested in requirements and business analysis, Process Impact provides numerous useful publications and other resources.