ETIS10 - BI Business Requirements - Presentation

2,826 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,826
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
120
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

ETIS10 - BI Business Requirements - Presentation

  1. 1. BI Business Requirements David M WalkerETIS Stockholm 14th-15th October 2010
  2. 2. 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 worthlessAnd then there are the projects that just don’t document them!Friday,  15  October  2010   ©2010  Data  Management  &  Warehousing     2  
  3. 3. 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 businessFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     3  
  4. 4. 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 requirementsFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     4  
  5. 5. 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 deliveredFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     5  
  6. 6. 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 deliverFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     6  
  7. 7. 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  
  8. 8. Creating achievable requirements•  Three step process: –  Business Requirements –  Data Requirements –  Query Requirements•  Additional Collateral –  Technical Requirements –  Interface Requirements•  By-products –  Business Definition DictionaryFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     8  
  9. 9. 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 requirementFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     9  
  10. 10. 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 requirementFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     10  
  11. 11. 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 requirementsFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     11  
  12. 12. 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  
  13. 13. Creating Useful Requirements•  Business Requirements –  Understood by the business•  Data Requirements –  Informs the analysis and design•  Query Requirements –  Provides the acceptance criteria for deliveryFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     13  
  14. 14. 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  
  15. 15. 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+ DRQFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     15  
  16. 16. 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  
  17. 17. 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 methodologyFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     17  
  18. 18. Things to watch out for … •  Success is Cultural •  Which Methodology? •  Mix & Match •  Supplier Divorce •  Where Metadata StartsFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     18  
  19. 19. 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 companyFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     19  
  20. 20. 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 yearsFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     20  
  21. 21. 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  
  22. 22. 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 informationFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     22  
  23. 23. 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 approachFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     23  
  24. 24. 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 processFriday,  15  October  2010   ©2010  Data  Management  &  Warehousing     24  
  25. 25. BI Business Requirements Thank YouETIS Stockholm 14th-15th October 2010

×