OBIEE Project Case Study 1 ---- Gathering Requirements

So based on my previous article introducing this project I was implementing, this is the follow up on how I gathered requirements in this project environment. Note that requirement gathering is an on-going process that doesn't end with one phone calls or one meeting sessions. So whatever I am going to talk about here is something I did repeatedly over the course of our development.

Anyways, so I joined this new project and I spent some time understanding what the company was trying to do and how they have decided to do it as described in the previous blog entry, now it's time to get some requirements. 

Now you should understand that for most OBIEE projects, the desired product from an end user's prospective will be reports that shows them data or charts that they want to see. The users aren't typically tech gurus, so they can only describe their requirements in their language. It is our job to understand what they want and figure out what's the best for them. 

So in my case, we are getting a bunch of documents with charts and graphs as desired. There are high level reports that shows the overview of each network devices within certain areas or network groups along with measures and stats to indicate the traffic counts, throughput and utilization %, and there are detail level reports that show the detail stats of each network devices found in that area. 

So now, looking at all these charts and graphs, who will know how to build them? 

Before we even go there, we need to know what are these users going to give us. There has to have something we can work with to start. In every project out there, this can be the raw data or files from transactional systems. These will be the data that users are familiar with and yet make no sense from analytical reporting perspective. 

Therefore, the first thing to understand after looking at the requirement document is to know how to obtain data for each of the network devices. In OBIEE's term, the dimension tables for each devices like LSP, Pseudo-wire, VRF have to be loaded from somewhere to begin with. Hence, this will be the first questions to ask the business. Secondly, the measures on each of these requirement documents need to be loaded into fact tables, but from where? 

These are some basic information we need from the users so we can have something to work with. In our project, it turns out that these data are coming from reference files generated from the lab that the client set up for testing products for their customers. As a result, the files are in certain format that does not make business sense.  Having mapped each files with each dimension and fact that we identified, now the next question is how to associate these files with each other? This is important for OBIEE because without it, we can not create our data models. 

Looking at the report requirement documents, we know that they want to see in each area, how many pseudo-wires are coming through, what are the top 10 pseudo-wires in each area ranked by Throughput and etc. This tells us that we need to find ways to join Pseudo-wire dimension, Area Dimension with a fact table. So the question becomes, how to find out what Pseudo-wire is coming through what Area by looking at the raw files from the lab?

Needless to say, this is the question that the business will have to tell us. The answer we get is that they are associated by an IP_Address given in one of the reference files. This is suggesting how to join these dimensions with fact. Obviously, the next question becomes, can each Pseudo-wire belong to multiple area and vice versa? This will tell us how to relate these dimension tables, are we going to create each dimension tables or denormalize them into one bigger table? At what level should be load the fact table?

Obviously, we haven't even gotten to dealing with time dimensions yet. This is another important aspect in requirement gathering. Knowing the update frequency, historical data storage and detail of time that the report is against are some of the key questions to ask in order to design our model.

Are we going to use one dimension or several dimensions? How are we going to design the schema? If I want to design the schema that joins Router dimension with one of the file for CPU Usage fact, can I do that? What does it mean in term of technology if I am reporting on a list of router with CPU usage? Does it mean sense? Can I join Interface Dimension with the file for ethernet fact which shows measures for radio station? Does radio station even have interfaces to which it terminates? The question goes on and on. 

This is a long process of gathering requirement and interpreting requirements. It is important to start thinking in terms of the business and use the answers gotten from the business to guide the implementation design. Although what I am doing here is specific for the subject of network engineering, the same method and exercises are transferable to other OBIEE projects as well.  If you are doing financial reporting, you need to understand what the business is trying to achieve, to ask questions about how they relate their GL accounts with transactions? What are the caveats that they are facing all the time? Are they dealing with multiple currencies? How do they know which currency the transaction is used? The list goes on. You will never be short of questions if you start thinking in terms of their business. The answers you get from these questions will be your good guide in terms of translating it into OBIEE language.

One important exercise I always do is keeping tracking of all of the meeting notes and sharing them with clients, users and other project managers. Requirements always changes, therefore, keeping a record of changes and the impact analysis associated with each potential changes will be a valuable information along the way.

Until next time.