Thesis Jodocus Deunk 2012

Radboud University Nijmegen
Guiding the
Business Rules
specification
process
How can we guide users in the process of business rule specification with
RuleSpeak?
Information Science
Jodocus Deunk
Supervisor: Dr. S.J.B.A. (Stijn) Hoppenbrouwers

Second supervisor: Dr. P. (Patrick) van Bommel
Thesis number: 166 IK
Guiding the Business Rules specification process
Preface
This master thesis is my final academic step before receiving the Master of Science degree.
During the last 2 years I became familiar with the area of Business Rules. It all started with the
Business Rules course at Radboud University Nijmegen and continued in the Business Process
Design course at Stockholm University.
During these courses, all the tools we used a strongly focused on skilled users. Skilled in both
the application and writing the rules. With this background knowledge a perfect subject for
this thesis was born.
Right now, one year after starting my master I finished this thesis. Because it all started with
his enthusiasm during the course I would like to thank Dr. Stijn Hoppenbrouwers. Certainly
also because of his guidance during this thesis project. We didn’t have that many meetings,
but in our meetings we always had a good discussion which helped me further in the process.
The process of writing a thesis can be hard, also for me. It was all depending on my own
motivation to spend time on working on this document. Especially when I started part-time
work my focus shifted to the wrong side. I assume the warnings of my girlfriend and family
helped. Thanks for helping refocusing.
Now it’s time to focus on new challenges, starting a fulltime job an extend my knowledge and
experience.
I hoop you will enjoy reading this thesis and playing with the Business Rule Guidance Tool
(BRGT).
Jodocus Deunk
June, 2012
2
Jodocus Deunk, Student Information Science
Abstract
Rules are everywhere, on campus, traffic rules, laws, games. Also in Businesses there are rules.
To maintain and write correct rules users can use a rule editor. The two methods: ‘Semantics
of Business Vocabulary and Business Rules’ (SBVR) and RuleSpeak make it possible to use the
tools to write pretty consistent rules because all aspects of the rule itself are available.
Because of the experience with RuleSpeak this method is used for developing a tool guiding
the user during the specification process. Current Business Rule editors seems to be developed
for more advanced users, where guidance isn’t is a big thing.
Before creating this Business Rule Guidance Tool (BRGT) a literature study has been done to
create a view on the concepts of Business Rules and the steps in the process of creating a
business rule. These steps are then integrated in BRGT. Also literature on the topic of asking
questions and guidance is investigated for aspects that can be added to BRGT.
The best way a tool like BRGT can work is working with small steps. With small steps a user can
focus on the various problems of creating a rule.
The outcome of this research can be used for further research in guidance and the topic of
asking questions, as well as the topic of Business Rules.
3
Table of Contents
PREFACE ................................................................................................................................................ 2
ABSTRACT .............................................................................................................................................. 3
1 INTRODUCTION ............................................................................................................................. 6
1.1 RESEARCH QUESTION ........................................................................................................................ 6

1.2 METHOD ........................................................................................................................................ 7
1.3 RELEVANCE ..................................................................................................................................... 7
1.4 RESULTS ......................................................................................................................................... 7
2 BUSINESS RULES, THE CONCEPT .................................................................................................... 8
2.1 DEFINITIONS ................................................................................................................................... 9

2.2 BUSINESS RULES IN THE ORGANIZATION .............................................................................................. 10
2.3 SEMANTICS OF BUSINESS VOCABULARY AND BUSINESS RULES................................................................. 11
2.4 RULESPEAK ................................................................................................................................... 11
2.5 COMPARING SBVR AND RULESPEAK ................................................................................................. 13
2.6 CHOICE FOR A BUSINESS RULES STANDARD ......................................................................................... 13
3 BUSINESS RULES, THE SPECIFICATION PROCESS........................................................................... 15
3.1 CREATING A NEW BUSINESS RULE ..................................................................................................... 15

3.2 REQUIREMENTS ON A BUSINESS RULE ................................................................................................ 16
3.2.1 Do’s and don’ts ..................................................................................................................... 16
3.2.2 Grammatical requirements................................................................................................... 17
4 GUIDING THE SPECIFICATION PROCESS ....................................................................................... 19
4.1 HELPING ...................................................................................................................................... 19

4.2 RULE EDITORS ............................................................................................................................... 20
4.3 PRE-DEFINED PROCEDURES .............................................................................................................. 20
4.3.1 Select the main item ............................................................................................................. 21
4.3.2 Converting main item into subject ........................................................................................ 21
4.3.3 Choose relevant rule-type ..................................................................................................... 21
4.3.4 Write the statement ............................................................................................................. 22
4.3.5 Optional: add (a) condition(s) or qualification(s).................................................................. 22
4.3.6 Define terms ......................................................................................................................... 22
4.4 QUESTIONS................................................................................................................................... 23
4.5 SUMMARY .................................................................................................................................... 24
5 BRGT ........................................................................................................................................... 25
5.1 THE WIZARD ................................................................................................................................. 25

5.1.1 Validating the main item ...................................................................................................... 26
5.1.2 Enter a condition................................................................................................................... 26
5.2 THE SETUP .................................................................................................................................... 27
5.3 APPLICATION SOFTWARE AND DATABASE ............................................................................................ 28
6 CONCLUSION ............................................................................................................................... 29
6.1 SUB-QUESTIONS ............................................................................................................................ 29

6.1.1 What does the process of business rule specification look like? ........................................... 29
6.1.2 In which way can instructions or focused questions guide this specification process? ........ 29
4
6.1.3 Which other kind of guidance’s are needed to guide the users in the specification process?
30
6.2 RESEARCH QUESTION ...................................................................................................................... 30
6.3 FUTURE WORK............................................................................................................................... 31
7 LITERATURE ................................................................................................................................. 32
I. APPENDIX A – CODE PREVIEW BRGT ........................................................................................... 34
II. APPENDIX B – DATABASE OVERVIEW .......................................................................................... 35
III. APPENDIX C – BRGT ..................................................................................................................... 36
5
1 Introduction
We all know there are some regulations in our life. Very strict rules or rules based on trust and
a reasonable way of thinking. Regulations are often expressed by rules: traffic rules, library
rules, university rules and laws: all kind of rules to regulate a specific domain.
1.1 Research question

With the upcoming use of computer systems for regulation in organizations also the
manageability of these rule sets became more important. In the beginning of the computer
age always technical programmers were needed to implement some rules in a computer
system, nowadays, for example because of agility, the business itself wants to be more in
control.
Methods like RuleSpeak were introduced to write the rules in a way the business could
understand them because they became plain English instead of the programming code written
by the technicians. Still, business people can’t write the rules themselves without any help of a
specialist. Mostly during some interactive sessions with a specialist the business people get
used to write rules according to the RuleSpeak standard, but there is no real guidance available
as a method.
Koen Derks, a former classmate and Jeffrey Schoenmakers: also an old Radboud student, did
some research in Business Rules creation and in the end Koen came-up with the BRAT tool, a
Business Rules Authoring Tool. This tool is helping the user with writing a rule according to the
RuleSpeak grammar.
Although Koen’s tool helped create rules according to the RuleSpeak grammar specification
still a lot of knowledge of the RuleSpeak method was needed. Therefore this thesis will focus
on the guidance of users during the specification process to end up with a rule created with
almost no knowledge of the RuleSpeak method.
How can we guide users in the process of business rule specification with RuleSpeak?
To answer this research question three sub-questions need to be answered.
1. What does the process of business rule specification look like?
2. In which way can instructions or focused questions guide this specification process?
3. Which other kind of guidance are needed to guide the users in the specification
process?
6
1.2 Method
To answer the research questions the research
process can be seen as the diagram on the right.
Implement Define need
Not the traditional Waterfall like model is used. By in BRGT for topic
seeing the research process as a circle, fixation on
one topic or solution is avoided. Some of the
background topics were already clear (focused
questions and instructions), but as the project
progresses others may needed.
Background
On the other hand the circle can be used as an Research
ongoing process. Hence, some boundaries are
needed. These limitation means the focus will be
only on the rules and writing the rules. For example terms are included in rules, but no explicit
research will be done in this area.
In the end the thesis will provide the outcomes of this research project, including the view on
the future work needed in this research area.
1.3 Relevance
In the first meeting with my supervisor Stijn several topics were discusses. One of these topics
was Koen Derks ‘s thesis. Because I followed the Business Rules course with him we both
mentioned the need for help during the use of the RuleSpeak method.
I still mentioned some need for help during the process. Koen ‘s application did help with
writing rules according to the RuleSpeak method but users still need some knowledge about
the method.
Talking to my supervisor we concluded some guidance during the specification process would
be a next step in transfer the management of rules to the business.
1.4 Results
The result of this research project will be a model for guidance during the specification process
and a proof-of-concept where this model will be implemented in. This proof of concept can be
used as a test mechanism to verify the model or to optimize it.
Before ending this project with the model and a proof of concept research needs to be done in
the area of business rules and how to guide the specification process.
7
2 Business Rules, the concept

There has always been a need for regulation of systems; therefore De Leeuw introduced the
Control Paradigm, which added a Regulation System to the Target System (De Leeuw, 1979).
Business Rules are one of the mechanisms to regulate this system and have their roots in
Artificial Intelligence. They can be seen as analogues to sports: a sports game consists of terms,
facts, rules and procedures. Looking at businesses you can see the similarity (Ross R. G., My
Story: To Play the Game You Need Rules) . Also within businesses these elements are visible.
Therefore doing business can be compared with playing games. Like in sports games business
rules are used to influence the behavior of the business (Ross R. G., 2003).
Systems analysts have been working for a long time on describing businesses in terms of
structure of data, and use of data. With the introduction of Business Rules there was a way to
handle constrains on this data (Hay & Anderson Healy, 2000). Mostly rules where forgotten or
seen as informal. During the design period of a system, rules were not integrated but put in
the programming code, so in one of the final stages of the project. Also, rules concerning
business processes are documented often, but general rules are not formally written down.
(Ross R. G., 2005)
Over time two methods became more and more popular: SBVR (Semantics of Business
Vocabulary and Business Rules) and RuleSpeak. This chapter is not meant as a deep archive
with a complete description of the two methods, but will focus on the main concepts and
differences between the two mentioned methods.
The fundamentals of the Business Rules Approach are collected in the Business Rules
Manifesto. These fundamentals are translated in several languages and are a result of all the
work the Business Rules Group (BRG) did since the 1980’s. (Ross R. G., 2003) (OMG, 2008)
The BRG came up with 10 articles describing what a business rule should do. Beside these 10
articles alse the Business Rule Mantra needs to be mentioned: “Rules build on facts, facts build
on concepts as expressed by terms”.
8
Article 1: Primary Requirements, Not Secondary
Article 2: Separate From Processes, Not Contained In Them
Article 3: Deliberate Knowledge, Not A By-Product
Article 4: Declarative, Not Procedural
Article 5: Well-Formed Expression, Not Ad Hoc
Article 6: Rule-Based Architecture, Not Indirect Implementation
Article 7: Rule-Guided Processes, Not Exception-Based Programming
Article 8: For the Sake of the Business, Not Technology
Article 9: Of, By and For Business People, Not IT People
Article 10: Managing Business Logic, Not Hardware/Software Platforms
2.1 Definitions
There is no one definition of what a business rule is. Only the Business Rules Group has already
two definitions, one from a business perspective and one for the information system
perspective. But generally the Business Rules Group says:
“A business rule is a statement that defines or constrains some aspect of the business. It is
intended to assert business structure or to control or influence the behavior of the business. The
business rules which concern the project are atomic ~ that is, they cannot be broken down
further.” (Hay & Anderson Healy, 2000)
With the two additions for the different perspectives:
From a business perspective

“it pertains to any of the constraints that apply to the
behavior of people in the enterprise, from restrictions
on smoking to procedures for filling out a purchase
order.”
From an information system

“it pertains to the facts which are recorded as data
perspective
and constraints on changes to the values of those
facts. That is, the concern is what data may or may
not be recorded in the information system.”
The definition of the Object Management Group (OMG) is a bit smaller and says: "… a rule that
is under business jurisdiction". Where Business Jurisdiction is explained as “Under Business
jurisdiction” is taken to mean that the business can enact, revise, and discontinue the business
rule as it sees fit” (Ross R. G., 2005)
9
The definition of a business rule I will use during my thesis project is the definition of the
Business Rules Group:
“A business rule is a statement that defines or constrains some aspect of the business. It is
intended to assert business structure or to control or influence the behavior of the business. The
business rules which concern the project are atomic ~ that is, they cannot be broken down
further.”
But because I think Business Rules should always come from the business side I’ll use the
definition of the OMG as an addition on the Business Rules Group definition.
"… a rule that is under business jurisdiction."
2.2 Business Rules in the organization

Not only rules are regulating the businesses organization, there are also policies, standards and
procedures. In his thesis Jeffrey Schoenmaker (Schoenmaker, 2010) did some research and
positioned the Business Rules in a company with the use of a small model, based on a security
policy model (The ISO27k FAQ).
Policies
Standards
Business Rules
Procedures
With the following definitions for the terms:
Policies Guidelines which create and support the

company’s philosophy
Standards Detailed rules describing the execution of the

policies
Business Rules Strict rules limiting the freedom of action to

meet the requirements described in the
standards
Procedures Detailed steps to implement and execute the

formulated Business Rules
10
So Business Rules are positioned between the Business standards and Procedures meaning
they (Business Rules) are written with the Business Standards in mind and shaping the
procedures of the business.
One of the main problems in businesses is the link between business people and IT people.
Both are talking in their own terms and use different references. Although there is IT involved
in creating business rules companies can’t just hire an (IT) employee with business rule
experience. Besides the knowledge of business rule also the knowledge of the company itself is
needed in the specification process.
2.3 Semantics of Business Vocabulary and Business Rules

In 2008 the Object Management Group (OMG) introduced the Semantics of Business
Vocabulary and Business Rules (SBVR), a standard for Business Rules. According to the
Business Rules Community there are three basic elements in the name, namely Semantics,
Business Vocabulary and Business Rules (BRCommunity, 2005).
Semantics of Business Vocabulary and Business Rules (SBVR) is a basis for creating business
rules in a semi-natural language. To realize this, a subset of the English grammar has been
taken. SBVR has two fundamental rule types: behavioral rules and definitional rules, also
known as operational and structural rules. (OMG, 2008)
Because SBVR has also part of formal logics in it, a rule is always a proposition. This formal
logics is not meant for business people but for discussing the semantic structures underlying
business communications of concepts, facts, and rules. An example concerning this: “a typical
business person does not tend to talk about quantifications, but he expresses quantifications in
almost every statement he makes. He doesn’t tend to talk about conjunctions, disjunctions,
logical negations, antecedents and consequents, but these are all part of the formulation of his
thinking. The vocabulary in this clause is for talking about these conceptual devices that people
use all the time” (OMG, 2008).
Characteristics of SBVR are (OMG, 2008):
 Using Prefix notation: this means the operators stand in front of the sentence or
formula. Example: “ +X Y”
 Selected set of Keywords: a limited set of keywords is available
2.4 RuleSpeak
In 1996 Ronald G. Ross started a project which resulted in the RuleSpeak standard. This set of
guidelines is now available in English, Spanish, German and Dutch (Business Rule Solutions).
RuleSpeak is developed for end-users, easy to notice in their slogan “let the business people
speak rules!” Therefore the rules written using the RuleSpeak guidelines are a bit easier to
read and understand.
The constructions of SBVR Structured English can be used in RuleSpeak, but RuleSpeak embeds
equivalent keywords within the propositions themselves (mix fix).
11
In RuleSpeak there is a distinction between structural rules and operative rules. These are
viewed as follows (Ross R. G., 2005):
 Structural rules prescribe criteria for how the business chooses to organize
(“structure”) its business semantics. Such rules express criteria for correct decisions,
derivations, or business computations. Structural rules supplement definitions.
 Operative business rules focus directly on the propriety of conduct in circumstances
(business activity) where willful or uninformed actions can fall outside the boundaries
of behavior deemed acceptable. Unlike structural rules, operative rules can be violated
directly.
Characteristics of RuleSpeak are (OMG, 2008):
 Using Infix notation: this means the operators stand in-between the sentence or
formula. Example: “X + Y”
 Essence by definitions, boundaries by rules
 Concept completely focused on the business
12
2.5 Comparing SBVR and RuleSpeak

Main difference between SBVR and RuleSpeak is the difference in bounding the way terms are
expressed. RuleSpeak is more business oriented and keeps the description of terms open to
the user, while SBVR is more delimited.
The difference in the rules themselves is displayed in the table below:
Modal claim type Statement form SBVR Structured RuleSpeak keywords

English keywords
obligation ‘obligate statement’ it is obligatory that p r must s

formulation form
obligation ‘prohibitive it is prohibited that p r must not s
formulation statement’ form
embedding a logical
negation ‘restricted it is permitted that p r may s only t
permission only if q
statement’ form
permissibility ‘unrestricted it is permitted that p r may s
formulation permission r need not s
statement’ form
Necessity
formulation ‘necessity statement’ it is necessary that p r always s
form
necessity formulation
embedding a logical ‘impossibility it is impossible that p r never s
negation statement’ form
‘restricted possibility It is possible that p r can s only t

statement’ form only if q
Possibility
formulation ‘unrestricted it is possible that p r sometimes s
possibility statement’
form r can s
(OMG, 2008, p. 345)
2.6 Choice for a Business Rules standard

In this chapter three movements are discussed. Before continuing with discussing the separate
parts a business rule, first we need to choose the method we’ll use in the further process.
During the further process of this research RuleSpeak will be used as a method. Although the
methods are close to each other, the choice for one method was rather easy.
The choice for RuleSpeak is mainly based on the experience with the RuleSpeak method by me
personally and my supervisor. Also the application Koen Derks developed within in thesis
project is based on the RuleSpeak method. Extending his functionality choosing another
method would be a bit suboptimal.
13
Choosing a specific method for this research is not limiting further research because
transformation between SBVR and RuleSpeak is possible.
14
3 Business Rules, the specification process

Now we know what a business rule is and what different kind of methods are out there. This
chapter provides more information on the specification process and the requirements on a
good business rule according to the chosen method: RuleSpeak.
3.1 Creating a new Business Rule

Starting with Business Rules writing your own rules (guided with the needed guidelines and
tooling) is the easiest way to get into it. Because there is no background knowledge yet, the
rules will be written in a clear way and as a writer you’re not aware of the complex
possibilities.
Koen Derks (Derks, 2011) wrote in his thesis about the process of creating a business rule,
party based on his experience during his work as a student assistant in the Business Rules
course he came up the following steps:
1. Select the topic for the rule

2. Make sure to understand what needs to be regulated with the soon be created
Business Rule
3. Evaluate stability of the rule: Fundamental or transient
4. Select one of the keywords which will fit the level of strictness
5. Write the rule
Koen also made a graphical representation of these steps:
Understand Define Select keyword

Validate rule as
Select topic the goal of the strictness of according to Write the rule
a Business Rule
new rule the rule guidelines
After writing the rule the rule must be validated. Ronald G. Ross made a list (Ross R. G., 2007)
of criteria for a rule making it a business rule:
1. The rule must be actionable (e.g. “A hard hat must be worn in a construction site”).
2. The rule must be about the business, not about either a knowledge/data-recording
system that supports the business, or a platform used to implement such a system.
3. The rule must be expressed in the language of the business.
4. The rule must be under business jurisdiction.
5. The rule must tend to remove a degree of freedom.
With only the steps and validation of the criteria you’re not done yet. You also need to define
the used terms and maybe there is also a need for a model expressing the rules.
15
3.2 Requirements on a Business Rule

What are the requirements on a Business Rule according to the RuleSpeak method? There are
some distinctions made and 4 types of rules have been defined.
Besides this there is some information provided by Business Rule Solutions, a Business Rule
Technique Company. These do’s and don’ts will also be discussed in this paragraph. I end this
chapter by shortly mention the grammar of a Business Rule. More information on that can be
found in the thesis of Koen Derks (Derks, 2011).
The main distinction in RuleSpeak is between structural and operative rules. Operational rules
can be violated directly because they focus on the propriety of conduct in circumstances
where actions are outside boundaries accepted by the organization. Structural rules focus on
criteria for making decision, derivations or computations by prescribing the way businesses
choose to organize their business semantics.
Another distinction of RuleSpeak rule types is guidelines, computations, action enablers and
inference ( Halle, 2001).
1. Guideline: The person executing the rule has freedom of choice in whether or not to
follow the rule.
2. Computation: This rule gives a formula for calculation which will lead to a business
decision.
3. Action enablers: The conditions of the situation will be checked with this rule. Based
on the check other business events will be initiated.
4. Inference: This rule also checks the conditions, instead of events, new facts will be
introduced.
3.2.1 Do’s and don’ts

Based on Business Rules Solutions came up with the do’s and don’ts for setting up proper
business rules (Business Rule Solutions, 2009).
1. Business Rules Statements should be 14. Non-numeric subjects for numeric

non-procedural thresholds is not good
2. Business Rules should be not be 15. Missing subjects are not good
inscrutable 16. Imperatives are not good
3. Enforcement and evaluation are 17. Non-specific qualification is not good
separate concerns 18. Conjunctions are often not good
4. Omitting a Rule Keyword is not good 19. “Etc.” is not good
5. “Can” is not good 20. Twosome words are not good
6. Extra words for emphasis are not good 21. Embedded numbers are often not
7. Free form is not good good
8. “To have” is often not good 22. Embedded calculations are not good
9. Missing Facts are not good 23. Embedded conditions are often not
10. Starting with “if” is not good good
11. Starting with a timeframe is not good 24. Explicit mention of processes is usually
12. Plural subjects are not good not good
13. Actors subjects are frequently not 25. CRUD is not good
good 26. “When” is often not good
16
3.2.2 Grammatical requirements

In the documents describing the RuleSpeak sentence forms some example tables of the
allowed RuleSpeak sentence forms are given (Ross R. , 2009). These tables can be used by
people who will probably understand the sentence forms. In order to have a software
application understand the sentence forms a more abstract version is needed.
Based on table 2 of the RuleSpeak Sentence Forms document Stijn Hoppenbrouwers made a
version (Hoppenbrouwers S. , 2011) describing the sentence forms in a shorter, more
computer technical way.
First part Keyword(s) Second part Keyword(s) Third part
SUBJ May STATE

SUBJ Need not STATE
SUBJ Need not STATE if COND
SUBJ MUST STATE
SUBJ MUST STATE when COND
SUBJ Must be computed as COMP
SUBJ Must be computed as COMP when COND
SUBJ Must be considered TYPE
SUBJ Must be considered TYPE if COND
SUBJ Must be performed when COND
SUBJ MUST NOT STATE
SUBJ MUST NOT STATE if COND
SUBJ MUST NOT be computed as COMP
SUBJ MUST NOT be computed as COMP when COND
SUBJ MUST NOT be considered TYPE
SUBJ MUST NOT be considered TYPE when COND
SUBJ MUST NOT be performed when COND
SUBJ May STATE only if COND
Table: RuleSpeak grammar
Some explanation of the shortenings this table is needed:
Shortening Description
17
Shortening Description
STATE Any description of a state:
 a/an NOUNSING
 a/an ACOND NOUNSING
 a/an NOUNSING CONDFN
NOUNCING Any singular noun phrase
ACOND Any adjective phrase expressing a specific

state or property of the “NOUNSING”
relevant as a condition
CONDFN Any STATE description applying to the

“NOUNSING”
COMP Any expression of a computation
SUBJ  a/an NOUNSING (NOUNSING simply

stand for singular noun phrase)
 a/an ACOND NOUNSING (ACOND
stands for “adjectival condition”)
 a/an NOUNSING CONDFN (CONDFN
stands for “condition following
noun”)
COND  if STATE
 when STATE
18
4 Guiding the specification process

Now we know what Business Rules are, what they look like and in short what the process looks
like. In this chapter the process itself and guiding during this process, is the main subject. This
chapter starts with answering the question ’What’s guidance?’. After that more is said about
the guidance in current tools. This chapter ends with some examples how a tool can guide
during the specification process.
4.1 Helping
As guiding is the topic of this thesis, first we take a look at the definition of guiding. Where
guiding can be used in many ways, this thesis uses the following definition (Van Dale, 2002),
translated from the Dutch ‘leiden’: “in een bepaalde richting of toestand brengen” as a
foundation:
Bring into a particular direction or state.
This definition speaks about a particular direction or state: the outcome of the guidance and or
the Business Rule itself. Because this definition says nothing about helping I would like to
change this definition to:
Help to bring into a particular direction or state.
Now the question rises what ‘help’ can be in this context. In the first chapter I argued that for
some cases, interactive group sessions with a facilitator are still needed to help write the rules
according to a standard like the RuleSpeak method.
Bostrom, Anson and Clawson (Bostrom, Anson, & Clawson, 1993) define these group sessions
as:
a meeting is an interaction that utilizes a set of resources (people, technology) to

transform the group's present problem state into its desired future state
(accomplishing specific meeting outcomes) through a series of action steps (agenda).
When building a tool to guide the specification process the tool should be able to help during
these sessions. Because the process of writing rules often is an individual process, we disregard
group sessions and focus on individual guidance. More on the group sessions can be found in
“Fostering self-direction in participatory process design” (Prilla & Nolte, 2010).
Still, all aspects mentioned by Bostrom, Anson and Clawson are needed to accomplish the
outcome: a set of resources, a problem state and its desired future state and a series of action
steps.
In a guidance tool these needs can be translated into:
A set of resources The user of the guidance tool.
A problem state (Unstructured) rules in the organization.
19
Its desired future state Current Business rules according to the RuleSpeak method.
Series of action steps A set of procedures, questions and instructions.
4.2 Rule editors

Several editors are currently helping organizations manage their business rules. These so called
Business Rule Management Systems (BRMS) are focusing on defining, deploying, monitoring
and maintaining the complexity of decision logic used by operational systems within
organizations.
These rule editors mainly focus on entering data and therefore they require a high level of
knowledge about the used rule standard. Although these systems pretend to be the solution
for domain experts, these experts need to have special skills to work with these tools.
In 2005, Graham (Graham, 2005) made a detailed comparison of the most used BRM systems:
Blaze Advisor from Fair Isaac Inc., JRules from ILOG SA and HaleyAuthority from Haley Systems
Inc. In the comparison he reviewed the applications from both a business and a technical
perspective. With a decision table the reader can make an easy comparison.
Graham concludes with saying that none of the applications can be used without an initial
training. So besides the training for the Rule language there is also training needed to get
started with the tools.
Also Hoppenbrouwers, van Bommel and Jarvinen (Hoppenbrouwers, Bommel, & Jarvinen,
2008) observed that current modeling tools are mostly experts-oriented editors. Support of a
‘way of working’ may not be needed or even by experts wanted because they know the drill
and are aware of the output.
4.3 Pre-defined procedures

Prilla and Nolte (Prilla & Nolte, 2010) found out during their research in process design:
“flexibly applying predefined procedures leads to better results”. Also Andersen and Richardson
(Andersen & Richardson, 1997) found out splitting procedures into small micro-procedures
lead to a more flexible meeting and improves the outcome.
Also Hoppenbrouwers and Wilmont (Hoppenbrouwers & Wilmont, 2010) presented some
theoretical notions that are helpful in understanding why modeling performed by novice
modelers can usually be best broken down in sub-tasks.
Although the research of Prilla and Nolte is focusing on participatory process design the
concept of splitting tasks into micro-procedures can also be applied to this project.
Splitting procedures into smaller parts can easily combined with focus questions, because
focus questions are also used to narrow the total process down to smaller parts or focus on
smaller parts. Right now we call them process steps.
Koen Derks (Derks, 2011) defined the following steps of the specification process:
20
1. Select the topic for the rule

2. Make sure to understand what needs to be regulated with the soon be created
Business Rule
3. Evaluate stability of the rule: Fundamental or transient
4. Select one of the keywords which will fit the level of strictness
5. Write the rule
While converting the steps into a wizard kind of application I found out that Koen ‘s steps are
not easily transferable to guided steps, especially when focusing on the novice user.
Therefore I changed the list of steps and came up with the following ones:
1. Select the main item for the rule

2. Converting the main item into a subject
3. Choose the relevant rule-type
4. Write the statement
5. Optional: add (a) condition(s) or qualification(s)
6. Define the new terms
4.3.1 Select the main item

Selecting the main item of the rule means focusing on the subject of the rule. Because the
main item has no restrictions in any way it’s an easy way to write what the rule is about. No
knowledge of RuleSpeak is needed for this. The input can be used in further steps or
recognizing the rule afterwards.
4.3.2 Converting main item into subject

In the first step a main item for the rule is provided. Now the second step is to convert the not
restricted input of the main item into a valid subject according to the RuleSpeak method.
The RuleSpeak documentation (Ross R. , 2009) provides some restrictions on the subject. In
this step the user is asked to perform checks on these restrictions and also the application
itself is checking some of them.
Checks made by the applications are for example:
Check for: Input Check Return
Number $input If $input in (‘one’, ‘two’,.. ) False
Number $input If $input in (1,2,3,…) False
Singularity $input If lastlettersof($input) == ‘s’ OR ‘es’ False
4.3.3 Choose relevant rule-type

The outcome of this step is the second column of the sentence structure table
(Hoppenbrouwers S. , 2011): the first keyword(s).
21
Most Business Rules are using the keyword ‘MUST’: the common rule. Besides this common
rule there are 4 more specific rule-types: ‘Guidelines’, ‘Definitions’, ‘Computations’ and
‘Procedures’.
Rule-type Keyword(s) Example rule
Common-rule “MUST” “An order” MUST have a promised shipment

date.
Guideline “MAY” “An item” MAY be returned if some proof of

purchase is provided.
Definition “MUST be considered as” “A customer” MUST be considered high-risk if

the outstanding balance exceeds €500,- on each
of their last three successive invoices.
Computation “MUST be computed as” “A product’s cost” MUST be computed as the

sum of the cost of all products’ components.
Procedure “MUST be performed … The procedure ‘Send-Advance-Notice’ MUST be

when” performed for an order when the order is
shipped.
4.3.4 Write the statement

With use of the given input from the previous steps a question will be asked on the rule
statement. The answer of this question will be the body of the rule: the statement (second
part of the structure table (Hoppenbrouwers S. , 2011)).
Example:
Subject Rule-type Example question
A shipment Definition What should be the case for “A shipment”?
4.3.5 Optional: add (a) condition(s) or qualification(s)

Most of the rules include some qualification indicating the circumstances under which they
apply. It’s possible that the user already submitted the condition in their statement field. If so,
he’s able to mark the condition.
Some business rules only apply a some point(s) in time or under certain conditions. Therefore
multiple conditions can be added to the rule.
4.3.6 Define terms

Last step of the process is to define the used terms that are not yet defined. Terms already
defined in earlier rules are filled in already and can’t be changed at this moment.
22
Because terms can consist of multiple words the user is able to combine words to one term.
4.4 Questions
We now know we need to narrow down focus and split the rules into smaller parts. But what
kind of questions can we ask in the mentioned steps? The area of asking questions is an
extensive one, and time is limited. Therefore not a total research is performed on the topic of
asking questions but only some small parts are used in this thesis.
In the area of asking questions the WH-questions topic raises pretty quick, but as Ertseschik-
Shir (Erteschik-Shir, 1986) argues: only in a small number of cases the Wh-words help to focus
in questions, for example echo questions. Because in the process of understanding the input
in the BRGT application needs to be verified some of the WH-words can be used. Verification
of answers can be done with the Echo questions.
We use echo questions either because we did not fully hear or understand what was
said, or because its content is too surprising to be believed (Erteschik-Shir, 1986)
Overview of the WH-words used to inquire about specific information:
When? Time
Where? Place
Who? Reason
How? Manner
What? Object/Idea/Action
Which (one)? Choice of alternatives

Whose? Possession
Whom? Person (objective formal)
How much? Price, amount (non-count)
How many? Quantity (count)
How long? Duration
How often? Frequency
How far? Distance
What kind (of)? Description
Because only a question word like a WH-word is not enough to form a question-sentence, I
was looking for more background on the question-sentence topic. In a session with my
supervisor Stijn Hoppenbrouwers we discussed this and ended up with a table describing the
building blocks of a question sentence.
G Main question & utility
Q Question & Scope
F Description of answer
E Example
23
4.5 Summary
This chapter started with defining what guidance is. From the definition of Van Dale (Van Dale,
2002) guidance is defined as:
Help to bring into a particular direction or state.
In the second section of this chapter current rule editors are quickly analyzed for the way how
they implemented guidance. Both the conclusion of Hoppenbrouwers (Hoppenbrouwers &
Wilmont, 2010) and Graham (Graham, 2005) is that the current tools are designed for users
who are (highly) skilled in Business Rules.
Prilla and Nolte (Prilla & Nolte, 2010) found out that splitting advanced tasks into smaller steps
lead to a more flexible process and improves the outcome. Based on the research of Koen
Derks the steps of the specification process are defined and explained. The process consists of
6 steps, starting with selecting a main item for the rule and ending with defining the unknown
terms.
This chapter ends with a small section on how questions should be formulated. WH question
words where raising very quick when searching for background information. Research of
Ertseschik-Shir (Erteschik-Shir, 1986) concluded that WH questions are only useful in a small
amount of situations: Echo-questions. Because understanding what the input during the
specification is and use this input in further questions WH-words can be useful.
24
5 BRGT
In the previous chapters we have seen some ways to guide the Business Rule Specification
Process. The Business Rules Specification Process Guidance Tool (BRGT) is developed as a
concept tool to show how guidance can take place during the specification process.
The whole idea behind BRGT is that users should not need to care about the grammar but can
focus on the content of the rule.
BRGT can be found on the CD in Appendix III, and by typing the following URL in your web
browser: http://thesis.dataintegratie.com/
5.1 The wizard

The conclusion (Prilla & Nolte, 2010) and (Hoppenbrouwers & Wilmont, 2010) concerting
splitting up of procedures in micro-steps led to a wizard-like structure in the BRGT application.
The steps in the wizard are partly adopted from Koen Derks ‘s (Derks, 2011) steps. In the
application these steps are located in the top (blue bar) to show the user where in the process
he is.
By placing the user focus on the rule itself and not on the grammar the flow in the application
is pretty strict. By letting the users check their input and give the possibility to optimize their
input the strict lines are still usable.
Checking the input is done in several steps. Two examples: validating the main items and
entering a condition.
25
5.1.1 Validating the main item

The user entered a main item for the rule in the first step. Second step is converting this main
item into a valid RuleSpeak subject. Three items should be checked by the user:
 Is the subject NOT singular?

 Is the subject NOT a number?
 Is the subject NOT imperative?
Let the user check his/her input makes the user more aware of the RuleSpeak method and no
large databases need to be maintained, for example with all singular words in the English
language.
5.1.2 Enter a condition

Because the user is not an expert in Business Rules yet, a user can enter a condition in the
state. At some point in the wizard the user is asked if he already entered a condition or wants
to add one. If the user thinks he entered a condition already he can select it. In the end the
rule looks the same, but now the application can also recognize the text as a condition. This
can help the user or application in future use.
26
5.2 The setup

This model represents the wizard of the BRGT application.
27
5.3 Application software and database

The application is written in PHP code in combination with a MySQL database. Appendix Code
contains an example of the code.
The database contains two groups of data: application and rule data.
To make the wizard application flexible, steps, questions and fields are loaded in the database
and built up dynamically in the application.
The final rule is saved in a rule table. Because a rule can have multiple conditions, the
conditions are stored in a separate table.
By using the items defined in Hoppenbrouwers ‘s grammar table, the database can always be
used by other applications very easily.
28
6 Conclusion
This chapter is the final chapter of this thesis. With the answers of the sub-questions, which
are formulated in the beginning of this project, the main research question of this thesis
project can be answered. This chapter will complete with possible future work in the area of
guiding the Business Rule specification process.
6.1 Sub-questions
By answering the sub-questions the main question can also be answered. The sub-questions
are formulated in the beginning of the project.
6.1.1 What does the process of business rule specification look like?
Before anything can be said on the guidance during the Business Rule specification process,
first the specification process itself should be clear.
During his master thesis project Koen Derks (Derks, 2011) defined the so called road map of
creating a Business Rule. This road map consists of 6 steps, drawn as one arrow and are
designed for a user that has a typical rule authoring tool.
Select
Understand Validate
Define keyword
the goal of Write the rule as a
Select topic strictness of according
the new rule Business
the rule to
rule Rule
guidelines
As Prilla and Nolte concluded: splitting advanced tasks into smaller steps lead to a more
flexible process and improves the outcome. By analyzing Koen Derks his proof-of-concept the
process is then divided into the following (small) steps:
1. Select the main item for the rule

2. Converting the main item into a subject
3. Choose the relevant rule-type
4. Write the statement
5. Optional: add (a) condition(s) or qualification(s)
6. Define the new terms
6.1.2 In which way can instructions or focused questions guide this specification
process?
29
Both Hoppenbrouwers and Wilmont (Hoppenbrouwers & Wilmont, 2010) and Prilla and Nolte
(Prilla & Nolte, 2010) conclude that splitting complex processes into smaller task is better,
especially when the user is a novice modeler. Therefore the model of Koen is taken and
translated into a wizard where the user is guided during the specification process. Each step in
the wizard contains a question which is formulated with the already given input. All answers
together are used by the wizard to build the correct Business Rule.
The way questions are asked is very important in these steps. Questions should always contain
certain elements: the main question and utility, a question and scope, a description of the
answer and an example. Not always all elements can be put in one question, but one should
always aim for as much as possible. This will make a question more understandable and the
output more predictable.
6.1.3 Which other kind of guidance’s are needed to guide the users in the
specification process?
Pretty early during this thesis project the focus became the novice modeler: a user that is not
familiar with both the tool and the modeling language. Therefore the application BRGT is
focusing on the content of a business rule: where does the user want to write a rule about?
The number of grammar questions is minimized.
Besides focusing on the content of the rule also the use of already given information is guiding
the user. Easy functions like an autocomplete on the rule ‘s subject or terms are helping the
user choosing the right words.
6.2 Research question

Now all sub-questions are answered and summarized, the main research question of this
thesis can be answered. The main question of this thesis was as follows:
Everyone has a different level of knowledge about the business rules specification process.
Therefore its maybe hard to define one what to guide users during this process. Nevertheless
this research also delivered a guidance tool where some basic aspects of guidance are rooted
in.
First, in a complex process, users, and especially novel modeling users, are helped to solve the
problem by splitting the process into smaller tasks. These small tasks need to be fulfilled first
before the whole process can be finalized.
Second, by focusing on the content of the rule instead of the grammar the users first only has
to think about what to say with the rule and not how to solve the grammar issues. This leads to
some limitations for the more advanced users, but these users also need some other kind of
guidance. The novice modelers can almost see the effect of their choices to the business rule
real-time. Although the BRGT tool is not meant for learning the syntax of a specific Business
Rule method, the user can see the effect of their choices and learn from it.
30
At last the use of autocomplete functions helps users choosing the right words for parts of a
rule like the subject or terms.
The BRGT concept tool is based on the thought of splitting complex processes and focusing on
the content of a rule. In the end the user will walk through five or six steps. By seeing the result
of their input the user is able to learn from its input so in the future strict guidance like the
BRGT wizard is not needed anymore.
A sum-up of:
 Splitting the specification process into small steps

 Focus on the content of the rule, not the grammar
 Formulate clear (focused) questions
 Use already given input
6.3 Future work

This thesis resulted in a proof-of-concept tool (BRGT) where users are guided while specifying
Business Rules. This guidance in BRGT is mostly implemented by asking questions. Other kinds
of guidance like doing exercises or playing a game can also be linked to specifying Business
Rules.
BRGT is development as a proof-of-concept and only for specifying rules and terms in these
rules. This concept can be extended with linking terms, condition and rules to each other,
which will result in a more business-proof application.
In the area of asking questions there is also some work to do. A lot of research is done in
questionnaires, but not in how a question can really focus or guide the questioned person.
31
7 Literature
Halle, B. V. (2001). Business Rules Applied:Building Better Systems Using the Business Rules
Approach. Wiley.
Andersen, D., & Richardson, G. P. (1997). Scripts for group model building. System Dynamics
Review Vol. 13, No. 2, 107-129.
Bostrom, R. P., Anson, R., & Clawson, V. K. (1993). Group Facilitation and Group Support
Systems. In E. L. Jessup, J. Valacich, & V. Nostrand Reinhold, Group Support Systems:
New Perspectives.
BRCommunity. (2005). SBVR Speaks: The Key Notations of the SBVR Approach. Business Rules
Journal.
Business Rule Solutions. (2009). Basic RuleSpeak Guidelines - Do's and Don'ts in Expressing
Natural-Language Business Rules in English.
De Leeuw, H. (1979). On the concept of flexibility: a dual control perspective. Progr. Cybernet.
Syst. Res. S.
Derks, K. (2011). Creating a Business Rules Authoring Tool. Nijmegen: Radboud University.
Erteschik-Shir, N. (1986). Wh-questions and focus. Linguistics and Philosophy Vol. 9. Nr. 2, 117-
149.
ESLgold. (2010, 2 15). Wh - Questions. Opgeroepen op 01 20, 2012, van ESLgold:

http://www.eslgold.com/grammar/wh_questions.html
Graham, I. (2005). Service oriented business rules management systems. TriReme.
Hay, D., & Anderson Healy, K. (2000). Defining Business Rules - What Are They Really? the
Business Rules Group.
Hoppenbrouwers, S. (2011). RuleSpeak grammar. Nijmegen: Radboud University.
Hoppenbrouwers, S., & Wilmont, I. (2010). Focused Conceptualisation: Framing Questioning

and Answering in Model-Oriented Dialogue Games. Third IFIP WG 8.1 Working
Conference on the Practive of Enterprise Modeling (PoEM 2010).
Hoppenbrouwers, S., Bommel, P. v., & Jarvinen, A. (2008). Method Engineering as Game
Design-An Emerging HCI Perspective on Methods and CASE Tools. Workshop
Proceedings of EMMSAD 2008: Exploring Modeling Methods for Systems Analysis and
Design affiliated to CAiSE 2008, (pp. 97-111). Montpellier, France.
OMG. (2008). Semantics of Business Vocabulary and Business Rules v1.0.
Prilla, M., & Nolte, A. (2010). Fostering self-direction in paricipatory process design. 11th
Biennial Participatory Design Conference (pp. 227 - 230). New York: ACM.
32
Ross, R. (2009). RuleSpeak Sentence Forms - Specifying Natural-Language Business Rules in

English.
Ross, R. G. (2003). Principles of the business rule approach. Addison-Wesley Professional.
Ross, R. G. (2005). Business Rule Concepts.
Ross, R. G. (2007). Are all Rules Business Rules? Not! Business Rules Journal Vol. 8 No. 5.
Ross, R. G. (n.d.). My Story: To Play the Game You Need Rules. Retrieved 10 16, 2011, from
Ronald G. Ross: http://www.ronross.info/story.php
Schoenmaker, J. (2010). De rol van een editor. Nijmegen: Radboud University.
Van Dale. (2002). Van Dale Groot woordenboek hedendaags Nederlands. Utrecht / Antwerpen.
33
I. Appendix A – Code preview BRGT

The complete code of the application is provided on a CD. Nevertheless it can be interesting to
see a bit of the code of the application in this document.
The code below is used to determine the rule action. As said in the section on choosing the
relevant rule-type there are four options:
1. Computation
2. Guideline
3. Procedure
4. Consideration
Code:
function generateruletype($ruletype,$negative){
switch($ruletype){
case 'Computation':
$output = 'MUST be computed as';
if ($negative == true){ $output = 'MUST NOT be computed as';}
break;
case 'Guideline':
$output = 'may';
if ($negative == true){ $output = 'Need NOT';}
break;
case 'Procedure':
$output = 'MUST BE performed';
if($negative == true){ $output = 'MUST NOT BE performed';}
break;
case 'Consideration':
$output = 'MUST be considered as';
if ($negative == true){ $output = 'MUST NOT be considered as';}
break;
case 'Common':
$output = 'MUST';
if ($negative == true){ $output = 'MUST NOT';}
break;
}
return $output;
}
34
II. Appendix B – Database overview
The database consists of 8 tables. In the database there are two sections: the first one if for
the rules, terms and conditions. The second section is for the application itself: steps, fields
and texts. This appendix contains an overview of how the tables are related. The database is
also available on the CD.
From the database the user can extract an XML file with his/her rules. This XML file has the
following structure:
<rule set>
<email></email>
<rule>
<id></id>
<subject></subject>
<rule type></rule type>
<state></state>
<conditions>
<condition>
<id></id>
<condition body></condition body>
</condition>
</conditions>
</rule>
<rule>
…
</rule>
….
</rule set>
35
III. Appendix C – BRGT

Below a disc has been added containing the code and database of the BRGT concept. BRGT can
also be found on: http://thesis.dataintegratie.com/
36

Thesis Jodocus Deunk 2012

Uploaded by

Copyright:

Available Formats

Thesis Jodocus Deunk 2012

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thesis Jodocus Deunk 2012

Uploaded by

Copyright:

Available Formats

Radboud University Nijmegen

Supervisor: Dr. S.J.B.A. (Stijn) Hoppenbrouwers

1.1 RESEARCH QUESTION ........................................................................................................................ 6

2 BUSINESS RULES, THE CONCEPT .................................................................................................... 8

2.1 DEFINITIONS ................................................................................................................................... 9

3 BUSINESS RULES, THE SPECIFICATION PROCESS........................................................................... 15

3.1 CREATING A NEW BUSINESS RULE ..................................................................................................... 15

4 GUIDING THE SPECIFICATION PROCESS ....................................................................................... 19

4.1 HELPING ...................................................................................................................................... 19

5.1 THE WIZARD ................................................................................................................................. 25

6.1 SUB-QUESTIONS ............................................................................................................................ 29

I. APPENDIX A – CODE PREVIEW BRGT ........................................................................................... 34

II. APPENDIX B – DATABASE OVERVIEW .......................................................................................... 35

III. APPENDIX C – BRGT ..................................................................................................................... 36

1.1 Research question

To answer this research question three sub-questions need to be answered.

1. What does the process of business rule specification look like?

2 Business Rules, the concept

Article 1: Primary Requirements, Not Secondary

Article 2: Separate From Processes, Not Contained In Them

Article 3: Deliberate Knowledge, Not A By-Product

Article 4: Declarative, Not Procedural

Article 5: Well-Formed Expression, Not Ad Hoc

Article 6: Rule-Based Architecture, Not Indirect Implementation

Article 7: Rule-Guided Processes, Not Exception-Based Programming

Article 8: For the Sake of the Business, Not Technology

Article 9: Of, By and For Business People, Not IT People

Article 10: Managing Business Logic, Not Hardware/Software Platforms

With the two additions for the different perspectives:

From a business perspective

From an information system

"… a rule that is under business jurisdiction."

2.2 Business Rules in the organization

With the following definitions for the terms:

Policies Guidelines which create and support the

Standards Detailed rules describing the execution of the

Business Rules Strict rules limiting the freedom of action to

Procedures Detailed steps to implement and execute the

2.3 Semantics of Business Vocabulary and Business Rules

Characteristics of SBVR are (OMG, 2008):

Characteristics of RuleSpeak are (OMG, 2008):

2.5 Comparing SBVR and RuleSpeak

The difference in the rules themselves is displayed in the table below:

Modal claim type Statement form SBVR Structured RuleSpeak keywords

obligation ‘obligate statement’ it is obligatory that p r must s

‘restricted possibility It is possible that p r can s only t

2.6 Choice for a Business Rules standard

3 Business Rules, the specification process

3.1 Creating a new Business Rule

1. Select the topic for the rule

Koen also made a graphical representation of these steps:

Understand Define Select keyword

3.2 Requirements on a Business Rule

3.2.1 Do’s and don’ts

1. Business Rules Statements should be 14. Non-numeric subjects for numeric

3.2.2 Grammatical requirements

First part Keyword(s) Second part Keyword(s) Third part

SUBJ May STATE

SUBJ Need not STATE if COND