BI specific requirements engineering – part 1

(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.

Figure 1 Negotiation based on off-the-shelf softwareAs 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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)

Advertisements

6 Responses to BI specific requirements engineering – part 1

  1. I am not sure the opening analogy is appropriate. The sales person would be asking which features of a cart are important – does it just have to get you from A to B? Are you interested in how it looks? What sort of style do you like? are there any features of the driving experience which are important to you? Automatic of manual gear shift?

    I can’t envisage a scenario where any half decent BI consultant would sit down with their customer and ask them to “Design” the solution, but defining the requirement is essential in almost all transactions and if the customer fails to engage in this, or the consultant fails to engage the customer then it will likely end in failure.

    The rest of the article makes some sense about structuring those requirement selections, just that the analogy isn’t really right.

  2. rbranger says:

    Hi John
    Thanks for taking the time to read an comment. Maybe this is a misunderstanding or English language problem on my side: The analogy is meant ironically: Actually what you explain is exactly how I would expect a car dealer to act: Namely asking for certain key features which differentiate the different car models from each other. It would be very strange if he or she wouldn’t behave like this. On the other hand, I had several times exactly this experience in BI projects: Especially in comapnies where their process framework is originated in the software development. Usually there is only a statement that some business users should define requirements in some generic way. But these business users are left alone with it – or at least they don’t get assistance in how to fill in a requirements document with BI specific content nor what the dependencies are to off-the-shelf software. In this context, do you think the ironic analogy makes sense now in your eyes?

    Best regards
    Raphael

  3. Hi Raphael

    I think I perhaps just disagree with “This is how many Business Intelligence (BI) experts deal with their customers today.” and using that analogy – I don’ believe that happens in large numbers of circumstance where you are talking about BI front end choice / design.

    It may well happen when it comes to spec’ing reports, but that is a different story . . . 🙂

    Kind regards

    John

  4. rbranger says:

    Yep, you are right. This could be formulated more precisely.

  5. Pingback: BI Picture Books (BI specific requirements engineering – part 2) | My life as a BI consultant

  6. Pingback: A (Webi) dashboard built by a business (power) user | My life as a BI consultant

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: