enterprise modeling and decision-support for automating the business rules lifecycle

Automated Software Engineering, 9, 361–404, 2002c© 2002 Kluwer Academic Publishers. Manufactured in The Netherlands.

Enterprise Modeling and Decision-Supportfor Automating the Business Rules Lifecycle

DANIELA ROSCA [email protected] of Software Engineering, Monmouth University, W. Long Branch, NJ 07764, USA

SOL GREENSPAN [email protected]

CHRIS WILD [email protected] of Computer Science, Old Dominion University, Norfolk, VA 23529-0162, USA

Abstract. Business rules represent policies, procedures and constraints regarding how an enterprise conductsits business. To get the full benefits of modeling business rules requires an approach to managing them throughtheir full lifecycle, from acquisition through deployment and evolution. The research reported in this paper isaimed at determining what infrastructure capabilities are needed to provide this lifecycle support. The solutionembodies a modeling framework that captures the structure of the enterprise, in terms of which the businessrules can be expressed, and decision-support capabilities for reasoning about and deriving business rules. Thepaper demonstrates the possibility of automatic support of the business rules lifecycle by automatically generatingbusiness rules from the captured information, along with data representing domain assumptions in a case study(the London Ambulance System). A system was implemented to illustrate the methodology and to demonstratethe feasibility of the approach. The methodology also gives guidance on how to deal with pragmatically importantsituations such as rules that involve both automated and human tasks, nondeterministic rules, and goal-orientedversus operational rules.

Keywords: business rules, enterprise modeling, decision support systems, traceability, decision tree learning,requirements engineering

1. Introduction

In order to remain flexible in today’s competitive markets, organizations need to under-stand their way of doing business. One important step in this understanding is repre-sented by the identification and modeling of the enterprise business rules. They reflectpolicies, procedures or other constraints on ways to satisfy customers, make good use ofresources, conform to laws or business conventions. These rules represent decisions abouthow a business has decided to carry out its work to provide services to its customers. Assuch, they give rise to requirements on any system being developed or procured for theenterprise.

Business rules arise from the business objectives of an enterprise. For example, a bankrequires a supervisor’s signature before cashing a check over $5000 to minimize loss incase of fraud. A customer service organization, trying to resolve customer complaints

362 ROSCA, GREENSPAN AND WILD

by telephone, tries to avoid transferring the customer’s phone call more than once andhopefully not at all (this is called the “two-touch” rule, and is intended to minimize customerinconvenience). A travel agent has been contracted to provide a client corporation with“the lowest available airfares” which helps the client corporation achieve financial goals.A company requires all departments to remain within 10% of budget, provided the totalcompany budget is met within 1%, also to meet financial goals.

The need for the identification of business rules and their traceability to the compo-nents of a software system has been emphasized by others as well (Kilov, 1997; Ross,1997; Sandifer and von Halle, 1993). There is a strong motivation for modeling businessrules, since in reality, it is frequently the case that the only way to determine an organiza-tion’s business rules is to look at the operational system; how does the Customer ServiceRep schedule a repair visit? How does the software calculate the insurance reimburse-ment? You know there is a problem if you have to “look at the code,” i.e., when thereis no other explicit statement of what the business rules are. This has motivated discus-sion of “mining” business rules (Paul, 1995) through a kind of reverse engineering activityon the software. However, this can be from difficult to impossible, since the manifesta-tion of the rules might be scattered throughout the code, and since the belief that therewere conscious business rules in the first place might be flawed. This case may be thesource of an inflexible enterprise behavior, since the business rules are hard coded anddistributed into the system implementation, and therefore difficult to retrieve and change.Other aspects of business rules that make them an interesting topic of research are relatedto the possible conflicts among rules, as they are elicited from various viewpoints, aswell as the eventual inconsistencies between the rules and the actual way of running thebusiness.

The benefits of explicitly modeling the business rules are multiple: first, this enables ananalysis from a global perspective to see if the operating principles are sufficiently com-plete and consistent; second, it makes possible an analysis of how well the rules achievethe enterprise objectives; third, it ensures that the developed or acquired applications andsystems are in conformity with the operating principles of the enterprise; finally, the de-veloped systems are better capable of quickly changing in response to modified operatingprinciples, without major systems efforts.

The paper presents aspects of a methodology that was developed to cope with theseissues by prescribing an approach that deals with lifecycle support for business rules, i.e.over the lifecycle of the enterprise and its operational system. The methodology supportingthe business rules lifecycle consists of

• a conceptual high level architecture (metamodel)• a prescription of activities for populating the models of the architecture• techniques for using the information populating the models for requirements engineering,

including continuous lifecycle support.

The methodology relies on a conceptual modeling framework or metamodel, presentedin Section 3, which prescribes representations for the enterprise model, the business rules,and a decision space. The needed support for requirements engineering is then defined interms of relationships between the submodels.

ENTERPRISE MODELING AND DECISION-SUPPORT 363

The methodology consists of three overall activities, presented in Section 4:

• Business rules acquisition. Facilitating expression and management of business rules atan enterprise level.

• Business rules deployment. Getting the system to follow the rules.• Business rules evolution. Enabling change without major re-development effort.

Acquisition includes not only eliciting the business rules and the enterprise model interms of which they are stated, but also capturing the deliberation process that producedthe rules. Acquisition includes, in addition to populating the business rules environment,the automatic extraction of deployable business rules from the decision space. The businessrules extraction method, in Section 5, is based on an induction algorithm that uses knowledgefrom the decision support system and statistical data about domain assumptions. Section 3.1introduces the example the London Ambulance Service (Finkelstein and Dowell, 1996) usedto illustrate the method.

Deployment includes the resolution of issues such as determinism, conflicts, and ambi-guity due to ungrounded terms, and also an evaluation of how well the business rules areexpected to support enterprise goals.

Evolution deals with incorporating changes due to new information about the organiza-tion’s operational system obtained from diverse monitoring activities, operational decisions,or external sources of the enterprise.

More background on business rules is given in Section 2. There the reader will findmore explanation of business rules, additional motivation for the approach taken by themethodology, insights gained from studying a sampling of a few hundred business rulesassociated with several years of business process re-engineering projects, and a discussionof related work and the state of technology regarding business rules modeling.

2. More background on business rules

Business rules are presumed to be of strategic/tactical importance to the success of the busi-ness. Therefore they are characterized by a set of distinguishing features that are describedbelow. Business rules are to be formulated and analyzed by business-oriented people, not byinformation technologists or software engineers. Decisions about cost, quality, responsibil-ity, and good service are not supposed to be delegated to system designers or programmers,but are to be implemented/deployed after they are decided upon by the appropriate parties.Therefore, they need to be expressed in terms of an enterprise-level model (Loucopoulosand Katsouli, 1992; Bubenko Jr. and Wangler, 1993), not in terms of programs.

The most demanding characteristic of business rules is that the business is likely to wantto change them. Business rules are formulated to have planned consequences that contributeto the success of the business, and therefore it is expected that the rules will be continuallyre-evaluated and subject to change to improve the performance of the business. Businessrules can also be generated by or in response to external sources, such as regulatory bodies,the law, market forces, or physical realities. Since the business does not have control overthese external forces, the enterprise must be prepared to change the business rules thatgovern its operation.


Figure 1. Setting business rules in context.

The deployment of business rules is not a straightforward application of the organizationalprinciples, instead it involves strategies of satisficing business goals (Chung et al., 1999),making tradeoffs between conflicting rules, dealing with exceptional cases, etc.

As shown in figure 1, business rules are positioned between enterprise objectives andthe operational system of the enterprise. The operational system is the combination of thehardware, software and humans that carry out the work of the enterprise. Enterprise objec-tives are the general aspirations of the enterprise: “make (more) money,” “make customershappy,” and “keep shareholders satisfied with their investment,” etc. They are the ultimatesource of all requirements on the operational system. The enterprise objectives give rise tohigh-level business rules (policies), which we call goal-oriented business rules, that can befurther refined, eventually to the point where they can be translated into operational businessrules (procedures) that can achieve the goals. These business rules are aimed to be carriedout by the operational system, with the intent that the “deployed” or “operationalized” ruleswill realize the enterprise objectives. For example, in a retail store, one could start with theobjective that “The store will offer the lowest prices among competitors”. This objectivecan be refined into a goal-oriented rule, such as “Encourage positive customer attitudes”,which could be further refined into an operational rule “Refund all valid claims of lowerprices from competitors, if receipt available and time less than 30 days”.

Because of the ambiguities and conflicts inherent in the enterprise objectives, businessrules are not simple refinements of the objectives; rather, business rules represent decisionsthat are made about how to achieve the enterprise objectives. Some business rules giverise to requirements that govern the operational system of the enterprise and determinehow the business is actually run. To answer the central question, “does the operationalsystem satisfy the business objectives (and to what degree)?”, one must simultaneouslyaddress two subquestions, which are subjects for requirements analysis involving businessrules:

• Decision-making: Do the business rules embody the right (or best) decisions about howto achieve the objectives of the business?

• Operationalization: Does the operational system behave according to the business rules?

Decision-making requires one to choose among alternative business rules for achievingobjectives, considering the expected influences or consequences—both in support of and indenial of the objectives, based on various assumptions. As described earlier in Rosca et al.(1995) we propose a decision support system/structure (DSS) for capturing the reasoningassociated with business rules. (The DSS of Rosca et al. (1995) has since then been refinedand implemented.) In addition to supporting the reasoning for choosing business rules, theDSS supports business rules extraction.


Operationalization of business rules requires a strategy (built into the enterprise infras-tructure) and tactics (methods such as transformations) to deploy the business rules in theoperational system. For each type of business rule in the taxonomy, an approach is neededfor deployment, preferably with minimal time and expense. Some classes of business rulesare directly deployable, such as the ones implemented by trigger rules and integrity con-straints in databases (Ullman and Widom, 1997), while others require varying degrees oftransformation and implementation; still others have no direct path into operation, and mustbe approximated in other ways.

2.1. A study of business rules and other related work

The motivation for our work on business rules came from three years of requirements effortsassociated with business process re-engineering projects. On these projects, informationreferred to as business rules was considered important to gather and document, but therewas no particular method for doing so. There were requirements modeling methods andtools being used, but business rules were not part of the modeling framework. They had tobe added as annotations to business process models or just captured separately in notebooks.

We studied a sampling, from one project, of some 250 statements referred to as businessrules to try to understand better what kinds of information were being captured. An attemptto classify them produced the taxonomy shown in figure 2. This taxonomy is not claimed tohave any scientific validity but only indicates what kinds of business rules were present inthis particular application.

The taxonomy is divided into rules for processes and rules for data. A more detailedexplanation and analysis of the taxonomy is beyond the scope of this paper, and we assumethat the rule categories, together with the examples shown, are sufficiently self-explanatoryto the reader. The classification is quite close to the classification made in Martin and Odell(1995) and to that used in our implementation.

However, a high percentage of the rules were extremely simple (attribute/value constraintsand cardinality constraints). These rules seemed too low-level to have an important impacton the business. We suspect that these types of rules dominated because of a reliance on anEntity-Relationship style of thinking. Process-oriented rules were less popular, but amongthem the stimulus/response rules were the most numerous. These are also fairly simplerules, with a clear operational semantics. We suspect that the other kinds of rules are just asimportant but are more difficult for business-oriented people to specify and reason about.There are also other kinds of rules, not present in the taxonomy, that would be useful to have.

Business rules have received a lot of attention in the trade press and other literature as hold-ing the answers to many information technology problems. The current state of technologyaddressing business rules includes commercial products that emerge at a fast pace (Businessrules solutions (http://www.brsolutions.com), centralized business rules repositories to sepa-rate business rules from code, parameterized to support global updates (Feuerlicht and Blair,1990), active databases which implement triggers and integrity constraints. All of these toolsare focused only on data business rules, due to the Entity-Relationship approach taken.

Some of the literature simply advocates the idea that it is important to spend the effort togive conscious consideration to business rules (as opposed to not doing it at all). Even just


Fig

ure

2.A

taxo

nom

yof

busi

ness

rule

s.


gather a list of English language statements (Sandifer and von Halle, 1993) is considered agood first step. Other proposals are more structured, relying on the syntax of E-R diagrams, orin the case of Ross (1997), a much more elaborate diagrammatic syntax. Still others proposea conceptual model approach for describing an enterprise, with a notation for specifyingrules that further specify the requirements on the enterprise (Loucopoulos and Katsouli,1992; Bubenko Jr. and Wangler, 1993). This is closest to our approach although our currententerprise model is limited to process and data/object rules, as in Martin and Odell (1995).

Some of the elements of our methodology have been discussed to some extent in theRequirements Engineering literature. For example, in Yu (1997) support for the early phaserequirements engineering is envisioned in terms of enterprise modeling, where the emphasisis on representing external and internal intensional, strategic relations among actors oragents, who seek to achieve a set of goals and softgoals. In Taveter (1999) and Taveter andWagner (2000) a methodology for modeling information systems is proposed, by makinguse of business rules as agents’ beliefs that constitute preconditions for their actions.

In Chung et al. (1995) nonfunctional requirements are treated as goals that have to bemet through a decision-making process in which change is expected. In Lamsveerde et al.(1995) a goal-directed requirements elaboration methodology attempts to cope with the“deidealization of unachievable goals” and also models assumptions attached to goals. Also,in van Lamsverde (2000) a methodology is presented for obtaining requirements from globalorganizational goals, very similar with our approach for refining business objectives intogoal-oriented and ultimately, operational business rules. The modeling of our decision spacemodel is closer to those presented by the issue based systems, argumentation frameworksand design rationale (Conklin and Begeman, 1998; Lee, 1992; MacLean et al., 1991).

There is a significant body of literature that deals with inconsistency and incompleteness,two major issues in software engineering (Ghezzi and Nuseibeh, 1998; Easterbrook andNuseibeh, 1995; Balzer, 1991; Boehm et al., 1995). Our approach of these issues offersguidance to the users and shows them how to act, should inconsistency occur, based on theinformation stored in the metamodel. This is a less formal approach than one could find inthe viewpoints or the KAOS frameworks (Finkelstein et al., 1994; van Lamsweerde et al.,1998), but it might be more appropriate for the business-oriented people who are intended toexpress and manage business rules. Dealing with inconsistency as it arises, not necessarilyat analysis time, has been advocated also in Pohl et al. (1997), where “choice contexts” areused for offering flexibility at run time for users.

In Fickas and Feather (1995), there is a discussion of requirements monitoring to in-strument the running system to determine whether, and to what degree, requirements arebeing met by the system. These are examples of the work we are trying to bring to bear onbusiness rules.

3. A high level architecture for the business rules environment

This section describes the high level architecture, in preparation for introducing the method-ology activities in the next section. The high level architecture consists of three models: theEnterprise Model, the Business Rules Model, and the Decision Space Model. The EnterpriseModel represents the world to which the business rules apply. It defines the domain concepts


Figure 3. System configuration.

about which the rules are expressed. The Business Rules Model represents the business rulesthemselves. The Decision Space Model offers information about the enterprise objectivesthat comprise the origin of business rules and captures the reasoning leading to the selectionand ultimate generation of the business rules.

The architecture has been implemented in a system whose configuration can be seenin figure 3. The system has been developed using the LiveModel platform (Intellicorp.1995), which provided the most advanced tool support at the inception of this work. UsingLiveModel meant adopting its enterprise model, rule language and rule engine, for therepresentation of two of the three models included in our high-level architecture. The thirdmodel, the Decision Space with its editors and traceability tool, was implemented on top ofLiveModel’s modeling features, its rich graphical user interface package, and its proprietaryprogramming language, ProTalk (a flavor of C++). The rule induction component wasdeveloped in C and consists of a decision tree induction module, a rule induction fromdecision tree module, and a production system inference engine. While the particulars of thissystem are not the subject of this paper, it should be noted that this system has been populatedwith the models and data presented here, and the rule generation algorithms have beenimplemented. The results presented below were produced by running the system on the data.

3.1. The LAS example

The example that will be used for illustrating our ideas in the next sections of the paper isinspired from the London Ambulance Service (LAS) case study.


LAS is in charge of dispatching resources such as ambulances, helicopters and emergencysquads to incident scenes following emergency calls. Some of the key objectives of thesystem are: to get the most appropriate resource to the scene of an incident (e.g., a heartattack, a traffic accident, a terrorist attack, etc), to get it there as quickly as possible (i.e.,according to standards that describe acceptable response times), to reduce the staff of LASby introducing information technology in their process of handling emergency calls, and toimprove the decision-making process.

The old LAS system was completely manual: a call taker wrote down the details of theincident on a paper form and identified the location of the caller when an incident wasreported (Receive call operation in figure 6). All the incident forms went to a central collec-tion point where a staff member reviewed the details recorded on each of them and decidedwhat type of resources were needed for each incident. Also, a decision was made aboutwhich resource allocator, from the three London divisions, should find the resources (AssessResource Needs in figure 6). The resource allocator decided which resource should be mo-bilized from his own division, based on information about availability of each resource,which was also recorded on paper forms (Allocate resources in figure 6). The resourceinformation was recorded on paper form and given to a dispatcher who passed the mobi-lization information (Mobilise Resources in figure 6) to the appropriate resources, such asvehicles, crews, hospitals, etc.

In the new LAS system, a Computer Aided Dispatch system was introduced aiming atimproving the performance of all the aspects of the dispatch process, from call taking, toresource allocation, and to mobilization. Note that a lot of human judgment is needed, thatthe decisions about whether humans or the new system will do something is not clear, andthat changes are likely over time.

Next we will see examples from this case study illustrating how the high-level architecturesupports the representation of business rules and the motivation and reasoning leading totheir selection. In particular, we will see examples of operational business rules that can beeasily mapped into the process models that represent the underlying business processes ofan enterprise.

3.2. Enterprise model

In the early phase of the requirements engineering process, enterprise modeling plays a keyrole (Loucopoulos and Karakostas, 1995). This modeling is concerned with understandingand representing the organizational structure of the enterprise, the business objectives, orthe business rules that govern its operation (figure 4). Also, it is concerned with the datathat needs to be manipulated, the tasks that need to be accomplished and the actors who areresponsible for these tasks. By capturing this information we are setting the foundation formore efficient and flexible software systems, that quickly adapt to change.

Proposals in the literature for introducing business rules as important enterprise artifactsgenerally focus on the identification and documentation of business rules, storage in acentral repository, and the need for clarity, consistency, and completeness (Sandifer andvon Halle, 1993; von Halle, 1993a; Feuerlicht and Blair, 1990). However, most of the abovework assumes business rules to be written in natural language, with little help expected


Figure 4. The business rules environment.

from formal methods or tools. Expressing the business rules in terms of an enterprise modelallows a more systematic approach of their lifecycle.

The types of business rules that are be expressed and reasoned about depend on the rich-ness of the enterprise model in terms of which the rules are stated. In much of the currentliterature (e.g., Sandifer and von Halle, 1993; Chen et al., 1992; von Halle, 1993b) the ex-pressiveness of business rules is limited to whatever can be expressed in Entity-Relationshipstyle (E-R) models. Others, including Bubenko Jr. and Wangler (1993), Loucopoulos andKatsouli (1992), Champion and Moores (1996), and Herbst (1995), express business rulesin terms of business concepts and corporate knowledge that are captured in a more generalconceptual modeling architecture, as proposed in this paper. A somewhat more expressiveapproach is taken by LiveModel (Martin and Odell, 1995), which represents an enterprisemodel in terms of object diagrams and event diagrams to which various types of rules canbe attached. Compared to E-R diagrams, a greater variety of business rules, such as triggers(stimulus-response) and computation rules, can be specified as attachments to the diagrams.More of the business rules that are created in natural language can find their way into aformal rule structure.

As previously mentioned, the enterprise modeling paradigm of LiveModel was adoptedfor the representation of our Enterprise Model component. In LiveModel an enterprise isdescribed in terms of “objects” and “processes” (see Martin and Odell, 1995). Objectsare represented by Object Diagrams that are essentially Entity-Relationship diagrams (theObject diagram for a fragment of the LAS example can be seen in figure 5). The ObjectDiagrams are based on the following primitives:

• object types that represent the classical entities in an E-R diagram (Incident, Patient,Resources Needed in the figure)

• object type partitions that represent the division of an object type into disjoint subtypes(Vehicles, Equipment, Professionals are subtypes of the object type Resources needed inthe figure)

• associations that represent mutual relationships between two object types (involves, in-volved in, needs, associated with in the figure). The LiveModel representation limitsthis relationship to only two object types. This was one of the problems that had to becircumvented whenever we needed to represent n-ary relationships.

• subtype of that represents a relationship between an object type A and an object typeB, where B is a specialization of A (the relationship between Resources Needed andVehicles, Equipment, Professionals in the figure)


Figure 5. An object diagram for a fragment of the LAS example.

• component of that represents a relationship between an object type A and an object type B,where objects of type B contain objects of type A. The same discussion as for associationrelationships applies here as well.

We represent business processes by a set of LiveModel Event Diagrams, which define thesequence of operations and events for process execution (the corresponding Event Diagramfor a fragment of the LAS example can be seen in figure 6). An Event Diagram is built fromthe following components:

• operations, represented by the named rectangles in the figure.• triggers that invoke an operation and assign the necessary inputs to that operation. Triggers

respond to an event and invoke the target operation. They assign the inputs of the targetoperation based on the outputs of the source operation and the inputs of the entire eventdiagram. They are represented by arrows pointing to the invoked operation. When atrigger is annotated with a slash mark it shows that a trigger rule is attached.

• entry/exit points that represent the starting and stopping points in a diagram. They arerepresented in the figure by double circles.


Figure 6. An event diagram for a fragment of the LAS example.

• events that are created whenever an operation or an entry/exit point are completed. Theyare represented in the figure by black triangles attached to an operation or entry/exit point.

• event partitions that divide an event into two or more subtypes. Event partitions are usedas decision points in an event diagram. They are represented in the figure by a sequenceof black triangles inside a rectangle.

• event subtype of links that are used to connect event partitions with their event supertype.They are represented in the figure by a link containing a small triangle pointing to theevent supertype.

• control conditions that indicate checks applied to a trigger or synchronization of multipletriggers. The control conditions are always interposed between a trigger and the operationthey trigger. They check whether an operation should be activated, i.e. it satisfies a specificcondition. The condition is specified in terms of an object state, or a combination of objectstates. If the condition is not true, the execution of the process terminates at that point.

These Event Diagrams model a hierarchy of business processes, decomposing each op-eration in a diagram, if necessary, into a more detailed diagram. The Event Diagrams areexecutable specifications of a process as soon as: (1) input and output variables to operationsare specified; (2) trigger rules are created to define branching and control conditions; (3)procedures to define operations are written. LiveModel allows the attachment of rules toEvent Diagrams, with a particular operational semantics based on those of the Object andEvent Diagrams.

3.3. Business rules model

As we have noted earlier, most of the literature (Sandifer and von Halle, 1993; von Halle,1993a; Feuerlicht and Blair, 1990) assumes business rules to be stated in natural language.


For example, Leite and Leonardi in (1998) have included business rules expressed in naturallanguage in the client oriented requirements baseline, for helping in the identification ofsoftware requirements. They propose scenarios as possible ways for enacting businessrules viewed as policies. This representation is less amenable for the application of formalmethods or tools that would permit some form of automated reasoning.

Others (Herbst, 1995; Bubenko Jr. and Wangler, 1993; Champion and Moores, 1996)propose the form event-condition-action (ECA) for representing business rules. This formis more appropriate for representing and reasoning about operational business rules. For thesimplest form of an ECA rule

WHEN eventIF conditionDO action

when the event occurs, if at that time the condition is found to hold, then the action isinitiated.

The events conditions, and actions are formulated as expressions on the entities in theEnterprise Model. As discussed in Bubenko Jr. and Wangler (1993); where similar rules areused, judicious interpretations of special cases (such as default meanings for omitting oneof the components of the rule) allow ECA rules to express most of the business rules typesin the taxonomy presented in Section 2. For example, based on the LiveModel trigger rules(ECA based rules) that define the conditions under which an operation occurs and calcu-late the inputs to that operation, the stimulus-response, operation constraint and requiredvalue rules in the taxonomy can be modeled. An example of stimulus-response rule fromthe LAS case study, implemented in the LiveModel rule language, can be seen in figure 7.The event part of the rule (WHEN <>) specifies the operation whose completion pro-duces the event that triggers the activation of the rule. The condition part of the rule (SOTHAT <>) defines the conditions under which the action part (THEN <>) can occur. Thevariables preceded by a question mark are input and output variables of an operation, whilethe variables without a leading question mark are local to a rule.

Figure 7. Example of stimulus/response (trigger) rule in the LAS case study.


Additionally, an ECA rule can be used to express the non-operational semantics, abstractbusiness rules defined in Section 5 for the automatic acquisition of certain types of businessrules.

3.4. Decision space model

The Decision Space (DS) captures pre-traceability information (Gotel and Finkelstein,1994) which consists of the business rationale that supports the elicitation of business rules. Itoffers information about the origin of business rules, tracing back to the enterprise objectivesthe reasoning for the selection and generation of the business rules. DS is the repository ofinformation about alternatives, criteria, arguments, and assumptions that provides a domainspecific knowledge source for assisting in the elicitation, deployment and evolution ofbusiness rules. The complete set of primitives of the decision support framework can beseen in figure 8. Examples of the basic primitives are given in figure 9. The representation ofthe decision structure is based on previous work on Decision Based Software Development(DBSD) (Wild and Rosca, 1994), augmented in several directions to better capture andreuse elements of the decision process.

Figure 8. The decision space model. The relationships among primitives should be read clockwise. For example,Alternative meets Criterion.


Figure 9. Decision support terminology.

The refinement of goal-oriented business rules generates issues that need to be solved.Also, new issues can be raised in the context of an information system that is introduced tosupport some enterprise activities. Requirements elicited from stakeholders can raise newissues that need to be solved, which would ultimately lead to the creation of new rules orthe modification of existing ones. These changes are due to the modifications introducedin the business processes impacted by the information system. Another source of issuesare the exceptional cases that occur sometimes by the application of an operational businessrule. These issues are retrieved following a creates link from the alternative underlying anoperational business rule.

Issues refinement are captured by AND/OR graphs created with specialization/generalization links. An issue can be decomposed into an AND set of subissues. Also,an issue can be solved by an OR set of alternatives. This technique borrowed from artificialintelligence techniques leads to the creation of a hierarchy of rules, which operate at differ-ent levels of abstraction. The aim is to reach an operational level where rules are sufficientlydetailed and explicit such that they could be immediately mapped into the requirements ofa software system, or they would readily define procedures for human enactment.

In order to solve an issue, different alternative solutions are considered for evaluation. Thealternatives are evaluated against a set of criteria to decide which gives the best solution.The criteria are represented in terms of softgoals (Yu, 1997) or non-functional properties ofthe business. A decision involves assessing the degree to which each alternative meets theentire set of criteria and choosing that alternative which best satisfies this set. Arguments andcounterarguments are recorded to document the evaluation of the alternatives, or the creationof new issues that may follow after applying a business rule. The arguments are expressed


as a weight of the merit of an alternative in terms of how it fares against each criterion.The assumptions of the arguments are explicitly represented to help in selecting the bestalternative from the set of proposed alternatives, and also for choosing the information thatneeds to be monitored during the operation phase, in order to validate some provisional orconditional decisions (see Section 4).

The best alternative solution is reflected in the resulting artifact, which in our case isrepresented by a rule in decision support system (DSS) format—DSS business rule. TheDSS format is an event-condition-action (ECA) format where the condition and action partscan be structured or unstructured expressions. When the DSS rule is obtained by applyingthe rule extraction algorithm presented in Section 5, its condition part is a conjunctivenormal form (see rule 5 in Section 5.3). In the case of other types of business rules wherethe algorithm cannot be applied, the condition and action parts of the rules are expressedin a structured English language. The DSS rules are implemented by operational businessrules that govern the operational system of the enterprise. Some operational business rulesgive rise to requirements for a traditional software development effort, while others areimplemented as procedures or manuals necessary for training employees.

Next we present the features that distinguish our decision support framework from otherissue-based decision systems, argumentation frameworks, or design rationale like SIBYL(Lee, 1991, 1992), REMAP (Ramesh, 1991, 1992), gIBIS (Conklin and Begeman, 1988),QOC (MacLean et al., 1991). Relationships of conflict and/or synergy between alternativesof the issue under consideration and alternatives of other issues in the DS are first takeninto consideration in the process of evaluation of the alternative solutions of an issue.These types of relationships are expressed in the DS framework by the invalidates/validateslinks between alternatives of different issues. For example, in a classical business processreengineering task (Hammer, 1990), the decision of improving the purchasing departmentprocesses by entering the purchase orders on an on-line database, will invalidate the decisionpreviously taken about paper-based purchase orders. The first decision was related to theissue about how to improve the purchasing process, while the second was related to theissue about how to prepare a purchase order.

The assumptions play an important role in the identification of the best alternative (seeSection 5) and the identification of the operational metrics that will be used during thedeployment of business rules in order to assess the validity of a conditional decision. Theoperational metrics are monitored in the operational system and when enough violationsare found, or at periodical intervals of time, feedback is given to the decision makers Thisfeedback can lead to a change of decision and therefore to a change of the business ruleassociated with that decision.

Besides the instantiation of the framework’s primitives as a result of the decision process,two other by-products are created in relation with a business rule: the decision matrix andthe grounding guide related to that rule. The decision matrix synthesizes the criteria formaking the decision regarding a business rule and the alternatives considered, together withtheir underlying arguments and assumptions (see figure 10). This information is displayedin a staged process, upon user request. The decision matrix offers useful information duringthe deployment and evolution of the business rules, for the various stakeholders interested inusing or changing them. The decision matrix is similar in many aspects to the “relationship


Figure 10. Decision matrix and data base of assumptions for the How to Assess Resource Needs issue. Theassumptions table contains a sample of examples referring to the argument Sending ambulance is Quick in non-life-threatening cases.

matrix” from the House of Quality work of Hauser and Clausing (1988), but based on itsinformation our work proposes a well defined algorithm for making a decision, as will beshown later in this paper.

An example of a decision matrix can be seen in figure 10. It is associated with the issue“How to Assess Resource Needs” in the LAS case study. The content of the matrix waspopulated with information gathered from the decision makers. In the Assess ResourceNeeds step of the LAS process shown in figure 6 a staff member has to decide whether tosend to an incident site an ambulance, a helicopter or a major incident team, based on thelocation and type of incident details mentioned in the incident form. In order to make thisdecision the staff member takes into account criteria such as “quick response time”. Thefigure shows the pro- and counter- arguments, taken into account for assessing the degree ofsatisfaction of the Quick Response Time criterion by the Send Ambulance alternative. Thesupporting arguments are distinguished among other information, by their importance in theevaluation process. Positive numbers in the arguments importance column reflect supporting


arguments, while negative numbers are associated with counter-arguments. Also, in figure 10we show a fragment of statistical data recording various assumption values that underliethe argument “Send ambulance is quick in non-life-threatening cases.” These assumptionsare statements about attributes that characterize the non-life-threatening cases (we haveconsidered just a few of them for this example) and the distance of the incident locationfrom the nearest hospital.

The grounding guide is a structure created at operation time for the business rules that con-tain ungrounded terms. It describes information related to ungrounded terms and applicabledefinitional business rules extracted from the links between the models of the high-levelarchitecture. This information can be used for choosing one of the existing values of anungrounded term, based on the existing definitional business rules, or for introducing newvalues for grounding a term. For example, to choose the best rule to apply in case of a bankoverdrawn, a bank clerk can select at operation time one of the legal values (good/bad)of an ungrounded term (Customer. Classification) by looking at a grounding guide (seeFigure 11). The guidance consists of definitional rules that would indicate the bank’s defi-nition of a good or bad customer, and other parameters one should look for when makinga decision (see figure 12), reflecting the fact that, in general, a decision is not made in avacuum of knowledge.

By having access to the rationale behind the business rules or software requirements,software engineers can make decisions that are better able to support the evolving nature ofthe business and to suggest changes to the business rules which result in simpler softwaresolutions. They no longer have to treat the business rules as a “black box”. During the system

Figure 11. Grounding guide for disambiguating the meaning of Customer.Classification and Customer.Historyusing definitional business rules attached to an object Customer in the enterprise model.


Figure 12. Definitional rule.

operation the business rules can be revisited. In this case, the decision support system willprovide the framework for making decisions, understanding trade-offs and finding similardecisions.

3.5. Traceability links

The needed support for requirements analysis is defined in terms of traceability relationshipsbetween the previous models. The examples given refer to the Object and Event Diagramsof the LAS case study illustrated in figures 5, respectively 6, and the business rule fromfigure 7 which is attached to the trigger marked with a slash in the Event Diagram.

3.5.1. Business rules → Enterprise model. Using the objects/processes type of enter-prise model one can easily determine which process component(s) are defined/constrained/governed by a business rule, or what object types are referred to by a business rule. Thisway, one is better capable of quickly changing the system in response to changed businessobjectives or rules. For example, by parsing the business rule in figure 7 one can determine:

• Which event/action operations are referred to by a business rule?

Assess Resource NeedsSend Ambulance

• What object types are referred to by a business rule?

IncidentPatientResources Needed

The traceability information shown above is highly influenced by the enterprise modelused. We argue that a richer model of an enterprise like in Greenspan and Feblowitz (1993),or Yu (1994), and Yu and Mylopoulos (1996) would enable mining for a larger set oftraceability information.

3.5.2. Enterprise model → Business rules. Based on the same object/process type ofenterprise model, the architecture allows the examination of which business rules does a


specific object type participate in, or what business rules define/constrain/govern a specificprocess component? For example, if the Incident object type is modified including one moretype of incident that needs to be covered by the ambulance system, the following businessrules are candidates for examination for determining whether they need to be changed, orother rule (s) need to be added to the system:

SendAmbulanceRuleSendHelicopterRuleSendMajorIncidentTeamRule

If involved in a business processes reengineering effort, one could easily extract allthe business rules defined for a specific business process and examine which of them areobsolete, and therefore need to be changed or replaced.

3.5.3. Business rules → Decision space. The links between the business rules and thedecision space models show a unique feature of this architecture, which provides pre-traceability information for a business rule. Linking a business rule to the issue that hasgenerated it, one can have a comprehensive picture of the business rationale that lies behindthat rule, in terms of the alternatives, criteria, arguments and assumptions that have beenstated during the elicitation of that business rule.

For example, figure 10 shows the origin of the rule illustrated in figure 7, by reveal-ing the existing alternatives for solving the issue “How to Assess Resource Needs”, andthe associated decision rationale information in terms of related criteria, arguments andassumptions.

3.5.4. Decision space → Business rules. When factors like Government regulations,company policies, etc. change it would be useful to be able to track what business rulesaddress a specific issue. This kind of traceability information can be extracted using thelinks between the Decision Space and the Business Rules Models. For example, the businessrules addressed by the issue “How to Assess Resource Needs” are:

SendAmbulanceRuleSendHelicopterRuleSendMajorIncidentTeamRule

The same traceability links could be a useful source of information for the reuse ofbusiness rules, by identifying the rules in a similar business process.

3.5.5. Decision space → Enterprise model. This link identifies what object types/attributesare addressed by a decision/issue. This way, when a decision is changed one can identifywhat entities in the enterprise model are affected. In our example, for the Patient objecttype the following attributes are addressed by the business rule in figure 10:

Systolic Blood PressureDiastolic Blood Pressure


PulseTemperature.

3.5.6. Enterprise model → Decision space. Using this link one could easily determinewhat decisions involve a specific entity from the enterprise model. This information couldbe useful in identifying what decisions need to be revisited when an object changes. Forexample, the Resources Needed object type is addressed by the following issues in thefragment of the LAS example described earlier in this chapter:

“How to Assess resources needed”“How to Allocate resources needed”“How to Mobilize resources needed”

These should be the issues whose decision information needs to be revisited when theResources Needed object type changes.

3.5.7. Business rules → Requirements. If a business rule determines a requirement ofthe operational system of the enterprise, this link supports an analysis that reveals whetherthe requirements comply with the company policies (Sibley et al., 1992; Kilo, 1997). Thistype of analysis represents another unique contribution of this work to requirements analysis.We argue that a business analysis phase that identifies the set of business rules relevant to anew information system, should always precede the requirements elicitation for that system,to avoid building a system that doesn’t satisfy the real organization needs. For example, therule “Use automated allocator” could be the reason for the requirement “The response timeof the allocator algorithm should be less than 10 seconds”.

3.5.8. Requirements → Business rules. Another interesting analysis is made possible byrevealing the changes in the enterprise operating principles when a new information systemis introduced. For example, the requirement “The automated allocator finds the nearestresource based on the current positions of all resources in the field”, could determine thefollowing operating procedure: “The ambulance personnel should always indicate theircurrent position.”

4. Methodology for the business rules lifecycle

The flexibility of an enterprise is reflected in how rapidly it adapts to continuous internaland external changes. To achieve this, an enterprise needs to better understand the wayit is doing business, implicitly its business rules. Because business rules are expected tochange, factoring them out is a strategy for supporting the evolution of their embeddingsystems. We believe that when looking at business rules, it is important to address theirentire lifecycle, because there is a natural evolution of understanding which starts whendefining the business rules and which continues forever throughout their lifetime. Themethodology we propose (Rosca et al., 1995, 1997), spans all phases of the business ruleslifecycle: acquisition, deployment and evolution (see figure 13). Next, an overview of the


Figure 13. A decision making methodology in support of the business rules lifecycle.

methodology is presented, followed by an in depth analysis of each of the business ruleslifecycle phases.

During the acquisition phase, enterprise objectives, goal-oriented rules and constraintsare discussed, raising issues that need to be solved in order to generate operational businessrules. This phase includes not only the acquisition of business rules and the enterprise modelin terms of which they are stated, but also captures the deliberation process that lead to thoserules, starting with high level enterprise goals. Based on the decision structures populatedduring the deliberation process, we developed an algorithm for the automatic acquisition ofcertain types of business rules that will be presented in detail in the next section. The contentof the deliberation records attached to a business rule is defined as a-priori justificationsbecause they are based on the best information available before the deployment of businessrules.

During the deployment phase, the methodology distinguishes between the deterministicand nondeterministic business rules. The deterministic rules uniquely characterize thesituations where they can be applied without further decision making. The decision ismade at analysis time. Therefore, if the rules are encoded in the enterprise’s informationsystem, they are automatically applied by the system, without human interaction; or theyare rigorously applied by humans.

In the case of nondeterministic rules, human interaction is required at operation timedue to either conflicting or ambiguous business rules. We call these decisions operational


decisions because they are taken at operation time instead of analysis time. The decisionmaker is assisted by providing the deliberation information associated with the conflictingrules, and in the case of ambiguous rules, by providing the definitional rules that wouldhelp in grounding the terms with values available at operation time.

Because of lack of experience with the consequences of a given business rule, a-priori jus-tifications are often inappropriate. Conditional/Provisional Decisions are decisions basedon uncertain justifications which the developers have chosen to monitor during the op-erational usage. In the case of conditional decisions, where there is a question about theadequacy of the decision assumptions, we propose to monitor the consequences of the de-cision by identifying observable information which can be captured during operation. Thisinformation will measure the effects of applying a business rule and will validate or denythe decision of choosing that particular business rule after reflecting on the monitoring data.This process may also affect related decisions. We call the information resulting from theanalysis of monitoring data a-posteriori justifications in the sense that it will provide theanswer for the questions: has the chosen rule achieved the goals it was supposed to achieve?And to what degree?

In the evolutionary phase, based on the information provided by the monitored dataor by the operational decisions, one could determine that some business rules are wrongor incomplete. In correcting and improving the set of business rules, the decision modelcan be used to assess what is missing or whether any changes have occurred in thedeliberation information. For example, one could determine that there are some miss-ing criteria, arguments, alternatives or assumptions, or that changes might have occurredin the values of the assumptions underlying a business rule. Also, changes in internalor external sources of an enterprise might induce the necessity of changing some busi-ness rules. In all these cases, for the types of rules we are able to automatically gen-erate, we propose to assist the process of their evolution, by providing the informationexisting in the decision space associated with the rules that need to be changed, andby providing an algorithm for the rapid modification of the rules, based on the newinformation.

The methodology proposed here incorporates CMM level 4 practices (Paulk et al., 1993)by prescribing a systematic collection of monitoring data and their analysis for a betterunderstanding of the business processes. Also, by allowing the issues that appear duringthe operational decisions to be reflected upon and participate in the evolution of businessrules, the methodology also incorporates CMM level 5 practices, which fuel a continuousexperience-based process improvement.

While other attempts at modeling business rules have considered only their acquisition(Wangler et al., 1995; Herbst and Myrach, 1995; Leite and Leonardi, 1998), our methodol-ogy supports a systematic approach to the acquisition, deployment and evolution of businessrules. It empowers the inclusion of business rules into operational systems in a manner whichallows consideration to be given to:

• the degree of understanding and determinism of the business rules• the confidence placed in the business rules analysis• the need to accommodate rapidly changing business rules.


In the case where the business rules are well understood, where a deterministic systemsolution is implied, the confidence in the analysis is high, and the need to rapidly accommo-date changes in the rules is not viewed as critical, the methodology provides for a traditionalsystem development where the rules are encoded in the software or faithfully executed bypeople.

In the case where the business rules are fairly well understood and a deterministic systemsolution is still implied, but confidence in the business rules analysis is low, the methodologyprovides for a traditional system development and encoding of the rules, augmented byadditional requirements to monitor the degree of achievement of the enterprise objectivesin the running system. This monitoring can be used to confirm or deny the business ruleanalysis, however, should changes to the system be indicated, the method of achieving thechange is via the traditional mechanism of posting requirements changes and modifyingthe system to accommodate them. This option does not accommodate the need for rapidlychanging the system solution.

In another case, the methodology provides for a novel and high leverage solution namelyin situations where the business rules are not very well understood, where they imply anon-deterministic system solution, either due to under-specification (i.e., lack of groundingof terms in the operational environment) or over-specification (i.e., inconsistent businessrules), where by definition the analysis to resolve the business rules cannot be done withconfidence, and where the need to rapidly accommodate changes is crucial. In this case, thefinal business rule analysis is shifted from analysis time to run time. The applicable businessrules and the decision support structure are provided to the system users at runtime to helpthem make a decision as to which rules are to be applied (in the case of inconsistent rules)and how to interpret them (in the case of ungrounded/underspecified rules). The same toolsand data used by an analyst during requirements analysis are used to guide the system’sbehavior. This methodology supports system development in the face of inconsistent andambiguous requirements. It permits development to move forward even when requirementsare not fully understood.

4.1. Business rules acquisition

We see three major phases in the acquisition of business rules: the elicitation, the analysis andgeneration of business rules in different areas of expertise, and validation (see figure 14(a)).During the elicitation phase (figure 14(b)), brainstorming sessions take place for deliberatingwhich are the goals, constraints of the business that need to be modeled, and generalstrategies for achieving the goals. As a result of these deliberations, initial versions of theEnterprise Model and Decision Space are sketched and also a first set of business rules isdefined, specifying in general terms how the goals should be achieved. Therefore these goal-oriented business rules express very high level decisions. These rules need to be refined inorder to become operational.

In the analysis and rule generation in different areas of expertise phase (figure 14(c)) busi-ness analysis is carried out by separate groups of people, with different areas of expertise, forrefining the understanding of business entities, processes and business rules. These activitiesimply more detailed discussions, scenarios description (Jarke and Kurki-Suonio, 1998), or


Figure 14. Business rules acquisition process. Figures (b), (c), and (d) expand each box from figure (a).

viewpoints elicitation (Nuseibeh et al., 1994) on the ways of achieving the goals, policiesand constraints of the business. They can be complemented with interviews with domainexperts and/or reading existing documentation and information related to the subject ofanalysis. As the understanding of the enterprise objectives becomes clearer, the EnterpriseModel and the Decision Space are updated. In this process new goals may appear and newrules may be defined.

Based on the entities and processes modeled in the Enterprise Model, on the decisionstructures captured in the Decision Space, and on statistical data from the enterprise’s way


of doing business, certain types of business rules can be automatically extracted followingan algorithm described in the next section. These decision support system (DSS) level rulesare the source of the operational business rules that would govern the operational systemof the enterprise. They can be easily mapped into formal rules expressed in a formal rulelanguage, an example being the one used in the LiveModel tool. For process simulations,these rules can be attached to operation triggers in process diagrams, as we have shown inthe previous section. Other types of rules are mapped into the requirements of the softwaresupporting the business processes of the organization, or are the source of procedures andmanuals for training employees.

There can be multiple iterations on each step of the analysis and rule generation indifferent areas of expertise phase of the business rules acquisition, until a stable set ofbusiness rules, as well as a clear and comprehensive Enterprise Model for each specific areaof expertise, are obtained.

During the validation phase (figure 14(d)), all of the existing sets of business rules,Decision Spaces, and fragments of the Enterprise Model are put together, checking theircompleteness or detecting redundancies and conflicts (for example, redundant entities oroperations, or conflicting business rules). The detection is facilitated by the types of anal-yses discussed in Section 3.5. These redundancies and conflicts should be eliminated bynegotiation and iteration on the previous phases of the acquisition. Should this not be pos-sible, these situations should be made explicit as exceptional cases to the users of businessrules.

As shown here, this process offers more guidance in acquiring business rules thanJAD/RAD (Wood and Silver, 1995). Also, it clearly specifies what knowledge needs tobe acquired, proposes a method for automatically generation of certain types of businessrules, and provides tool support for most activities of the proposed methodology.

4.2. Business rules deployment

Business rules deployment includes the resolution of issues such as determinism, conflicts,incompleteness, and ambiguity due to ungrounded terms. It also includes an evaluation ofhow well the business rules are supporting the enterprise goals.

After the operational business rules are defined and integrated into the enterprise businessprocess they are activated in one of the following contexts: executable contexts or choicecontexts, as specified in the NATURE process metamodel (Pohl, 1996; Pohl et al., 1997).Executable contexts represent parts of the process definition which can be strictly enforced,either by being automated or by being faithfully executed by people. These contexts arecharacterized by deterministic business rules, in the sense that there is only one applicablebusiness rule and the data referenced by the rule are known with certainty (are unambiguous).Such a rule can be automatically applied either by the underlying information system or bypeople.

Choice contexts represent parts of the process definition where human intervention isrequired for making a decision. The decision might be needed because of overspecification,i.e. there are multiple, conflicting business rules applicable in the context or, because ofunderspecification, i.e. the applicable business rules have ambiguous terms. We associate


these contexts with nondeterministic business rules that need operational decisions in orderto be activated:

1. When a context is characterized by multiple, conflicting business rules, the decisionmatrix associated with those rules is displayed and the user can browse through it,analyze the information contained in the decision structures and assess the merit of eachalternative associated with each rule, based on data available at operation time. The usercan choose the best rule proposed by the system, based on the merit of its associatedalternative, apply his own judgment and select another rule, or propose a new rule. Thisway the decision of which rule is the best has been shifted from analysis time to operationtime.

2. When a context is characterized by ambiguous business rules, e.g. they contain un-grounded terms whose grounding couldn’t be done with certitude at analysis time dueto subjective definitions, a process of instantiation or disambiguation is needed. Thisprocess is made possible by the links among the business rules, the Decision Space andthe Enterprise Model. The definitional business rules attached to various attributes of theentities in the business become available for consulting. The user can choose one of thelegal values of an ungrounded term based on definitional business rules, or can disagreewith those rules and choose a value according to his own judgment.

Finally, another aspect we are concerned with during the deployment of business rules isthe achievement degree of the enterprise objectives by the operational business rules. Ifthere where concerns about the validity of the assumptions underlying some business rules,we have introduced the concept of conditional decisions that need to be monitored duringthe application of the associated business rules. The monitoring data is analyzed and fedback to the system for updating the business rules, enterprise model and/or decision space.This approach is similar to Basili’s Goal-Question-Metric (GQM) framework (Basili andWeiss, 1984). A set of goal-oriented business rules are refined to the level of operationalbusiness rules, similar to the GQM goals that are refined into a set of questions that helpachieve the initial goals. If in this process there are some questionable business rules, wepropose to identify a set of monitoring data that is collected during the deployment of thebusiness rules, similar to the metrics in the GQM paradigm. The data collected helps answerthe questions about the validity of the initial decisions and therefore helps in moving a stepcloser towards achieving the enterprise goals. More explanations and examples about thedeployment can be found in Rosca and Wild (2001).

4.3. Business rules evolution

It is expected that business rules will be continually re-evaluated and subject to change inorder to improve the performance of the business. The source of change can come fromthe analysis of monitoring data and/or from the information gathered during operationaldecisions. Also, change may be determined by internal or external sources that the enterprisecannot control, such as change of laws, market forces, regulatory bodies, political factors,etc.


When a rule needs to be changed, by studying the deliberation leading to that rule, one candetect that some criteria, alternatives, arguments or assumptions could be added/eliminated,or that their current importance weighting is wrong. For certain types of business rules, byapplying the algorithm described in Section 5, one can rapidly modify the obsolete rules,based on the new configurations of the Decision Space and Enterprise Model. Therefore,over time it may be possible to refine certain non-deterministic rules, replacing them eitherby deterministic ones, or better constrained non-deterministic rules.

When a change in the importance of different decision primitives needs to be made, justby propagating the new values throughout the decision structures associated with the rulethat needs to be changed, one can choose another rule associated with the same issue, bychoosing another alternative from the existing ones. If none of the existing alternatives meetthe new context coordinates, one can create new rules by adding new alternatives to theissue that generated the initial rule.

When the change is due to influences in internal or external forces, there is a great chancethat it will impact several aspects of the business process. For these situations the closure ofthe impact is assessed and a suggestion is made about what other elements of the process,including business rules need to be modified. This assessment is done using the informationexisting in the decision space associated with the process that needs to be changed. Moreexplanations about the evolution of business rules are outside the scope of this paper, butthe interested reader could find more information in Rosca and D’Attilio (2001).

Computer-based tools for automating the business rules life-cycle will likely play aprimarily supporting role rather than a full automation, due to the fact that knowledgeabout organizations is typically incomplete, and therefore often requires human input andjudgment. Nevertheless, here we have attempted to automatically generate certain types ofbusiness rules building upon the information captured in the decision structures and alsostatistical domain knowledge.

5. Business rules acquisition

5.1. Decision structure knowledge

First we formalize the knowledge captured by a decision matrix. This knowledge is used inthe rules acquisition algorithm, and corresponds to the primitives described in the DecisionSpace Model in Section 3.4. The primitives are naturally expressed in terms of variablesdefined on a hierarchy of decision data types. Next we present the data types and examplesof corresponding variables, as seen in figure 10:

• The issue (Iss) that needs to be solved: Assess Resource Needs in our example.• A number of alternatives (Alti ) that are proposed as solutions to the issue Iss. For example,

Alt1 = Send Ambulance.• A set of criteria (Crit j ) against which all the alternative solutions are evaluated in order

to decide upon the best alternative. For example, Crit1 = Quick Response Time.• A number of pro and counter arguments that correspond to each pair (alternative, criterion)

(Argk(Alti , Crit j )). For example, Arg1(Alt1, Crit1) = Unacceptable Response, related tothe description “Send Ambulance is too slow in life-threatening cases”.


• A set of assumptions that underly each argument (Assml(Argk)). Assumptions representstatements about groundable attributes Attrm(Assml) of one or more objects in the Enter-prise Model that are relevant to the issue under consideration. Some attributes may becommon for various arguments. For example, Attr1(Assm1(Arg3(Alt1, Crit1))) = SystolicBlood Pressure is an attribute of the entity “Patient”, relevant for judging whether a pa-tient is in a non-lifethreatening situation. An example of a set of assumptions that underlyargument Arg3, is the first row in the assumptions matrix: Assm1(Arg3(Alt1, Crit1)) =〈(Systolic Blood Pressure, very high), (Diastolic Blood Pressure, very high), (Pulse,high), (Temperature, high), (Distance, 15)〉. The relation between the values of the set ofassumptions and the value of an argument is captured in the Class of that argument.

5.2. Abstract format of the automatically generated business rules

The Business rules extracted from decision structures and statistical data follow the generalpattern

WHEN ContextIF Cond1[w1] < op > Cond2[w2] < op > · · ·THEN Action[MeritAction]

where context, conditions and actions are represented in terms of decision type variables.The context represents the environment where the condition and action part of the rule areevaluated. For example, when the action part of the rule is instantiated with the alternativeAlti , the context of alternative Alti is the issue for which it represents a possible solution. Theconditions are predicates over decision type variables. The action is an assignment of truthvalue to a decision type variable. The weight wi is the static weight factor of conditioni .

Rules are interpreted using a production system inference engine. The inference enginecomputes a dynamic merit for each Action according to the general aggregation formula:

Merit(Action) = f (Merit(Cond1) ∗ w1, Merit(Cond2) ∗ w2, . . .)

The aggregation formula f will be discussed later for each business rule type.We are introducing three types of abstract business rules that correspond to different

levels of detail. They are the rules obtained at the criteria level, at the arguments level andat the assumptions level of a decision matrix. These abstract business rules correspond todifferent levels of decision making in the hierarchy of an enterprise. Their combination willlead to the generation of operational business rules. The computation of the dynamic meritassociated with these abstract business rules will be done at operation time, based on theoperational data available at that time.

5.2.1. Criteria level. The criteria level rules reason about the degree of satisfaction of theproposed decision criteria by the existing alternatives. The reasoning is performed in orderto select the best alternative. Criteria level rules correspond to high level decision makingand express enterprise objectives in very general terms. These objectives will need to be


refined to the point where they can be translated into operational business rules. Objectiveswill serve as criteria for evaluating the alternatives proposed for solving the issue underconsideration.

For example, the rule

WHEN Assess Resource NeedsIF Quick Response Time = True[1] (1)THEN Send Ambulance = True

statically expresses what criteria will be used for evaluating the alternative Send Ambulancefor the issue Assess Resource Needs. Dynamically, the rule computes the merit of an alter-native against a set of criteria. For simplicity, we will assume only one criterion for thisissue: Quick Response Time of the resources sent to the incident site. At this level of ruleabstraction there is no precise definition yet of what the non-functional requirement QuickResponse Time really means. The only thing we know at this stage is the importance of eachcriterion in evaluating the alternatives. In this example, since there is only one criterion, itsimportance is 1.

The general format of this type of rule is:

WHEN IssIF Crit1[w1] ∨ Crit2[w2] ∨ · · · ∨ Critn[wn]THEN Alti

where wi represents the weight or importance of criterion Crit j in the process of evaluationof alternative Alti (see figure 10). Their values should sum up to 1. The wi values are givenby the decision makers at elicitation time.

Whenever a criteria level rule is activated at operation time, the system computes themerit MeritAlti of the alternative Alti from the action part of the rule. The computation isbased on the summation of the merit MeritCritj of alternative Alti in satisfying each criterionCrit j , adjusted by the sum of the weight wCritj of each criterion.

MeritAlti =∑ncrit

j=1 wCritj ∗ MeritCritj∑ncritj=1 wCritj

(2)

where MeritCritj will be defined next, and ncrit represents the number of criteria defined forevaluating the alternatives of an issue.

MeritAlti is calculated for all alternatives suggested for solving an issue. The alterna-tive with the largest merit is proposed as the solution to the issue. The operational rulecorresponding to this alternative is chosen for deployment.

5.2.2. The arguments level. These rules express the negotiation that should take placeamong stakeholders when refining the enterprise objectives. They reflect the knowledgeused in deciding how well an alternative satisfies a criterion when several arguments are


presented for, or against the alternative. Dynamically, the rules combine the evidence aboutthe merit of each argument Argk correlated with a pair (Alti , Crit j ), in order to compute theMeritCritj of the alternative Alti against criterion Crit j .

For example, in the context of sending an ambulance to an incident, the process of refiningthe meaning of the Quick Response Time objective brings up three arguments with differentweights, as shown in the rule:

WHEN Send AmbulanceIF Unacceptable Response = True[−1.0] ∨

Acceptable Response = True[0.3] ∨ (3)Ideal Response = True[1.0]

THEN Quick Response Time = True

The arguments correspond to different situations perceived by various stakeholders as plau-sible: (1) Sending an ambulance may be unacceptable in life-threatening cases where thelocation of the incident is far away from a hospital. Therefore, this is a counterargumentfor sending an ambulance in these cases. (2) Sending an ambulance may be acceptable inlife-threatening cases if the incident is close to the hospital. (3) Sending an ambulance isan ideal solution in non-life-threatening situations. This argument gives a stronger supportthan argument (2), as indicated by its higher weight. All these arguments will be taken intoconsideration when making the decision about whether to send an ambulance.

The general format of this type of rule is:

WHEN Alti

IF Arg1[w1] ∨ Arg2[w2] ∨ · · · ∨ Argn[wn]THEN Crit j

where wi represents the static weight of argument Argi in the evaluation process. Weightscan take values on a scale of [−1.0, 1.0]. When wi = −1.0, Argi is a strong counterargument,while when wi = 1.0, Argi is a strong supporting argument.

Whenever this type of rule is applied at operation time, the system computes the dynamicmerit MeritCritj of alternative Alti in satisfying the criterion Crit j . The computation ofMeritCritj is based on the weight of each argument (wArgi ) and the predicted accuracy of thetruth value of that argument (MeritArgi ):

MeritCritj =∑narg

i=1 wArgi ∗ MeritArgi∑narg

i=1 wArgi

(4)

where MeritArgi will be defined next, and narg is the number of arguments related to thepair (Alti , Crit j ), whose conditions are matched by the operational data of a specificincident.

5.2.3. The assumptions level. This is the most detailed level of rules where business ob-jectives find their operational meanings. The assumption level rules express the operational


conditions necessary for the alternative Alti to meet the criterion Crit j . Based on variousdomain assumptions they assess the validity of the arguments Argi associated with the pair(Alti , Crit j ). The antecedent part of these rules, consists of conditions on the assumptionsunderlying the argument Argi , which is represented in the consequent part of the rule. Theseconditions are obtained either automatically by induction from statistical data, or when thisdata is not available, by interaction with the decision makers.

For example, the rule

IF (Diastolic Blood Pressure = high ∧Systolic Blood Pressure = high)

THEN Ideal Response = True [75%]

shows the operational conditions necessary for the argument “Send ambulance is a quicksolution in non-life-threatening situations” to be true. More than that, it shows the perceivedaccuracy (75%) of this assessment, which will be used at operation time in calculating themerit of the Send ambulance alternative. The above conditions were obtained by applyingan induction algorithm from statistical data. The data used for inducing this rule is shownin figure 16. The algorithm will be presented in the next section.

The antecedent of this type of rules is a conjunctive normal form formula that containsvarious atomic assumptions about the argument under consideration. An atomic assumptionhas the format Asmpt ≡ (Attr <op> value), where <op>={=, <=, >}. The general formatof this type of rule is:

IF (Asmpt1 ∧ Asmpt2 ∧ · · · ∧ Asmptn)THEN Argi

[MeritArgi

]

where Attri represent the attributes whose values vi contribute to the value of the argumentArgi . The MeritArgi describes the predicted certainty factor about the truth value of argumentArgi . It is a by-product of the decision tree generation algorithm (Quinlan, 1987; Rosca andRosca, 1989) that will be discussed next.

5.3. Automatic generation of business rules

Given the information gathered during the elicitation phase about the business rules andtheir rationale, we explore the possibility for lifecycle automated assistance by supportingthe acquisition of certain types of business rules.

The method for the automatic generation of business rules uses the knowledge structureprovided by the decision support system through decision matrices. Also it uses statisticaldata that record how historical domain assumptions have been related to various arguments.

We distinguish two types of automatically created business rules. The first type arethe business rules that capture heuristic knowledge from the decision matrix. These rulescorrespond to criteria-level and argument-level rules from above. The second type of rulesare extracted from decision trees induced from statistical data by applying inductive learningtechniques. They correspond to the assumption-level rules from above.


As shown in the algorithm in figure 15, a criteria level rule is deduced from the associationof an issue with one of its alternative solutions, and the criteria that need to be met by thatsolution (see rule (1)). There will be one such rule created for each proposed alternative inthe decision matrix.

An argument level rule is obtained from the issues’ arguments table, which is associatedwith an alternative that is evaluated against a criterion. The argument name and importanceare extracted from the table for each argument listed (see rule (3)).

An assumption level rule is automatically generated from a decision tree induced fromdomain assumptions. For each argument from the argument table there will be generatedone or more assumptions rules. The set of training examples (E) used for the induction of thedecision tree (DT(E)) is extracted from a database of domain assumptions (see figure 15).

Figure 15. Algorithm for automatic generation of business rules from decision structures and statistical dataabout domain assumptions.


Figure 16. Training set for determining the class of ambulance response.

E refers to a specific argument Argk . The training examples are stated in terms of tuplesof domain assumptions and associated values (see figure 16). The domain assumptions arerepresented in terms of a set of attributes (A). The algorithm tolerates missing values forsome of the attributes, therefore allowing for imprecise information about an assumption.Classes represent various arguments.

Decision tree learning (Quinlan, 1986) is a machine learning technique that starts witha collection of training examples and outputs a compact classification, called a decisiontree. Training examples are n-tuples specifying the classification of a given combination ofattribute values. For example, in figure 16, the first line in the Assumptions Table showsthe following tuple: 〈(Systolic Blood Pressure, very high), (Diastolic Blood Pressure, veryhigh), (Pulse, high), (Temperature, high), (Distance, 15)〉. The classification of this exampleis “ideal = true”, representing the type of ambulance response in this case. The internalnodes in a decision tree correspond to tests on the values of particular attributes, whilethe leaves correspond to class values. The algorithm we have implemented and used in theconstruction of decision trees is shown in figure 17. It follows the ideas presented by Quinlanin (1986). The decision tree induced from the training set in figure 16 is shown in figure 18.The number of training cases to start with depends on the number of attributes, classesand the complexity of the underlying concept to be learned. The more attributes, classes,higher complexity concept, the more training cases are needed. For a simple concept, tensor hundreds of training cases would be sufficient, while for a complex model, one mightneed hundreds or even thousands of cases. Nevertheless, cross-validation techniques canbe used when the number of available training cases is small. We used 18 cases for trainingin our example, which is adequate for the type of concepts we wanted to learn.

As indicated in figure 17, in order to build a node of the tree, we need to select the attributethat maximizes the information entropy (Shannon, 1964) of the set E. The entropy of a set


Figure 17. Algorithm for induction of decision trees.

Figure 18. Decision tree induced from the training set in figure 16.

E is the average amount of information that is needed to identify a class of an example inE. If an example selected at random from a set E belongs to the class Ci , the informationconveyed is

− log2

(freq(Ci , E)

|E |)

bits

where freq(Ci ,E)|E | represents the frequency of the number of cases in S that belong to class Ci .

Therefore, the entropy of a set E is calculated according to the following formula:

info(E) =k∑

i=1

freq(Ci , E)

|E | × log2

(freq(Ci , E)

|E |)

bits


The similar measurement taken after the set E has been partitioned according to the ncategories of a test X , is calculated by the following formula:

infoX (E) =n∑

i=1

|Ei ||E | × info(E) bits

In order to create a node of the decision tree we will select the attribute Ai that maximizesthe difference between info(E) and infoX (E). For example, for the set of examples infigure 16, info(E) is calculated as follows:

info(E) = − 5

18× log2

5

18− 3

18× log2

3

18− 10

18× log2

10

18= 1.415 bits

When we calculate infoX (E) for a scalar attribute, for example the Diastolic BloodPressure, the entropy is

infoX (E) = 8

18

(−4

8log2

4

8− 2

8log2

2

8− 2

8log2

2

8

)

+ 4

18

(−1

4log2

1

4− 3

4log2

3

4

)+ 1

18

(−1

1log2

1

1

)

+ 3

18

(−3

3log2

3

3

)+ 1

18

(−1

1log2

1

1

)= 0.84 bits

The same calculation done for the Systolic Blood Pressure results in 0.93 bits. Computingthe information gain for these two attributes (0.575 and 0.485, respectively), the conclusionis that the Diastolic Blood Pressure attribute will be preferred to the Systolic Blood Pressure,due to a higher information gain.

When infoX (E) is calculated for a numeric attribute, for example Distance, we first sortthe values of the attribute under consideration, let’s say k values. Therefore we will havek − 1 possible splits on the values of the attribute, and for each of the intervals createdwe calculate infoX (E), considering the tests A <= Tj and A > Tj . Tj is a threshold valuecalculated as the midpoint of each interval. For example, in the case of the Distance attribute,the minimum value of infoX (E) (0.495) is obtained for the threshold value 28. As such,the information gain will be 1.415 − 0.495 = 0.920. This result promotes Distance as theattribute that maximizes the information gain on the set of examples E and therefore becomesthe root of the decision tree, as seen in figure 18. This procedure is recursively applied oneach branch of the decision tree created by the test on the attribute Ai , and on the set oftraining examples that are clustered in each category CTi dictated by the chosen test on Ai .

From an induced decision tree we extract, generalize and optimize assumptions levelrules, as suggested in Quinlan (1993). The generalization is applied at the rule level, whilethe optimization is applied at rule sets level (see the algorithm in figure 19). A rule isextracted from the decision tree by traversing a path from the root to a leaf. Therefore everyleaf will correspond to a rule such as

if X1 ∧ X2 ∧ · · · ∧ Xn then class C


Figure 19. Algorithm for induction of rules from decision trees.

Figure 20. Rules induced from the decision tree.

where conditions Xi correspond to the tests on the nodes along the traversed path, andclass C corresponds to the label of the leaf on that path. The rules induced from the decisiontree in figure 18, are shown in figure 20.

After obtaining this initial set of rules we try to generalize them, by eliminating theunnecessary conditions. The pruning is done only if the elimination of a condition doesn’tdecrease the certainty factor of the rule. The certainty factor is a measure of estimating how


many unseen examples will be classified correctly by this rule. For our purposes it representsthe predicted accuracy of the value of an argument. The calculation of the certainty factoris based on observing how many training examples satisfy all the conditions Xi of the ruleand belong to the class C (E1 in the table below), and how many of them satisfy all theconditions of the rule, but belong to other classes (E2 in the table below). The sets Ei

are calculated with respect to a set of examples that satisfy all the other conditions fromthe left hand side of the rule, with the exception of condition Xi . This information can besummarized in a contingency table as follows:

Class C Other classes

Satisfies condition Xi E1 E2

Doesn’t satisfy condition Xi E3 E4

Based on the sets Ei from the contingency table, the formula used for the calculation ofthe certainty factor of a rule before eliminating condition Xi , taking into account the Yate’scorrection for continuity (Snedecor and Cochran (1980)), is the following:

Ci (E1, E2) = E1 − 1/2

E1 + E2

After eliminating condition Xi , the certainty factor will be given by the formula C f (E1 +E3, E2+E4). Therefore we will eliminate a condition only if C f >= Ci , which enforces thatthe accuracy of a rule will not be decreased. After eliminating a condition, the contingencytables for the remaining conditions need to be reevaluated.

For example, in rule R1 of the initial sets of rules, analyzing whether to eliminate thecondition Distance >= 28, we obtain the following contingency table:

Class ideal Other classes

Satisfies condition Distance >= 28 1 0

Doesn’t satisfy condition Distance >= 28 1 0

Based on the data from the contingency table, Ci = 1−1/21 = 0.5 and C f = 2−1/2

2 = 0.75.For the condition Distance >= 51, C f = 2−1/2

2 = 0.75. In the case of the Diastolic BloodPressure = high and Systolic Blood Pressure = high, C f = 0.25. We will eliminate the con-dition that has the least detrimental effect on the certainty factor of the rule. In this case, wehave two such conditions: Distance >= 28 and Distance >= 51. We will randomly pickone, say Distance >= 28 to be eliminated. This process is repeated as long as there are stillconditions to be eliminated. From the initial set of rules in figure 20, the generalized rulesobtained by applying the above procedure are shown in figure 21.

After obtaining the set of generalized rules, we are also interested whether this is thesmallest set of rules that correctly classifies the largest number of examples from E.For this purpose we calculate the importance of a rule, as the difference between the


Figure 21. Generalized rules.

number of examples from E that are correctly, respectively incorrectly classified onlyby that rule. If the importance is negative or zero, that rule can be dropped because re-moving it will not increase the number of examples that are incorrectly classified. In do-ing this we have built a production rule interpreter (classifier), which given an example,finds the rule that classifies it. If more rules are applicable, i.e. their left hand side con-ditions are satisfied, the interpreter will choose the one with the highest certainty factor.If no rule is activated, the example is classified according to the most frequent class inthe training set. For our particular set of rules, the calculated importance for each rulein the set is respectively: 2, 3, 4, 3, 9. Because the importance for all the rules is posi-tive, we cannot eliminate any of them without decreasing the number of examples thatare misclassified. Also, we don’t have any cases of duplicate rules or too general rulesbecause of the small set of examples we started with. Therefore the final set of rulesextracted from the training set E is the one shown in figure 21. They are the set of as-sumption level rules that will be used in the deduction of operational business rules at runtime. The algorithms presented above were tested on multiple sets of data using cross-validation.

For the deduction of business rules, as it is mentioned in step 3 of the algorithm in figure 15,a consequent expansion transformation is applied to the criteria level and argument levelrules. Consequent expansion replaces a condition on a variable v in the antecedent of a rule,with the antecedent of the rule that has v as a consequent.

When the consequent expansion is applied on an argument level rule, its conditions willbe replaced with the left hand side of the assumption level rules, which are activated whenthe operational data of an incident is run through the classifier. For example, let’s assumethat the data about a new incident shows that the patient has Systolic Blood Pressure = high,

Diastolic Blood Pressure = high, Pulse = low, Temperature = high, and Distance = 42.Running this example through the classifier, rules one and four from figure 21 will beactivated. Therefore the resulting rule corresponding to the alternative Send ambulance


will be:

WHEN Assess Resource NeedsIF ((Distance from Hospital >= 28) ∧ (Distance from Hospital < 51)) (5)∨ ((Diastolic Blood Pressure = high) ∧ (Systolic Blood Pressure = high))THEN Send Ambulance = True[0.77]

The merit (0.77) of this rule was obtained by applying the formulas 4 and 2, where themerit of each argument is the certainty factor of the corresponding activated assumptionlevel rule. In our case,

MeritCrit1 = 0.3 ∗ 0.83 + 1 ∗ 0.75

1 + 0.3= 0.77

and

MeritAltl =1 ∗ 0.77

1= 0.77

Following this procedure the merit of each alternative from the decision matrix in figure 10will be calculated. The alternative with the highest merit will be chosen to be applied forthat specific operational data. This procedure ensures that the best rule that complies withcompany policies is applied for every particular situation.

6. Summary and conclusions

A methodology has been presented that provides a fair degree of guidance for the activitiesof acquiring, deploying and evolving business rules of an enterprise. This covers a largerpalette of aspects than what is present in the current literature, which is mainly concernedwith the acquisition of business rules (Kilov, 1997; Leite and Leonardi, 1998; Bubenko Jr.and Wangler, 1993). We have highlighted the special nature of business rules as decisionswhose consequences are speculative and subject to change. The sense in which businessrules are “satisfied” is also defined flexibly to correspond to how they must be treated andtolerated in practice.

A business rules modeling framework has been introduced for representing the infor-mation needed to conduct the methodology. A prominent feature of the framework is thefacility for capturing the decision support information, which is associated with businessrules analysis and which enables automatic generation of business rules. The concepts ofthe decision support framework (i.e. alternatives, criteria, arguments, etc.) were specificallydesigned to be used in the learning algorithms, which automatically generate new rules. Thefact that the rules can be automatically generated demonstrates the successful integrationof the components of the framework, including effective traceability relationships betweenthem. The framework has been implemented on top of a commercial platform that providedfor modeling of objects, processes and rules. The objects and process models, taken to-gether, were construed to be our “enterprise model”, in terms of which the business rules


are expressed. This simplified enterprise model was sufficient to demonstrate the method-ology, which is not hard-linked to any particular enterprise model. However, ultimately, aricher enterprise model would facilitate the expression of additional types of business rules,such as rules about services, organizations, and other aspects of an enterprise. The Service-Oriented Systems model (Greenspan and Feblowitz, 1993) proposes such extensions. Thegoal, task and resource dependencies of the i∗ framework (Yu, 1994) also offer appropriatefeatures for extending the enterprise model.

This paper has made the distinction between the goal-oriented business rules, as the rulesthat embody the high level enterprise policies, and operational business rules as the opera-tional procedures that achieve the business objectives. We have argued that the goal-orientedbusiness rules should be refined to the point where they are transformed into operationalbusiness rules, that can be mapped directly either into requirements of an enterprise in-formation system, or procedures for human enactment. In the former case, this paper hasproposed a decision support framework for recording pre-traceability information about re-quirements, and assessing to what degree the requirements of an information system satisfythe enterprise objectives. This represents a step forward toward an easier system evolution,and a quicker reaction to the inevitable changes in the enterprise objectives.

We studied a project (Reubenstein, 1995) where business rules were recorded to under-stand the types of business rules and the factors that determined them. We were motivatedby the desire to include business rules in a requirements modeling framework.

The possibility for lifecycle automated assistance has been demonstrated in terms of theautomatic extraction of some types of business rules using the decision support frameworkand domain assumptions. The extraction algorithm applies a technique that is well-knownin the field of Machine Learning to a new field, Requirements Engineering, by using it inthe business rules context. The acquisition method is geared towards deployment, acquiringonly those types of rules that can be directly deployed into the operational system of theenterprise. More work needs to be done in the area of business rules evolution, a first attemptbeing documented in Rosca and D’Attilio (2001), where business rules are encoded as XMLdocuments.

We have described how the methodology offers solutions for real-world situations, bysupporting the flexibility of the operational system in dealing with nondeterminism. It guidesthe users to choose the most appropriate business rule from multiple conflicting ones, or toground ambiguous terms when insufficient information has been provided at analysis time.These activities rely on run-time values and status of the process.

The methodology presented could be used in an enterprise whose goal is to reach CMMlevel 5, for documenting continuous improvement practices. This can be achieved by usingthe monitoring capabilities proposed in this paper to learn from experience, and continuouslyevaluate and adjust the business rules as the enterprise and its operational system evolve.

The work presented here has an impact not only in the advance of state of the art inbusiness rules, but also in the early phases of requirements engineering, business processreengineering and organizations, in general. Although many benefits of this work cannotbe easily estimated quantitatively, we can do this in the case of the automatic generation ofcertain types of business rules. The cost of capturing and maintaining the decision supportknowledge is estimated to be 30% of a person/year effort, according to a study of a large scale


project (Terveen and Selfridge, 1995). The types of rules that can be automatically generatedby our procedure are stimulus-response rules, preconditions, postconditions, and compu-tation rules. These categories represent 45% of the rules captured in the re-engineeringproject we have studied. This is an encouraging result that motivates us to further searchfor ways of extending the automatic generation procedure to other types of business rules.The methodology has not been applied in practice, so there is no experience to report on itsoverall effectiveness.

The contributions of this paper are in the synthesis of the elements of the methodology,and in the automated procedure that uses the information captured in the framework in orderto infer business rules. The components of the framework although individually are not new,they are being newly applied to business rules. As such, we have shown the application of adecision support model to the analysis and generation of business rules, and to the refinementof goal-oriented rules into operational rules, the use of inductive learning algorithms for thegeneration of business rules, the integration of an enterprise model with a decision supportmodel and inductive learning techniques, and a methodology that helps resolve key issuesat various stages of the business rules lifecycle.

Acknowledgments

We acknowledge the anonymous reviewers for their thorough comments that helped raise thequality of this paper. Also, we acknowledge Howard Reubenstein (then at GTE Laboratories)for his work on the taxonomy of business rules, Mark Feblowitz (then at GTE Laboratories)for his valuable feedback in earlier stages of this work, and Charlene Varnis (from theUniversity of Rochester School of Medicine) for her supervision in the collection of trainingexamples for the learning algorithms.

References

Balzer, R. 1991. Tolerating inconsistency. In Proceedings ICSE’91, Silver Spring, MD: IEEE Computer Press,pp. 158–165.

Basili, V. and Weiss, D.M. 1984. A methodology for collecting valid software engineering data. IEEE Transactionson Software Engineering, 10(6):728–738.

Boehm, B., Bose, P., Horowtiz, E., and Lee, M.J. 1995. Requirements negotiation and renegotiation aids: Atheory-w based spiral approach. In Proceedings ICSE’95, Silver Spring, MD: IEEE Computer Society Press,pp. 23–30.

Bubenko, Jr. J. and Wangler, B. 1993. Objectives driven capture of business rules and of information systemsrequirements. In Proceedings of the International Conference on Systems, Man and Cybernetics, pp. 670–677.

Champion, R. and Moores, T. 1996. Exploiting an enterprise model during systems’ requirements capture andanalysis. In Proceedings of the International Conference on Requirements Engineering ICRE’96, Silver Spring,MD: IEEE Computer Society Press.

Chen, Y., Segarra, G., and Chong, P. 1992. Visualizing business rules in corporate databases. Industrial Managementand Data Systems, 92(7):3–8.

Chung, L., Nixon, B., and Yu, E. 1995. Using non-functional requirements to systematically support change. InSecond IEEE International Symposium on Requirements Engineering.

Chung, L., Nixon, B., Yu, E., and Mylopoulos, J. 1999. Non-Functional Requirements in Software Engineering.Norwell, MA: Kluwer Academics.

Conklin, J. and Begeman, M. 1988. gIBIS: A hypertext tool for exploratory policy discussion. ACM Trans. OfficeInfo. Systems, 6(4):303–331.


Easterbrook, S. and Nuseibeh, B. 1995. Managing inconsistencies in an evolving specification. In ProceedingsRE’95, Silver Spring, MD: IEEE Computer Press, pp. 48–55.

Feuerlicht, G. and Blair, A. 1990. An architecture for managing business rules using knowledge engineeringtechniques in RDBMS environment. In Proceedings 4th Australian Joint Conference on Artificial Intelligence,pp. 384–393.

Fickas, S. and Feather, M. 1995. Requirements monitoring in dynamic environments. In Proceedings of IEEEInternational Symposium on Requirements Engineering.

Finkelstein, A. and Dowell, J. 1996. A comedy of errors: The London Ambulance Service case study. In Proceedingsof the 8th International Workshop on Software Specifications and Design (IWSSD’96), Silver Spring, MD: IEEEComputer Press.

Finkelstein, A., Gabbay, D., Hunter, A., Kramer, J., and Nuseibeh, B. 1994. Inconsistency handling in multiple-perspective specifications. IEEE Transactions in Software Engineering, 20(8):569–578.

Ghezzi, C. and Nuseibeh, B. 1998. Special issue on managing inconsistency in software development. IEEETransactions on Software Engineering, 24(11):906–907.

Gotel, O. and Finkelstein, A. 1994. An analysis of the requirements traceability problem. In Proceedings ofthe International Conference on Requirements Engineering, Silver Spring, MD: IEEE Computer SocietyPress.

Greenspan, S. and Feblowitz, M. 1993. Requirements engineering using the SOS paradigm. In Proceedings ofIEEE International Symposium on Requirements Engineering, San Diego.

Hammer, M. 1990. Reengineering work: Don’t automate, obliterate. Harvard Business Review.Hauser, J. and Clausing, D. 1988. The house of quality. Harvard Business Review, 63–73.Herbst, H. 1995. A meta-model for specifying business rules in system analysis. In Proceedings of CAiSE’95,

pp. 186–199.Herbst, H. and Myrach, T. 1995. A repository system for business rules. Technical Report 57, Institute of Infor-

mation Systems, University of Berne.Intellicorp. 1995. LiveModel User’s Guide.Jarke, M. and Kurki-Suonio, R. 1998. Special issue on scenario management. IEEE Transactions on Software

Engineering, 24(12):1033–1035.Kilov, H. 1997. Business rules: From business specification to design. Technical Report, IBM, T.J. Watson.Lamsveerde, A.V., Darimont, R., and Massonet, P. 1995. Goal-directed elaboration of requirements for a meeting

scheduler: Problems and lessons learnt. In Proceedings of RE’95, Silver Spring, MD: IEEE Computer SocietyPress.

Lee, J. 1991. Extending the Potts and Bruns model for recording design rationale. In International Conference onSoftware Engineering, pp. 114–125.

Lee, J. 1992. Capturing, reusing, and managing the reasons for decisions. Ph.D. Thesis, Department of ComputerScience, MIT.

Leite, J. and Leonardi, C. 1998. Business rules as organizational policies. In Proceedings of the InternationalWorkshop on Software Specifications and Design, Silver Spring, MD: IEEE Computer Society Press.

Loucopoulos, P. and Karakostas, V. 1995. System Requirements Engineering. New York: McGraw Hill.Loucopoulos, P. and Katsouli, E. 1992. Modelling business rules in an office environment. SIGOIS Bulletin,

13(2):28–37.MacLean, A., Young, R., Bellotti, V., and Moran, T. 1991. Questions, options, and criteria. Human-Computer

Interaction, 6:201–250.Martin, J. and Odell, J. 1995. Object-Oriented Methods: A Foundation, ch. 20. New York: Prentice Hall.Nuseibeh, B., Kramer, J., and Finkelstein, A. 1994. A framework for expressing the relationships between multiple

views in requirements specification. IEEE Transactions on Software Engineering.Paul, L. 1995. Hidden assets. PC Week.Paulk, M. Curtis, B. and Chrisis, M. Capability maturity model for software, version 1.1. Technical Report,

Software Engineering Institute.Phol, K. 1996. Process-Centered Requirements Engineering. New York: John Wiley.Pohl, K., Domges, R., and Jarke, M. 1997. Towards method-driven trace capture. In Proceedings of CAiSE’97.Quinlan, J. 1986. Induction of decision trees. Machine Learning, 1:81–106.Quinlan, J. 1987. Generating production rules from decision trees. In Proceedings IJCAI, pp. 304–307.


Quinlan, J. 1993. C4.5: Programs for Machine Learning. Los Altos: Morgan Kauffmann.Ramesh, B. 1991. Process Knowledge Based Support for Systems Development. Ph.D. Thesis, Leonard Stern

School of Business, New York University.Ramesh, B. 1992. Supporting systems development by capturing deliberations during requirements engineering.

IEEE Transactions on Software Engineering, 18(6):498–510.Reubenstein, H. 1995. An analysis of a business rules sampler. Technical Report 0304-09-95-163, GTE

Laboratories.Rosca, D. and D’Attilio, J. 2001. Interoperability of distributed systems through XML-encoded business rules. In

Proceedings Software Engineering and XML Technologies Workshop, ICSE’01, pp. 56–61.Rosca, D., Greenspan, S., Feblowitz, M., and Wild, C. 1997. A decision making methodology in support of the

business rules lifecycle. In Proceedings of the International Symposium on Requirements Engineering RE97Conference, pp. 236–246.

Rosca, D., Greenspan, S., Wild, C., Reubenstein, H., Maly, K., and Feblowitz, M. 1995. Application of a decisionsupport mechanism to the business rules lifecycle. In Proceedings of the Knowledge Based Software EngineeringKBSE95 Conference, pp. 114–122.

Rosca, J. and Rosca, D. 1989. Knowledge acquisition facilities within an expert system toolkit. In Proceedings ofthe Seventh International Symposium on Computer Science, Jassy, Romania.

Rosca, D. and Wild, C. 2001. Towards a flexible deployment of business rules. Journal of Expert Systems withApplications, Special Issue on SEKE’01, to appear.

Ross, R. 1997. The Business Rules Handbook: Classifying, Defining and Modeling Rules. Database ResearchGroup, Inc., Boston, MA.

Sandifer, A. and von Halle, B. 1993. Business rules: Capturing the most elusive information asset. In B. von Halleand A. Kull, editors, Handbook of Data Management. Philadelphia, PA: Auerbach.

Shannon, C.E. 1964. The Mathematical Theory of Communication. Champaign, IL: University of Illinois Press.[c1949].

Sibley, E., Wexelblat, R., Michael, J., Tanner, M., and Littman, D. 1992. The role of policy in requirementsdefinition. In Proceedings of the International Conference on Requirements Engineering, Silver Spring, MD:IEEE Computer Society Press.

Snedecor, G. and Cochran, W. 1980. Statistical Methods. Iowa State University Press.Taveter, K. 1999. Business rules approach to the modeling, design, and implementation of agent-oriented infor-

mation systems, In Proceedings of The Agent-Oriented Information Systems Workshop, CAiSE’99.Taveter, K. and Wagner, G. 2000. Combining aor diagrams and ross business rules’ diagram for enetrprise modeling.

In Proceedings of The Agent-Oriented Information Systems Workshop, CAiSE’2000.Terveen, L. and Selfridge, P. 1995. “Living Design Memory”— Framework, implementation, lessons learned.

Human Computer Interaction, 6(1):1–37.Ullman, J. and Widom, J. 1997. A First Course in Database Systems. New York: Prentice Hall.van Lamsverde, A. 2000. Requirements engineering in the year 00: A research perspective. In Proceedings ICSE

2000, IEEE Computer Press, pp. 5–19.van Lamsweerde, A., Darimont, R., and Letier, E. 1998. Managing conflicts in goal-driven requirements engineer-

ing. IEEE Transactions in Software Engineering, 24(11):908–925.von Halle, B. 1993a. Staying the course. Database Programming Design, August:13–16.von Halle, B. 1993b. Making business rules real. Database Programming Design, September:13–15.Wangler, B., Wingstedt, U., and Wohed, R. 1995. Requirements capture in practice: Experiences from a case study

at Sweden Post. Technical Report, SISU.Wild, C. and Rosca, D. 1994. Evolution and reuse of formal specifications using decision structures. In Proceedings

of the KBSE94 Conference, pp. 108–115.Wood, J. and Silver, D. 1995. Joint Application Design. New York: Wiley.Yu, E. 1994. Modelling Strategic Relationships for Process Reengineering. Ph.D. Thesis, University of Toronto.Yu, E. 1997. Towards modeling and reasoning support for early-phase requirements engineering. In Proceedings

RE’97, IEEE Computer Press, pp. 226–235.Yu, E. and Mylopoulos, J. 1996. Using goals, rules, and methods to support reasoning in business process reengi-

neering. International Journal of Intelligent Systems in Accounting, Finance and Management, 5(1):1–13.

enterprise modeling and decision-support for automating the business rules lifecycle

Documents