ETIS10 - BI Business Requirements - Presentation

BI Business Requirements David M Walker

ETIS Stockholm 14th-15th October 2010

How Valuable Are Your Requirements?

70 •  Why? –  Written but never

referred to (Shelf-ware)

–  Out of date before they are built

–  Cover the wrong things

–  Can’t be tested

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

%+ of all

documented requirements are worthless

And then there are the projects that just don’t document them!

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



•  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



•  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


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


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 …


Creating achievable requirements

•  Three step process: – Business Requirements – Data Requirements – Query Requirements

•  Additional Collateral – Technical Requirements – Interface Requirements

•  By-products – Business Definition Dictionary


Step 1: Business 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.

•  A business value must be associated with each requirement


Data Requirements

Query Requirements

Business Requirements

Step 2: Data 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


Data Requirements

Query Requirements


Step 3: 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


Data Requirements

Query Requirements


How the requirements fit together


Business Requirement

Data Requirement

Data Requirement

Data Requirement

Data Requirement

Data Requirement

Business Requirement

Query Requirement

Query Requirement

Query Requirement

Query Requirement

Query Requirement

Query Requirement

is defined by the

data in the

are uIlised by the

which demonstrate that it is possible to saIsfy the

Creating Useful Requirements

•  Business Requirements – Understood by the

business •  Data Requirements – Informs the analysis

and design •  Query Requirements – Provides the acceptance

criteria for delivery


Does the process support the delivery?


Requirements

Analysis

Design

Build

Acceptance Test

IntegraIon TesIng

System TesIng

Unit TesIng

Did we deliver what we promised?

Does the system hang together?

Have we build what was designed?

Does the code we’ve wriWen work?

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


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/


Can we have your templates? •  Templates are an ‘aide

memoir’ for methodology practitioners not a substitute

•  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


•  No! But not for the reason you think

Things to watch out for …

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


Success Is Cultural

•  Results are about: –  Your company culture

•  Are you adversarial? •  Are you willing to

adapt? •  Do you have a “can do”

attitude?

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

company

–  Then the methodologies templates and data models

–  Then the technology


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


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

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”

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


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

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


BI Business Requirements Thank You

ETIS Stockholm 14th-15th October 2010

ETIS10 - BI Business Requirements - Presentation

Technology

Transcript of ETIS10 - BI Business Requirements - Presentation