BI Business Requirements

David M Walker ETIS Stockholm 14th-15th October 2010

Friday,  15  October  2010  

How Valuable Are Your Requirements?

of all documented requirements are worthless

% +

•  Why?
–  Written but never referred to (Shelf-ware) –  Out of date before they are built –  Cover the wrong things –  Can’t be tested

And then there are the projects that just don’t document them!
©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    


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    


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    


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    


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
Business   Requirements   Data   Requirements  

•  These detail the requirements from a business point of view, using language which is meaningful to business users •  The business requirements must be clear and precise
–  Any business terms used must be defined so that the business and the BI team have a shared, unambiguous, understanding of each requirement.

Query  Requirements  

•  A business value must be associated with each requirement

Friday,  15  October  2010  

©2010  Data  Management  &  Warehousing    


Step 2: Data Requirements
Business   Requirements   Data   Requirements  

Query  Requirements  

•  Detail the requirements for business information from the data perspective •  Identify specific data structures and data items •  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    


Step 3: Query Requirements
Business   Requirements   Data   Requirements  

Query  Requirements  

•  These requirements provides acceptance criteria so that the BI team can test that each requirement has been met •  They lists a number of potential queries that the solution should be 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
©2010  Data  Management  &  Warehousing     11  

Friday,  15  October  2010  

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

Business   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?
Requirements   Did  we  deliver  what  we  promised?   Acceptance   Test   IntegraIon   TesIng   System     TesIng   Unit     TesIng  


Does  the  system  hang  together?  


Have  we  build  what  was  designed?  


Does  the  code  we’ve  wriWen  work?  

Friday,  15  October  2010  

©2010  Data  Management  &  Warehousing    


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:

Friday,  15  October  2010  

©2010  Data  Management  &  Warehousing    


Can we have your templates?
•  Templates are an ‘aide •  No! But not memoir’ for methodology for the reason practitioners not a substitute •  People who just take the you think

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    

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    


Success Is Cultural
•  Results are about:
–  Your company culture
•  Are you adversarial? •  Are you willing to adapt? •  Do you have a “can do” attitude?

–  Then the methodologies templates and data models –  Then the technology

–  The people you engage
•  The individuals •  Not the supplier company

Friday,  15  October  2010  

©2010  Data  Management  &  Warehousing    


Which Methodology?
•  No evidence that any particular approach is “the best” •  Vendors & Systems Integrators market their successes but not their failures •  Anecdotally smaller and truly agile projects are also very successfully
Friday,  15  October  2010  

•  The right one is the one that you can make function inside your organisation over many years

©2010  Data  Management  &  Warehousing    

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:
–  Understandable & Accessible –  Revisions –  Testable –  An integrated part of the development process

•  Watch out for:
–  Success is Cultural –  Which Methodology? –  Mix & Match Solutions –  Supplier Divorce –  Where Metadata Starts

Friday,  15  October  2010  

©2010  Data  Management  &  Warehousing    


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