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.