TDWI Requirements Gathering Preview - v1
TDWI Requirements Gathering Preview - v1
All rights reserved. No part of this document may be reproduced in any form, or
by any means, without written permission from The Data Warehousing Institute.
Module 1
Requirements and the BI Lifecycle
Topic Page
Kinds of Requirements 1-2
Kinds of Requirements
A Multi-Level View of Requirements
Kinds of Requirements
A Multi-Level View of Requirements
THE CHALLENGE Gathering business requirements for BI systems is more difficult than for
OF GATHERING operational systems. Without the specifics of business transactions,
scheduled reports, and prescribed business rules it is difficult to know
REQUIREMENTS
where to start and how to proceed.
GETTING STARTED Defined scope for a program or project is the essential starting place to
gather, define, and document requirements. A good scope document
expresses very high level requirements in terms of business capabilities,
services, or products that are needed.
REQUIREMENTS Requirements are the essential first step of every BI program and project.
FIRST They are, in fact, the beginning for successful programs and projects of
many kinds – both technical and non-technical. The importance of
requirements is expressed in many popular phrases: Look before you leap.
Measure twice, cut once. Fools rush in. Each of these sayings expresses
the importance of thought before action. The wisdom of this simple
principle – think first, then act – is obvious. Thoughtful action saves time,
money, waste, rework, effort, frustration, and embarrassment.
For BI programs and projects the principle becomes real as the concept of
requirements first, then design. The idea of understanding requirements
before designing solutions applies regardless of scope and lifecycle – for
architectural, linear, iterative, and agile analysis and design processes.
PROGRAM LEVEL Business requirements at the program level describe BI capabilities that
REQUIREMENTS & are needed by the business. A good definition of BI serves as a guide to
the kinds of business requirements that are beginning of BI architecture.
BI ARCHITECTURE
Dave Wells’ definition (www.b-eye-network.com/wells) works well for
this purpose:
“Business Intelligence is the ability of an organization or business to
reason, plan, predict, solve problems, think abstractly, comprehend,
innovate, and learn in ways that increase organizational knowledge,
inform decision processes, enable effective actions, and help to
establish and achieve business goals.”
Architectural requirements progress from requirements for business
capabilities (reason, plan, etc.) to functional requirements that express
how to deliver capabilities (report, monitor, etc.), and finally to technical
requirements describing the roles of technology in delivering business
capabilities.
Module 2
Kinds of BI Requirements
Topic Page
The Scope of BI Requirements 2-2
BI SPECIFIC The requirements types business, functional, and technical are generic.
REQUIREMENTS They apply to requirements for information and software systems of
many kinds. When working specifically with business intelligence it is
practical to further classify requirements into a structure that helps to
assure completeness of both the requirements gathering process and the
resultant set of requirements.
from Putting the Business Back in BI: A Framework for Requirements and Value Management
© David L. Wells, Reprinted with Permission
A BI Requirements Checklist
Summary
Business Capabilities
Reporting
Analysis
Measurement
Monitoring and Forecasting
Visualization
Search
Business Value
Cost-Value Comparison
Return on Investment (ROI) and Return on Assets (ROA)
Strategic Value
Tactical Value
Operational Value
Business Services
Metrics
Monitoring
Analysis and Analytics
Query and Reporting
Data and Information
Support and Training
Business Applications
Information Systems
Monitoring Systems
Management Systems
Data Integration
Source Data
Data Consolidation
Data Quality
Granularity
Detail
Service Levels
Performance
Timeliness
Capacity
Security
Privacy
Availability
Recoverability
Technology
Data Management
Metadata Management
Data Integration
Data Warehousing
Information Delivery
Business Analytics
Data Mining
Infrastructure
A BI Requirements Checklist
Summary
PUTTING IT ALL The facing page summarizes the topics of this module as a checklist of
TOGETHER forty kinds of requirements in seven groups. Collectively these categories
span the levels of requirements – business, functional, and technical – and
represent most of the common kinds of BI requirements. They may occur
as program-level and architectural requirements and as project-level and
product specific requirements.
Module 3
Requirements Gathering Techniques
Topic Page
Requirements as a Human Process 3-2
ROLES
analyst
subject matter expert
interviewer
surveyor
facilitator
documenter
observer
prototype builder
modeler
reviewer
SKILLS
communication
brainstorming
group dynamics
conversation
clarification
abstraction
precision
visualization
synthesis
analysis
THE ROLES Each person involved in a requirements gathering process typically fills
one or more of the following roles:
THE SKILLS The roles described above work together with these kinds of skills:
THE PEOPLE Getting the right people involves more than roles and skills. Equally
important are the right interests, and these come from the stakeholders. A
stakeholder is anyone whose job may be affected by the program or
project that is the subject of requirements analysis. Stakeholder interests
occur in several forms including:
Ten Techniques
Surveys and Questionnaires
Planned
Structured
Group Focused
Individually Completed
Impersonal
Informative
Ten Techniques
Surveys and Questionnaires
WHY Surveys and questionnaires are most effectively used to get information
from a large number of participants, to gather consistent data from
members of a group, and as a means to collect data that can is easily
summarized and aggregated.
HOW Surveying is a process of multiple steps that are more complex than they
may appear to those who receive and complete surveys. A complete
survey process includes steps to:
Ten Techniques
Interface and Use Case Analysis
Ten Techniques
Interface and Use Case Analysis
Bittner and Spence describe it this way: “Use cases, stated simply, allow
description of sequences of events that, taken together, lead to a system
doing something useful.” (Kurt Bittner, Ian Spence (2002). Use Case
Modeling. Addison Wesley Professional, 2-3. ISBN 0-201-70913-9)
HOW Each use case focuses on describing how to achieve a goal or task. For
most software projects this means that multiple, perhaps dozens, of use
cases are needed to define a robust set of requirements. The degree of
formality in interface or use case analysis varies widely from simple text
descriptions of business scenarios to UML-based use-case models.
Regardless of formality and detail, analysis should minimally identify:
Ten Techniques
Summary
Brainstorming !
Surveys & Questionnaires !
Prototyping !
Observation
Ten Techniques
Summary
CHOOSING The matrix on the facing page summarizes the ten techniques just
REQUIREMENTS discussed and associates them with some of the common considerations
and challenges of requirements gathering. Use it as a guide to select the
TECHNIQUES
techniques that best fit your project profile.
Module 4
Requirements Management Techniques
Topic Page
Requirements as a Systems Process 4-2
TEST Requirements testing is the third and final step of the process. Each
REQUIREMENTS requirement must be evaluated with respect to ensure that it is clear, non-
ambiguous, complete, consistent, necessary, and feasible.
Collecting Requirements
Capturing Requirements
Identity What? Why? Who?
Collecting Requirements
Capturing Requirements
SPECIFY, MODEL, There are many ways in which requirements can be captured and
OR DOCUMENT? recorded. It is that variety that causes the diffusion of language about
requirements gathering – EST, EMT, or EDT. Note that the differences
are entirely about the way in which requirements are recorded: specify,
model, or document. Debate about which is the right way is pointless.
There is no single “best” way to record requirements. The only correct
answer is to use a method and format that works for you and your
requirements team.
SOME GUIDELINES Regardless of the form in which you choose to record requirements, some
guidelines will help to achieve well written requirements statements.
Some of the guidelines found among widely accepted best practices for
requirements gathering:
Testing Requirements
Testing Completeness
Testing Requirements
Testing Completeness
Managing Requirements
Managing Scope
Managing Requirements
Managing Scope
Be careful not to cry “OUT OF SCOPE!” each time a new subject arises.
That is the fast track to unhappy and disengaged stakeholders. And it is
often difficult to know whether a new topic is in scope until it has been
explored.
SCOPE CREEP AND Expanding scope can easily become creeping scope – gradual and
CONTAINMENT unintended expansion of project size and complexity. Compressed scope
risks loss and rework unless out-of-scope requirements continue to be
tracked. Both of these circumstances can be managed by adding one or
more columns to your requirements management document. Depending
on your particular needs, consider columns for:
Module 5
Summary and Conclusion
Topic Page
Best Practices for Requirements Management 5-2
A GUIDE TO GOOD The facing page itemizes ten guideposts for successful and effective
REQUIREMENTS requirements management. Keeping this list in mind (and perhaps visibly
posted) whenever doing requirements work will increase both
MANAGEMENT
effectiveness and efficiency of your requirements processes.
Appendix A
Bibliography and References
Exercises
for TDWI Requirements Gathering
Topic Page
Scenario B-2