Contenu connexe
Similaire à ETIS10 - BI Business Requirements - Presentation
Similaire à ETIS10 - BI Business Requirements - Presentation (20)
Plus de David Walker (20)
ETIS10 - BI Business Requirements - Presentation
- 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 worthless
And then there are the projects that just don’t document them!
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
2
- 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 business
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
3
- 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 requirements
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
4
- 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
delivered
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
5
- 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
deliver
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
6
- 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. Creating achievable requirements
• Three step process:
– Business Requirements
– Data Requirements
– Query Requirements
• Additional Collateral
– Technical Requirements
– Interface Requirements
• By-products
– Business Definition Dictionary
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
8
- 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 requirement
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
9
- 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 requirement
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
10
- 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 requirements
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
11
- 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. Creating Useful Requirements
• Business Requirements
– Understood by the
business
• Data Requirements
– Informs the analysis
and design
• Query Requirements
– Provides the acceptance
criteria for delivery
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
13
- 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. 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
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
15
- 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. 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 methodology
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
17
- 18. Things to watch out for …
• Success is Cultural
• Which Methodology?
• Mix & Match
• Supplier Divorce
• Where Metadata Starts
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
18
- 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
company
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
19
- 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 years
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
20
- 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. 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
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
22
- 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 approach
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
23
- 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
process
Friday,
15
October
2010
©2010
Data
Management
&
Warehousing
24