Moss L.T., Atre S. Business intelligence roadmap: The complete project lifecycle for decision-support applications

Подождите немного. Документ загружается.

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

[ Team LiB ]

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

161/631

[ Team LiB ]

The Interviewing Process

The more detailed the requirements document, the more the scope can be solidified

and the more the estimates for the effort can be validated. To accumulate the

necessary details in order to understand the business process, the interview team

must spend some time interviewing all the stakeholders of the application and

studying their environment. When documenting the project requirements, use

graphic techniques whenever possible, such as bubble charts, cause-and-effect

diagrams, entity-relationship diagrams, star schema models, and even functional

decomposition diagrams and data flow diagrams where appropriate. Diagrams make

excellent communication tools. Through visualization, the interviewee can better

verify the interviewer's understanding of the requirements.

Interviewing Considerations

Before scheduling the interviews, some preparation is required. Figure 4.5 lists items

that need to be considered for the interviewing process.

Interview team: Preferably, the interviewer should not conduct the interview

and take notes at the same time. He or she should team up with a "scribe" who

can take notes during the interviews. It is difficult to keep the momentum of the

meeting going if you have to ask the questions, write down the answers, and

think of the next question to ask all at the same time.

Interviewees: Interviews can be conducted with individuals or groups of

individuals. Group interviews work well among peers from the same work area

if they share similar responsibilities. What one person says often triggers a

thought in another person. This synergy can be very productive. The drawback

of group interviewing is that some interviewees may not be as honest or

forthcoming in their responses. The most effective approach to interviewing is

often a balance between individual interviews and group interviews.

Research: Before scheduling the interviews, the interviewer should spend

some time researching existing documents, reports, and Web sites, including

competitors' Web sites. It helps to have as much understanding as possible of

the industry, the business processes, and the organization's terminology and

acronyms.

Questionnaire: A questionnaire for the major topics should be prepared and

mailed to the interviewees before the scheduled interviews. That gives the

interviewees a chance to prepare and to bring supporting documentation to the

interview.

Interview schedule: Do not schedule more than four one-hour interviews per

day because it will take at least one hour after each interview to review, fill in,

or clarify the interview notes. It is imperative to complete or rewrite the notes

taken during an interview on the same day of that interview, so that no

ambiguity or incompleteness remains.

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

162/631

Figure 4.5. Items to Consider for the Interviewing Process

Interviewing Tips

The following interviewing practices can make the process run smoothly and

effectively:

The initial interview should focus on the basic requirements necessary to solve a

specific business problem. Do not dwell on any of the mechanical and logistical

aspects, and do not promise anything hastily. There will be time to get into

detailed analysis later.

Frequently, interviewees will be quite comfortable telling you what they

currently have, but they can provide only minimal insight into what they want

but do not have. Be prepared to guide them with leading questions.

Be prepared to hear and resolve conflicting views and priorities. This is

especially true when speaking with knowledge workers, business analysts, and

business managers from different departments and from different levels of the

organizational hierarchy.

Taking notes usually involves a fair amount of scribbling (or, if using a laptop, a

fair amount of abbreviating). While the discussions are still fresh in the minds

of the interviewer and the scribe, they should review the notes immediately

after each interview and expand on the scribbles and abbreviations. By the end

of the day, the notes must be in such condition that they can be understood

several days or weeks later.

Tape recording interviews can be very helpful when the interview team consists

of only one person. Making a tape allows the interviewer to concentrate on the

questioning rather than on note taking. It is imperative to ask the interviewees

for their permission to record the interview session. Many interviewees do not

like to be recorded, and other interviewees may not be as forthcoming and

honest when they know they are being recorded.

As soon as time permits after each interview, transcribe the interview notes into

a clean interview notes document and send it to all interviewees who

participated in that interview for their approval. Ask the interviewees to change

any misinterpretations and add anything they forgot to mention during the

interview.

[ Team LiB ]

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

163/631

[ Team LiB ]

Project Requirements Definition Activities

The activities for defining project requirements do not need to be performed linearly.

Figure 4.6 indicates which activities can be performed concurrently. The list below

briefly describes the activities associated with Step 4, Project Requirements

Definition.

Define the requirements for technical infrastructure enhancements.

You should have already reviewed the technical infrastructure components to

determine whether they can support the BI application or whether changes are

required. Requirements for technical infrastructure components could include

one or more of the following:

- New or additional hardware

- New database management system (DBMS) or upgrades to the existing

DBMS

- New development tools

- New data access or reporting tools

- New data mining tool

- New meta data repository or enhancements to it

- New network requirements

Define the requirements for nontechnical infrastructure enhancements.

You should have also reviewed and evaluated the nontechnical infrastructure

components. If changes are required, define these requirements now.

Nontechnical infrastructure components to be added or revised could include:

- Estimating guidelines

- Roles and responsibilities

- Standards

- Procedures for:

Use of a methodology

Scope management (change control)

Issues management

Security process

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

164/631

SLAs

Prioritization

Testing process

Support functions

Dispute resolution

Meta data capture and meta data delivery

Data quality measures and triage process

Communication

Define the reporting requirements.

During the interview process, collect or create sample report layouts and

queries. Define and document business rules for deriving data and for creating

aggregations and summaries. It is advisable to determine who will be the

stewards of the query libraries and universes (data views in OLAP tools).

Define the requirements for source data.

Define the detailed data requirements and select the most appropriate source

files and source databases from the potential list of sources created during prior

steps. Spend some time on defining the data-cleansing requirements and the

critical business rules for the data. Perform some cursory data analysis on

suspected poor-quality data so that the scope and the effort estimates created

during Step 3, Project Planning, can be validated.

Review the project scope.

Compare the detailed requirements to the high-level scope in the project

charter. Determine whether the scope is still doable and whether the estimates

are still realistic. If you have learned something that puts the commitment in

the project charter in question, it is time to renegotiate.

Expand the logical data model.

A high-level logical data model was probably produced during earlier steps

(Step 1, Business Case Assessment, or Step 3, Project Planning). Using the

information from the interview sessions, expand the logical data model with

newly discovered entities, relationships, and attributes. If a logical data model

was not produced during prior steps, create a high-level logical data model for

the data requirements in preparation for the data analysis activities.

Define preliminary service-level agreements.

Although many technicians may argue that it is much too early to commit to

SLAs, most business people will ask for them because they constitute the

acceptance criteria. It is best to find the outermost acceptable limits for each of

the following SLAs and refine them as the project progresses:

- Availability

- Security

- Response time

- Data cleanliness

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

165/631

- Ongoing support

Write the application requirements document.

In the application requirements document, itemize the requirements for

functions, data, cleansing, performance, security, and availability. In addition,

list the requirements for enhancing technical and nontechnical infrastructure

components during the BI project. Include the high-level logical data model in

this document.

Figure 4.6. Project Requirements Definition Activities

[ Team LiB ]

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

166/631

[ Team LiB ]

Deliverable Resulting from These Activities

Application requirements document

This document should contain the following sections:

- Technical infrastructure requirements

- Nontechnical infrastructure requirements

- Reporting requirements

- Ad hoc and canned query requirements

- Requirements for source data, including history

- High-level logical data model

- Data-cleansing requirements

- Security requirements

- Preliminary SLAs

Include a list of conducted interviews in date order, a list of the

interviewees, and a summary of the interview notes.

[ Team LiB ]

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

167/631

[ Team LiB ]

Roles Involved in These Activities

Application lead developer

The application lead developer should add application-specific data access and

data analysis questions to the interview questionnaire and should lead that

portion of the interviews. He or she should not conduct separate interviews but

should participate with the data quality analyst and data administrator in the

same interviews. Business people get very annoyed when different IT people

ask them the same questions in different interviews.

Business representative

In addition to sharing the same responsibilities as the subject matter expert,

the business representative should be prepared to demonstrate his or her daily

work routine to the data quality analyst, data administrator, and application

lead developer either before or after the interview sessions.

Data administrator

The data administrator can be of great help to the data quality analyst by

participating with follow-up questions and scribing the answers. In addition, the

data administrator will get a jump start on his or her logical data modeling

activities by hearing the interview discussions firsthand. Such participation in

the interviews also eliminates the need for the data administrator to revisit

some topics with the interviewees where he or she might have had questions.

Data quality analyst

The data quality analyst, the data administrator, and the application lead

developer should develop an approach for conducting the interviews. They need

to decide when and how they will take turns being the interviewer, the scribe,

and the observer. Most likely, the data quality analyst will be the principal

interviewer.

Meta data administrator

The meta data administrator may join the interview team either as a participant

or as an observer, depending on the scope of the proposed meta data

repository solution. The meta data administrator should add his or her own set

of meta data requirements questions to the questionnaire and should lead that

portion of the interviews.

Subject matter expert

The subject matter expert together with the business representative must be

prepared to address the topics on the questionnaire. He or she should also

bring to the interview sessions any reports, forms, screen layouts, code

manuals, and other documents that support or explain the project

requirements.

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

168/631

[ Team LiB ]

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

169/631

[ Team LiB ]

Risks of Not Performing Step 4

Some organizations combine requirements definition activities with data analysis or

with application prototyping activities. While that can be an effective approach, the

danger lies in losing sight of the big picture, that is, the objectives and scope of the

project. When data modelers dig into the data details too soon, analysis paralysis

often results. When the application developers start prototyping too soon, scope

creep often occurs. Other potential risks are that functionality or data are missed,

security issues are ignored, requirements are not prioritized, and business objectives

are not targeted. For all these reasons it is advisable to separate requirements

gathering from data analysis and prototyping.

[ Team LiB ]

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

170/631