Knowing What You Don’t Know: Gathering Requirements in the Discovery Phase

By Peter Keers
  Tuesday, January 06, 2009

Project managers know a critical success factor in any project is good requirements gathering.  For Business Intelligence (BI) initiatives this is particularly crucial since lack of clarity about data at the outset of a project is very common. Because data is at the heart of BI, failure to clearly understand data requirements will almost always increase project cost and time and, possibly, cause the project itself to fail.

To address this issue, OnApproach devotes the first two phases of its project process to requirements gathering. The Discovery phase is the first iteration of requirements gathering. The results of this phase are expanded and enhanced in the subsequent Requirements phase. This iterative method is very effective in finding and documenting information about data for the project.

The Discovery phase has five main steps:

• Technical review
• Identify top level reporting requirements and report owners
• Interview Report Owners  and other  Subject Matter Experts (SMEs)
• Document and validate all reporting requirements information
• Perform preliminary analysis of data relationships

Technical Review

The Technical Review is intended to create an understanding of the technical landscape in which the Development Team will be operating. This includes:

• Hardware used in the environment
• Operational and developmental software used
• System interfaces
• Existing project processes – standards, approvals, documentation artifacts

During this review the Data Analyst and other appropriate Development Team members need to be granted all appropriate permissions to system and physical environments.

Top Level Reporting Requirements

Reporting requirements fall into three categories:

• Recreate existing reports
• Create new reports
• Create an ad hoc reporting capability

It is not unusual for a project to have requirements in all three categories. While an organization may have a main goal of producing existing reports from a data warehouse, new reports and reporting capabilities are frequently needed as well.

For every required report it is essential that a Report Owner or SME be identified.  This person will be accountable for providing the detailed requirements about the report. If the Report Owner is not able to directly provide the requirements, he or she are responsible for finding resources within the organization that that can.

Interview Report Owners

For existing reports, the Data Analyst and Report Owner work to discover the following:

• Report purpose
• Report recipients
• Data object definitions (data objects are the discrete data elements in a report)
• Calculations and aggregations
• Source of data  and update frequency

If a new report is needed, the Report Owner needs to provide the same information as above. Often, the best way to accomplish this is to create a report mock-up which is a realistic facsimile of the desired report.  If ad hoc reporting is required, then the Report Owner needs to create realistic, comprehensive, and specific query scenarios that will be analyzed just like a report. 

All reports and scenarios developed in this phase are repurposed as test cases to be used in the future phases.  Therefore, careful and thorough analysis is essential so the test cases truly reflect the intended requirements of the project.

Document and Validate All Reporting Requirements Information

Armed with the interview results, the Data Analyst “dissects” all target reports and query scenarios and records the results in a document called the Data Objects Analysis Matrix (DOAM).

The reports are analyzed column by column, row by row. All calculations are documented and their individual data elements are specified and traced back the tables from which they originate. If additional information is called for on a new report, the Report Owner should give specific feedback on what additional data elements are needed and what calculations need to be performed.

Once all the reports and scenarios have been recorded in the DOAM, then the Report Owner reviews the document in order to validate completeness and accuracy.

Perform Preliminary Analysis of Data Relationships

Once the DOAM has been validated, then the Data Analyst tests the source data tables. The main areas of testing are:

Data Quality: What is the condition of the data? Are there nulls in columns that were otherwise thought to the 100% populated? Are there values in columns that are unexpected (e.g. – alpha characters where only numerals were expected)?