(Thanks to my co-author Alexander van’t Wout for supporting me writing this blog post!)
Collecting requirements for BI front end tools is often frustrating.
Imagine a sales conversation at your local car dealer. After some small talk you are going to tell the salesperson about your interest in buying a brand new car. Nothing easier than this you might think. But suddenly you are confused. The friendly salesperson asks you if you would please write down exactly what you want and draw a sketch of what you have in mind. As if this was not funny enough he hands a sketch board over to you with a blank sheet of paper on it.
This is how many Business Intelligence (BI) experts deal with their customers today. End users are often left alone to «design» their requirements. A car is a «commercial off-the-shelf product» and therefore very similar to a BI toolset, which is «off-the-shelf software». A common characteristic of both product types is the standardization of features, and therefore a limited set of features. On one hand, this might limit your flexibility; on the other hand, it simplifies the process of requirements’ definition drastically because you do not need to consider each and every detail to build a system.
We can distinguish two major scenarios where a business user community needs to specify requirements for BI front end tools: scenario A) is an organizational environment where the business intelligence software suite is already predefined. This means that for a regular project the project team is not free to choose from all available tools on the market, but only within the limited frame of what is usually called strategic vendors. In most organizations this means no choice at all. Typically, most organizations limit themselves to one or two strategic BI vendors, whereas every vendor provides a suite of tools and therefore provides a choice to project teams.
Scenario B) takes place when a company is about to choose their strategic BI vendors, or when it is about to define a front-end tool strategy based on a given toolset available. The difference to scenario A) is that there are no concrete requirements or previous use cases to do this. Decisions involving, for example, choosing strategic BI vendors, or building a front end tool strategy usually have to be derived from corporate requirements, which may mean some high-level requirements that are influenced by end users only in an indirect way.
In Scenario A, the main task is to map requirements to concrete features and specify detailed requirements (which take into consideration the chosen features). In scenario B, the main task is to get to know multiple tools and multiple tool suites of different BI vendors and make them comparable in an easy and quick way. For both cases, the authors suggest the visual approach of BI Picture Books as an analogy to a car catalog. In subsequent paragraphs, “end user” is used as a synonym for the party who is in charge of defining requirements for the BI front end tools.
As outlined in the introduction, working with business intelligence software is working with off-the-shelf software nowadays. This means that not all imaginable requirements are allowed anymore. In particular in scenario A) end users cannot have all they want, but their requirements need to be aligned with the available features of a given tool set. Still, the first step is collecting business requirements to compare with the technical features of the standard software. This process can be very frustrating for the business user after s/he has noted his requirements on a blank sheet of paper and tried to picture himself using a solution that fits his needs. The necessary negotiations regarding the technical feasibility are more likely a surrender of the business user’s initial requirements.
Therefore, the question that arises is, how could we show the end user in advance which options are available and therefore feasible as a solution to his requirements? To answer this question, we take a look at the automotive sector again.
Today, modern car manufacturers provide web-based car configurators, where customers can “build” their own car. The customers have to walk through several steps, e.g. choosing the color, the wheels, the engine and accessories. We can learn two things from such car configurators: First, guide the end user defining the necessary (and feasible) requirements. Second, provide visual support to the end user showing what different available options look like.
Structure BI front end requirements
To «build» a BI front end solution we identified seven crucial categories which need to be addressed during the requirements’ engineering process. This corresponds to scenario A above. For scenario B one can still use the same categories, but instead of defining requirements along the lines of these categories you can structure the available features and thus make the comparison of the different tools much easier. The following sections will outline the seven categories in more detail:
- Content options: In this first step, end users have to roughly define what information products they want to receive in the end, and the approximate content of these products. (The term information product is an umbrella term for all the various BI front end types such as report, statistics, cockpit, dashboard, analysis etc.). For scenario A end users are relatively free to note down everything they want, except for data content, which is a priori not available in the project time frame. For scenario B, the BI expert might list and compare all the available data connectivity options for a certain toolset.
- Navigation and selection options: In this second step, the end users need to think about how to navigate to or between the defined information products (e.g. using a folder structure in a given BI portal). Whereas navigation takes place outside information products, the selecting interactively data usually takes place inside an information product. In either case, the available options are limited by the software.
- Layout options: This third step is about collecting requirements regarding page layout, chart and table options. A common pitfall for end users is to assume that BI front ends are either like Microsoft Excel or Word. Trivial looking items such as a table of contents or some specific chart options which are available in Office products might not be available in the BI front end tools. In addition, if the end users’ organization adheres to notation standard rules such as the International Business Communication Standards (IBCS; http://www.ibcs-a.org/) this might further restrict the allowed layout options, in particular for charts and tables.
- Functional options: Whereas the third step addressed more of the static elements in a report, this fourth step is about defining requirements for the functions of a BI front end solution (in addition to the functions already defined in the navigation and selection category). Typical examples of functions are the usage of (interactive) alerts, export to various formats, printing, search, multi-language options, commentary features and so on. This category depends even more on the available features of a given BI front end tool than the previous ones.
- Delivery options: Step number five addresses how an information product is delivered to end users. Besides defining the delivery channel (e.g. by web browser, mobile, email) one must define how and when the report is refreshed. One possible option is viewing an information product on demand (the refresh is triggered directly by an end user). Scheduling the information product to be run at night is another option. Scheduling can be further divided into single information product scheduling and information product bursting where, based on one main product, a personalized instance of the information product is created and usually distributed to the specific recipient. Requirements for this category’s “delivery options” usually depend not only on the front end tool itself, but also on the underlying BI platform system or available third party extensions, e.g. for bursting.
- Security options: Finally, end users have to think about security. In the context of BI front end solutions, there are two main security aspects to consider: Access restrictions on information product level, on one hand, and data level security, on the other hand. For the first aspect, an end user has to define who and in which role is allowed to see the report, and which features should be available, e.g. one user might access and refresh the report, but must not export the report. Similar to the previous category of delivery options, the access restrictions are highly dependent on the underlying BI platform and the available security options.
The the second aspect of data level security is either addressed on database level or some kind of semantic layer of the BI front end tool. Again, the available technology decides upon available options.
- Qualitative options: Last but not least, this final category of options summarizes requirements of a qualitative nature. This includes elements such performance or usability requirements. For this category, it is more difficult to define requirements allowed. Nevertheless, one can guide the end user in defining realistic requirements, e.g. instead of asking an end user to define the maximum report refresh duration, provide predefined performance classes such as “< 30 sec”, “30 – 60 sec” and so on. This way an end user won’t define an unrealistic value like “every report must be refreshable below 3 seconds”.
Using these seven categories to either structure your end user requirements (scenario A) or structure and therefore compare the available features of multiple tools in an evaluation process (scenario B), you will be able to catch at least 80% of typical BI front end requirements. Depending on the concrete project, you will most probably have to extend the list with your own items. Still, the basic principle of guiding end users whilst defining requirements remains the same.
Another way of structuring the requirements using the seven categories is to outline dependencies. Similar to web based car configurators, there are certain requirements in a given category which have a direct impact on the allowed (or needed) requirements in another category, e.g. defining a delivery channel using mobile devices will most probably have an impact on the desired (or available) layout options, as well as certain security options. In such a case, one needs to cycle back or forwards in the categories and adjust previously defined requirements. In sum, the typical procedure will be to run through the seven categories in an iterative way starting with a rough idea of requirements in the first round and refining requirements (also considering newly discovered dependencies) in subsequent rounds.
However, there is one question left: What does a non-technical user understand by these categories? A simple feature list is usually not enough, in particular for people whose daily business is not building a BI front end solution. The authors suggest building and using a visual catalog of available options, just like the car-configurator. We call this a BI Picture Book. (More about this in part 2)