Project-Specific Requirements

Project-Specific Requirements

Requirements gathering for a specific project deliverable focuses on defining the explicit business needs of the business sponsor for whom the BI application is being developed. The project requirements should be stated in business terms and should describe the business problem to be solved as well as the acceptance criteria for the BI solution. Figure 4.3 shows an example of a requirements statement.

Figure 4.3. Requirements Definition Statement

A precompiled wish list of data elements and a stack of mock reports do not constitute a requirements definition.

The application requirements document must clearly state the BI project objectives and expected deliverables in terms of:

• Nature of the existing business problem

• Damage (lost business opportunity, exceeded operating costs) caused to the organization by the existing business problem

• Why the problems cannot be solved without a BI solution

• How the BI application will solve the problem

• Detailed requirements for reports and canned queries on the desired subject areas

• Requirements for graphical representation tools, such as OLAP

• Prioritized, detailed data requirements for:

  - All data required for the BI target database(s) as well as for reports and queries

  - All potential data source files and source databases

  

  Source data requirements should be defined in as much detail as possible and as early as possible to enable rigorous source data analysis in the next step. Waiting until the design stage to determine how to source the BI target databases is too late.

• Prioritized, detailed functional requirements for the data-cleansing transformations

• Requirements for historical data (how many years of history)

• Required security features

• Requested service-level agreements (SLAs) for query response time, data cleanliness, hours and days of the BI application's availability, and tool functionality

Defining requirements is a different activity than designing a solution. Exercise caution ”do not jump into designing the BI application at this time, as many technicians tend to do.

Interviewees for Project-Specific Requirements

The interviews for project-specific requirements are limited to those individuals who are directly involved with the BI project and those who are directly impacted by the BI application.

• The business representative should provide the details about the work he or she is performing. It is important to understand the business workflow and where the bottlenecks are since they point to potential challenges with the data or the functionality. Overlooking these challenges could possibly lead to underestimating the project effort.

• The business sponsor sets the objectives for the BI application and states the business need as well as the expectations for the return on investment. He or she should prioritize the requested deliverables if the scope is too large given the project constraints of effort (time), budget, resources, and quality.

• " Power users " often perform the analysis functions, which the BI application is supposed to replace. They have a wealth of information about the detailed requirements for solving the stated business problem.

• Stakeholders could be other knowledge workers, business analysts, or business managers who are performing similar functions and who will use the data in the BI target databases for their own decision-support needs. The BI project team should identify these stakeholders early to determine potential overlapping needs. Stakeholders could also be the data owners. The data owners should always be included in the interviewing process because it is their responsibility to verify that their data is being used and interpreted correctly.

• Subject matter experts could be the same people as the "power users" or could be senior business analysts. They, along with the business representative, are the prime interviewees for project-specific requirements.

Application Requirements Document

The deliverable from a project-specific requirements definition activity is a requirements document itemizing the detailed functional requirements, the detailed data requirements, and the potential sources of data. This document should also detail the requirements for data cleansing, performance, data security, and availability, as shown in Figure 4.4.

• Functions: All functional requirements for reporting and for data access and analysis should be listed and prioritized. This includes contents and algorithms for reports and queries, ad hoc capabilities, Web displays, and other graphical representations. Summarization and aggregation requests as well as drill-down capabilities must be described as well.

• Data: The desired subject areas (e.g., product, customer, orders, campaign) should be confirmed, and the required data elements should be defined. Be judicious about the data scope because going after too much data "just in case they'll need it some day" leads to more complex data models and more time and money spent for data extraction, cleansing, and maintenance.

  

  IT technicians can help identify which source data may not have to be included in the BI target databases based on current low usage of data. However, the final decision on whether or not to include rarely used source data must be made by a business person, not by IT.

  In addition, all previously identified potential source files and source databases should be reviewed. If storing history is a requirement, the archived source files must also be identified and reviewed. Additional data-specific requirements should be defined, such as data load frequency (e.g., daily, weekly, monthly) and data security.

• Data cleansing: The list of requested data elements must be prioritized into critical, important, and insignificant categories. The tolerance level for dirty data must be defined for each data element in the critical category, for example, "Monthly Sales Total: dirty data threshold = 2 percent; Daily Average Portfolio Amount: dirty data threshold = 0.05 percent." Next, the dirty data tolerance level must be defined for each data element in the important category. Insignificant data elements are often passed across without cleansing, mainly due to time constraints.

• Performance: Most knowledge workers of operational systems are accustomed to subsecond response times. Expectations must be set and managed in this respect. Techniques and technologies can improve report and query response times, but rarely ”if ever ”will the response times be as low as subseconds. The question to ask is not what the desired response time is but what an acceptable response time is, followed by the question of how much business management is willing to pay in order to get a better response time.

• Security: Since the data in the BI target databases is the same data as in the operational systems, it should be given similar security considerations. Some exceptions may apply if the data is highly summarized and no drill down to the detail is allowed or even available.

• Availability: Requests for 24/7 availability are rarely valid since a BI decision-support environment primarily supports strategic decision making. The requirement for 24/7 availability is typically an operational requirement. However, it could be valid under some circumstances, such as for international companies that have offices around the globe and that will access a centralized database. In addition to determining hours and days of availability, the percentage of availability during scheduled hours should also be specified, for example, "97 percent availability Monday through Saturday between 5 A.M. and 11 P.M. EST and 90 percent availability Sunday between 5 A.M. and 3 P.M. EST."

Figure 4.4. Application Requirements Document Content