BORM: Agile Modelling for Business Intelligence

BORM: Agile Modelling for Business Intelligence

Martin Molhanec (Czech Technical University, Czech Republic) and Vojtech Merunka (Czech University of Life Sciences, Czech Republic)
Copyright: © 2012 |Pages: 12
DOI: 10.4018/978-1-61350-050-7.ch006

Abstract

The business intelligence system gradually became of vital importance for many organizations nowadays. But unfortunately, the traditional static modelling may not be able to deal with it. One solution is to use an agile modelling that is characterized with better flexibility and adaptability. The introduced BORM (Business and Object Relation Modelling) method is just an object-oriented and process-based analysis and design methodology, which has proved to be effective in the development and simulation of large and complex business systems such as business intelligence represents. This chapter describes BORM method and presents it on an application example created in Craft. CASE analysis and modelling tool. At the beginning the authors introduce fundamental principles of BORM method and explain the most important concepts of the method. Finally the authors make clear the method in more detail by means of simple and descriptive, but nontrivial, example from real practice.
Chapter Preview
Top

Background

One of the biggest problems of creating a good business model lies in the initial stages of model development cycle. The initial stages of business modelling methodologies are concerned with two tasks.

The first is the specification of the requirements for the system.

The second is the construction of an initial business model; this model is often called an essential or conceptual model and is built out of the set of the domain specific objects known as essential or conceptual objects.

We must not forget that both these tasks should be carried out with the active participation of the stakeholders, in order to ensure that the correct system is being developed. Consequently, any tools or diagrams used at these early stages should be meaningful to the stakeholders, because many of them are not “software engineering literate”. Finally, these diagrams must not deform or inadequately simplify the requirement information.

Purchase this chapter to continue reading all 12 pages >

Complete Chapter List

Search this Book:
Reset