A template for a business intelligence requirements gathering workshop

1. Gathering Business Requirements
An overview of the Data Management & Warehousing approach
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

2. Agenda
¤ Overview of the process
¤ Why gather requirements like this?
¤ Types of requirement
¤ Understanding what we can do
¤ Business processes create data
¤ Understanding dimensions and measures
¤ How these requirements are used
¤ Things to remember
¤ Straw-man Proposal
¤ A "straw-man proposal" is a simple proposal intended to
generate discussion of its disadvantages and to
provoke the generation of new and better proposals.
¤ Next Steps
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

3. Overview of the process
Why gather requirements like this?
Types of requirement
Understanding what we can do
Business processes create data
Understanding dimensions and measures
How these requirements are used
Things to remember
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

4. Why gather requirements like this?
¤ Your opportunity to explain to us what you want to see
from the system in a way that we can understand
¤ There are two parts to this:
¤ US: Ensuring that you get the information that you need to
run the business effectively
¤ YOU: Ensuring that we understand enough about what you
want to quickly and effectively deliver that information
¤ Success requires effective two way communication
¤ Requirements always change
¤ Don’t worry – we know that things will be forgotten or
change – but once we have a good baseline it is much
easier to refine and enhance the solution
¤ We will address how to update the requirements later
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

5. Types of requirements
¤ There are two types of requirement we need:
¤ Business Requirements
¤ What information do you want to see?
(the data and how it needs to be grouped)
This is the primary focus of the workshop
¤ Technical Requirements
¤ When do you want to see the information
(Frequency of refresh and of reporting)
¤ How do you want the information formatted?
(Tables, graphs, charts, etc.)
¤ Where do you want to see it?
(Web, e-mail, RSS, application, etc.)
¤ Who should see the information?
(Security, publication)
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

6. Understanding what we can do
¤ We can only deliver data that is there
¤ We capture as much as we can at the lowest level to use
but your environment creates limitations
¤ This is true of every organisation
¤ We have to prioritise which data we deal with
¤ Whilst we try to deliver as much as possible as quickly as
possible we have to ensure that the most important things
are delivered first
¤ We can only optimise what you ask us to optimise
¤ Business intelligence solutions group and aggregate data
to optimise it for reporting and presentation
¤ Whilst we will have all the data that is available it may take
time to make it available if we don’t know that it is
required as a priority for reporting
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

7. Example Limitations
¤ We only get a feed once a day from the source
¤ LIMITATION: Data can only be refreshed daily
¤ We only get source data in x units
¤ LIMITATION: Limits the granularity of the reports (e.g. if the data is
number of calls per hour, we can not report calls per minute)
¤ The source data has data type discrepancies
¤ LIMITATION: Over time this will negatively affect data quality (e.g. if
31st Feb consistently appears it how do we handle the data?)
¤ We only get a subset of data from source system
¤ LIMITATION: If we haven’t asked for it we won’t get it
¤ LIMITATION: We may not be able to go back and get historical
information if we change the subset of data
¤ None of these are show stoppers, all can be changed as long
as we know what we need
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

8. Business processes create data
¤ There is a known state - a checkpoint
¤ This is measurable using a set of criteria known as dimensions
¤ Some process step is performed – a flow
¤ There is now a new known state - another checkpoint
¤ This is also measurable
¤ Some of the dimensions will have remained the same
¤ But some dimensions will be added and some removed
¤ Reporting is the delivery of data for a given state or states
¤ Reports should be designed to inform management decision making
¤ Analysis is the attempt to gain understanding of the causes of the
state change
¤ Analysis should be designed to help improve the business process
¤ You must have the reporting data before you can effectively
perform analysis
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

9. Understanding Dimensions
Levels Hierarchy Values and
Descriptions
Filters: Level = Value e.g. Month = ‘December 2010’
¤ Typical Dimensions might include:
¤ Calendar ¤ Customer ¤ Product ¤ Manufacturer
¤ Geography ¤ Channel ¤ Partner ¤ Discount Type
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

10. Understanding Measures
¤ Numeric Values
¤ Examples: Quantities, Money, Time
¤ Basic Maths: Sum, Count, Maximum, Minimum
¤ Derived Maths: Average, StdDev, Rank
¤ Linked to and described by Dimensions
¤ Every measure relates to many dimensions
¤ Always relates to the lowest possible level of each
hierarchy
¤ Example:
¤ Number (Measure) and Value (Measure) of
Product (Dimension) sold on Date (Dimension) through
Channel (Dimension)
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

11. How these requirements are used …
Select Month Descriptions
County
Count(Policy) Basic Maths
Sum(Premium) On Numeric Values
Average(Premium) Derived Maths
Rank(Policy) On Numeric Values
From Policies Measures
Calendar Dimensions
Geography
Where Year = ‘2010’ Filters
And Country = ‘England’
And Policy Date = Calendar Date Joins
And Policy Postcode = Geography Postcode
Group By Month Levels
County
Order By Rank(Policy) Sorting
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

12. … to produce a report …
Month County Count(Policy) Sum(Premium) Average(Premium) Rank(Policy)
Jan-2010 Portsmouth 4,956 200,000.00 £40.36 1
Jan-2010 Greater London 4,851 7,611,900.00 £1,569.14 2
Jan-2010 Southampton 4,707 234,600.00 £49.84 3
Jan-2010 Luton 4,424 191,800.00 £43.35 4
Jan-2010 Blackpool 4,064 141,900.00 £34.92 5
Jan-2010 Leicester 4,020 294,700.00 £73.31 6
Jan-2010 Southend-on-Sea 3,935 164,300.00 £41.75 7
Jan-2010 Nottingham 3,919 292,400.00 £74.61 8
Jan-2010 Bristol 3,844 421,300.00 £109.60 9
Jan-2010 Slough 3,724 121,200.00 £32.55 10
Jan-2010 Hull 3,621 258,700.00 £71.44 11
Jan-2010 Reading 3,607 145,700.00 £40.39 12
Jan-2010 Bournemouth 3,549 163,900.00 £46.18 13
Jan-2010 Plymouth 3,169 252,800.00 £79.77 14
Jan-2010 Brighton & Hove 3,104 256,600.00 £82.67 15
Jan-2010 Derby 3,065 239,200.00 £78.04 16
Jan-2010 West Midlands 2,905 2,619,500.00 £901.72 17
Jan-2010 Middlesbrough 2,580 139,000.00 £53.88 18
Jan-2010 Stoke-on-Trent 2,569 240,100.00 £93.46 19
Jan-2010 Poole 2,144 138,800.00 £64.74 20
Jan-2010 Torbay 2,131 134,000.00 £62.88 21
Jan-2010 Merseyside 2,090 1,347,800.00 £644.88 22
Jan-2010 Tyne and Wear 2,025 1,093,400.00 £539.95 23
Jan-2010 Greater Manchester 2,017 2,573,500.00 £1,275.90 24
Jan-2010 Halton 1,515 119,800.00 £79.08 25
Jan-2010 Medway 1,320 253,500.00 £192.05 26
Jan-2010 Warrington 1,086 196,200.00 £180.66 27
Jan-2010 West Yorkshire 1,084 2,200,500.00 £2,029.98 28
Jan-2010 Bracknell Forest 1,049 114,700.00 £109.34 29
Jan-2010 Blackburn with Darwen 1,027 140,700.00 £137.00 30
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

13. … or to produce a chart
£5,000.00
£4,500.00
£4,000.00
£3,500.00
£3,000.00
£2,500.00
£2,000.00
£1,500.00
£1,000.00 Average(Premium)
£500.00 Count(Policy)
£0.00
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

14. Insurance Example
CHECKPOINT FLOW CHECKPOINT
REPORTING ANALYSIS REPORTING
The quantity and value Why do people convert? The quantity and value
of quotes by: • What are the common of policies by:
• Quote Date characteristics • Policy Start/End Date
• Proposed Start Date • What are the differences • Channel
• Channel • Personal Data
• Personal Data
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

15. More checkpoints …
Anonymous quotes provided to aggregator
Flow
Anonymous quotes provided to website
Known quotes provided to website
Flow
¤ At each subsequent
checkpoint we Quote conversion
typically get: Flow
to policy
¤ More dimensions – more information to qualify the data
¤ Less transactional data – less individual transactions
involved
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

16. Things to remember …
¤ Keep your requirements ‘reasonable’
¤ Can be sourced from existing source systems
¤ Will be used to affect your decision making
¤ Consider things in terms of ‘MoSCoW’:
Must Have; Should Have; Could Have; Would Have
¤ Focus your time and effort on Must and Should Haves
¤ Expect to be challenged by us
¤ This is just to make sure that we understand everything by
getting you to (re-)explain and justify
¤ You are the experts in your business ...
¤ We know how manage data to deliver business
intelligence
¤ We know more than most about how data works
¤ See http://datamgmt.com/how-data-works
¤ Working together we can specify the optimal solution
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

17. Straw-man Proposal
A "straw-man proposal" is a simple proposal intended to generate
discussion of its disadvantages and to provoke the generation of
new and better proposals. Often, a straw man document will be
prepared by one or two people prior to kicking off a larger project.
In this way, the team can jump start their discussions with a
document that is likely to contain many, but not all the key aspects
to be discussed.
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

18. Sources for Straw-man
Sources for the straw- Other potential data
man: sources:
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

19. Straw-man Description
Measures Analyse by
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

20. Next Steps …
Do we need more time to add more requirements?
How will we review the requirements?
Who will help flesh out the technical requirements?
Who will sign off the requirements?
Any other questions?
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

21. Simply Explained …
Geek & Poke
http://geekandpoke.typepad.com
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

22. How we record requirements
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

23. Understanding the requirements gap
The difference between what was
required when the development started
and what is required when the
development is delivered
Overcome by:
a) accepting and embracing it
b) ccommunicating with users so
everyone understands the time lag
c) delivering in fast, small increments
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010

24. Thank You
Gathering Business Requirements © 2010 Data Management & Warehousing 21 Jan 2010