Moss L.T., Atre S. Business intelligence roadmap: The complete project lifecycle for decision-support applications
Подождите немного. Документ загружается.
Chapter Overview
This chapter covers the following topics:
Things to consider when defining requirements
The differences between general business requirements and project-specific
requirements
The appropriate people to interview to determine general business
requirements
The sections to complete in a business requirements report
The appropriate people to interview when gathering project-specific
requirements for a BI application
The sections to include in an application requirements document
Interviewing considerations and interviewing tips
Brief descriptions of the activities involved in requirements definition, the
deliverables resulting from those activities, and the roles involved
The risks of not performing Step 4
Things to Consider
Functional Requirements
What types of information do the business people in our
organization need? What types of business questions are they unable
to answer today and why?
What reports do they want?
Which reports are most important? Which are least important?
Which reports can be replaced with "canned" queries?
What types of queries will the business analysts run?
Who will administer the query libraries and set up the universes,
for example, data views in online analytical processing (OLAP) tools?
Are the business analysts and knowledge workers planning to write
many ad hoc queries? Can we get some samples of old queries from
them?
Data Requirements
What data do the business people need? Where do they get that
data today?
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
151/631
How clean is the data today? How clean does it have to be?
What data is considered most critical to the business?
Can the data be summarized? If yes, by what dimensions?
Will the business analysts want the capability to drill down to the
detail? How granular does the detail have to be?
Do other business people need the same data? Do we know who
they are? Will they be available to validate the meta data?
What are the expectations for the timeliness of the data and the
availability of the data?
Historical Requirements
How many years of history do we need to keep?
Can we start collecting history from this point forward or do we
have to load data from old archived files?
Security Requirements
How secure does the data have to be? What type of security exists
on the operational source data?
Are the security requirements homogeneous (should all the data
have the same level of security)?
Who should have access to the data?
Performance Requirements
What is the slowest response time the business people will accept
for a query?
Can reports be run overnight rather than during the day in order to
avoid resource contention with interactive usage of the BI target
databases?
How often and for how long will knowledge workers and business
analysts access the BI target databases during the day for ad hoc
reporting and data analysis?
Requirements come in two flavors: (1) general high-level business requirements for
the BI decision-support environment, which are identified at the onset of a BI
initiative and are periodically reviewed, and (2) project-specific requirements, which
concentrate on the detailed deliverables expected from each BI application release.
Table 4.1 lists the differences between the two types of requirements.
Table 4.1. General Business Requirements versus Project-
Specific Requirements
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
152/631
General Business Requirements
Project-Specific
Requirements
Purpose
Determine the general
business needs of the
organization for a BI decision-
support environment
Define the specific
functions and data to be
delivered at the end of a
BI project
Interviewees
Business executives
Information technology (IT)
managers
IT staff
Line-of-business managers
Subject matter experts
Business sponsor
Business representative
"Power users"
Stakeholders
(knowledge workers,
business analysts, data
owners)
Subject matter experts
Deliverable
Business requirements report
Application
requirements document
Content of
deliverable
Findings
Issues
Opportunities
Recommendations
Next steps
Functional requirements
Data requirements
Data-cleansing
requirements
Security requirements
Performance
requirements
Availability
requirements
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
153/631
[ Team LiB ]
General Business Requirements
Marketing strategies often propel the BI decision-support initiatives at organizations
because of the constant challenge to keep up with the competition and to retain
market share. To a large degree, it is the marketing focus that drives the impetus for
more knowledge about the business, in particular about its customers. Marketing
strategies have had an impact on the evolution of decision-support systems since the
early days of IT. Figure 4.1 shows the effect this evolution has had on increasing the
decision-support value of customer-centric applications.
Traditional decision-support systems focused on product-related
operational processes of the organization. Decision-support capabilities were
limited, and marketing efforts revolved around products, not customers.
Customer information files were the first attempt to aggregate all customer-
related data from dozens, if not hundreds, of disparate operational systems into
one central file. Decision-support focus started to shift from products to
customers.
House-holding databases contained customer hierarchies in order to help
business managers understand customer-to-customer relationships. These
databases also contained organizational hierarchies in order to help business
executives understand organizational and regional profitability. House-holding
was the rudimentary precursor of customer relationship management (CRM).
Data warehousing was the first ambitious undertaking of cross-organizational
integration of data for decision-support purposes, such as sales reporting, key
performance indicators, performance trend analysis, and so on. Due to the
enormous effort involved, a wave of new tools started to flood the market, with
extract/transform/load (ETL) and OLAP tools leading the pack.
Customer relationship management focuses on customer-product (sales)
relationships, as well as on customer service, customer buying behavior, and
other knowledge about customers. The goal is to improve customer sales and
services through personalization and mass customization.
Business intelligence is a more holistic and sophisticated approach to cross-
organizational decision-support needs. It uses data mining to gain hidden
(nonexplicit) knowledge about customers, general market conditions, and
competitive products. The goal is to "predict" the future by analyzing the
present, thereby gaining a competitive edge.
Figure 4.1. Increasing Decision-Support Value
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
154/631
Besides marketing, other departments in the organization are also keen to take
advantage of today's technologies to solve their business needs. Such departments
include finance, product management, portfolio management, customer service,
engineering, and inventory management, to name a few.
Interviewees for General Business Requirements
Determining the general business needs of the organization requires interviewing
individuals at every level of the organizational hierarchy, both on the business side
and on the IT side.
Business executives are the visionaries. They know which direction the
organization should move and how to achieve new goals. They also know what
the organization's business pains are. The business executives' requirements
will be focused around strategic information from the BI decision-support
environment.
IT managers support the operational systems of the business areas. They
know the deficiencies of these systems very well, and they are aware of the
backlog for decision-support requirements. Their input can be helpful in
identifying unfulfilled decision-support requirements and in determining how
the BI application can improve the workload for IT.
IT staff work directly with the business staff. The IT staff have firsthand
knowledge of the unfulfilled requirements. They also know the technical skills of
the business people with whom they work. This information will become
valuable input for access and analysis tool selection.
Line-of-business managers are responsible for the smooth operations of the
organization. They focus on tactical decisions on a daily basis. Their
requirements frequently include a mixture of strategic information and
operational information.
Subject matter experts are the senior business analysts with the 10,000-foot
view of a department or a division. Sometimes they are the "power users";
other times they act as internal business consultants. In addition to having an
overall business view, subject matter experts are usually very familiar with
detailed operational data and can give a lot of insights into current data quality
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
155/631
problems.
Data Quality Requirements
Data quality must be discussed with all interviewees. Questions to ask fall into three
categories: existing data quality, desired data quality, and prioritization for data
cleansing.
Existing data quality: Different interviewees might have a different
perspective of what is clean and what is not. They will also have a different
perspective of what should be cleansed and what can remain "dirty."
1.
Desired data quality: Knowledge workers "in the trenches" typically have a
higher tolerance for dirty data than business executives do, mainly because the
knowledge workers have learned over the years how to decipher and interpret
their bad data.
2.
Prioritization for data cleansing: Critical and important data must be sorted
out from insignificant data. Business executives and line-of-business managers
should make that decision.
3.
Data quality affects business people in all critical business areas of an organization,
especially strategic decision-makers, business operations staff, customer support
staff, and marketing staff.
Strategic decision-makers: Probably more than anyone else, strategic
decision-makers (the business executives of the organizations) are affected by
poor-quality data. The decisions they make have an effect on the organizational
lifeline.
Business operations staff: Line-of-business managers and their staff could be
much more efficient if they did not have to constantly resolve errors and waste
time on rework.
Customer support staff: The customer representatives and the sales force
have direct contact with the organizations' customers. Poor-quality data puts a
tremendous burden on this group to keep the customers satisfied and to
prevent them from leaving.
Marketing staff: Managers and knowledge workers in the marketing
department do not want to waste millions of dollars by soliciting customers who
are not worth soliciting, by sending marketing materials to customers who have
moved, or by pursuing dissatisfied customers who have defected to the
competition.
Business Requirements Report
The deliverable from a high-level business requirements activity is a report on the
findings, issues, opportunities, recommendations, and next steps, as shown in Figure
4.2.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
156/631
Findings: The compilation of all requirements from the interviewees should be
sorted by topic. Each finding should be associated with the interviewees and the
interview dates.
Issues: A separate list should highlight critical business issues, so that these
issues can be addressed immediately. Not all business issues require a BI
solution.
Opportunities: Obvious business opportunities should also be extracted and
highlighted from the findings. Again, not all business opportunities will translate
into BI requirements.
Recommendations: After analyzing the findings, issues, and opportunities, a
list of recommendations should be added. These can be recommendations for
correcting a problem on the existing systems or for building a new BI solution.
Next steps: Certain recommended actions are more critical than others, and
some recommended actions may depend on the completion of others. This
section of the report should list the prioritized sequence of actions to be taken
toward implementing a BI solution.
Figure 4.2. Business Requirements Report Content
This report is not listed as a deliverable for a BI project because it occurs outside of
an already approved BI project. It may be used in lieu of a business case assessment
report, if the business case assessment is high-level and not specific to a BI
application.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
157/631
[ Team LiB ]
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
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
158/631
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.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
159/631
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)
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
160/631