In my last column, I described some requirements gathering techniques that are based on understanding the existing environment – analysis of existing queries and reports, spreadsheet inventory and extract inventory.
Observation also leverages the existing environment for determining the requirements going forward. Observation is defined as “paying attention” and “careful watching and recording of something” (Encarta World Dictionary). The first definition is somewhat passive – it’s the second definition that explicitly requires action on behalf of the observer.
Since observation does not directly delineate requirements, it is up to the BI analyst to structure the surveillance so that it can be used as the basis for gleaning requirements. For transaction processing systems, observation pertains to the actions being taken to perform a business processes. Business intelligence is about analytics and decision-making – the first step is determining the process that needs to be observed. Examples include:
- A sales analyst establishing the forecast for the upcoming period.
- A manager analyzing the variance between actual sales and the forecast.
- The vice president for strategic planning reviewing progress on attaining the strategic goals.
Observation of the sales analyst is likely to reveal various sources of information that are obtained and reviewed, steps taken to verify the data, steps taken to understand the data, and steps taken to actually create the forecast. At each of these points, it is important to understand what the analyst is doing, how long it is taking, and the issues encountered. That understanding will provide information on the current data requirements and the outputs of the process. With that understanding, it will be important to shift to a technique such as interviewing to gain insight into the accuracy of the sales forecasts, feedback received on the format and timeliness, etc.
The manager is likely to reveal that he/she receives a report each period, showing the actual sales, the forecast, the variance and possibly additional data. Observing what the manager does with that report reveals BI needs. For example, if the manager looks at a cover sheet, then goes to page 25, then back to page 12, it is likely that the manager found a positive or negative exception and is then navigating through the data to understand the reasons. This should be explored further and will likely provide input into designing OLAP capabilities. Another approach that could be observed is that the manager, after reviewing the report and making notes, convenes a meeting to discuss it. Further exploration of this observation may lead requirements pertaining to annotation and collaboration. If there are multiple sales managers involved, a facilitated session to discuss their use of the report may be useful.
The vice president for strategic planning is charged with establishing the strategic goals and tracking progress. This person is likely receiving a dashboard or report with key performance indicators. If the report is at a summary level only, then observation will likely expose techniques (e.g., looking at additional inputs, calling others to provide explanations, querying other systems) the VP uses to understand the KPIs. The BI analyst, who understands how BI operates, can use this information to glean the requirements for data content and navigation requirements. An important part of this process, as described in one of my earlier columns, is to talk with the VP and try to understand why the information is needed, and possibly why the strategic targets are at a particular level. A dialogue at that level enables a synergistic process that may help the company adjust its strategic goals.
One of the commonalities of the three situations described is that observation is not the only technique that was used. In each case, it was combined with additional information gathering techniques to provide a more complete picture of the requirements. While observation does not stand on its own, it often provides a good nonintrusive starting point for gathering information requirements.
Throughout my last few columns, I explained some of the differences between traditional requirements gathering and requirements gathering for BI. One of the key distinguishing factors is that the requirements for BI are often not known in advance, and the BI analyst must help the businessperson discover them. We also explored several techniques, including interviewing, facilitated sessions, understanding existing techniques, and finally observation. These and other methods should be appropriately combined to get the best requirements definition possible. But remember, even with the best approach, the nature of business intelligence is that requirements evolve. The BI analyst must determine when he or she has enough information to move forward and recognize that progress toward satisfying a full set of requirements will be made through a series of initiatives.
I welcome your input – please send me your thoughts (at email@example.com).
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
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access