ETIS10 - BI Business Requirements

8/8/2019 ETIS10 - BI Business Requirements

http://slidepdf.com/reader/full/etis10-bi-business-requirements 1/25

BI Business Requirements David M Walker

ETIS Stockholm 14th-15 th October 2010



How Valuable Are Your Requirements?

70 • Why?

– Written but neverreferred to(Shelf-ware)

– Out of date beforethey are built

– Cover the wrongthings

– Can’t be tested

Friday,15October2010 ©2010DataManagement&Warehousing 2

%

+of alldocumentedrequirements

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 withinthemselves and that thedeveloped solution meetsthe requirements when it is

delivered




An essential piece of the puzzle

Good requirements are part of yourend-to-end methodology:

If you don’t know when and how youare going to use the requirements it is

unlikely you will get any value fromthem

If you don’t meet the business’expectation that is created by thegathering requirements process thenit is unlikely that your project will beregarded as successful whatever youdeliver




Requirements & Testing

• Ensure the requirementsare achievable withinthemselves

• Test that the developedsolution meets the

requirements when it isdelivered

• Every methodology will be different• What follows is how wedo 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 froma business point of view, usinglanguage 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 theBI team have a shared, unambiguous,understanding of each requirement.

• A business value must be associated

with each requirement


Data

Requirements

QueryRequirements

Business

Requirements



Step 2: Data Requirements

• Detail the requirements for business information from the dataperspective

• Identify specific data structures anddata items

• Still written from the businessperspective, but map-able to actualdatabase tables and columns

• Many data requirements for each business requirement and eachdata requirement may help satisfy may business requirement


Data

Requirements

QueryRequirements

Business

Requirements



Step 3: Query Requirements

• These requirements providesacceptance criteria so that the BIteam can test that eachrequirement has been met

• They lists a number of potential

queries that the solution should beable to provide answers to• They illustrate how the business

requirements can be satisfied fromthe data requirements

• Many query requirements usemany data requirements to satisfy many business requirements


Data

Requirements

QueryRequirements

Business

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

isdefinedbythe

datainthe

areuIlised

bythe

whichdemonstratethatitispossibletosaIsfythe



Creating Useful Requirements

• Business Requirements – Understood by the

business

• Data Requirements – Informs the analysis

and design

• Query Requirements –

Provides the acceptancecriteria for delivery




Does the process support the delivery?


Requirements

Analysis

Design

Build

Acceptance

Test

ntegraIon

TesIng

System

TesIng

Unit

TesIng

Didwedeliverwhatwepromised?

Doesthesystemhangtogether?

Havewebuildwhatwasdesigned?

Doesthecodewe’vewrienwork?



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 onfree 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 ‘aidememoir’ for methodology practitioners not a substitute

• People who just take thetemplates rarely follow themethodology and then blamethe methodology for theirfailures

• Our consultancy services and white papers are more useful

to you in developing your ownsuccessful BI methodology


• No! But notfor 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 suppliercompany

– Then the methodologiestemplates and datamodels

– Then the technology




Which Methodology?

• No evidence that any particular approach is“the best”

• Vendors & Systems

Integrators markettheir successes butnot their failures

• Anecdotally smallerand truly agile

projects are also very successfully


• The right one is theone that you canmake function inside

your organisationover many years



Mix and Match

• One provider is unlikely to successfully work withthe deliverables from

another provider


– Different methodologies put information and steps indifferent places so trying to marry them up always hasoverlaps and gaps

– The price of vendor review and re-use is often largerthan allowing the vendor to just do it their way andthen internally ensure that everything is carried overfrom 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 Requirementsare 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 anintegrated approach



In summary

• Useful Requirements:

– Understandable & Accessible

– Revisions

– Testable

– An integrated part of the developmentprocess

• Watch out for:

– Success is Cultural

– Which Methodology?

– Mix & Match Solutions

– Supplier Divorce

– Where Metadata Starts




BI Business RequirementsThank You

ETIS Stockholm 14th-15 th October 2010

ETIS10 - BI Business Requirements

Documents

Transcript of ETIS10 - BI Business Requirements