We often preach how important effective and accurate business requirements are to the success if BI projects. We also lament that gathering these requirements can be difficult. There are any number of reasons for this. They range from analysts claiming “users can’t tell me what they want” to statements from customers like “just give me the data and I’ll know what to do with it.” That story usually does not end well.
Others like to play the Agile card and claim that documented requirements are not necessary and they will get to the right place through prototyping and iterative development. That may happen in some cases, but it becomes hard to predict how long this will take and what the costs night be using this method exclusively.
Let me make a couple of suggestions that might help make your requirements more effective. The first has to do with process. As business analysts, we are taught to discover, design, and document business processes so that we may find ways to enable them with information technology. But, you may say (and I have) that BI has nothing in common with a traditional business process like order-to-cash, for example. The result of the preceding question determines the next one, right? This lack of predictability makes traditional requirements gathering difficult if one goes about it using conventional methods.
Simply documenting capabilities is another approach, but it is a cop out. How worthless to a developer is a spreadsheet that says “the System Shall…” about 150 times?
The fact is that we are in the business of supporting decision making and decision making IS a process. Think about the purchase decisions we all make. We gather information from a variety of sources, some of it structured like price lists, supplemented by unstructured information like reviews and often aided by collaboration with friends over social media. This is a defined process that we enable with technology.
Business analysts should never begin requirements gathering by trying to mock up reports or defining the necessary data. Instead, find out what the decisions are that are to be supported. Discover how they are made now, and then work to improve the process with BI technology. Then the data acquisition, integration, presentation, and collaboration requirements will fall right out and you will end up with a document that takes a systemic approach to a better decision support capability.
I promised a second tip, so here it is. When you set up requirements interviews with your customers, ask them to produce the spreadsheets they use now. Even if your customer has trouble telling you what they need, the spreadsheets usually speak volumes. They are the best evidence of how data should be managed and presented, as they are usually used to do what current reporting systems cannot. Oh, and don’t be satisfied with just replicating what the spreadsheet is doing. Think of them as prototypes that are limited by the technology that you are there to improve.