Gathering Business Requirements

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

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

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

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

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

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

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

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

Understanding Dimensions
Levels Hierarchy Values and Descriptions

Filters: Level = Value e.g. Month = ‘December 2010’
¤  Typical Dimensions might include: ¤  Calendar ¤  Geography

¤  Customer ¤  Channel

¤  Product ¤  Partner

¤  Manufacturer ¤  Discount Type
21 Jan 2010

Gathering Business Requirements

© 2010 Data Management & Warehousing

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

How these requirements are used …
Select Month County Count(Policy) Sum(Premium) Average(Premium) Rank(Policy) From Policies Calendar Geography Where And And And Group By Order By
Gathering Business Requirements

Descriptions Basic Maths On Numeric Values Derived Maths On Numeric Values Measures Dimensions Filters Joins Levels Sorting
21 Jan 2010

Year = ‘2010’ Country = ‘England’ Policy Date = Calendar Date Policy Postcode = Geography Postcode Month County Rank(Policy)
© 2010 Data Management & Warehousing

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

Gathering Business Requirements

© 2010 Data Management & Warehousing

21 Jan 2010

… 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 £500.00 £0.00

Average(Premium) Count(Policy)

Gathering Business Requirements

© 2010 Data Management & Warehousing

21 Jan 2010

Insurance Example
CHECKPOINT FLOW CHECKPOINT

REPORTING The quantity and value of quotes by: • Quote Date • Proposed Start Date • Channel • Personal Data

ANALYSIS Why do people convert? • What are the common characteristics • What are the differences

REPORTING The quantity and value of policies by: • Policy Start/End Date • Channel • Personal Data
21 Jan 2010

Gathering Business Requirements

© 2010 Data Management & Warehousing

More checkpoints …
Anonymous quotes provided to aggregator

Flow

Anonymous quotes provided to website

Flow

Known quotes provided to website

¤  At each subsequent checkpoint we typically get:

Flow

Quote conversion 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

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

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

Sources for Straw-man
Sources for the strawman: Other potential data sources:

Gathering Business Requirements

© 2010 Data Management & Warehousing

21 Jan 2010

Straw-man Description
Measures Analyse by

Gathering Business Requirements

© 2010 Data Management & Warehousing

21 Jan 2010

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

Simply Explained …

http://geekandpoke.typepad.com

Geek & Poke

Gathering Business Requirements

© 2010 Data Management & Warehousing

21 Jan 2010

How we record requirements

Gathering Business Requirements

© 2010 Data Management & Warehousing

21 Jan 2010

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

Thank You

Gathering Business Requirements

© 2010 Data Management & Warehousing

21 Jan 2010