From User Requirements to Conceptual Design in Data Warehouse Design - Data Warehousing Design and Advanced Engineering Applications - page 5

multidimensional solutions (MOLAP/ this information should be provided for a correct

use. Unfortunately, as has already happened in
many other software engineering fields, much
more work has be done for the first type than for
the second one.
As for functional requirements three different
design principles can be identified: supply-driven,
goal-driven and user-driven. Part of the literature
refers to the last two approaches as demand-driven
since requirements are mainly obtained by inter-
viewing the company personnel. We will use this
term when the peculiarities that distinguish the
two original ones are not relevant.
The Supply-driven approach (also called data-
driven ) is a bottom-up technique that starts with
an analysis of operational data sources in order
to identify all the available data (Golfarelli et al.
1998, Jensen et al. 2004). Here user involvement
is limited to select which chunks of the available
data are relevant for the decision-making process.
Supply-driven approaches are feasible when all
of the following are true: (1) detailed knowledge
of data sources is available a priori or easily ob-
tainable; (2) the source schemata exhibit a good
degree of normalization; and (3) the complexity
of source schemata is not too high. While the
supply-driven approach simplifies the design of
the ETL because each data in the DW corresponds
to one or more attributes of the sources, it gives
user requirements a secondary role in determining
the information contents for analysis and gives
the designer little support in identifying facts,
dimensions, and measures. Consequently, the
multidimensional schemata obtained could not fit
the user requirements. This happens not only when
business users are asking for information that is
not actually present in the data sources, but also
when the desired KPIs are not directly available but
could be obtained through some computations. In
other words, with the supply-driven approach there
is the risk of generating performance information
targeting a non-specified user group; such a risk
is particularly high when the target users are at
the strategic levels where the use of complex and

HOLAP).
2.4 ETL process design : designs the mappings
and the data transformations necessary to
load into the logical schema of the DW
the data available at the operational data
source level.
2.5 Physical design : addresses all the issues spe-
cifically related to the suite of tools chosen
for implementation - such as indexing and
allocation.

Requirement analysis and conceptual design
play a crucial role in handling DW peculiarities (a)
and (b) described at the beginning of the present
section: the lack of settled user requirements and
the existence of operational data sources that fix
the set of available information make it hard to
develop appropriate multidimensional schemata
that, on the one hand, fulfill user requirements
and on the other, can be fed from the operational
data sources.

REQUIREMENT ANALYSIS
TECHNIQUES

In this section we classify the requirement analysis
techniques proposed in the literature discussing
their strengths and weaknesses in order to help
the reader understand when and why they can be
successfully adopted in a real project.
First of all it is necessary to distinguish be-
tween functional and non-functional requirements
(Mylopoulos et al. 1992, Chung et al. 1999).
Informally speaking, in software systems func-
tional requirements answer what the system does
and non-functional requirements answer how the
system behaves with respect to some observable
quality attributes like performance, reusability,
reliability, etc. More specifically within DW
systems functional requirements are mainly re-
lated to what information the DW is expected to
provide, while non-functional ones answer how