Lately we have run into a number of projects that focus on reporting and analytics. As always our job is to determine the requirements. For analytics and reporting however, the requirements are a bit different than a traditional functional based portion of the system. We use a couple of different models, the report table, report flows, data dictionary and display action response (DAR) models.
The purpose of this post is to outline the steps we take to document requirements for analytics and reporting. A lot people we see doing this work focus on the data in the reports. However this is a bit backwards. Instead, we focus on the business processes and the key decisions that are made from the reports. Ultimately the reports are used to make business decisions (even if those decisions are sometimes to do nothing) or to decide to take a specific action. Instead of focusing on fields, we start with the business process and the decisions that the people using the reports need to make.
The problem with focusing on the fields is that it becomes very easy to group related information together, yet make it very hard for someone in the business to make their decision because they don’t have all the information that they need in a single location.
Here is the process in a nutshell:
1) Define the business process – hopefully this is done as part of the overall requirements effort so you won’t need to do it for this portion of the project.
2) Define the decisions or actions that are being taken – often times these are the diamonds in the process flows.
3) Define the specific information that is required to make the decisions.
4) Design reports that support one or more decisions.
The key model that we use is called a report table. Included is the information that we collect to form our report table.
Reports are also linked in a variety of ways. We typically define a dashboard level which shows KPIs. KPIs are groupings of metrics and metrics consist of layers.
An example might be, a KPI of Growth which contains multiple metrics such as new customers and canceled customers. Within the metric of canceled customers there would be multiple layers of drill downs into more detailed information. Potentially the first layer is at a company level, the next level is a regional level, and then down to the level of viewing a breakdown of cancellations by cancel reason. The format we use is an excel spreadsheet with tabs (worksheets) for each metric. Within each tab are the fields as rows and the layers as columns.
