I searched through your archive of questions and could not find an answer to my question, so I am submitting one in the hope you can provide some very practical assistance.

What, in your opinion, is the best approach to take to the whole SDLC (as it relates to BI) when tackling requirements that are not well known or are difficult to articulate by the users?

How do you progress with an initiative when you do not clearly understand the end result? ie. what is the best way to get a project up and running (to secure some resources) when you don't know the end game? Obviously the BA is critical in this area and will be the main resource. Is there merit in the BA conducting development using an iterative or prototyping methodology to help determine requirements? If so, how does this coincide with the need to conduct a business case, i.e., which should come first? Is it appropriate for the BA to become involved in determining the requirements before the project is formally started?


Sid Adelman’s Answer: There’s probably some business pain and some information the business desperately needs to make its important decisions. Go after those requirements and ask what data is required to support those needs. Prototyping can help elicit requirements from the user if you are able to show them something that’s at least close to what they need, and of course with their data.

What you might want to do is identify applications and information the business needs, discuss those requirements with a strong and supportive business sponsor and ask that person to be the project’s sponsor. If they are not interested, move on to the next business person. Without strong business sponsorship your efforts are doomed. Once you have that sponsorship, you can begin gathering requirements. The last thing you want to do is develop a system (or even a prototype) that does not stop the bleeding or does not solve an important information problem.

Chuck Kelley’s Answer: As often as your business changes, the end game will change. That is why the common SDLC approach (the one we all learned in school) does not quite fit business intelligence.

There is great merit in conducting development using an iterative approach. This allows you to get more and more information on what the user community wants to see in the business intelligence environment.

The business analyst (BA) should be involved from the outset. They should have a lot of leeway in determining what should be in each iteration of the environment. From that, you have a plan of attack to get the resources needed to start the development process. Understand that the plan will change as the business and user community changes its requirements. Make sure you have into place a mechanism to discuss costs and time changes as the requirements change.

Joe Oates’ Answer: One of the keys to a successful data warehouse implementation is to understand the for project planning and project management. I think that some research in this area will help. One of the most important ingredients for success is for the implementation team and the customer to have the same definition of success. The project planning process is essential to coming to this common definition. From what I infer from your question, a formal project planning process is not in place. I think you should get one in place before you start the project. The article found at http://www.dmreview.com/master.cfm? NavID=216&EdID=604 should help. You can also go to the Web and look up "data warehouse project plan."

Nancy Williams’ Answer: You are not alone in struggling with how to define BI requirements. This is an area that is commonly troublesome for DW developers and many data warehousing efforts have limped along due to problems in this area. I strongly suggest that you stay away from the temptation to define BI requirements as the list of data elements that the business users hand over to you and ask you to put in the database. Rather, I believe that it is very important to actively involve business users in this process. I suggest utilizing facilitated sessions/interviews to review their business processes and business goals and to discuss how information can be used to support the achievement of these goals. This should provide you with a clear understanding of the business need for information and enable you to formulate the business case associated with the BI requirements. In short, it should be clear to everyone involved why the information you will be delivering to the business is needed, and how it supports the business. As long as the BI requirements are defined in relation to a stated business need, you will be on solid ground as you begin your development efforts. Since BI requirements are not always as easy for users to articulate as operational system requirements, I do strongly urge you to use prototyping techniques as a means to determine and confirm design prior to moving into development.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access