Maximize the BI Requirements Definition Process

Register now

Let’s start with the first law of BI requirements: BI requirements cannot be created nor destroyed; they can only be transformed from one form to another.

In all customer environments, the requirements for a BI system are always available in some form or another. It’s common that data in every transaction system gets analyzed and reported in one of various forms. The BI system is built to improve that process of analysis to be much easier and more sophisticated.

Typical requirements understanding takes place through questionnaires, interviews and joint discussions. These kinds of requirements-gathering techniques could miss user needs because they might not ask the right questions or the user may not remember all that he needs at that point of time.

Two ways of ensuring that we maximize the BI requirements definition process are user object analysis and system object analysis

User object analysis is the process by which we try to understand the BI requirements from a user perspective through the analysis of the objects that a user creates or uses in his daily activities.

A user object is any artifact that a user is creating as part of his data preparation, analysis and reporting. This object could be an Excel spreadsheet, PowerPoint slide, Access database, Word Document, a notepad or weekly/monthly email.

Following are the steps in user object analysis:

  1. Collect all the user objects from all users. Do not discard any; collect all of them that the user feels are relevant and applicable.
  2. Convert all of the content in each of the user objects into a relational structure. The conversion process would involve mapping the information in the user objects into data elements, such as the business names/elements, tables, columns, username, department, etc. Any Excel applications or Access databases have SQL queries, and then we use parser components to convert the SQL query into tables and columns.
  3.  Analyze the collected metadata, prepare an understanding document and raise queries where clarifications are required.
  4. Prepare and submit the user object analysis report, highlighting what data each user collects to get user confirmation. We will be able to determine user clusters (users who perform similar activities or have similar requirements) based on this analysis. We probably will also be able to interact for validation as user clusters.

Benefits of user object analysis include: 

  • An effective means to understand the needs of a user based on what he does as a daily routine.
  • An easy way for the user as he has to just read through final report on what he needs and approve it.
  • One of best means when the user base is large and across multiple locations.
  • A good platform for us to define improvements for the existing process of analysis.
  • Consolidation of the requirements across multiple users and carves out the user clusters who perform same kind of analysis.
  • An improvement in business process understanding.
  • A wider view; it enables questioning and helps us to define new perspective to the existing processes.
  • System object analysis is the means of understanding the business process and the system functions of a source system by looking at its data elements and their values.

Even though system owners or functional experts provide the details of the transaction system, there are still many data elements, dependencies and relationships that are not clued in through these inputs. To build a BI system that is functionally wide enough to accommodate future or new data analysis requirements of the users requires us to look at things as whole and perform system object analysis. This enables us to guide users to define their need.

Following are the steps in system object analysis: 

  1. Collect all tables from the source system - physical metadata like table name, column name and data type.
  2. Write the descriptions in terms of the kind of data each of these tables store.
  3. Group the tables based on the functions through description understanding or through naming conventions present among the tables.
  4. Certain tables or groups can get eliminated here by interaction with the users like audit or process tables.
  5. Also, a table can belong to multiple groups; reverse-engineering the underlying data model would be useful to determine the groups.
  6. Perform data profiling for each of tables, understand the domain values, their significance in terms when such value can occur and the relationship between tables.
  7. Determine the different scenarios on how the data gets inserted, updated and deleted in the table.
  8. Determine the fact, dimension and attributes of dimensions within each functional area/group.
  9. Prepare certain questions that a business can get answered within and across the functional area (groups). Validate the questions generated with the business and possibly collect more questions to find out if any elements are missing from the group.
  10. Present to the business on what can be delivered from the system. Prioritize the needs with business and prepare the implementation plan.

System object analysis:

  • Ensures complete understanding of the process by which data gets modified in the source system.
  • Helps prioritize requirements, build a case for the dependency and prepare rollout plan.
  • Provides a means to trigger the requirements definition from user through an interactive process, gets us raise many questions to the business about their system and process.

Often the requirements defined by the business for a BI system is to build an ad-hoc query environment over a transaction system. User object analysis and system object analysis outputs enable the users to navigate their needs through the inputs from the technical team; this process becomes almost mandatory when users do not know what they want in the BI system.

For reprint and licensing requests for this article, click here.