A roadmap for the elicitation of business rules in information systems projects
The Authors
Panos Kardasis, Deloitte & Touche Consulting, Halandri, Athens, Greece
Peri Loucopoulos, Department of Computation, UMIST, Manchester, UK
Acknowledgements
We would like to express our gratitude to the reviewers for their insightful comments to an earlier version of this paper.
Abstract
Purpose – In this paper we present a roadmap for the elicitation of business rules based on different stakeholders' perspectives, in order to facilitate the processes of structuring, organizing and expressing business tactic and policy in a way that it is close to the business milieu and stakeholders' viewpoints.
Design/methodology/approach – This paper has derived from a combined research practice. Initially, the development of a roadmap for understanding different stakeholders' perspectives and for identifying their views on business tactics and policies was based on well-grounded work on enterprise goal modelling, combined with a theoretical study of business rule – related concepts. The outcome of this work was tested against a real business case dealing with the development of an electronic procurement system in the pre-fabricated construction sector.
Findings – As a conclusion, the paper put forward a comprehensive methodological framework for dealing with rule-intensive projects. The proposed roadmap can help IT practitioners in collecting and organizing business rule statements that apply within a particular organization, either towards the implementation of change on a business level, or in the context of specifying the (existing or future) functionality of supporting information systems (IS).
Research limitations/implications – The rule roadmap presented here has been coupled with a modelling approach for expressing rules in a structured, consistent manner and for organizing them in a rule repository. Future work includes the extension of this approach to cover design and implementation as part of rule-centric information systems engineering.
Practical implications – Therefore, the overall contribution of this work relates to the provision of guidance for identifying business policy and tactics at an intentional level (through the investigation of the rationale behind them) and for transforming relevant models to the operational level, where business rules are linked to business processes, information and systems.
Originality/value – Although the business rule concept has been examined from different points of view over the past years, the paper attempts to bridge the gap between approaches that see rules as extensions of business goals, other approaches that consider rules as limitations on the way business activities are performed, and finally, approaches according to which rules constrain the creation, modification and deletion of information entities.
Article Type:
Viewpoint
Keyword(s):
Business analysis; Maps; Business planning; Knowledge management; Information systems.
Journal:
Business Process Management Journal
Volume:
11
Number:
4
Year:
2005
pp:
316-348
Copyright ©
Emerald Group Publishing Limited
ISSN:
1463-7154
1 Introduction
The term “information system project” largely covers a number of different types of activities: information technology (IT) strategies development, package selections, solutions customisation and integration, development of custom products, but also management of IT changes (e.g. systems migration, services outsourcing, etc.). Projects that deal with designing and enforcing new ways of working within an organisation can also be considered as IT projects, given that they can be imposed by the adoption of new solutions and related needs.
“Rule-intensive information system (IS) projects” are undertakings where the identification, organisation and structuring of business rules is of major importance. Business rules are defined as “declarations of policy or conditions that must be satisfied” (Martin and Odell, 1998). Typical situations of rule-intensive projects deal with the design, development/customisation and deployment of information systems related to customer relationship management, document management, e-commerce, electronic procurement, enterprise resource planning, project management, workflow management, but also provision of enterprise portal services, decision support and computer-based training.
The complexity of rule-intensive IS projects increases significantly in multi-stakeholder environments. The term “stakeholder” represents individuals (or groups of individuals) that have a direct or indirect interest in an organisation or a particular project. Traditional organisations' introvert character now trades places with a modern, extrovert philosophy, which creates a need to reconcile conflicting stakeholder views. While deregulation allows more freedom in the way business is conducted (and thus less intervention on behalf of the State), more control is required now due to the public requirements for privacy and data protection, preservation of the environment, provision of equal opportunities to individuals and so on. The EU initiative also plays a major role through the enforcement of recommendations and regulations at a European level. Globalisation and mergers oblige organisations to conform (or to be able to conform) to international or local affiliates' ways of working. Business expansion through the Internet places additional constraints. Finally, organisations tend to become more customer-centric pursuing greater customer satisfaction and retention, and also try to motivate their employees by treating them as partners. In both cases, new views are being taken into account in decision-making. This pluralism of views, and therefore pluralism of requirements and constraints, exposes projects to the risk of stakeholders' disagreement at the requirements level, as well as the risk of inconsistency at the specifications level: Different stakeholders have different views on the way business strategies, business tactics and project objectives are/can be operationalised through the project. In rule-intensive projects, an important portion of operational specifications is crystallised in business rule statements.
The main objective of this work is to present a roadmap for the collection of business rules during the analysis phase of multi-viewpoint, rule-intensive IS projects. According to the proposed roadmap, business rules are treated during three different analysis phases: the intentional analysis phase, the operational analysis phase and the IS architecture analysis phase. The intentional analysis phase is mainly concerned with the identification of all the different stakeholders' expectations from the project, and with the capturing of their view on business constraints that need to be taken into account. The operational phase deals with the transformation of these unstructured constraint expressions to business rule statements which reference enterprise knowledge models describing the organisation under investigation structurally and behaviourally. The third phase (IS architecture analysis) aims at adding implementation details to the aforementioned business rulesets, in accordance with the information systems development paradigm to be followed (e.g. through the choice of a specific customisable rule engine, an active database, and so on).
All the necessary methodological tools for collecting and analysing business rules in rule-intensive IS projects, proposed by this work, have their origins in the enterprise knowledge development (EKD) framework (Kardasis, 2001; Loucopoulos, 2000; Kardasis et al., 2000; Wangler et al., 1999; Kardasis and Loucopoulos, 1998; Loucopoulos and Kavakli, 1997, 1995). EKD examines enterprise knowledge from different perspectives, by enabling the modelling of organisational, operational and informational elements of an enterprise.
This theoretical framework has been developed in the context of a number of large, industrial-size applications (Loucopoulos et al., 1991a, b; McBrien et al., 1991; Loucopoulos and Katsouli, 1992; Loucopoulos et al., 1998; Prekas and Loucopoulos, 2000; Wangler et al., 1999). The empirical evidence obtained from these projects has been instrumented in influencing the roadmap presented in this paper. Moreover, it is important to note that other authors have also dealt with the same topic through their involvement in large research initiatives (Rosca et al., 1995; Herbst, 1996b).
The structure of this paper is as follows. The second section presents a number of existing rule approaches and attempts their evaluation based on different criteria. The third section provides a classification of business rules, approached from three perspectives: business context, business process and IS implementation. The fourth section is the proposed roadmap for collecting and organising business rules. The application of this roadmap is illustrated by a case study, which has been based on an EC-funded R&D project. The main objectives of this project include improvement of purchasing and sub-contracting processes in the construction sector, through the development of an electronic procurement system.
2 Business rules in information systems analysis methodologies
An information system (IS) is interpreted as a computer-supported system, which provides a set of users with information on specific topics of interest in a certain organisational context (Iivari and Hirschheim, 1996). A main purpose of information systems analysis is to collect all relevant information about the universe of discourse of an information system (Pohl, 1993). Such information is the description of static and dynamic constraints (i.e. rules) about phenomena perceived in the universe of discourse (Theodoulidis et al., 1990). Naturally, business rules as part of requirements gathering and systems analysis have not been ignored by structured analysis, information engineering or object-oriented analysis approaches (Moriarty, 1993), which to varying degrees, subsume or represent business rules as part of notation schemes used to specify application requirements (Gottesdiener, 1997).
Ross (1997) comments that traditional IS methodologies have addressed rules poorly, and only relatively late in the system development lifecycle. Hay and Healy (1997) mention that rules dealing with information structure may be represented by any of several flavours of Entity – Relationship or Object Class Diagrams, and responses to events may be shown via Essential Data Flow Diagrams (McMenamin and Palmer, 1984) or as Entity Life History Diagrams (Robinson and Berrisford, 1994). There are fewer notations available, however, to describe action assertions. Most notable of these few is probably Object Role Modelling (Halpin, 1995), derived from the Nijssen Information Analysis Method. Herbst et al. (1994) and Amghar et al. (2000) investigate exhaustively the issue, and agree (more or less) on the same conclusions.
In recent years there has been an increasing interest of the IS community in business rules, which has resulted in dedicated rule-centric modelling frameworks and methodologies (Zaniolo et al., 1997; Ross, 1997; Gottesdiener, 1999), international initiatives for the investigation of business rules' role in the context of knowledge management (Hay and Healy, 1997), conferences, workshops and tutorials (Mens et al., 1998; Ross and Lam, 1998), and rule-centric rule management tools and application development support environments (e.g. Blaze Advisor Builder, BRS RuleTrack, Business Rule Studio, Haley Technologies, ILOG Rules, Platinum Aion, Usoft Developer and Visual Rule Studio).
According to Mens et al. (1998), in order to evaluate dedicated rule approaches, one needs to examine whether each one of them:
- Provides a highly expressive rule language which will allow business people to participate in the requirements development phase of IS analysis. Other user-friendly modelling notations may also be necessary to enhance understanding of the application area and to enable communication between the involved parties.
- Provides a formal rule language for expressing rules at the design stage of IS engineering. These rules expressions must be easily implementable in some high-level programming language, or even directly executable.
- Achieves consistency between rules and underlying models (e.g. data models, activity diagrams, class diagrams, state transition diagrams, sequence diagrams, and so on).
- Proposes a meta-model for organising rules in a rule repository, and for facilitating their retrieval (e.g. according to the stakeholders that impose certain rules, the activities that are constrained by them, the object classes that they reference, the objectives that they satisfy, and so on).
- Proposes a roadmap for developing rule models at the analysis stage, and for translating them to rule specifications at the design stage.
- Allows the adoption of any architecture and platform that may suit the needs of the specific application.
Table I attempts to evaluate and compare all the rule approaches that the authors of this paper are aware of, according to a number of evaluation criteria (Herbst et al., 1994; Amghar et al., 2000).
- Formalism. “Formalism” deals with the expressiveness of formalisms for representing business rules, and can take three possible values: “HE” (highly expressive), “ME” (medium expressiveness) and “LE” (low in expressiveness). According to this criterion, a natural language rule statement is highly expressive, while a rule written in C++ or Prolog is not. The idea is that a good formalism should allow business people to understand, modify, or even write from scratch rule expressions with little support from IT experts and knowledge engineers.
- Guidance. The term “guidance” refers to the methodological support that the approach provides, and again, this can be sufficient, or poor, or it may not exist at all. A methodology is by definition supposed to offer guidance about how to use it. A good rule methodology should provide precise information about how to collect and organise rules at the analysis level, and how to translate them to formal rule expressions at the design level.
- Organisation. “Organisation” has to do with how manageable rule models are. Rule models can be highly manageable, or they can be medium or low in manageability. A modelling framework with high manageability should allow the retrieval of rules according to different criteria, imposed by the needs of the various proposed analysis and design activities.
- Rationale. “Rationale” is concerned with the traceability of decisions that enforce or change rules, and its values are “HT”, “MT” and “LT” (high, medium and low traceability, respectively). It has been selected as an additional criterion of rule models manageability, as it is useful for changing and refining rules.
- Formality. “Formality” examines whether rule statements can be expressed based on a formal language or not (“F” is formal, and “inF” is informal), and whether they are in accordance with other models that are necessary for the development of an information system (e.g. a data model).
- Openness. “Openness” deals with whether the examined approach assumes that the IS will be developed according to a specific implementation paradigm or even platform (e.g. using a certain active database). An “open” approach allows the adoption of different architectures and platforms, in order to be able to choose the one that satisfies the needs of the particular application area better.
In BROCOM (Herbst, 1996a, b), the rule language is a type of structured English, and therefore, it is highly expressive. Moreover, rules are organised according to a rich meta-model, and can be retrieved based on a number of different criteria. On the other hand, the rationale behind business rules is not addressed at all. As far as methodological guidance is concerned, Herbst proposes the development of various models which are of great help during the analysis phase, but the process of creating and using them is not clearly defined and described. As an overall criticism, one could say that the BROCOM approach offers a quite satisfactory rule-centric solution for the phase of IS analysis. However, the transition from analysis to design and implementation has not been addressed, which is not necessarily a bad thing, as a specific implementation paradigm has not been taken for granted, and therefore, the adoption of any convenient architecture and platform is allowed.
DSS (Rosca et al., 1995; Rosca and Wild, 1996) is another approach that can assist in the analysis phase of IS development. Its focal point is the support of the rationale behind the establishment of rules. Moreover, DSS adopts the Event-Condition-Action (ECA) paradigm for structuring rule expressions and also links these expressions to the entities of an underlying enterprise model. Therefore, DSS rule models are generally manageable. On the other hand, the existence of a formal rule language could extend the applicability of DSS to the rule specifications generation and rule implementation phases.
The GUIDE project (Hay and Healy, 1997) identifies terms and facts in natural language rule statements, and consequently, the expressiveness it allows is very high. The meta-model it provides for describing the relations between these terms and facts is very detailed. This is good for two reasons:
- GUIDE rule models are highly manageable; and
- they are very formal and fully consistent with the information models of a specific organisation.
A disadvantage of GUIDE is that it does not distinguish between informational and workflow concepts.
IDEA (Zaniolo et al., 1997) is the only methodology that fully covers all the stages of the IS development lifecycle. The maintenance of formality and consistency with underlying business models are two of its focal characteristics. Another advantage is that it offers guidance for every activity being involved in the development of a rule-centric information system. A disadvantage is that the IDEA methodology is directed towards the use of specific active and deductive databases, and of the corresponding rule languages. As a result of this
- IDEA rules are rather difficult to be expressed or even understood by business people; and
- the choice of technologies to be employed for the development of an information system is rather limited.
Martin and Odell (1998) focus on defining business rules and on proposing a rule typology that has been adopted by many methodologists. They also indicate ways that rules can be integrated with various other (OO) IS analysis techniques.
The Ross Method (Ross, 1997) is one of the most complete methodologies presented here. It is formal, in accordance with the underlying data models of an organisation, offers sufficient methodological guidance, and allows management of rule expressions based on a very detailed meta-model. It is also the only methodology that adopts a graphical notation for expressing rules. However, this does not seem to be an advantage, as the complexity of the resulting diagrams and the vast amount of graphical symbols they contain makes them impossible for to be understood by business people.
The Object Constraint Language of UML (Eriksson and Penker, 2000) has also got advantages and disadvantages. Although it is tightly bound with the widely accepted UML diagrams that assist in the design of OO information systems, the formalism it proposes is not very simple to understand and use. Moreover, it does not provide any methodological guidance for the collection of rules. Finally, it does not propose a meta-model for organising them. Instead, the structure it allows is implied by the allocation of rules to classes, attributes, associations and operations.
3 Classifying business rules
It has already been mentioned that the term “business rule” is used by different methodologists in different ways. In Rosca et al. (1995), business rules are “statements of goals, policies, or constraints on an enterprise's way of doing business”. In Herbst (1996a), they are defined as “statements about how the business is done, i.e. about guidelines and restrictions with respect to states and processes in an organisation”. Mitchell Krammer considers them as programmatic implementations of the policies and practices of a business organisation (Krammer, 1997). “Depending on whom you ask, business rules may encompass some or all relationship verbs, mathematical calculations, inference rules, step-by-step instructions, database constraints, business goals and policies, and business definitions” (Halle, 1994).
In this work, business rules are approached from an information systems analysis and design perspective, and can be defined as:
Projections of external constraints on an organisation's way of working, and on its supporting information systems' functionality.
Therefore, we can also distinguish between three types of business rules (Kardasis, 2001; Kardasis and Loucopoulos, 2003), in accordance with the stages of rules analysis which is going to be discussed in Section 4:
- “Intentional rules” are expressions of business rules seen from a business context perspective. They express laws, external regulations, or principles and good practices, which constrain the way an organisation conducts business. Laws are imposed by the legal system of the environment in which the organisation operates (e.g. the State enforces laws on the estimation of taxes). Regulations are not legally binding but are imposed by other organisations as a prerequisite for interacting with them (e.g. an organisation may have regulations about the content, structure and appearance of service offerings submitted by other companies to them). Principles/good practices are recommended ways of working, leading to the acceptance of an organisation by its environment (e.g. a company may adopt the principle of equal opportunities for employing personnel).
- “Operational rules” are expressions of business rules, approached from a business process perspective. They prescribe action on the occurrence of some business event, or describe valid states of an organisation's informational entities.
- “IS implementation rules” are expressions of business rules examined from an IS architecture perspective. They describe valid states of data entities, or prescribe action on the occurrence of some systems event.
“IS implementation rules” are usually derived from specific “operational rules”. Operational rules are usually derived from specific “intentional rules”. In this sense, all the “intentional”, “operational” and “IS implementation” rules of an organisation, together, do not form an unambiguous business ruleset for this organisation. It would be more precise to say that each expression of business policy or constraint has its instance(s) at the intentional, operational and IS architecture level, which relate to three different levels of business regulation maturity.
3.1 Examining rules from a business context perspective: intentional rules
The classification of rules according to business context criteria is based on the distinction between specific application areas (or business activity groups), which exist within most industry sectors. Extensive consulting experience has shown for example that management, business development, sales and marketing, procurement and administration activities can be found in a number of different markets: insurance, construction, manufacturing, banking, utilities, healthcare, real estate, retail, telecommunications, and so on. An empirical classification of rules along these lines is shown in Figure 1.
- Management rules are expressions of business policy or constraints that deal with managerial issues, such as strategy development, tactical planning, business performance management, financial management, investments management, project management, and risk management (quality assurance and issues management).
- Business development rules deal with feasibility exploration concerning a new product or service idea, new product or service design, an existing product's or service's enhancement, trial/testing of a product or service, costing and pricing.
- Sales and marketing rules relate with market analysis, trends forecasting, product or service marketing, product or service withdrawal, public relationships management, customer relationships management, tendering, personalisation of offerings, purchase/service order management, customer account management and customer training.
- Core business rules constitute the wider rule category and depend on the particular characteristics of different industries. Some examples are: product manufacturing rules, distribution rules, returns management rules, store operation rules, operation scheduling rules, billing and revenues collection rules, benefits and claims management rules, service provision rules and service provision network management rules.
- Procurement rules concern purchasing of materials or sub-contracting of business services. Relevant activities are supplier/service provider selection, supplier relationships management, material procurement, service procurement and payables management.
- The term administration rule refers to supporting business activity policies and constraints, and can represent asset management rules, facilities construction and maintenance rules, inventory control rules, IT management rules, legal issues management rules, document management rules, accounting rules and human resources management rules.
Finally, there is a wide variety of rules representing the obligations of an organisation towards the State and the society. These rules relate to: economy, taxation and market, culture and education, employment and equality, environment and energy, health and safety, security and justice, and privacy, data and intellectual property protection.
3.2 Examining rules from a business process perspective: operational rules
The distinction between various types of operational rules is correlated with the attempt to analyse the application domain business processes, through the identification of different interrelated enterprise knowledge entities: actors, activities, activity enablers and information objects. This approach is followed by several existing methodologies, which distinguish between structural and action assertions (elsewhere referred to as integrity constraints and automation rules, or even data and process rules) (Herbst, 1996a; Rosca et al., 1995; Hay and Healy, 1997). In the approach presented here, “operational rules” can be divided into two major categories: “descriptive rules” and “prescriptive rules” (Figure 2).
- Descriptive rules describe valid states of an organisation's informational entities (i.e. information objects, actors, activities and activity enablers), and can be further specialised in “information object rules”, “actor rules”, “activity rules” and “activity enabler rules”. “Information object rules” examine the attributes of “information objects”. “Information objects” represent entities containing information that is useful for an organisation. A service proposal, a product purchase order, or even a product are all represented by the corresponding “information objects”. “Information object rules” define how an “information object” attribute derives from other “information object” attributes, or assign values to such attributes, or examine their integrity. “Actor rules” are very similar, dealing with “actor” attributes (i.e. attributes of employees, partners, customers, and so on). “Activity rules” describe status of activities. And “activity enabler rules” are concerned with the status of “activity enablers”, i.e. the infrastructure that allows the execution of activities.
- Prescriptive rules prescribe action on the occurrence of some business event, and are distinguished into “workflow rules” and “information assertion rules”. “Workflow rules” examine a set conditions on the occurrence of some event, and determine what workflow actions need to be taken. “Information assertion rules” examine a set of conditions on the occurrence of some event, and perform information updates accordingly. Given that all rules are associated with some event implicitly (otherwise they would never take effect), “descriptive rules” are very similar with “information assertion rules”. However, the events of “descriptive rules” are trivial (representing the creation, viewing, updating or destruction of “information objects”), and therefore, they can be omitted. On the contrary, “prescriptive rules” are associated with non-trivial events that occur in the business environment of an application.
3.3 Examining rules from an IS architecture perspective: IS implementation rules
“IS implementation rules” represent the implementable projection of “operational rules” on specific information systems. Meaning that a portion of an organisation's “operational rules” will be automated with the information system under development in the form of “IS implementation rules”. “IS implementation rules” can be of two major types: “systems schema rules” and “systems instance rules” (Figure 3). “Systems schema rules” examine or affect data entities at the schema level (e.g. they refer to clients, purchase orders, the tendering process, and so on). “Systems instance rules” examine or affect data entities at the instance level (e.g. such a rule may determine the access permissions of a particular user on some operation of the information system). “Systems schema rules” are further divided into:
- Data derivation rules aim at deriving a certain object attribute from other attributes of the same or different business objects. Data mapping rules are a special case of “data derivation rules”.
- Data integrity rules determine the legal states or legal state transitions of data attributes, and can be either “data value integrity rules”, or “data association cardinality rules”, or “data value transition rules”.
- Data value assertion rules may (or may not) examine a set of conditions on data attributes in order to assign values to another data attribute. Some types of rules that can be modelled as “data value assertion rules” are data profiling or clustering rules, systems security rules, systems user interface rules, and so on (depending on the selected architecture for the information system under development).
- Systems workflow rules prescribe the execution of a certain systems function on the occurrence of some systems event and as long as a number of conditions hold. Again, “systems workflow rules” can be used for modelling a number of different types of rules depending on the information systems architecture (e.g. systems security and systems user interface rules).
- Systems instance rules can be classified in a similar way, but the corresponding typology is not presented here for reasons of economy.
4 Proposing a business rules collection roadmap
The aim of this section is to propose a roadmap for collecting business rules as part of the requirements engineering process in multi-stakeholder, rule-intensive projects. The principal idea behind this roadmap is that different stakeholders have different views on the objectives of a particular enterprise/project. Therefore, it is necessary to identify all the different interested parties and to examine enterprise/project goals and constraints from their point of view. At a later stage, all these goals and constraints need to be translated to operational expressions of business policies. At the end, such expressions can be easily implemented in one or more business supporting information systems. The three groups of activities mentioned above can be packaged in three major roadmap stages as shown in Figure 4.
- Intentional rule analysis contains preparatory activities aiming at an initial understanding of the organisation, crystallisation of the project's scope and objectives, identification of all the different stakeholders (or their representatives) who can contribute to the rules collection process, and deliberation together with them in order to reveal the origins of the various business rules (i.e. business tactics and constraints).
- Operational rule analysis involves the development of the necessary background in order to express business rules in accordance with actor, activity and information models that describe the organisation, in a structured way.
- IS architecture rule analysis deals with the specification of rules, which are going to be implemented in the rule-intensive information system under development. Such a system can be related to customer relationships management, document management, e-business, electronic procurement, enterprise resource planning, project management, workflow management, portal services, and so on.
The three main stages of the rules collection roadmap (see Sections 4.1-4.3, for more details) are in accordance with the business rules classification scheme of chapter 4, which identifies intentional, operational and IS implementation rule statements.
4.1 Intentional rule analysis
Intentional rule analysis consists of the following steps (Figure 5):
- Business charting includes the study of actors and roles that play an important role within the organisation under investigation. Business charting results in the development of traditional organisational charts and high-level actor-role diagrams, which show the main goals of enterprise actor roles and dependencies with other actor roles.
- Project scoping deals with the identification of specific project goals, and boundaries of the application area to be approached by the project. This step results in the development of enterprise goal graphs and association of their leaf goals with related enterprise roles.
- In viewpoints analysis different stakeholders (or representatives of stakeholders) are asked to explain the objectives of the organisation from their viewpoint, taking into consideration the particular project boundaries. Therefore, the outcome of this step is a set of new goal graphs, representing every different viewpoint.
- In intentional rules collection, the aforementioned goal graphs are analysed, and business rules that affect the realisation of goals positively or negatively are identified in accordance with the rules classification proposed by this work.
4.1.1 Business charting
Any individual or group that is referenced by the organisational chart of an enterprise is an actor. Therefore, actors are the physical entities that are responsible for some aspect of the business. Actors may play one or more roles, be they collections of interrelated atomic activities that contribute to the fulfilment of one or more business objectives. Within this roadmap, the high-level description of roles can be achieved through the development of actor-role diagrams (Prekas and Loucopoulos, 2000). Actor-role diagrams present the main goals of each role, as well as the dependencies between different roles. Dependencies between two roles can be:
- Authorisation dependencies. These denote hierarchical dependencies that may exist between roles.
- Resource dependencies. These illustrate the need for one role to use a resource that can be provided by another role.
- Co-ordination dependencies. These express the fact that a role may await the completion of an activity by another role, or the need for the two roles to co-operate towards the completion of a task.
Actor-role diagrams represent the first attempt of knowledge engineers to understand the organisation's structure and way of working.
4.1.2 Project scoping
The boundaries of a certain project can be explored through the use of a goal-based approach. Goals represent the purpose, rationale, and motivations behind enterprise structures and operations, as well as the intentions, objectives and visions of stakeholders regarding enterprise future states (Dardenne et al., 1993; Loucopoulos and Kavakli, 1995; Yu, 1995). The proposed approach uses the goal concept in order to address both:
- the why and what-if questions behind enterprise operations; and
- the intention of business changes.
Therefore, at the initial stage of a project, key stakeholders need to be approached in order to decide on the exact goals that the project will fulfil. These goals must be elaborated and structured in goal graphs (elsewhere referred to as goal hierarchies or goals trees), the upper levels of which represent ends, while the lower levels represent means for achieving the ends. High-level goals are decomposed to less-abstract goals of the lower level. Extending goal graphs downwards (i.e. refining goals) denotes goal fulfilment (Kavakli and Loucopoulos, 1998). The leaves of goal graphs must link to specific enterprise roles, the activities of which contribute to or are affected by the operationalisation of business goals in a direct or indirect manner.
4.1.3 Viewpoints analysis
Ross and Lam (1998) present the relationship among enterprise “missions and objectives”, “business tactics” and “policies” in the following two definitions:
A tactic is defined as a course of action that can be followed to meet objectives.
A policy expresses that some specific or quantified constraint is needed to meet objectives.
In the same work, it is mentioned that “… a policy must always be sufficiently detailed and precise to give direct guidance to workers such that they know what to do or how to make some decision in relevant circumstances”. Therefore, the fulfilment of objectives becomes feasible through the employment of appropriate tactics, and tactics are implemented in policies.
In the work presented here, the term “goal” embraces both objectives and tactics (Figure 6). Business rules represent policies, and are clearly separated from tactics and goals. Thus, the fulfilment of strategic goals (objectives) depends on the satisfaction of operational goals (tactics), which are eventually implemented in business rules (policies).
The difference between goals and rules is illustrated in the following examples. “To support evaluation of responses to RFPs” is an enterprise goal at the strategic level
Based on all the above, the core idea behind this work could be summarised as follows:
All the rules that are applied consciously or subconsciously within an organisation are hidden behind the rationale of the various enterprise structures and ways of working, and behind the decision paths that have been and are being taken at the various enterprise development stages.
The terms “rationale” and “decision path” refer to sets of goals organised in goal graphs. Such graphs have already been developed to illustrate the general directions of the organisation and of the particular project. However, different stakeholders have different views on business objectives. In Nuseibeh et al. (1994), “views” are characterised as vehicles for separation of concerns, allowing stakeholders to address only those concerns or criteria that are of interest, ignoring others that are unrelated.
Stakeholders with different views are usually aware of different business constraints (in other words, different business rules). These stakeholders need to participate in the requirements analysis phase of the project, by stating their own goals and by discussing how these goals are translated to business rules. Although, the selection of stakeholders is a very crucial but also complicated issue, its investigation is beyond the scope of this paper
The outcome of different stakeholders' involvement in the requirements analysis process is, initially, a set of complementary goal graphs (one or more goal graphs per stakeholder). Problems in the development of different stakeholders' goal graphs may reveal the need for revisiting the project goals (project scoping step). At a later stage, all goal graphs are analysed and rule expressions that are hidden behind them are identified (in accordance with the intentional rule typology presented in a separate section). The relation between goals and rules is threefold:
- goals reveal rules that are enforced by them;
- goals reveal rules that create opportunities for their fulfilment; or
- goals may reveal rules that hinder their fulfilment.
Each rule that is identified within viewpoints analysis is recorded in natural language and is associated with a number of parameters related to
- the stakeholder that revealed it;
- its enforcement authority;
- its enforcement status (e.g. active, suspended);
- its first enforcement date;
- its expiry date;
- its enforcement level (e.g. strict, flexible); and
- Other comments.
4.2 Operational rule analysis
The knowledge modelling “exercise” described in this work mainly aims at the design of business supporting information systems, which will either be built from scratch, or may be based on the configuration of a packaged solution. An initial step in information systems design deals with “architecturing”, which concerns the identification of its distinct (although usually integrated) operational parts. Each one of these parts has a specific objective (“goal”). This objective is fulfilled through the facilitation of a specific workflow (“activities”). A systemic workflow involves one or more types of users (“actors”), uses or produces information (“information objects”), and also engages other enterprise resources (“activity enablers”). Operational rule analysis is based on this rationale, as shown in Figure 7.
“Context” represents the activities of an organisational unit, a certain business process or the boundaries of a specific elementary (business or system) application. For example, we may be talking about the “Purchasing Department” context, or the “Supplies Procurement” context, or the “Electronic Auctioning System” context. Contexts are being identified during business charting and project scoping.
“Actors” must be identified with a view to represent all different operational interests within a particular context, e.g. we may need to refer to “clients”, “suppliers”, etc. in addition to usual internal actors.
An “activity” is an elementary unit of action, necessarily dedicated to the satisfaction of a particular business goal. “Procurement” is not an activity, because it is not elementary (it involves many smaller activities). “Conduction of reverse auction” is an activity. “e-Mailing users” is not an activity because it is not dedicated to the satisfaction of one single business goal.
“Information objects” and “activity enablers” are the various informational and infrastructural resources which need to be used for the execution of the activity.
Actors, activities, information objects and activity enablers are all associated with a number of “attributes”, e.g. the “actor” “client” has a “priority”, the “activity” “auction” has a “type”, the “information object” “printing paper” has a “price” and the activity enabler “electronic marketplace” has a “status”.
The approach presented here does not propose a particular technique for describing actors, activities, information objects and activity enablers. However, widely used formalisms that allow description of business activities at a high level (or escalating levels) of detail are most suitable. For instance, the process modelling component of the IEEE IDEF formalisms (IDEF0, 1993) provides the necessary semantics and notations for depicting major groups of business activities and the ways they interact with each other, along with the relevant information objects. Data flow diagrams (SSADM method; Robinson and Berrisford, 1994) are also an option for representing business activities and produced/used information objects. Information objects can be presented in two types of models: Business object diagrams (which are a variation of the Unified Modelling Language class diagrams) and object lifecycle diagrams, which aim at “describing the states of business objects, from the time they are created until they are destroyed” (Whitten and Bentley, 1998). Business object diagrams are concerned with the way information objects are associated with their attributes and with each other. Object lifecycle diagrams approach information objects from a different perspective: the way they evolve through the occurrence of different business events.
The most important step in operational rule analysis is the development of business rule expressions in accordance with the enterprise knowledge models described above. During this step, some or all of the “intentional rules” collected during intentional rule analysis will be refined to more precise statements which will determine the behavioural aspects of the system under development. More specifically, during operational rules collection, the following actions are being taken:
- “Intentional rules” need to be distinguished into “descriptive” and “prescriptive” ones. “Descriptive rules” describe the structure of all types of informational entities. “Prescriptive rules” explain what has to be done on the occurrence of a certain event, and given that various conditions hold.
- All rules need to be refined to the lowest possible level of operational detail. This will derive a number of “prescriptive rules” from existing “prescriptive rules”. It may also derive “prescriptive rules” from “descriptive rules”.
- All rule expressions need to be rephrased in a way that they become consistent with the models of the previous operational analysis steps, and with a certain rule language.
- “Prescriptive rules” need to be rephrased in a way that it is clear:
- What is the event that triggers their execution.
- What are the conditions that need to be checked.
- What is the action that needs to be taken.
The schema for structuring “operational rules” according to the ECA paradigm (Assche et al., 1988)
4.2.1 Structuring operational rules according to the ECA paradigm
According to the schema of Figure 8, a certain “operational rule” may contain zero, one or more than one events (“operational WHEN part”), zero, one or more than one conditions (“operational IF part”) and one and only one action part (“operational THEN part”). The existence of more than one event indicates that all the events must occur in order for the rule to be executed. Similarly, the existence of more than one conditions means that all the conditions need to be examined in order for the rule to be enforced. Alternative events or alternative conditions are stipulated by multiple rule expressions.
A rule's “operational WHEN part” is used for storing the business “event” that triggers its execution. Events have been defined as “indivisible atomic units of action, with no duration, that occur in the real world, and affect at least one business entity” (Snoeck and Poels, 2000). Although, event modelling is a quite complex area, and one can identify a wide variety of event types, we consider sufficient to refer to distinct business “events” that trigger the execution of “activities”, without analysing them any further. On the contrary, the analysis of “operational rule” conditions and actions is significant in the context of rule management, and therefore, is discussed in detail subsequently.
The “operational IF part” schema presented in Figure 9 shows how rule conditions can be associated with information entity attributes and/or information entities, so that appropriate grouping of rules is facilitated. It is worth mentioning that one condition may be associated with more than one information entities or information entity attributes.
Figure 10 shows a schema for structuring “operational THEN parts”. According to this, different types of assertions, or declarations, or actions are defined on different enterprise information entities (“actors”, “activities”, “activity enablers”, “information objects” and their attributes). Derivations (a special category of “attribute assertion”) are associated with information entity attributes with two types of relationships (“is defined on” and “is used by”), so that it is easy to identify the attribute that a derivation derives, and the attributes that it derives it from. Associations accommodated by the proposed schema allow grouping and retrieval of rules according to their effect on business structures and ways of working. For example, it is easy to retrieve all the rules that affect a certain enterprise activity, or that concern a particular actor.
The type of the “operational THEN part” characterises a rule as a whole. Therefore, if a rule activates an enterprise “activity” in its “operational THEN part”, then it is a workflow rule (no matter whether it examines “activity attributes” or “information objects” in its “operational IF part”).
Finally, an “operational rule” may reference one or more “activity/activity enabler relationships”, “activity/information object relationships” or “actor/activity relationships”. This type of reference determines the context of the rule, especially in cases of complex condition parts, where different informational entities are examined, and it is not clear how these entities relate to each other.
4.3 IS architecture rule analysis
The final stage of the rules collection roadmap deals with the transformation of “operational” to “IS implementation rules”. The first step of IS boundaries finalisation is a refinement of the analysis that took place during the operationalisation stage, which revealed the main groups of functionality to be accommodated by the IS under investigation. The IS boundaries finalisation step provides a more informed view on the IS architecturing process, taking into account all the practical limitations and the available solutions that can be adopted (Figure 11). Subsequently, the IS designers can proceed with the development of the data schema which will support the new IS. IS implementation rules will make references to this data schema, which may not contain all the informational entities mentioned in the operational rule analysis stage (i.e. all actors, all activities, all information objects, all activity enablers, and all their attributes). This depends on the constraints placed by the selected architectural solution.
At the final step of IS implementation rules collection, previously collected “operational rules” are translated to the corresponding “IS implementation rules” according to the typology presented in a previous section. Again, there will be many “operational rules” which will not be projected on the IS architecture level in any way, while a number of rules (e.g. dealing with data mappings, security, etc.) will appear for the first time during this stage.
It is worth mentioning that the collection of “IS implementation rules” depends on the information systems' implementation choices very heavily (especially in cases of packaged solutions' customisation). Therefore, it is very difficult to prescribe methodological actions at a great deal of detail, for tackling all the issues that may need to be solved.
5 Collecting business rules towards the design of an electronic procurement system in the construction sector
The case study presented in this section illustrates the application of the business rules collection roadmap in a rule-intensive project within the construction sector. The objective of this project was to design an electronic procurement system, which would assist a medium-sized construction company in purchasing raw materials from their suppliers, and in sub-contracting services to other companies. The structure of the following paragraphs reflects the different steps of the proposed roadmap.
5.1 Business charting
An initial activity of the business charting step involved the development of the organisational chart of Figure 12. According to this chart, the company has two different levels of management: The upper level consists of the Managing Director and two assisting managers (technical manager and financial manager). The lower level consists of the various project managers (one for each construction site), and the managers of the supporting departments (accounting, administration, legal, central warehouse). All the individuals or groups of individuals represented by the company's organisational chart are our project's “actors”.
The enterprise roles played by a portion of the above actors are shown in the actor-role diagram of Figure 13. Each role contains the main goals that the corresponding actors fulfil through his/her enterprise activities, as well as its dependencies with other roles. For example, in order for the Project Manager “to manage contracts with specific clients”, the Managing Director needs to “sign off contract … ”.
5.2 Project scoping
The project scoping step starts with the development of a goal graph presenting the general expectations from the project. According to the goal model of Figure 14, the main aims of the project are “to manage RFPs electronically” and “to perform electronic catalogue procurement”. RFPs are the requests for proposals on behalf of sub-contractors and involve the publishing of specifications for sub-contracted services, the evaluation of proposals and the management of contracts. Catalogue procurement concerns the purchasing of raw materials, and includes creation of purchase orders, invoicing, payments and monitoring of order execution.
Matching of project scoping “goals” discussed above with the “role” goals collected during the business charting step can lead to the identification of enterprise internal enterprise “actors” who have some stake in the realisation of each project goal, and therefore, need to participate in the analysis process. This is shown in Table II.
5.3 Viewpoints analysis
The objective of this step is to identify all the different viewpoints that need to be taken into account in the rule analysis process. These viewpoints are not only internal to the organisation. The “client”, the “supplier”, the “sub-contractor” and even the “State” also have an interest in the project. For example, the client expects from the project to stay within budget, and to respect quality standards described in the contract. The “State” has legal requirements regarding the construction process and product, tax requirements, and so on. External viewpoints will be discussed by the appropriate internal actors as shown in Table III.
The following two goal graphs (Figures 15 and 16) represent the viewpoints of the construction company itself and of the sub-contractor. The reader can notice that the same project goals are refined differently for each one of the two different viewpoints. For example, as far as the electronic evaluation of proposals are concerned, the construction company has three goals: “to pre-select top ranking suppliers”, “to reject suppliers that do not seem to be credible”, and “to select proposals with highest technical quality/price rate”. On the other hand, the objectives of the sub-contractors are “to ensure transparency of the evaluation process”, “to ensure opportunities to new entrants in the field”, and “to ensure that there can be negotiations on terms and prices after the proposal stage”.
5.4 Intentional rules collection
The following tabular structures present “intentional rule” expressions collected by analysing the goal graphs of the viewpoints analysis step. Each tabular structure is organised as follows. Top cells contain goals. Below each goal there is one or more rules. Each rule is accompanied by a rule type (based on the rules classification scheme presented in an earlier section of this work) and the type of relationship between the rule and the goal behind it. Additional information is also kept (e.g. details about the session that revealed a particular rule) which is not shown in this example (Table IV).
5.5 Operational rule analysis
The objective of operational rule analysis is to develop a structured business process and enterprise knowledge context concerning the organisation under investigation, and to transfer “intentional rule” expressions into this context, in the form of ECA rules.
Table V attempts to present main operational elements that are of interest within our project's scope in terms of “actors”, “activities”, “activity enablers” and “information objects”. Each row of this table reads as follows: “Actor” participates in “activity”, which uses/produces “information object”, by using “activity enabler”. Two examples are: “Construction company participates in RFP publishing which uses/produces RFP”; and “Construction company and sub-contractor participate in contract development, which uses/produces contract”.
The information entities of the above table can also be presented in graphical enterprise knowledge models, which will facilitate communication and deliberation with the stakeholders. In the case study presented here, the simplified data flow diagram of Figure 17 shows flow on information objects from one activity to another, while the simplified entity – relationship diagram of Figure 18 represents the main relationships between the aforementioned information objects.
At the final step of operational rules analysis, “intentional rule” expressions developed during the intentional analysis stage will be rewritten in a way that they are
- in accordance with the ECA paradigm; and
- consistent with the operational (activity and information) models describing the organisation under investigation.
Some of the results of this process are shown in Figure 19.
6 Summary and conclusion
This paper puts forward a roadmap for collecting business rules and proposes a set of methodological tools for managing the artefacts of the rules collection process in the context of rule-intensive information systems analysis. The proposed approach, which has been illustrated through a case study dealing with the design of electronic procurement support in the construction sector, is based on the analysis of different stakeholders' enterprise goals. In principle, business rules are considered to be either the effect of enterprise goal operationalisation, or the reason behind the way goals are operationalised. Based on that, rules are “harvested” by examining the views of different stakeholders on their organisation's objectives, and on the relation between these objectives and existing business constraints. In this way, it is guaranteed that the collected rules represent the policies and tactics that enterprise management has decided, and not the ones that the organisation's employees are used to apply (possibly and often incorrectly). Moreover, it is guaranteed that parameters that employees may not be aware of (e.g. complex legal issues, delicate ethical concerns, and so on) will also be taken into consideration.
The roadmap to business rules collection is also strengthened by the use of a comprehensive rule classification, which identifies all the possible areas of interest within most business environments (e.g. management, business development, sales and marketing, and so on) and indicates the stakeholders that need to play some role in the analysis process. The proposed classification has been based on extensive consulting experience from analysing different industrial domains, and from designing information systems either from scratch or based on the available functionality of customisable packaged solutions.
A final advantage of the proposed approach concerns rule management. The concept of rule management is closely related to the efficient organisation and retrieval of business rule expressions. The work presented here proposes a schema for structuring and organising rules, by linking them with the goals and other rules they derive from, information about the rule collection sessions that revealed them, business or information system events that trigger their execution (if there are any), and various information entities (i.e. “actors”, “activities”, “activity enablers” and “information objects”) that constitute their context, and that characterise their condition and action parts. Therefore, by organising rules according to the proposed approach in a repository environment, it is easy, for example, to retrieve all these rules that concern a particular supplier, or apply on a specific activity, or need to be triggered as soon as the status of an activity enabler changes.
On the other hand, the proposed approach has a number of limitations, which also point out directions for future work. For example, the rule collection roadmap needs to be enriched with guidelines for selecting the appropriate stakeholders to participate in the process. A methodology for resolving conflicting stakeholder views also needs to be encompassed. Moreover, a rule management tool is necessary in order to be able to exploit the potential of the proposed rule organisation schema. Another disadvantage that needs to be mentioned relates to the size and complexity of rule projects that adopt the proposed approach. The fact that rule operationalisation pre-assumes extensive process modelling of the application domain is a discouraging parameter, given that it increases the duration and cost of the project as a whole. Finally, the success of a rule project is highly dependent on the organisation's culture, in the sense that key stakeholders need to be convinced about the necessity of knowledge management activities in general, have to be familiar with the concept of “business goal” and “business rule” in particular, and must be in agreement with the choice to take into account different viewpoints in order to determine requirements and IS specifications.
Figure 1Intentional rules classification
Figure 2Operational rules
Figure 3IS implementation rules
Figure 4The three main stages of the rules collection roadmap
Figure 5Intentional rule analysis steps
Figure 6From goals to rules
Figure 7Operational rule analysis steps
Figure 8Operational rules schema
Figure 9Operational IF part schema
Figure 10The operational THEN part schema
Figure 11IS architecture rule analysis steps
Figure 12Organisational chart of the construction company
Figure 13High-level actor-role diagram for the construction company
Figure 14Using goal graphs for project scoping
Figure 15The construction company's viewpoint
Figure 16The sub-contractor's viewpoint
Figure 17Simplified data flow diagram for the procurement under investigation
Figure 18Simplified entity – relationship diagram for the procurement application
Figure 19Final outcome of the rules operationalisation process
Table IEvaluation of existing rule approaches
Table IIIdentification of actors
Table IIIAppropriate internal actors
Table IV“Intentional role” expressions
Table VMain operational elements of interest
References
Ahn, J.H., Skudlark, A.E. (1997), "Resolving conflict of interests in the process of an information system implementation for advanced telecommunication services", Journal of Information Technology, Vol. 12 No.1, pp.3-13.
Amghar, Y., Meziane, M., Flory, A. (2000), "Using business rules within a design process of active databases", Idea Group Publishing, Vol. 11 No.3, pp.3-15.
Assche, F.V., Layzell, P., Loucopoulos, P., Speltincx, G. (1988), "Information systems development: a rule-based approach", Knowledge-Based Systems, Vol. 1 No.4, .
Dardenne, A., Lamsweerde, A.V., Fickas, S. (1993), "Goal-directed requirements acquisition", Science of Computer Programming, Vol. 20 pp.3-50.
Dayal, U. (1988), "Active database management systems", in Beeri, C., Schmidt, J.W., Dayal, U. (Eds),Morgan Kaufmann, San Matheo, CA, paper presented at 3rd International Conference on Data and Knowledge Bases, pp.150-69.
Eriksson, H-E., Penker, M. (2000), Business Modelling with UML, OMG Group, Wiley Computer Publishing, New York, NY, .
Gottesdiener, E. (1997), "Business rules show power, promise", Application Development Trends, Vol. 4 No.3, .
Gottesdiener, E. (1999), "Discovering an organisation's knowledge: facilitating business rules workshops", Williamsburg, Virginia, .
Halle, B.V. (1994), "Back to business rule basics", Database Programming and Design, October, available at: www.dbpd.com/vault/new_online.shtml, .
Halpin, T. (1995), Conceptual Schema and Relational Database Design, Prentice-Hall, Englewood Cliffs, NJ, .
Hay, D., Healy, K.A. (1997), "Business rules: What are they really?", GUIDE (The IBM User Group), available at: www.BusinessRulesGroup.org, .
Herbst, H. (1996a), "Business rule oriented conceptual modelling", Physica-Verlag, .
Herbst, H. (1996b), "Business rules in system analysis: a meta-model and repository system", Information Systems, Vol. 21 No.2, pp.147-66.
Herbst, H., Knolmayer, G., Myrach, T., Schlesinger, M. (1994), "The specification of business rules: a comparison of selected methodologies", in Verijn-Stuart, A.A., Olle, T.W. (Eds),CRIS 94, University of Limburg, Maastricht, .
IDEF0 (1993), "Integration definition for function modelling (IDEF0)", Computer Systems Laboratory, National Institute of Standards and Technology, FIPS Pub 183, 21 December, .
Iivari, J., Hirschheim, R. (1996), "Analysing information systems development: a comparison and analysis of eight is development approaches", Information Systems, Vol. 21 No.7, pp.551-75.
Kardasis, P. (2001), "Business rule modelling", Information Systems Engineering Group, Computation Department, UMIST, Manchester, .
Kardasis, P., Loucopoulos, P. (1998), "Aligning legacy information systems to business processes", Springer, Pisa, paper presented at 10th International Conference on Advanced Information Systems Engineering (CAiSE 98), .
Kardasis, P., Loucopoulos, P. (2003), "Managing business rules during the requirements engineering process in rule-intensive IT projects", in Abramowicz, W., Klein, G. (Eds),Colorado Springs, CO4-6 June, .
Kardasis, P., Prekas, N., Loucopoulos, P. (2000), "A framework of patterns for the banking sector", paper presented at DEXA 2000 DomE – International Workshop on Enterprise and Domain Engineering in conjunction with the DEXA 2000 Conference, pp.818-22.
Kavakli, V., Loucopoulos, P. (1998), "Goal-driven business process analysis – application in electricity deregulation", in Pernici, B., Thanos, C. (Eds),Springer, Pisa, 10th International Conference on Advanced Systems Engineering (CAiSE 98), .
Krammer, M.I. (1997), "Business rules: automating business policies and practicies", Distributed Computing Monitor, May, .
Lacity, M.C., Hirschheim, R. (1995), "Benchmarking as a strategy for managing conflicting stakeholder perceptions of information systems", Journal of Strategic Information Systems, Vol. 4 No.2, pp.165-85.
Loucopoulos, P. (2000), "From information modelling to enterprise modelling", in Brinkkemper, S., Lindencrona, E., Solvberg, A. (Eds),Information Systems Engineering: State if the Art and Research Themes, Springer, New York, NY, pp.67-78.
Loucopoulos, p., Katsouli, E. (1992), "Modelling business rules in an office environment", SIGOIS Bulletin, Vol. 13 No.2, pp.28-37.
Loucopoulos, P., Kavakli, E. (1995), "Enterprise modelling and the teleological approach to requirements engineering", International Journal of Intelligent and Cooperative Information Systems, Vol. 4 No.1, .
Loucopoulos, P., Kavakli, V. (1997), "Enterprise knowledge management and conceptual modelling", Springer-Verlag, New York, NY, paper presented at ER'97 Preconference Symposium, .
Loucopoulos, P., McBrien, P., Schumacker, F., Theodoulidis, B., Kopanas, V., Wangler, B. (1991a), "Integrating database technology, rule-based systems and temporal reasoning for effective information systems: the TEMPORA paradigm", Journal of Information Systems, Vol. 1 No.2, pp.129-52.
Loucopoulos, P., McBrien, P., Theodoulidis, C. (1991b), "TEMPORA – databases, rule-based systems and temporal logic for more effective information systems", IEEE Office Knowledge Engineering Newsletter, .
Loucopoulos, P., Kavakli, V., Prekas, N., Dimitromanolaki, I., Yilmazturk, N., Rolland, C., Grosz, G., Nurcan, S., Beis, D., Vgontzas, G. (1998), "The ELEKTRA project: enterprise knowledge modelling for change in the distribution unit of the public power corporation", Hellenic Naval Academy, Athens, paper presented at the 2nd IMACS International Conference on Circuits, Systems and Computers (IMACS-CSC '98), pp.330-6.
Lyytinen, K. (1988), "Stakeholders, IS failures and soft systems methodology: an assessment", Journal of Applied Systems Analysis, Vol. 15 pp.61-81.
McBrien, P., Niezette, M., Pantazis, D., Seltveit, A.H., Sundin, U., Theodoulidis, B., Tziallas, G., Wohed, R. (1991), "A rule language to capture and model business policy specification", CAiSE*91, Springer, Trondheim, .
McMenamin, S.M., Palmer, J.F. (1984), Essential Systems Analysis, Yourdon Press, Englewood Cliffs, NJ, .
Martin, J., Odell, J. (1998), Object-Oriented Methods: A Foundation – UML Edition, Prentice-Hall, Englewood Cliffs, NJ, .
Mens, K., Wuyts, R., Bontridder, D., Grijseels, A. (1998), Tools and Environments for Business Rules, ECOOP'98, Brussels, .
Moriarty, T. (1993), "The next paradigm", Database Programming and Design, .
Nuseibeh, B., Krammer, J., Finkelstein, A. (1994), "A framework for expressing the relationships between multiple views in requirements specification", IEEE Transactions on Software Engineering, Vol. 20 No.10, .
Pohl, K. (1993), "The three dimensions of requirements engineering", in Rolland, C., Bodart, F., Cauvet, C. (Eds),Springer, Pisa, paper presented at the Fifth International Conference on Advanced Information Systems Engineering, .
Pouloudi, A., Whitley, E.A. (1997), "Stakeholder identification in inter-organisational systems: gaining insights for drug use management", European Journal of Information Systems, Vol. 6 No.1, pp.1-14.
Prekas, N., Loucopoulos, P. (2000), "A unifying framework for representing structural and operational aspects of electricity sector deregulation", Requirements Engineering Journal, Vol. 5 No.1, .
Robinson, K., Berrisford, G. (1994), Object-Oriented SSADM, Prentice-Hall, Englewood Cliffs, NJ, .
Rosca, D., Wild, C. (1996), "Business rules in the real world: a decision support approach", paper presented at The Software Engineering and Software Engineering Conference (SEKE96), .
Rosca, D., Greenspan, S., Wild, C., Reubenstein, H., Maly, K., Feblowitz, M. (1995), "Application of a decision support mechanism to the business rules lifecycle", paper presented at the 10th Knowledge-Based Software Engineering Conference (KBSE95), .
Ross, R.G. (1997), "The business rule book: classifying, defining and modelling rules", Data Base Newsletter, .
Ross, R.G., Lam, G. (1998), Putting Business Rules to Work: A Tutorial and Workshop on Business Rules, Business Tactics and Policies, Business Rule Forum, Technology Transfer Institute, Chicago, IL, Section 1, .
Ruohonen, M. (1991), "Stakeholders of strategic information systems planning: theoretical concepts and empirical examples", Journal of Strategic Information Systems, Vol. 1 No.1, pp.15-28.
Snoeck, M., Poels, G. (2000), "Analogical reuse of structural and behavioural aspects of event-based object-oriented domain models", paper presented at the International Workshop on Enterprise and Domain Engineering – DomE 2000 (within the DEXA 2000 Conference), .
Theodoulidis, C., Loucopoulos, P., Wangler, B. (1990), "Requirements specification in TEMPORA", paper presented at the 2nd Nordic Conference on Advanced Information Systems Engineering (CAiSE 90), .
Vidgen, R. (1997), "Stakeholders, soft system and technology: separation and mediation in the analysis of information system requirements", Information Systems Journal, Vol. 7 No.1, pp.21-46.
Wangler, B., Holmin, S., Loucopoulos, P., Kardasis, P., Xini, G., Filippidou, D. (1999), "A customer profiling framework for the banking sector", IOS Press, Amsterdam, paper presented at the 9th European – Japanese Conference on Information Modelling and Knowledge Bases, .
Whitten, J.L., Bentley, L. (1998), Systems Analysis and Design Methods, McGraw-Hill, New York, NY, .
Yu, E. (1995), "Modelling strategic relationships for process reengineering", University of Toronto, .
Zaniolo, C., Ceri, S., Faloutsos, C., Snodgrass, R., Subrahmanian, V.S., Zicari, R. (1997), Advanced Database Systems, Morgan Kaufmann, San Matheo, CA, .