BI Business Requirements

David M Walker
ETIS Stockholm 14th-15th October 2010
70
How Valuable Are Your Requirements?

% •  Why?
–  Written but never
referred to

of all
documented
+ (Shelf-ware)
–  Out of date before
they are built
–  Cover the wrong
requirements things
–  Can’t be tested
are worthless
And then there are the projects that just don’t document them!
Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     2  
 What Makes Requirements Useful?
•  Understandable & Accessible
–  Business requirements should be written in
such a way that anyone in the business can
understand them
–  Business requirements
should be easily accessible
by anyone in the business

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     3  

 What Makes Requirements Useful?
•  Revisions
–  It must be quick and easy to
update the requirements and
possible to track the changes
–  Developers must have a stable
set of requirements whilst the
business must be free to innovate
and create new requirements

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     4  

 What Makes Requirements Useful?
•  Testable
–  It must be possible to test
both that the requirements
are achievable within
themselves and that the
developed solution meets
the requirements when it is
delivered

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     5  

 An essential piece of the puzzle
Good requirements are part of your
end-to-end methodology:
If you don’t know when and how you
are going to use the requirements it is
unlikely you will get any value from
them
If you don’t meet the business’
expectation that is created by the
gathering requirements process then
it is unlikely that your project will be
regarded as successful whatever you
deliver

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     6  

 Requirements & Testing
•  Ensure the requirements
are achievable within
themselves
•  Test that the developed
solution meets the
requirements when it is
delivered

•  Every methodology will

be different
•  What follows is how we
do it …

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     7  

 Creating achievable requirements
•  Three step process:
–  Business Requirements
–  Data Requirements
–  Query Requirements
•  Additional Collateral
–  Technical Requirements
–  Interface Requirements
•  By-products
–  Business Definition Dictionary
Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     8  
 Step 1: Business Requirements
•  These detail the requirements from
a business point of view, using
language which is meaningful to
Business  
Requirements  
Data  
Requirements   business users
•  The business requirements must be
clear and precise
Query  Requirements  
–  Any business terms used must be
defined so that the business and the
BI team have a shared, unambiguous,
understanding of each requirement.
•  A business value must be associated
with each requirement

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     9  

 Step 2: Data Requirements
•  Detail the requirements for
business information from the data
Business   Data  
perspective
Requirements   Requirements  
•  Identify specific data structures and
data items
Query  Requirements  
•  Still written from the business
perspective, but map-able to actual
database tables and columns
•  Many data requirements for each
business requirement and each
data requirement may help satisfy
may business requirement

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     10  

 Step 3: Query Requirements
•  These requirements provides
acceptance criteria so that the BI
team can test that each
Business  
Requirements  
Data  
Requirements   requirement has been met
•  They lists a number of potential
queries that the solution should be
Query  Requirements  
able to provide answers to
•  They illustrate how the business
requirements can be satisfied from
the data requirements
•  Many query requirements use
many data requirements to satisfy
many business requirements

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     11  

 How the requirements fit together
Query  
Data   Requirement  
Requirement   Query  
Business   Data   Requirement  
Requirement   Requirement   Query  
is  defined   are  
Data   Requirement  
by  the   uIlised  
Requirement   by  the   Query  
data  in  the  
Business   Data   Requirement  
Requirement   Requirement   Query  
Data   Requirement  
Requirement   Query  
Requirement  

which  demonstrate  that  it  is  possible  to  saIsfy  the      

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     12  

 Creating Useful Requirements
•  Business Requirements
–  Understood by the
business
•  Data Requirements
–  Informs the analysis
and design
•  Query Requirements
–  Provides the acceptance
criteria for delivery

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     13  

 Does the process support the delivery?

Acceptance  
Requirements   Did  we  deliver  what  we  promised?  
Test  

IntegraIon  
Analysis   Does  the  system  hang  together?  
TesIng  

System    
Design   Have  we  build  what  was  designed?  
TesIng  

Unit    
Build   Does  the  code  we’ve  wriWen  work?  
TesIng  

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     14  

 What does it take to do this?
•  European Fixed Line Operator
–  At start: 15 BRQ; 50 DRQ; 100 QRQ
•  BRQ/DRQ took 3 weeks, QRQ took another 3 weeks
–  At 5 years: 19 BRQ; 72 DRQ; 225+ QRQ
•  Effort incremental over time
–  Business Definition Dictionary (BDD) built as
part of the process
•  European Mobile Operator
–  At start: 18 BRQ; 100 DRQ
•  BRQ took 3 weeks
–  At 1 year: 18 BRQ; 150+ DRQ

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     15  

 How Do We Implement This?
•  Project Services
–  Integrated Environment based on
free open source software Trac
–  Web Based solution with:
•  Wiki / Ticketing / Version Control /
Test Management / Security
–  More Info:
http://projects.datamgmt.com/

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     16  

 Can we have your templates?
•  No! But not •  Templates are an ‘aide
memoir’ for methodology
for the reason practitioners not a substitute
you think •  People who just take the
templates rarely follow the
methodology and then blame
the methodology for their
failures
•  Our consultancy services and
white papers are more useful
to you in developing your own
successful BI methodology

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     17  

 Things to watch out for …

•  Success is Cultural
•  Which Methodology?
•  Mix & Match
•  Supplier Divorce
•  Where Metadata Starts

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     18  

 Success Is Cultural
•  Results are about:
–  Your company culture –  Then the methodologies
•  Are you adversarial? templates and data
•  Are you willing to models
adapt? –  Then the technology
•  Do you have a “can do”
attitude?
–  The people you engage
•  The individuals
•  Not the supplier
company

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     19  

 Which Methodology?
•  No evidence that any
particular approach is
“the best”
•  Vendors & Systems
Integrators market
their successes but
not their failures •  The right one is the
•  Anecdotally smaller one that you can
and truly agile make function inside
projects are also very your organisation
successfully over many years

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     20  

 Mix and Match
•  One provider is unlikely
to successfully work with
the deliverables from
another provider
–  Different methodologies put information and steps in
different places so trying to marry them up always has
overlaps and gaps
–  The price of vendor review and re-use is often larger
than allowing the vendor to just do it their way and
then internally ensure that everything is carried over
from other projects, this also avoids the “blame game”
Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     21  
 Supplier Divorce
•  BI Projects are long-term
–  Typically 10-15 years
•  DWH Development Contracts are shorter
–  Typically 2-5 years
•  There will come a time
when the developer leaves
–  It’s not always amicable
–  Plan for succession
–  Internalise critical parts of the methodology/
process and information
Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     22  
 This is where Metadata your starts
•  Business & Data Requirements
are the core of your Metadata

•  Spine around which to build:

–  Business Definitions, Data Models,
ETL Loads, Universes
•  There isn’t a single tool to do this
•  You need several tools and an
integrated approach

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     23  

 In summary
•  Useful Requirements: •  Watch out for:
–  Understandable & –  Success is Cultural
Accessible –  Which Methodology?
–  Revisions –  Mix & Match Solutions
–  Testable –  Supplier Divorce
–  An integrated part of –  Where Metadata Starts
the development
process

Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     24  

BI Business Requirements
Thank You
ETIS Stockholm 14th-15th October 2010