Requirements for Business Intelligence Projects
In short Business intelligence (BI) and analytics systems turn large volumes of data into information for decisions. Wiegers and Beatty recommend eliciting their requirements from the decisions people must make, not from the reports or data fields they ask for.
Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed. (Microsoft Press, 2013), ch. 25.
On this page
Key ideas#
What is different about this kind of project#
- There are few discrete features to prioritize; the value lies in better decisions.
- Users often cannot say in advance what they need, especially if they have never seen analytics beyond spreadsheets. Revealing capabilities in small increments helps them discover their needs, so these projects suit incremental delivery.
- Every answer raises new questions, so the system keeps evolving.
Three linked components#
The authors describe analytics as three parts, each of which can lead to the others: data (sources, storage, management, extraction), analysis (transformations and calculations) and information use (delivery, format, adaptability). A user may start with the data and then realize a different analysis or source is needed.
From describing the past to predicting#
Citing Patel and Taylor and Davenport, the authors describe a range from simple to advanced: standard reports on the past, ad hoc queries, alerts, statistical analysis of patterns, forecasting and optimization, predictive models, and “what if” scenarios. Organizations new to analytics start at the simple end.
Start from decisions#
Following Taylor’s decision-centric approach: 1. Describe the business decisions the information will support. 2. Link each decision to business objectives. 3. Break each decision into the questions that must be answered, including the questions that come first. 4. Work out how analytics will help answer them.
A good decision statement is as unambiguous as a good requirement: who decides what, how often, and based on what. When someone asks for a specific report or field list, ask “what will you decide with this?” and work backward. The overall order of work: prioritize by decisions, then define how information will be used, then data needs, then analytical operations.
Information use#
For people, specify the delivery mechanism (email, portal, mobile), the format (report, dashboard, raw data) and how much users can manipulate it, from a personal copy to self-service ad hoc queries. For systems, analytics can be embedded in an application to make decisions automatically. The authors show both the power and the ethical risks of this, and describe automated trading systems that sold shares within seconds of a false social-media report, setting off other automated sellers. Specify limits on what an automated decision can do when it is wrong.
Data requirements#
For big data, the authors cite Franks’ three traits: volume, velocity and complexity. Structured data fits ordinary entity-relationship models and data dictionaries. Unstructured data (voicemail, free text) needs analysis in context; the same word can mean very different things in different texts. Semi-structured data (email, images with metadata) sits in between. Questions to ask, adapted from Brijs: - Sources: which objects and attributes, how to access them, how likely the source is to change, whether history must be migrated. - Storage: current volume and expected growth, retention, security. - Management: structure, transformations to unify sources, archiving and deletion rules, integrity. - Extraction: required speed; real time or batch, and how often.
Analysis requirements#
Decision makers often do not know in advance what to look for, so plan for exploratory queries and what-if tools, not only predefined reports. Ask about time horizons: what insights from the past, what immediate actions from the present, what predictions about the future? For complex calculations, the authors suggest Withall’s formula pattern: describe the value calculated, the formula, the variables and where their values come from, and the response time needed.
Example#
The Workshop, a fictional bike-repair chain, writes its first decision statement: “Each month, the owner decides how many mechanics to roster at each workshop for each weekday, based on bookings, walk-ins and average repair times.” - Questions: Which weekdays are overbooked? How long does each repair type take? How many walk-ins arrive per day? - Data: the booking system, job cards (repair type, start and end times) and the front-desk walk-in log. - Use: a monthly dashboard for the owner, and a weekly alert to managers when bookings exceed capacity.
Checklist#
- Each requirement traces to a stated business decision.
- Decision statements name who decides, what, how often and on what basis.
- Delivery mechanism, format and flexibility are specified for each user group.
- Data sources, storage, management and extraction questions are answered.
- Exploratory and what-if needs are covered, not only fixed reports.
- Automated decisions have limits on the damage an error can do.
- The first release is small, and users can ask for the next questions.
Sources and further reading#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 25 (including the authors’ references to Taylor, Patel and Taylor, Davenport, Franks, Brijs and Withall).