Requirement Engineering (RE)
The concept of requirement engineering (RE) actually explores the objectives of different stakeholders and the activities carried out by the system. Based on numerous studies (Lubars, Potts, & Richter, 1993; McGraw & Harbison, 1997) it is stated that a system’s functionality when not successful is frequently due to the insufficient understanding of user requirements, hence RE is concerned with overcoming this inadequacy. RE relates to the elicitation and definition of system requirements. Most of the existing research focuses on deriving a surface definition of user requirements, addressing the question “What the system is meant to do” (Guttag & Horning, 1993; Jacobson, 1995; Jones, 1990; Rumbaugh, Blaha, Lorensen, Eddy, & Premerlani, 1991; Spivey, 1992). Recent approaches have emerged targeting user requirement elicitation, or in other words, user requirement discovery, and concentrate on the subject “Why is the system like this?” The following section presents facts on RE and issues encountered, particularly when focusing on the conceptual modelling for user requirements. The related literature and existing work on RE in regards to system objectives and system functionalities has raised the incentive to explore one of its existing approaches, namely the goal-oriented approach as illustrated in Dardenne, Van-Lamsweerde and Fickas (1993). It is important to recognise that, generally, goal-oriented approaches have been largely targeted at the development of software systems rather than focused on document data warehouses involving embedded XML structures. Given this, we will extract and extend the notion of this goal-modelling approach to XDWs, particularly in deriving requirements. This would then help guide the design of the XDW structure by identifying data warehouse dimensions and the nature of the fact repository.
Requirement Engineering Conceptual Modelling
Conceptual modelling is the conventional way of developing information sys- tems, which is the means to accomplish an organisational intention, while requirement engineering aids in conceptualising such systems. In RE, the
conceptual model of a future system is derived from the specification, which outlines the functionalities of the system. Nowadays it is becoming evident that organisational change is rapid, hence the reforms that occur in user require- ments. These changes may occur at any stage in the system’s development process and therefore it is essential to be able to accommodate them as they arise. Based on these facts, two important points are considered:
(a) In order to elicit and validate a system’s requirements it is important to consider their significance to the relevant organisation, and
(b) Conceptual modelling is carried out on a system with the stated objectives (Rolland & Prakash, 2001). What remains an unsolved issue is actually understanding and recording the impact of business changes on user requirements (Lubars et al., 1993).
As is the case for data warehouses, a large number of conceptual models have also been developed to represent information systems, continuously aiming to fulfil the need to capture in greater detail real world semantics. Due to the increasing number of such models, Olle et al. (1988) developed one of the existing frameworks, arranging models based on the perception adopted to examine the universe of discourse. This allows information systems to be viewed from three perspectives, which include: process oriented, data ori- ented and behaviour oriented. In relation to developing conceptual models, one approach shows that the majority of them are based upon the integration of process-oriented and data-oriented viewpoints. The second approach as ob- served by Yourdon (1989) loosely connects the data flow approach (a process model) with entity-relationship (ER) modelling and state transition diagrams. The product characteristics are the focus when developing a system’s conceptual model. In the early days, process models were activity-based, given that a process consists of a set of activities. As time went on more compliant models have been developed, such as the waterfall model (Royce, 1970).
As stated in Rolland and Prakash (2001), user requirements originate from two sources:
(a) The users: User-defined requirements come from people in the organisation where they express their goals and intentions, and
(b) The domain environment: Requirements of the domain which are
related to the nature of the domain and factors that govern it. These cause the universe of discourse to form two worlds, namely, the usage world: Consists of users who will work independently with the system to meet goals and objectives, and the subject world: Relates to the domain where
real-world objects are represented in conceptual schemas (Jarke & Pohl, 1993).
From the information presented so far, it is evident that in RE the two most important aspects are the system objectives and the user viewpoints. The modelling approaches that exist focus on these aspects and give conceptual modelling another dimension. The goal-driven approaches relate organisational objectives with the system functions, whereas the scenario-based approaches and use-case modelling develop a system model by putting emphasis on the user viewpoints as well as deriving useful system functions by including the role of the individuals involved.
In this chapter we will focus on the notion of one existing goal-oriented approach (Dardenne et al., 1993) to model requirements. In addition, with further refinements to conform to the principles of our modelling approach, we introduce the XDW requirement model, which focuses on capturing and eliciting requirements. In order to perform this, it is important to take into consideration the organisational objectives as well as the user viewpoints. Furthermore, these are related to the XDW in particular on deriving dimensions, as opposed to associating organisational objectives to the system functions, which is tradition- ally carried out in RE. The key issue is the principal of correspondence between the real world representation and its domain. This involves the mapping of real world entities to clearly define the corresponding entities in the system, which tends to facilitate a system’s evaluation. We elect to apply a graphical represen- tation for our XDW requirement model to initiate a dialogue between the requirement engineer and the domain expert. Our approach is distinctive, as up to now there have been no attempts to capture user requirements and the entirety of their semantic nature. It is important to note that an essential purpose of a data warehouse is to provide enhanced design support. Therefore its structure must conform to the understanding of the business organisational objectives as well as to the user queries of the data warehouse that are likely to occur.
An overview of the chapter organisation is as follows: We begin with a general outline of the essential principles that exist in data warehouses. Aspects of our previous work are then presented relating to the XML document warehouse (XDW), which includes the conceptual modelling structure of the XML FACT (xFACT) repository and its dimensions, referred to as Virtual Dimensions (VDim), or Conceptual Views. In the third section we introduce the XML document warehouse (XDW) requirement model along with detailed discus- sions, illustrations and definitions. Finally the concepts outlined will be demon- strated using a walkthrough and a case-study example.
Prior to proceeding with the core segment of this chapter it is important to emphasize the fact that data warehousing relates with several compound
modules. Therefore it is essential for us to differentiate these and clearly explain our focus.