Business Rules for Business Governance
Naveen Prakash
1
, Deepak Kumar Sharma
1,2
and Dheerendra Singh
3
1
Department of Computer Science & Engineering, MRCE, Sector 43, Faridabad, 121001, India
2
Research Scholar, Punjab Technical University, Kapurthala Jalandhar, India
3
Department of Computer Science & Engineering, SUSCET, Tangori, Mohali, India
Keywords: Business Oriented Business Rules, Governance Model, Business Independent Governance Model,
Governance Properties, and Business Rules Typology.
Abstract:
To reduce the gap between the business-oriented view of business rules of business people and the technical
orientation of technical people, we introduce a Business layer on top of the CIM layer of MDA. This
facilitates an investigation into the features of business-oriented business rules. We underpin our work with
a four dimensional framework of business rules consisting of the domain, system, representation, and
application dimensions. Since our focus is on features of business rules, our interest is the domain
dimension. This dimension provides a number of attributes of business rules but we concentrate on the
governance/guidance attribute to develop the features needed for capturing this attribute in business rules.
We express governance concepts in three levels. The Governance model is the top most level and consists
of governance objects, governance criteria, and the governance relationship between these. We obtain
BIGm by instantiating the Governance model based on concepts of the Business Motivation Model. Finally,
BIGm is instantiated to yield BOGm. We illustrate our business rules with examples from the library
management domain.
1 INTRODUCTION
Business rules have been the subject of much
research. The MDA (OMG, 2003) framework has
been used for organizing business rules(Gaweł,
2012): at CIM we have proposals like
SBVR(OMG,2008), RECON (Barkmeyer, 2013),
and ACE(ACE, 2003); at PIM we have Rule ML
and R2ML; finally at the PSM level we have Java,
.Net, and other rule engines etc. Business rules are
used for forward engineering of systems in
(Kardasis, 2004) and for reverse engineering
systems as in (Wang, 2004), (Gang, 2009).
Frameworks for understanding business rules
were developed. The framework of (Kardasis, 2004),
organizes collection, expression, and structuring of
business rules to develop a business rules
management system, BRMS. The framework of
(Dubauskaitė, 2009) was built to address business
rule elicitation. Notice that these frameworks
emphasize the Information/software systems
perspective of business rules.
In contrast to this technical information system
perspective, the Business Rules Manifesto (Ross,
2003) highlights the business view of business rules.
This perspective is in ten articles and their clauses.
The Business Motivation Model(OMG,
2011)sees a business rule as a ‘directive’ that guides
and governs courses of action. While not elaborating
the nature of this governance, the Model assumes
that the representation of business rules is in
accordance with SBVR. However, SBVR is
positioned at the CIM level of MDA that is
information system oriented (Gaweł, 2012).This
creates a mismatch between the business level of the
Motivation Model and the CIM level of SBVR.
To remove this mismatch, we introduce a
Business level above the CIM layer. The Business
level facilitates a full investigation of the notion of
governance/guidance of the Motivation Model. As a
result, we obtain a number of new aspects of
business rules from the business perspective.
In an earlier position paper (Prakash,2013), we
proposed that the definition of the business layer is
4-dimensional: we identify the features of business
rules in the domain dimension, represent them in the
representation dimension, develop a BRMS in the
system dimension and use rules to develop
360
Prakash N., Sharma D. and Singh D..
Business Rules for Business Governance.
DOI: 10.5220/0004888603600367
In Proceedings of the 16th International Conference on Enterprise Information Systems (ICEIS-2014), pages 360-367
ISBN: 978-989-758-029-1
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
applications in the application dimension. The
attributes of each dimension were identified in
(Prakash, 2013).
This paper constitutes our first attempt to define
the Business layer and deals with the ‘guides’
attribute of the domain dimension (Prakash, 2013).
We shall explore the role of other attributes of the
domain dimension as well as other dimensions in
subsequent work.
As shown in Figure 1, the Business layer sits on
top of the CIM layer. The left hand side of the figure
shows our approach to populating the Business layer
as consisting of three levels of models. The top two
levels are the underpinnings of the third layer.
Figure 1: Populating the Business Layer.
At the topmost level, we have a generic model,
the Governance Model. This model brings out the
essential nature of guidance/governance independent
of the nature and level of business rules. To obtain
our business oriented governance model, we
instantiate the generic model to get a Business
Independent Governance model, BIGm. This
enables us to define the concepts in terms of which
governance in businesses is conceptualized. It is
business independent; all businesses that agree to the
instantiated concepts can define their governance
system. Finally, we will instantiate BIGm with the
operational concepts of a business to get BOGm, the
Business Operational Governance model.
In the next section, we consider the domain
dimension of our framework in detail. In section 3,
we describe the Governance Model and explain its
salient features. Thereafter, in section 4, we present
BIGm. Section 5 contains BOGm along with the
typology of business rules.
2 THE DOMAIN DIMENSION
The 4-dimensional framework is generic, it applies
to business rules at any level of abstraction,
Business, CIM, PIM, or PSM. It identifies the
attributes of each dimension. These attributes take
on values that determine the exact nature of the
business rule. Since our interest is the domain of
business rules, we describe here the attributes and
values of this dimension.
There are four attributes of the domain
dimension (see Figure 2) as follows:
a. Guides: This tells us what the business rule
controls. It takes on one or more values from the
set {courses of action, enablement of courses of
action, event, function, trigger, business
process}. According to the Business Motivation
Model, a business rule can guide the first two in
this set. Therefore, guides = {courses of action,
enablement of courses of action}. In case of
SBVR, guides ={function}. This is because its
logical formulation controls a verb concept and
therefore, the function carried out.
b. Contributes: This attribute describes the effect of
a business. It takes values from the value set,
{business goal, system goal, implementation
goal, function goal}. At the business level, a
business rule contributes to the achievement of a
business goal. Therefore, contributes = {business
goal}. On the other hand, at the CIM level, a
business rules contributes to a system goal.
c. Role: This attribute tells us the purpose of the
business rule. It takes on values from the set
{main, exception, error, compensation}. At the
business level, we have role = {main, exception}.
On the other hand, at PSM, the role attribute will
include errors.
d. Cost: This attribute is about the exclusions that a
business rule entails. It takes values from {lost
opportunity, lost freedom, lost functionality}. At
the business level Cost = lost opportunity (Ross,
2003). At the CIM level, SBVR suggests that the
cost is loss of freedom.
Attribute Value
Guides SET{Course of action, Enablement of
course of action, Business Process,
Trigger, Event}
Contributes SET{Business goal, System goal,
Implementation goal, Functional
goal}
Role SET{Main, Exception, Error,
Compensation}
Cost SET{Lost opportunity, Lost freedom,
Lost functionality}
Figure 2: The DOMAIN dimension.
We illustrate the foregoing with examples from the
Library Management domain. The library deals with
three broad activities namely, Manage Borrower,
Provide Services, and Stock Library material.
Manage Borrower involves the registration and
Governance
Model
BusinessOperational
Governancemodel
BusinessIndependence
GovernanceModel
BusinessLayer
CIM
populates
BusinessRulesforBusinessGovernance
361
deregistration of Library uses. Provide Services is
for issuing, returning, and reserving library material.
Finally, Stock Library deals with purchase and
inventory control.
From the business perspective, the business
rules of the library guide and control these three
courses of action and their enablement. Library
business rules contribute to the objectives, Meet
demand, Ensure Fair and Transparent Material
Distribution. Business rules may be main business
rules, for example those governing issue and return
of material or exceptional, for example, those
governing reservation of material when it is not
readily available. Finally, there may be lost
opportunity because we may constrain our library to
be used only by internal users and thereby bar
participation in a network of libraries.
3 THE GOVERNANCE MODEL
In the next three sections, we consider populating
the business layer. Following the Business
Motivation Model (OMG, 2011) we assume that
business rules govern the conduct of business. We
elaborate this view in the Governance model (see
Figure 3). The model consists of
Governance Object: A governance object is an
active business concept. By ‘active’, we mean
that governance objects are executable and are
the means to achieve business objectives.
Governance objects may be business strategies.
Governance objects need to be controlled and
deployed in specific business situations.
Governance Criteria: Define the situation in
which a governance object is deployed. This
situation may be the satisfaction of a condition.
For example, the governance object, Register
Borrower, is deployed only upon satisfaction of
the criterion that the borrower is a student.
Governance Relationship: Associates
governance objects with their criteria. As shown
in Figure 3its cardinality is M:N and that there
must be a minimum of one criterion associated
with a governance object. This is because
uncontrolled execution of a governance object
can lead to unforeseen business situations.
Governance Properties: These are attributes of
the governance relationship. Governance
properties may elaborate on the nature of the
governance, for example, whether it is
automatable or manual, or it may specify
constraints.
Figure 3: The Governance Model.
The Governance Model makes provision for
answering three kinds of questions in a business,
namely,
What is to be governed? Governance objects are
to be governed.
What does governance do? It is the application of
governance criteria to governance objects to
determine whether the governance object can be
executed or not.
What are the properties of governance? Such
properties are governance nature and governance
constraints
4 BIGm
There are at least two views of what is a governance
object of Figure 3. One is of the Business
Motivation Model (OMG,2011) that governance is
for the Means aspect of a business. The other view is
that governance is for achievement of business ends,
its goals and objectives (Rosca, 1997). It is possible
to instantiate the governance model with concepts of
either of these to achieve two different business
independent governance models. Here, we use the
concepts of the Business Motivation Model to
produce our BIGm.
The Motivation Model provides three major
notions in its Means aspect. These are Mission,
Courses of action and Directives. Directives govern
Courses of action and there are two kinds of
directives, business rules and policies. Our interest
here is in the former.
We instantiate, see Table I, Governance object by
the notion of Means. There are two kinds of means,
course of action and enablement. The former itself is
of two kinds, strategies and tactics. Courses of
action interact with one another through inclusion
and enablement. Inclusion implies the existence of
complex courses of action whereas enablement says
that a course of action is a pre-requisite/trigger for
another.
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
362
Table 1: Instantiation of Governance Model.
Governance Model BIGm
Governance Object Means: Course of action,
Enablement
Governance Criteria Acceptability Criteria
Governance
Relationship
Means: Acceptability criteria
Properties Necessity; Validity
Summarizing, we get:
1. A course of action standing alone: an individual
course of action is governed by its own business
rule.
2. Let us define a complex course of action as one
that includes other courses of action. Evidently,
governance for both the included as well as the
complex course of action is needed: if a course of
action A includes B and C, then all three are
separately governed by their own rules.
3. Governance of enablement: let a course of action
A enable course of action B. In addition to the
individual business rules of A and B, there are
business rules governing enablement.
Figure 4 shows the three kinds of means, atomic,
complex courses of action as well as enablement.
The Governance model defines governance as
the determination of whether a governance object
should or should not be done. We model this in
Figure 4 by the relationship ‘governs’ between
Acceptability criterion and Means. As shown, there
must be at least one acceptability criterion for a
means and an acceptability criterion can govern one
or more means.
Figure 4: Business Independent Governance Model.
We define two kinds of acceptability criterion,
condition and course of action. That is, either
condition satisfaction or execution of a course of
action activates a means. Thus, the relationship,
governs, takes on the following forms:
<condition, course of action>
<condition, enablement>
<course of action, course of action>
A condition may be the state of the business or
an event. For example, let a student approach to
library to reissue a book already issued to him. The
business rule governing the reissue is that the book
will be reissued only if it is not reserved by another
borrower. Here, the condition is the state ‘not
reserved’. Alternatively, a condition may be a
temporal event. For example, reissue can be done
fifteen days before the end of semester but not after.
We introduce two primitive properties of governs
as follows:
Necessity: Is it necessary to do the governance
object or can it be omitted
Validity: specifies a time for which the
governance object is valid.
Necessity
An atomic course of action may be necessary or not
in a given business context. If it is necessary, then
the course of action must be performed. When a
course of action is not necessary then it is optional.
A complex course of action has its own necessity
property and each of its components has its own. For
example, if A is complex and includes B and C, then
it may be possible that necessity of A = yes;
necessity of B = yes, and necessity of C = No.
Similarly, necessity applies to enablement and
course of action A may necessarily enable another
course of action B.
Validity
This property imposes a time limit within which a
governance object is relevant in the business. For a
course of action, it specifies a validity period of the
strategy/tactic whereas for enablement it specifies
the time limit within which enablement occurs.
Validity has two forms, mandatory or optional.
Mandatory validity means that a governance object
is performed before expiry of validity or not at all.
Optional validity allows violation of validity limit
but subject to a penalty decided by the business.
This penalty is specified as part of optional validity.
We can derive the property of a deadline (Prakash,
2010) from Necessity and Validity. Refer to Table
II. The first row of the table shows a hard deadline,
it is necessary to perform a governance object but
within a mandatory validity. In contrast (second
row), a soft deadline occurs when it is necessary to
BusinessRulesforBusinessGovernance
363
perform a governance object with optional validity
but under a penalty if validity is violated. The third
and fourth rows deal with conditional hard and soft
deadlines. The governance object is optionally
performed and validity applies only if it is
performed. Conditional deadlines are so named
because they are conditional on the governance
object being performed.
Table 2: Types of Deadline.
Necessity Mandatory
Validity
Optional
Validity
Deadline
Yes Yes No Hard
Yes No Yes Soft
No Yes No Conditional
Hard
No No Yes Optional Soft
Let us illustrate the cases of deadline of Table 2.
Assume that a book has been reserved in the library
by a borrower. This borrower must issue the book
within three days of its return otherwise the
reservation is cancelled. In other words, there is a
hard deadline as follows:
Issue reserved book within 3 days of return.
Now, let us consider a soft deadline. In our library,
if a book is returned late than a fine is imposed:
Return book within 7 days but impose a fine for
late return
We illustrate the remaining two forms of deadline by
considering the course of action, Register Borrower:
Conditional Hard deadline: registration is free up
to 31 July. It is possible not to do a registration
(unlike the first row) but if done then it must be
before 31 July.
Conditional Soft deadline: registration is free up
to 31 July but with a fine after that.
5 BOGm
Whereas BIGm defines the set of concepts for
business governance, the Business Operational
Governance model, BOGm, considers governance of
the business in operation. It deals with the
realization, in the business, of BIGm.
The instantiation of BIGm is shown in Table III.
However, we introduce in BOGm, the notion of
roles found in business process modelling (OMG,
2009) as shown in Figure 5. The Organization
Structure Model, OSM, (OMG, 2006) provides a
way to associate organization responsibilities with
business functions. We intend to use this for
business rules elicitation in future work.
Table 3: Instantiation of BIGm.
BIGm Concept BOGm Concept
Course of action Business function
Atomic course of action Atomic business function
Complex course of action Complex business function
Enablement Invocation
Acceptance Criterion Business Criterion
Govern Business rule
When the business rule cardinality is 1:1 then we
get an atomic business function. In other words, if
there is exactly one business rule governing a
business function then the function is atomic.
Further, a function is atomic only if there is exactly
one business rule governing it. A complex business
function includes other business functions.
Therefore, there is more than one business rule
associated with it.
Figure 5: Business Operational Governance model.
Let there be three functions, issue service, return
service and reserve service. All these are atomic
business functions having business rules as follows:
if the service request is for issue book then
perform the issue service
if the service request is for return book than
perform the return service
if the service request is for reservation of a book
then perform the reserve service.
These three functions are components of a complex
business function, provide services which, in turn, is
governed by the three business rule of the three
atomic functions and any additional rules that may
apply to it.
Now, let us consider invocation that relates a
business function to another. Given two business
functions, Register Student as Borrower and Provide
Service, we see a business rule that the latter can
only be done after the former. This is a <course of
action, course of action> rule of section 3.
Typology of Business Rules
Though BOGm defines business rules, it does so in a
global way as an association of criteria with business
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
364
functions. We explore the notion of a business rule
more deeply here by developing a business rule
model.
Figure 6 shows, that the business rules model
treats the notion of a business rules as an aggregate
of business function and criterion. Criteria can be of
two types, condition and business function as shown
in Fig. 5.
When a business function executes, then it can
be the antecedent of another business function or it
can cause a state change. If this state change results
in the satisfaction of a condition then another
business rule may be activated. We model this latter
by the relationship ‘affects’ between condition and
function in Figure 6.
We illustrate the use of affects in an example
from the Stock Library course of action. Let there be
a minimum threshold for the number of copies of a
title that the library must keep. Let us be given a
business function, called Condemn Book, to remove
unusable/damaged books from the library. Now, we
know that not every condemnation of a book results
in reordering of material. Rather, reordering happens
when quantity on hand, q_o_h, falls below the
specified threshold level. Thus, the reordering rule is
as follows:
IF CONDITION q_o_h.LE. threshold THEN
reorderbook
This rule implies that the business relationship
between Condemn Book and Reorder Book is lost.
The relationship, affects, restores it. Consider the
following formulation
IF CONDITION damaged book THEN
condemn book
Affects(condemn book, q_o_h)
IF q_o_h .LE. threshold THEN reorder
book
Notice that the relationship between Condemn Book
and q_o_h is articulated by the Affects statement.
Let us now consider the different types of
business rules introduced in Fig. 6. In this
presentation we tacitly assume the IF-THEN
representation of business rules. To distinguish
between a condition/function in the IF part we use
the two keywords CONDITION and FUNCTION
respectively.
5.1 Atomic Business Rules
An atomic business rule is one whose consequent is
anatomic business function (see Fig. 4). An example
of an atomic business rule is as follows:-
IF FUNCTION valid borrower AND number_
issued .LT. max THEN Give Book
In this rule, the consequent, Give Book, cannot be
decomposed any further.
Figure 6: The Model of Business Rules.
5.2 Complex Business Rules
A complex business rule is a meaningful collection
of simpler business rules. There are three kinds of
complex business rules, namely 1) Bunch, 2)
Transitive, and 3) Aggregate.
1. Bunch: A bunch is a named collection of business
rules having a common kind of antecedent. For
example, consider the collection as follows:
BUSINESS RULE NAME: register borrower
IF CONDITION borrower type =
‘student’ THEN register student-
borrower
IF CONDITION borrower type =
‘teacher’ THEN register teacher-
borrower
IF CONDITION borrower type =
‘administrative’ THEN register admin-
borrower
All these check the same variable. They form a
bunch of business rules named Register Borrower.
2. Transitivity: It is possible to construct complex
business rules using the notion of transitivity. There
are two ways in which transitivity arises, through
FUNCTION–FUNCTION transitivity and through
the affects relationship. Let a1, a2, and a3 be
business functions then the following holds:
(IF a1 THEN a2) AND (IF a2 THEN a3)
implies (IF a1 THEN a3)
The implication,
IF a1 THEN a3 is a complex
business rule built over two simpler ones. As an
example, consider the transitive rule,
IF FUNCTION registration request
THEN provide services
Its structure is as follows:
BusinessRulesforBusinessGovernance
365
BUSINESS RULE NAME: service borrower
IF FUNCTION registration request
THEN register borrower
IF FUNCTION register borrower THEN
provide services
Second, the notion of transitivity can be
extended to include the ‘affects’ relationship:
(IF a1 THEN a2) AND Affects (a2, c2)
AND (IF c2 THEN a3) implies (IF a1 THEN
a3)
Again, the implication, IF a1 THEN a3 is a
complex business rule.
3. Aggregate: An aggregate is a named collection
of business rules meeting a business governance
objective. It is a rather loose collection that is not
constrained by the norms of the other complex
business rules. So long as the governance objective
is met, an aggregate is defined. An example is as
follows:
BUSINESS RULE NAME: manage user
IF FUNCTION registration request
THEN register user
IF FUNCTION deregistration request
THEN deregister user
Manage user is a governance objective and the
two rules above are both relevant to this objective.
We say that Manage user is an aggregate of Business
rules.
5.3 Abstract
An abstract business rule is a generalization of
other business rules. This generalization can occur
when the business object of the antecedent and/or
consequent enters into generalization/specialization
relationship with other business objects. An example
of an abstract business rule is as follows:
BUSINESS RULE NAME :issue book
IF valid borrower AND number issued
less than maximum THEN give book
Generalization of
BUSINESS RULE NAME : issue book
student
IF valid student borrower AND number
issued less than student maximum THEN
give book
BUSINESS RULE NAME : issue book
teacher
IF CONDITION (valid teacher borrower
AND number issued less than teacher
maximum) THEN give book
Here, the business object, borrower, of the
antecedent can be specialized into student borrower
and teacher borrower respectively. This gives rise to
the two specialized rules.
6 COMPARISON
Our proposal is to introduce a Business level on top
of the CIM level. BOGm populates this layer and
reveals a number of features of business rules from
the perspective of business people.
Table 4 contains a feature analysis of BOGm with
SBVR(OMG,2008), ACE(ACE, 2003), and
RECON(Barkmeyer,2013) of the CIM level. The
first column of this table contains the features of
BOGm obtained from Figure 5. The rest of the
columns indicate the presence of the BOGm feature
in SBVR, ACE, and RECON respectively.
Table 4: Feature analysis of BOGm.
S. No. BOGm SBVR ACE RECON
1 Atomic business
rule
Yes Yes Yes
2 Complex
Business Rule
No No No
2 a Bunch No No No
2 b Aggregate No No No
2 c Transitive No No No
3 Abstract
Business Rule
No No No
4 Criterion Yes Yes Yes
4 a Condition Yes Yes Yes
4 b Function No No No
5 Necessity Yes No Yes
6 Validity No Yes No
7 Deadline No Yes No
It can be seen that BOGm provides a fairly rich
variety of business rules: atomic, three forms of
complex, and abstract business rules. The complex
and abstract business rules are not found in SBVR,
ACE, and RECON. To be sure, it is possible in these
approaches to separately express the abstract and
complex rules comprising the bunches, aggregates
and transitive rules. The notion of complex business
rules and abstract rules of BOGm provides the
hierarchical abstraction that binds these together.
However, the hierarchical abstraction of BOGm is
missing in SBVR, ACE, and RECON.
Now, let us look at the Acceptability criteria of
BOGm business rules (rows 4, 4a and 4b of the
Table IV). All approaches have the notion of
condition. In SBVR, this is realized through its noun
concept and as noun phrase in RECON. Now the
BOGm notion of a function as an acceptability
criterion is not found in SBVR, ACE or RECON.
This is because of the restriction of a criterion being
expressed as a noun concept or noun phrase
respectively.
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
366
The notion of necessity of row 5 of the table is
found in all approaches except ACE. It takes on the
form of modal operators in SBVR and RECON.
There is no notion of obligation in ACE. However,
validity (row 5) is not present in SBVR. It is
available in ACE . The situation with RECON is that
the basic grammar for its vocabulary provides
capability for date and time. However, the semantics
of these in business rules is not available in
(Barkmeyer,2013).
The last row of the table considers the
specification of a deadline in business rules of
BOGm. This notion is missing in SBVR and
RECON but is available in ACE.
7 CONCLUSION
Our proposal is to introduce a business layer on top
of the CIM layer. This helps us to focus on the
business nature of business rules. We picked up the
‘guides’ attribute to develop BOGm that populates
this layer. This model suggests that business
oriented business rules (a) govern not only courses
of action but their enablement too, (b) are not only
flat but also hierarchically structured, (b) have the
notion of validity which coupled with necessity
leads to deadlines for business rules. We have shown
that whereas necessity is an existing notion,
enablement, hierarchical structure, validity and
deadlines are specific features of business oriented
business rules.
In future, we intend to bring in other attributes of
the business layer in BOGm to make it
comprehensive. Thereafter, we shall look for a
representation system for business oriented business
rules and develop a BRMS.
REFERENCES
Attempto Controlled English (ACE), 2003, ver. 3, http://
web.science.mq.edu.au/~rolfs/papers/ifi99.03.pdf
Barkmeyer Ed, Neuhaus F.,2013, RECON - A Controlled
English for Business Rules, RuleML2013@Human
Language Technology, 7th International Rule
Challeng, Seattle, USA
Dubauskaitė R., Vasilecas,O. 2009, “An open issues in
business rules – Based information system
development”,Innovative Info -Technologies For
Science, Business And Education, Vol. 1.pg,77-91.
Gaweł B., Skalna I., 2012., “Model driven architecture
and classification of Business rules modelling
languages”, Conference on Computer Science and
Information Systems p.g.94-,952.
Gang X., 2009, Business Rule Extraction from Legacy
system Using Dependence-Cache Slicing, The 1st
International Conference on Information Science and
Engineering, 4214-4218.
Kardasis P., Loucopoulos P., 2004, Expressing and
organizing business rules, Information and Software
Technology, 701–718.
OMG, 2003, Model Driven Architecture, available at,
http://www.omg.org/mda/specs.htm
OMG, 2011, Business Motivation Model, available at
http://www.omg.org/spec/BMM/1.1/
OMG, 2006, Organization Structure, Meta-Model(OSM),
2nd Initial Submission, available at,
www.omg.org/cgi-bi/bim/09-08-02
OMG, 2009, Business Process Modeling Notation, ver.
1.2, available at,http://www.omg.org/spec/BPMN/1.2
OMG, 2008, Semantics of Business Vocabulary and
Business Rules (SBVR), v1.0, available at http://
www.omg.org /spec/SBVR/1.0/PDF
Prakash N., Deepak S., Deepika, Singh D., 2013, A
Framework for Business Rules, accepted in RiGIM,
Springer LNCS.
Prakash N., Chaturvedi A K., 2010, Representing Analysis
Models For Alignment, IEEE Proceeding of Fourth
International Conference on Research Challenges in
Information Science (RCIS,),p.g. 204-214.
Ross R. G. (ed.) November 1, 2003, Business Rules
Group, Business Rules Manifesto The Principles of
Rule Independence, Version 2.0, available at
www.businessrulesgroup.org/brmanifesto.htm
Rosca D. Greenspan S., 1997, A Decision Making
Methodology in Support of the Business Rules
Lifecycle, Requirements Engineering, 3
rd
IEEE
International Symp. on Requirement Engineering.
pp.236,246
Sriganesh S., Ramanathan C., 2012,Externalizing Business
Rules from Business Processes for Model Based
Testing, IEEE proceeding of ICIT, p.g. 312-318 .
Wang X., Sun J., Yang X, He Z., Maddineni S., 2004,
Business Rule Extraction from Large Legacy Systems,
IEEE Proceeding of the Eighth European Conference
on Software Maintenance and Reengineering,p.g.249-
258.
BusinessRulesforBusinessGovernance
367