Naveen Prakash

Indira Gandhi Delhi Technical University for Women | IGIT · Information Technology

We show that current approaches for data warehouse conceptual modelling are inadequate for capturing the range of analysis capabilities of the enterprise. In addressing this, our conceptual model retains the basic distinction between the analysis data and analysis parameters but additionally introduces intra analysis-data and intra analysis-paramet...

An IoT system is specified in terms of sensors/actuators and communication between them. However, we argue for performing upstream activities of the Systems Development Life Cycle during IoT application development. We propose the conceptual design stage followed by conversion to an IoT system and show that we need concepts for autonomy, perception...

An IoT system is specified in terms of sensors/actuators and communication between them. However, we argue for performing upstream activities of the Systems Development Life Cycle during IoT application development. We propose the conceptual design stage followed by conversion to an IoT system and show that we need concepts for autonomy, perception...

In both, bus of data marts and agile data warehouse development, it is required to select the next product part to be developed. Whereas this issue is not addressed in the former, agile development approaches leave selection from a backlog to the product owner. We provide an approach to backlog selection that is rooted in the decision-making proces...

Whereas requirements engineering for transactional systems aims to discover the functionality of the system-to-be, data warehouse requirements engineering aims to discover the Information contents of the data-warehouse-to-be. Though notions of goals, Decisions, business processes, business events have been used to set the context for Information di...

This chapter discusses the manner in which data warehouses are developed and the major issues in development of these systems. We start by providing a brief introduction to data warehousing concepts and the main problems of data warehouse projects. Thereafter, the systems development life cycle of data warehouse development, and the different ways...

The central role of a decision in data warehouse development is established in this chapter. It is shown that there are three types of decisions, for policy formulation, making policy enforcement rules and for business operations. The problem of requirements engineering is to discover these decisions as well as the information, the requirements gra...

In this book, we have presented an approach that makes requirements engineering as the fulcrum for data warehouse development. The requirements engineering process not only addresses the issue of obtaining requirements, but, additionally, subsumes consolidation to make for an agile development approach to data warehouse fragments. Thus, three dispa...

The book starts with failure statistics of transactional systems and the technological responses for failure mitigation. We discuss the evolution of development processes for transactional systems and highlight the emerging role of agile development. This mitigates failure through iterative and incremental development. The second response is to foc...

The first aspect of requirements engineering namely, determining the decisions of interest is considered here. The three kinds of decisions, that is, decisions for formulating policies, policy enforcement rules and operational decisions are identified. Policies are represented in first order logic and an expression in logic is considered as a hiera...

Since data warehouse projects are large and complex, this chapter proposes an agile technique for data warehouse development. The notion of a data warehouse user story is developed and its difference with user stories of Scrum is brought out. A model-driven approach is presented using which it is possible to build data warehouse user stories. In th...

The second aspect of requirements engineering, that of determining information relevant to a decision is taken up in this chapter. First, basic principles that should be followed in developing good quality elicitation techniques are laid down. Thereafter, requirements elicitation processes for each of the four factors identified in Chapter 3 are fo...

As the first to focus on the issue of Data Warehouse Requirements Engineering, this book introduces a model-driven requirements process used to identify requirements granules and incrementally develop data warehouse fragments. In addition, it presents an approach to the pair-wise integration of requirements granules for consolidating multiple data...

The Business Rules Group has highlighted the importance of the ownership of business rules by business people. This calls for a business oriented view of business rules. Accordingly, we propose to introduce a Business Layer on top of the CIM layer of business rules that considers the essential nature of business rules, their properties and structur...

Traditionally, data warehouse requirements engineering is oriented towards determining the information contents of the warehouse to be. This has resulted in a de-emphasis of the functional perspective of data warehouses. Consequently, it is difficult to specify functions needed for computing business indicators. Our approach aims to elicit needed b...

Data warehousing is largely directed towards “what to do next” type of decisions that essentially address operational decision-making needs. We argue for developing data warehouse support for deciding on organizational policies: policies evolve and therefore need continual decision-making support. We propose an RE approach for discovering informati...

Examination of the notion of situation shows that it does not reflect so much the method characteristics as the characteristics of projects/method implementations. By treating methods as functions the authors are able to postulate functional characteristics of methods. By including these in the description of a situation, they are able to describe...

Traditionally, data warehouse requirements engineering is oriented towards determining the information contents of the warehouse To Be. This has resulted in de-emphasized functional perspective of data warehouses. Consequently, it is difficult to specify functions needed for computing business indicators. Our approach aims to elicit needed business...

To reduce the gap between the business-oriented view of business rules of business people and the technical orientation of technical people, we introduce a Business layer on top of the CIM layer of MDA. This facilitates an investigation into the features of business-oriented business rules. We underpin our work with a four dimensional framework of...

The subject of business rules is complex. We propose a 4-dimensional framework to better understand, communicate, and realize such rules in organizations and application systems. Our 4-dimensions are domain, that considers the role of business rules in business; system for properties of business rule management systems; application platform to unde...

We propose two stages for data warehouse requirements engineering (i) an ‘early information’ part where the information relevant to decision making is discovered, and (ii) a ‘late’ part where this information is structured as facts and dimensions. Our focus is on the former. Early information data warehouse requirements engineering starts with targ...

Conceptual modelling is situated in the broader view of information systems requirements engineering. Requirements Engineering (RE) explores the objectives of different stakeholders and the activities carried out by them to meet these objectives in order to derive purposeful system requirements and therefore lead to better quality systems, i.e., sy...

We propose two stages for data warehouse requirements engineering (i) an 'early information' part where the information relevant to decision making is discovered, and (ii) a 'late' part where this information is structured as facts and dimensions. Our focus is on the former. Early information data warehouse requirements engineering starts with targ...

The area of method engineering has been researched extensively in the last two decades. The first exclusive conference in the subject was held in 1996. In this conference a number of major strands of work and possible directions for the future were discussed. Indeed, work in almost all these directions has progressed in the last fifteen years. Ther...

We address the alignment problem following the Business Driven Development model. A representation system for the first stage of BDD, namely, model is proposed. It is argued that the representation system should be a pure conceptualization of the business process, should abstract out important constructs of business processes, and should be able to...

We develop the notion of a decision requirement as the pair where ‘information’ is that required by the decision maker to assess if the ‘decision’ is to be taken or not. It is shown that there are two kinds of decisions, imperative and managerial. The former are decisions about which transactional service out of a choice of transactional services i...

With the emergence of mergers, acquisitions, and collaborative enterprises, the issues of alignment and interoperability in inter-organization information systems have become more complex than before. We propose a two level development approach driven by the intentional level and going to the process model level. Alignment and interoperability requ...

In order to produce data warehouse systems that reflect organizational decisional needs, development should be rooted in the goals and decisions of organizations. The goal-decision-information model and associated information elicitation techniques for decision making are presented. There are four main techniques, Ends analysis, Means analysis, Cri...

We propose here that enterprise business processes need to be mapped to information systems. Therefore, an information system deliverable is an integration of Enterprise information, Enterprise business rules, and Enterprise processes. Since the process model is built on top of business rules, we propose a uniform representation system that shall...

We focus exclusively on the issue of Requirements engineering for Data Warehouses (DW). Our position is that the information content of a DW is found in the larger context of the goals of an organization. We refer to this context as the organizational perspective. Goals identify the set of decisions that are relevant which in turn help in determini...

In general transformations across models need to be defined for every different pair of models for engineering transformational methods. In this paper we formulate a systematic, computer supported generic technique of performing transformation across models. We formalize the transformation technique by using the graph theoretic notion of isomorphis...

Situational method engineering can be done using either method module based or Intention-Architecture, MIA, based approaches. The latter is organized in the three stages of requirements, design, and construction engineering. We focus here on elaborating the relationship between design and construction engineering of the MIA approach. The key concep...

nformation systems development methods (ISDMs) produce a product, the application, by following a development process model. We argue that in failing to produce the application process model that supports the application product, ISDMs only address part of the IS development problem. Additionally, we show that there is, in fact, a range of abstract...

Variability has proved to be a central concept in different engineering domains, manufacturing, software development etc. in order to develop solutions that can be easily adapted to different organisational settings and different sets of customers at a low price. Our position is that families of business process models, by modeling variability, can...

We propose a three stage method development life cycle. The requirements engineering phase consists of elicitation and representation of method intentions, the design phase produces the architecture of the method and the construction phase consists of organizing method features in a coherent whole. We concentrate in this paper on the Design and Con...

Rather than produce schema transformation methods for every different pair of model, we formulate a systematic, computer supported generic technique of performing transformation across models. We formalize the transformation technique by using the graph theoretic notion of isomorphism. Model concepts are organized in an is built of method graph. Th...

The generic method model assumes that methods abound and method engineering and application engineering is done in diverse areas. Therefore, it is necessary to understand the notion of a method independent of information systems and software engineering. The generic model presented here abstracts out from product and process meta-models to define a...

Wide usage of model transformation in the Information Systems has resulted in a number of transformation approaches recently. In order to provide an insight into the existing transformation approaches, to draw out the practicability and analyze the strengths and weaknesses of these approaches a multidimensional classification is required. In this p...

We propose a requirements elicitation process for a data warehouse (DW) that identifies its information contents. These contents support the set of decisions that can be made. Thus, if the information needed to take every decision is elicited, then the total information determines DW contents. We propose an Informational Scenario as the means to el...

Data Warehouses are decisional information artifacts that are embedded in the organizations that create/maintain them. Therefore, Data Warehouse Requirements Engineering must start from goals and work its way to the decisional information needed to take decisions that fulfils these goals. We propose two associations, the goal-decision association a...

Meta-models and Generic models have been built in the area of Information Systems to facilitate the task of system designers. It de-emphasises the view under which applications are conceived in terms of real world data, operations, constraints and processes. We refer to methods that help in constructing such applications as 'application-centric' me...

The 3-layer architecture for methods consisting of the generic model, meta-model, and method layers is considered and the advantages of introducing the generic layer are brought out. It is argued that this layer helps in method selection, construction of methods in diverse domains and has the potential of rapidly engineering methods. A generic mode...

Rather than produce schema transformation methods for every different pair of models, it is proposed that a generic method should be developed using a method engineer friendly model called the Method View Model. Method concepts are organised in an is composed of hierarchy. A technique is presented that maps concepts of one hierarchy to those of the...

By analogy with a Software Requirements Specification (SRS), it is argued that a Method Requirements Specification (MRS) should be introduced in method engineering. It shares with the SRS the property of implementation-independence. This means that an MRS must be an instance of an abstract metamodel and not of a technical metamodel like GOPRR (Grap...

Although procuring enterprise resource planning systems from commercial suppliers is becoming increasingly popular in our industry, fitting those systems to customer requirements remains problematic. The authors propose an approach for matching ERP system functionality to customer requirements. The assumption made is that the ERP system postulates...

We argue that Enterprise Resource Planning (ERP) installations are difficult to align to specific requirements of the enterprise because of the low level at which ERP functionality is described. We raise this level from a functional description to a goal-oriented one. We use SAP R/3 to illustrate this. A SAP goal expresses the task that a SAP funct...

Situatedness of development processes is a key issue in both the software engineering and the method engineering communities, as there is a strong felt need for process prescriptions to be adapted to the situation at hand. The assumption of the process modelling approach presented in this paper is that process prescriptions should be selected accor...

We view a method as having a static and a dynamic part. The former is concerned with the structure of methods whereas the latter relates to the way in which this structure can be used to build products. Starting with the generic view of a method, the instantiation technique has been used to define a decision-oriented metamodel which, in turn, can b...

Development methods contain heuristics and constraints that help in producing good quality products. Whereas CASE tools enforce method constraints, they rarely support heuristic checking. This paper develops a generic quality model, capable of handling both method constraints and heuristics, which forms the basis of a uniform mechanism for building...

The absence of a formal specification of methods permits application engineers to interpret method concepts in any way they want. Further, different CASE tool designers can implement the same method concepts in different ways. The approach to formal method specification described here is in three levels: the generic level, the method independent le...

Methods are represented in terms of Abstract data types and taking this as the starting oint, CASE tool construction is viewed analogously to compiler construction. A development program is input to the tool. This program is written in a development language developed for expressing the process of conceptual schema generation. This language seeks t...

The new emerging method engineering discipline acknowledges the need for the construction of methods tuned to specific situations of development projects. This raises at least three problems (1) the representation of method fragments in a method base, (2) the formalization of the notion of project situation and, (3) the retrieval of relevant fragme...

Despite a constant improvement in automation in CASE environments, the level of guidance provided to developers is still low, especially in the early phases of information systems engineering. We argue in this paper that a more effective guidance to requirements engineers can be based on a process meta-model which allows us to deal with a large var...

. Reusability of project components, either at the code level or at the conceptual specification level, is considered a fundamental aspect in application development. More recently it as been argued that project histories can support reuse of design decisions. We propose a solution based on so-called process chunks which are generic process frames...

A model called the Evolutionary Object Model is proposed as a means of keeping track of the Requirements Engineering(RE) decisions, their rationales and their effects on the RE product. Under this model an RE artifact is looked upon as an object that can evolve in three ways, by transformation, mutation, and expansion. The history of object evoluti...

It is argued that a methodology provides primitives using which the developer can construct the desired process. From the point of view of a process, a methodology is a passive device which only specifies a set of steps and step transition constraints. A step of a methodology can be modelled in terms of the triplet, . A methodology is a collection...

A query facility to a network DBMS is described wherein it is possible to retrieve and update the data in the database. Apart from the existential and universal quantifiers, some additional quantifiers, which are found useful in a database environment, are provided for. A facility, called the discourse facility, by which a set of related queries ca...

A manner in which new types can be defined in a network model of data is considered. The technique described enables the construction of new record types and new coset types using those defined in the schema. The new types define explicitly the hidden relationships between the data structures of the schema. The rules for constructing both these typ...

A range of integrity constraints that can be specified on a schema expressed in the network model of data is presented. These integrity constraints can be of three kinds. The first, called value sets, defines values which fields of a record type can take on. The second kind can be specified on a record type and the third kind can be specified on a...

A practical method for scheduling multiple users is described here. This has been done by defining two resource lists, a retrieval list and an update list, which contain the resources required for retrieving and updating the database, respectively. For each user these lists are built at the time of the definition of a subschema. The resource lists...

Admin is a database management system based on the network model of data. It has a number of data definition facilities over and above those provided by the CODASYL DDLC. It is possible to define a schema and build subschemas on top of it. Further, one can build another layer of subschemas on any given subschema, subject to the restriction that a t...

In Sangrah, exception conditions of CODASYL have been replaced by fatal errors and by boolean valued functions. Fatal errors can occur either because all the preconditions necessary for a DML statement are not fulfilled or because of the state of the data base at the time when this statement is executed. A mechanism which anticipates the former sit...

A DBMS called Samhita is described. Samhita ia based on the network model of data. The prime motivation behind Samhita was to re-examine the motion of currency indicators with a view to minimising side effects in currency setting and to introduce the concept of multiple positioning in the data base. An attempt was also made to impose a discipline o...

In this document, a language, HYPOL is described. HYPOL represents efforts towards arriving atan integrated language, unified from the points of view of computation, data base definition/manipulation and access control. In arriving at this language the capability concept, as it exists in operating systems, has been used to define access control req...

Rather than produce schema transformation methods for every different pair of models, we formulate a generic way of performing schema evolution across models. We formalize the transformation technique by using the graph theoretic notion of isomorphism. Method concepts are organized in an is built of method graph. The generation technique is used to...