This is an interesting article about how to?uncovering business requirements?(click or see the article attached) though in reality it is an interview with Alan Alda, the long time host of PBS series ?Scientific American frontiers???Ross and Kimball recommend the interview approach used by Alda because it is the same as what we used to collect business requirements.
After read this article, please give your comments in the discussion board. You are encouraged to find more articles about how to collect business requirements and share it with the class.?
Alan Alda's Interviewing Tips for Uncovering Business Requirements
Good listening and conversational skills will uncover hidden needs and 'shadow functions.'
By Margy Ross and Ralph Kimball, InformationWeek
May 01, 2005
Alan Alda is still widely known as "Hawkeye" Pierce from the hit television series
"M*A*S*H" but he's also the long-time host of the PBS series "Scientific American
Frontiers," in which he interviews research scientists. Discussing his 11-year hosting stint on
National Public Radio recently, Alda described his approach for eliciting information from
brilliant scientists. His tactics struck a chord with us because they're similar to the methods we
advocate for collecting information from brilliant businesspeople at requirements interviews.
Here are a few of Alda's practical techniques with our embellishments for DW/BI
Be curious, but not too smart. Skilled interviewers must be curious. Alda has a natural
interest in science, but he warns of the "too-smart syndrome" where interviewers think they're
nearly as well versed in the subject as interviewees:
"I found I wasn't asking good enough questions because I assumed I knew something. I
would box them into a corner with a badly formed question, and they didn't know how
to get out of it. Now, I let them take me through it step by step, and I listen. Then I say, 'Well, if that's true, then
how could this be true?' or 'Tell me more about that.'"
Perhaps you've observed too-smart interviewers. Their questions tend to be long-winded, often eliciting blank stares or
responses like "What was the question again?" Interviewers who try to impress others are missing the point. Ask simple,
straightforward questions and you'll have a better chance of understanding complex concepts.
Know-it-all observers are also a potential problem. The observer's behind-the-scenes role during requirements
interviews should be self-explanatory. Observers who would rather be in the limelight sometimes jump right in and start
answering the questions on behalf of the intended interviewees. Once, while interviewing end users at a large
manufacturer, a team had to have a "time out" after the first interview so they could suggest to one of the IT "observers"
that he let the end users answer the questions.
The goal of a requirements interview is to ask questions in order to discover unknown frontiers. Think of it as a onehour immersion to better understand what businesspeople do and why. How do they make decisions today, and how
do they want to be making decisions in the future? First ask interviewees about their roles and responsibilities to get
them engaged and focused on their spheres. From there, cover the following areas:
What are the key business objectives?
For each objective, ask about measures for success to learn more about key metrics and business dimensions.
What roles do data and analysis play in achieving goals? Alternatively, how would better access and analysis
What are the current analysis challenges?
A good question to get the interview started is "How can people tell when you're doing a great job?" Marketing and
salespeople especially like to answer this question.
Take a look at the sample questionnaires in The Data Warehouse Lifecycle Toolkit (see "Required Reading" at the
end of this article ) to get a feeling for the process.
Be conversational. Alda believes "Scientific American Frontiers" is popular because of his conversational approach.
Alda sets a tone that makes the interview more enjoyable for his subject:
"The conversational element … makes it good. I'm trying to find out what she's doing, what it really means and
how she really does it … and she's trying to make me understand. She's not just giving a lecture. So it's a very
This is a profound subject, well known to office anthropologists. Thirty years ago at the Xerox Palo Alto Research
Center, I (Ralph Kimball) was very influenced by the well-known researcher David Holtzmann, who said that the
procedures in a typical office manual are worthless as indicators about how people acquire information and make
decisions. What was needed, in Holtzmann's opinion, were the "shadow functions" that described what really took
place. Perhaps the crucial source of information to make a decision came from informal conversations around the water
cooler. The interviewer needs to get past the procedures manual and find these shadow functions.
For the DW/BI practitioner, being conversational means putting yourself into a business frame of mind. Learn the
language of the business. Don't intimidate end users by asking "What do you want in a data warehouse?" End users
aren't systems designers. Acronyms and IT vernacular don't belong in a business requirements interview. Business as a
second language is a challenge for some of us: Not everyone is cut out to be a lead interviewer.
Tape recorders change meeting dynamics, so don't use them. Users are often uncomfortable being taped and they might
want segments of the meeting to be "off the record," which makes for awkward transitions. If you rely on recorders,
your written notes won't capture the interview's full content, so inevitably you'll have to listen to the recordings and take
supplemental notes. This process is like watching reruns on television: It isn't very interesting, but consumes large chunks
of time. It's better for the lead interviewer and an expert note-taker to be actively engaged in the session.
You're not setting the stage for conversation if you hand a list of data elements to interviewees and ask which ones are
important. Ask open-ended questions to draw them out. Several techniques can help you establish a more
Learn a bit about the business beforehand by reviewing the Web site or annual report to understand companyspecific vocabulary and hot-button issues.
Meet with interviewees on their own turf. Go to their offices or conference rooms, rather than IT meeting spaces.
Prior to the interview, send out an announcement describing the high-level discussion topics and confirming the
interview time and place. Don't attach a detailed questionnaire to this meeting notice. You can't achieve a
conversational flow if you're reviewing questionnaire results-presuming anyone bothers to complete the survey.
Interview questions prepared in advance are fallback devices, used only if uncomfortable lulls occur in
conversations or to ensure key points are covered before ending sessions.
Most good conversations tend to wander, so remember your session goals and steer conversations back on
track if you stray too far from core issues. Stay at a relatively high level in the interview's early stages. Don't
follow an early comment to a very low level of detail, only to run out of time and discover that you haven't
discussed three other major areas of responsibility with important requirements for the DW/BI effort.
Listen, and expect to be changed. When you're gathering requirements, your job is to listen intently:
"There's one skill that I really make use of in a big way, and that is listening. If you don't listen deeply, the
connection won't take place…. [You have to be] willing to be changed by the person you're listening to, where
you're not just waiting for a pause so you can say your thing, but you're actually letting them have an effect on
you if they can."
Good interviewers should be seen but not heard ? well, at least not heard too much. Strong active listening skills are
required (and don't be surprised if you're exhausted after a full day of requirements interviews). Use physical body
language and verbal clues to encourage interviewees and show your interest. Interviewees often understand what
information we're looking for during the requirements process; with a little prodding and a lot of subtle encouragement,
they essentially interview themselves.
Without a doubt, assumptions regarding the scope, timeline, architecture and other matters were made before the
requirements process was in full swing. It's also inevitable that you'll uncover requirements not accounted for in those
pre-existing assumptions. Many times in operational environments, the end user will announce that the data warehouse
"has to tie to the financial books." That's a classic hidden assumption that may be impossible to address. Pay close
attention and actively listen for the unexpected: Of course, once you discover a discrepancy, the DW/BI team needs to
correct the assumptions.
As you're gathering requirements from the business users, intersperse some data reality into the process by interviewing
key IT personnel, especially the master database administrators responsible for operational systems. Consider what the
business needs are in tandem with the availability of data to support these requirements. It's a balancing act, but failure is
inevitable if you consider one without the other. IT meetings tend to be informal discussions, beginning with
knowledgeable project team members. Once you start to hear consistent themes from users, it's time to sit down with
the data gurus and get into the extreme detail of their source systems. A COBOL copy book is worth its weight in gold!
During these data audit interviews, try to understand whether complete, realiable data is there to support what users are
asking for. You're also trying to understand where to find the data land mines ? indicator fields that were never
populated, for example. A good data profiling tool is enormously helpful for digging into the actual data records.
Your attitude and approach as an interviewer are more important than tactical and logistical concerns of setting up and
conducting the sessions. A good interview should seem to the end user like an interesting discussion with a touch of
flattery, rather than a courtroom cross-examination. We're sure Alan Alda would agree.
Dos and Don'ts for Gathering Requirements
Do talk with a vertical span of businesspeople, including executives, directors/managers and analysts.
Don't rely on a single user to represent the business, even if it's less intimidating and easier to schedule.
Do allow plenty of time to coordinate calendars for scheduling, especially with traveling business management.
Don't get angry if someone has to reschedule at the last second.
Do get help from skilled assistants to manage scheduling.
Don't offload interview coordination to someone unfamiliar with the project or organization.
Do arrive for the interview on time.
Don't bring food to the interview, leave your cell phone on or spill a large latte over the interviewee's
conference table and sample reports.
Do plan on a two-person requirements team in each interview, if possible.
Don't overwhelm a lone interviewee with six people sitting across from him, Inquisition-style.
Do designate one person as the lead interviewer with primary responsibility for steering the session.
Don't turn the interview into a free-for-all, bouncing randomly from one interviewer to the next.
Do flesh out your scribbled interview notes immediately, or you'll lose much of the interesting detail by the next
Don't schedule more than four interviews per day.
Do document what you learned during the requirements gathering and feedback results to close the loop with
Don't lose sight of the scope of your DW/BI requirements process.
"Boosting Business Acceptance"
The Data Warehouse Lifecycle Toolkit by R. Kimball, L. Reeves, M. Ross and W. Thornthwaite (Wiley, 1998),
Ralph Kimball, founder of the Kimball Group, teaches dimensional data warehouse and ETL design through
Kimball University and reviews large warehouses. He has four best-selling data warehousing books in print,
including The Data Warehouse ETL Toolkit (Wiley, 2004). Write to him at firstname.lastname@example.org.
Margy Ross is president of the Kimball Group. she cowrote The Data Warehouse Lifecycle Toolkit (wiley, 1998)
and The Data Warehouse Toolkit, 2nd Edition (wiley, 2002). Write to her at email@example.com.
Copyright ? 2012 United Business Media LLC, All rights reserved.