Search ::     [ Advanced ]
Username:   Password: Auto login next time?  

Corticon RulesWorld

AttainingEdge : World Class Training For Critical Business Innovations

RuleXpress: The business tool for expressing and communication business rules.

 

 

 

 

     ROSS ARCHIVES ...
untitled

Premise and Conclusion

RuleSpeak® Sentence Forms
Specifying Natural-Language Business Rules in English

by Ronald G. Ross

For a free download of the RuleSpeak Sentence Forms, complete with examples and list of do's and don'ts in expressing Business Rules, visit www.RuleSpeak.comAlso available for free in Dutch, German, and Spanish.

What is a Sentence Form?

Definition and Purpose

A Sentence Form is a basic pattern or template in natural language that can be used to express a certain kind of Business Rule in a consistent, well-organized manner.  Each Sentence Form is aimed for a particular kind of guidance.

The purpose of the RuleSpeak[1] Sentence Forms is to ensure that written Business Rules are more easily understood.  They also help ensure that different practitioners working on a large set of Business Rules express the same ideas in the same way.  Such consistency would not be possible if Business Rules were expressed in a completely "free-form" manner.

The Sentence Forms are not technical in nature.  In other words, they do not represent a formal language or syntax for implementing Business Rules using a software platform (e.g., a rule engine).  Rather, they are aimed at expressing Business Rules to improve communication at the business level.

Success Factors for the Sentence Forms

What is important — and what is not important — when applying the RuleSpeak Sentence Forms?  One thing that should not be considered is how the Business Rules will actually be implemented using a particular rule engine or programming language.  What matters above all else is effective business communication.  Sticking to that perspective sometimes proves difficult for those responsible for technical implementation.  They may want to get to the IT versions directly.  But doing that will not help with capturing the Business Rules succinctly from the business perspective.

Using the Sentence Forms to express Business Rules does require a modest measure of discipline.  This discipline can be achieved through a bit of practice, and by understanding certain fundamentals.  These fundamentals are discussed later in this column.

Finally, it is important to understand the level of Business Rules to which the Sentence Forms should be applied.  As above, the Sentence Forms are not aimed at system design or automation.  They are also not aimed at the highest forms of guidance — that is, the language of laws, regulations, contracts, business policies, etc.

Rather, the Sentence Forms are aimed at what is called practicable guidance.  Practicable Business Rules are ones used to make operational business decisions on a day-in-and-day-out basis.  If a business worker is properly authorized, and understands the business vocabulary, he or she should be able to apply the practicable Business Rules directly in the conduct of on-going business activity.

Often, these practicable Business Rules must be interpreted from the higher forms of guidance in order to clarify, disambiguate, and solidify their business intent.  The Sentence Forms facilitate such interpretation by providing predictable patterns of expression.  The same is true if practicable Business Rules are being reversed-engineered bottom-up from existing implementations or documentation, or harvested on a facilitated basis from subject matter experts.

Usage Notes

  • "Shall" – Highest forms of guidance — laws, regulations, contracts, business policies, etc. — often use the word "shall".  We prefer the less formal word "must", which is generally more appropriate for practicable Business Rules.

  • "Should" – Any Business Rule can be stated using "should" instead of "must".  Using "should", however, reflects an assumption or decision about the appropriate enforcement level of a Business Rule.  We prefer to document any sense of how strictly a Business Rule is to be enforced separately from the expression of the Business Rule itself.  We therefore prefer always using the word "must" instead of "should".

  • "May" We always use the word "may" in the sense of something being allowed (or disallowed).  We never use "may" in the sense of "might" — i.e., that something might occur or might be true.  Unfortunately, "may" does have this double usage in English, but no suitable alternative exists.  In any event, experience has proven that the correct sense "is allowed" quickly wins out.

Basic Concepts

Understanding fundamental ideas about expressing Business Rules will assist greatly in writing them effectively.  Briefly, these ideas are as follows.

Every Business Rule Statement should use a Rule Keyword

Every Business Rule can be expressed using one of the following two words.

  • "must"
  • "only"

These fundamental words are called the RuleSpeak Rule Keywords.  It is very important that every Business Rule Statement include exactly one of these two Rule Keywords.

Practicable guidance comes in two varieties

A Business Rule always removes a degree of freedom.  The presence of one of the two Rule Keywords in a sentence clearly indicates that intent.

A large majority of sentences typically expressed to give guidance are Business Rule Statements.  Sometimes, however, practicable guidance is worth expressing that does not remove a degree of freedom.  Such a Statement, which simply clarifies that something is allowed, or that something is not required, is called a Statement of Advice.

A Statement of Advice should never include either of the two Rule Keywords.  Instead, it should use exactly one of the following two RuleSpeak Advice Keywords.

  • "may"
  • "need not"

Note that "may" coupled with "only" in the same sentence always produces a Business Rule, not an Advice.  Statements of Advice and Business Rule Statements are both Guidance Statements.

Every Guidance Statement should be a complete sentence

English helps ensure wonderful completeness in the communication of thoughts (propositions) through grammatical rules about forming sentences.  Follow those rules religiously in writing all Guidance Statements.

Every Guidance Statement should have a subject

In good English construction, every sentence has a subject.  Although this subject may be implied or the sentence inverted, more often than not an explicit subject appears as the first word or phrase in the main body of the sentence.  Such sentences are usually direct and, if well written, easy to follow.  (The subject in the previous sentence, for example, is "sentences".)

RuleSpeak prescribes that Guidance Statements have an explicit subject at the beginning.  This subject should be a noun, possibly qualified.  The singular form is preferred.  This approach promotes overall clarity and consistency.

Many IT notations feature "If … then…" syntax for implementing Business Rules in rule engines or programming languages.  In such notations, the true subject does not appear until after the 'if' clause.

Besides being 'unfriendly' for business communication, such syntax is problematic for expressing certain types of guidance.  What, for example, is the "if" of the Business Rule Statement, "An employee must have a name."?

Any Guidance Statement may reference an instance

An instance is a single thing, rather than a class of things.  Instances can be referenced by Guidance Statements just as can classes of things.  If there could be any doubt as to whether a term in a Guidance Statement refers to an instance or a class, the prudent approach is to put the term in single quotes.

Example:  A yearly personal U.S. tax return is due on April 15.

In this example, there is only one "April 15" on a calendar, so there is little chance of confusion.  Similarly, there is only one country "U.S.", so this reference too is probably clear.

Example:  A 'flammable' sticker must be displayed on a tank containing a combustible fuel.

In this example, "flammable" refers to an instance of the class of things "sticker", rather than to a kind or category of sticker (i.e., a sticker that is flammable).  Therefore the word "flammable" has been enclosed in single quotes.

Qualifying Guidance Statements

Most Guidance Statements include some qualification(s) indicating the circumstances under which they apply.  Often but by no means always such qualification is expressed using "if".

Example:  A shipment must be insured if the value of the shipment is greater than $500.

Many qualifications can be expressed without using "if".

Example:  A retired employee must not be assigned to a project.

Here the qualification "retired" is used to modify "employee" directly.  This natural means of qualification is perfectly acceptable.

Example:  A shipment fee may be waived only for an order placed by an in-state customer.

Here the qualification "placed by an in-state customer" modifies "order" in a natural manner.  It too is acceptable.

Guidance that applies only at some point(s) in time

The word "if" indicates that qualification is continuous over time.  The word "when" should be used if a Guidance Statement applies only at certain point(s) in time.

Example:  The total enrollment fee amount owed by a student for a semester must be $5,065 when the student registers for that semester.

As stated, this Business Rule applies only at each point in time when a student registers for some semester.  At any other time, the Business Rule is assumed not to apply; that is, the total enrollment fee amount owed for the semester does not have to be $5,065 (and probably increases!).

Allowing something conditionally

The Sentence Form "… may … if …" (without an "only") should always be avoided.  Statements using that Sentence Form are quite tricky and can be easily misunderstood.

Example:  An item may be returned if some proof of purchase is provided.

This Statement expresses an Advice.  (This interpretation is dictated by logic.)  It covers only the situation in which some proof of purchase is provided.  It literally does not say anything about whether an item may be returned if some proof of purchase is not provided.  Most likely, however, the business intent was to disallow returns without providing some proof of purchase.  Assuming that to be the case, the Rule Keyword "only" should be inserted as follows, thereby turning the Advice into a Business Rule.

Example:  An item may be returned only if some proof of purchase is provided.

Qualifications in Statements of Advice based on the Sentence Form "… may …" expressed without using "if" are not as easily misunderstood.  They are therefore acceptable if used carefully.

Example:  A retired employee may work part-time in Alberta.

This Statement must be taken to express an Advice.  It does not imply anything about employees who are not retired, not working part-time, or not working in Alberta.  It just says what it says.  If some Business Rule is intended covering some or all of these circumstances, it must be expressed separately, as the following Business Rule Statement illustrates.

Example:  A retired employee must not work part-time outside Alberta.

How to say something is not a Business Rule under certain circumstances

If something is not a Business Rule under certain circumstances, the best Sentence Form to express the Advice is generally " … need not … if …".

Example:  A credit check need not be requested for an order if the amount of the order is under $1,000.

Note that by itself, this Statement of Advice leaves open the question of whether credit checks are required for orders that total $1,000 or more.  If such credit checks are required, a separate Business Rule Statement must be expressed.  The general point to remember about expressing guidance is that nothing is ever required (that is, everything is allowed) unless a Business Rule explicitly removes some degree of freedom.

References

[1]  RuleSpeak was one of three reference notations used in the creation of SBVR (Semantics of Business Vocabulary and Business Rules) and is consistent with that standard.  RuleSpeak is a technique of Proteus® — the BRS methodology for business analysis and business rules.  RuleSpeak® is a registered trademark of Business Rule Solutions, LLC.  Read more about RuleSpeak on www.RuleSpeak.com. return to article


Copyright, 2001-2009.  Business Rule Solutions, LLC.  All rights reserved.
Provided courtesy of Business Rule Solutions, LLC, the Business Rule Technique Company.



standard citation for this article:
Ronald G. Ross, "RuleSpeak® Sentence Forms:  Specifying Natural-Language Business Rules in English," Business Rules Journal, Vol. 10, No. 4 (Apr. 2009), URL:  http://www.BRCommunity.com/a2009/b472.html  

 about . . .

 RONALD G. ROSS


Ronald G. Ross is recognized internationally as the "father of business rules." He has Chaired the annual Business Rules Forum since 1997. He was a charter member of the Business Rules Group in the 1980s, and an editor of two landmark BRG papers, The Business Motivation Model and the Business Rules Manifesto. He is active in standards development, with core involvement in SBVR.

Mr. Ross is Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is author of eight professional books, including Business Rule Concepts (2009), a just released 3rd edition of his popular, easy-to-read 1998 handbook. Mr. Ross speaks frequently at industry events worldwide.

Mr. Ross is Co-Founder and Principal of Business Rule Solutions, LLC and is actively engaged in consulting, training and research. He co-developed RuleSpeak®. Mr. Ross gives highly regarded public seminars in North America through AttainingEdge and in Europe through IRM-UK.

For additional information about Mr. Ross, please visit his personal website at www.RonRoss.info.

March 2010
What Is a Business Rule?

February 2010
CRUD in Business Rules: Accident-Prone Decision Logic

January 2010
The Point of Knowledge

December 2009
When is an Exception Really an Exception? The Business Rule Principles of Accommodation and Wholeness

November 2009
Verb-ish Models for Verbalization: Give Us Back Our Verbs!

October 2009
From Rulebook Management to Business Governance: Where Business Rules Fit

September 2009
What You Need to Know About Rulebook Management

August 2009
When Is a Door Not a Door? ~ Basic Ideas of the Business Rules Paradigm

July 2009
General Rulebook Systems (GRBS): What's the General Idea?

June 2009
Becoming Strategy-Driven: The Policy Charter

May 2009
Product Quality and a Longer-Term View: A 'Simple' Matter of Business Policies

April 2009
RuleSpeak® Sentence Forms: Specifying Natural-Language Business Rules in English

March 2009
The Rulebook: To Play Ball You Need Rules

February 2009
Extreme Business Agility (Part 6): A Manifesto-in-Progress on the Semantic Re-Engineering of Products

January 2009
Extreme Business Agility (Part 5): The Optimal Edge of Business Performance

December 2008
Extreme Business Agility (Part 4): Change Deployment Hell

November 2008
Extreme Business Agility ~ Part 3: Examples of Non-Agile vs. Agile Business Capabilities

October 2008
Extreme Business Agility ~ Part 2: A Semantic Approach to Re-Engineering Your Company's Products

September 2008
Extreme Business Agility — Part 1: A Value Chain for Re-Engineering Your Company’s Products

August 2008
My Son, Business Rule Analyst — Governance and Compliance Through Young Eyes

July 2008
Rules vs. Processes (Again) — Part 2: Now for Events

June 2008
Rules vs. Processes (Again) — Part 1: There’s Simply No Need for Confusion

May 2008
Legacy Modernization, Semantics, and the Knowledge Economy ~ Have You Connected the Dots Yet?!

April 2008
The Emergence of SBVR and the True Meaning of ‘Semantics’: Why You Should Care (a Lot!) ~ Part 2

March 2008
The Emergence of SBVR and the True Meaning of ‘Semantics’: Why You Should Care (a Lot!) ~ Part 1

February 2008
The Phoenix Strategy ~ A Lower-Risk Approach to Rejuvenating Systems and Legacy Modernization

January 2008
'Rules of Record' Why 'System of Record' Isn't Enough

December 2007
The Decision Center: A Center of Excellence for Coordinating Business Rules and Other Process 'Smarts'

November 2007
The Latency of Decisions ~ New Ideas on the ROI of Business Rules

October 2007
Legacy Systems -- Poorly Engineered or Over-Engineered? New Insights about Business Rules and Enterprise Decisioning

September 2007
The Value of Decisions ~ New Ideas on the ROI of Business Rules

August 2007
A Case of Dueling Manifestos? Business Rules and Enterprise Decision Management

July 2007
What's Wrong with If-Then Syntax For Expressing Business Rules ~ One Size Doesn't Fit All

June 2007
Are IT Terms Fundamental to Every Business? Not!

May 2007
Are all Rules Business Rules? Not!

April 2007
Are Software Requirements Rules? Not!

March 2007
Are Integrity Constraints Business Rules? Not!

February 2007
From Rule Management to Business Governance, Part 4: Governance Engineers and the Chief Governance Officer (CGO)

January 2007
From Rule Management to Business Governance, Part 3: Re-Engineering the Governance Process

December 2006
From Rule Management to Business Governance, Part 2: Governance and How it Relates to Business Rules

November 2006
From Rule Management to Business Governance, Part 1: Governance and How it Relates to Business Rules

October 2006
Rules and Processes: Examples Showing How They Relate

September 2006
The Meaning of Things: Definitions, Intensions, Rules, and Extensions

August 2006
Re-Vitalize, Don't Just Re-platform! ~ Three Tests for Whether Your Company 'Gets It' with Respect to Re-Platforming Business IP

July 2006
The Dirty Secrets About Your Company's Business IP That Nobody Wants to Talk About

June 2006
A Personal Insurance Saga ~ The Economics of Business Rules

May 2006
Concepts, Definitions, and Rules: RuleSpeak® Practices

April 2006
The RuleSpeak® Business Rule Notation

March 2006
How Rules and Processes Relate ~ Part 6. Point-of-Knowledge Architecture (POKA)

February 2006
How Rules and Processes Relate ~ Part 5. Scripts -- Rule-Friendly Process Models

January 2006
How Rules and Processes Relate ~ Part 4. Business Processes vs. System Processes

December 2005
How Rules and Processes Relate ~ Part 3. Three Best Practices for Designing Business Processes with Rules

November 2005
How Rules and Processes Relate ~ Part 2. Business Processes

October 2005
How Rules and Processes Relate ~ Part 1. The Challenges

September 2005
Rule Quality ~ The Route to Trustworthy Business Logic

August 2005
Decision Tables, Part 2 ~ The Route to Completeness

July 2005
Decision Tables, Part 1 ~ The Route to Consolidated Business Logic

June 2005
Rule Reduction ~ The Route to Atomic Business Rules

May 2005
Essence Definitions and Business Rules ~ Developing Stable Anchor Points for Operational Knowledge

April 2005
Can You Violate Structural Rules? (part 3) ~ The Difference Between Breaking Rules and 'Breaking' Knowledge

March 2005
Can You Violate Structural Rules? (Part 2) ~ The Difference Between How to Compute and How to Behave

February 2005
Can You Violate Structural Rules? (Part 1) ~ The Difference Between Violations and Bad Decisions

 

Janauary 2005
Business Rules and Knowledge Workers ~ Getting to the 'Point of Knowledge'

 

December 2004
Can a Definition be Violated? ~ Definitions and Business Rules

 

November 2004
Rustling Up Good Definitions ~ There's a Lot Less and a Lot More to It

 

October 2004 

Clarifying Clarifications ~ Universal 'And' to the Rescue

 

September 2004 

Relearning the Basics of Communicating ~ Business Semantics and Business Rules

 

August 2004 

The Light World vs. the Dark World ~ Business Rules for Authorization

 

July 2004 

Best-Fit Decision Points ~ How They Fit into the Business Rule Approach

 

June 2004 

What Rule Independence Means to System Models ~ Less and More than You Think!

 

May 2004 

The Semantics Lexicon ~ Terms For The Business Rules / Smart Process

 

April 2004 

Don't Reinvent Rule Engines!

 

March 2004 

Rules And Compliance Tactics

 

February 2004 

Tracing the Path of Rule Reduction

 

December 2003

Do Rules Decompose To Processes Or Vice Versa?

 

November 2003

Should You Encapsulate Knowledge in Modeling Real-World Things?

 

October 2003

Business Rules, Encapsulation, and Models of the Real World

 

September 2003

Business vs. Environment in Business Models

 

August 2003

Requirement Statement vs. Rule Statement

 

July 2003

Rules as Constraints:  On or By the System Design?

 

June 2003

Rules Reveal Events -- Not Actions

 

May 2003

Actions Are Not Rules (and Vice Versa)

 

April 2003

The Definitions of 'Business Rule' and 'Rule'

 

March 2003

Business Problems Addressed by the Business Rule Approach

 

January 2003

About the Business Rules Manifesto ~ The Business Rule Message in a Nutshell

 

November 2002

Business Rules for the Company's Provisioning Processes ~ There’s a Lot More to Reference Data than Just Data!

 

September 2002

The Terminator -- I'll be Back (with Just the Right Term)

 

July 2002

What Does it Mean to be Business-Driven? (Part 2)

 

May 2002

What Does it Mean to be Business-Driven? (Part 1)

 

March 2002

A Telltale E-mail Trail:  The Case for In-Line Business Rule Analysis

 

January 2002

Managing M x N Vs. M + N, Market-Driven Economies, and Other eCommerce Issues (part 2)

 

November 2001

Managing M x N Vs. M + N, Market-Driven Economies, and Other eCommerce Issues (part 1)

 

September 2001

The BRS Rule Classification Scheme

 

July 2001

Minding Your P's and Q's

 

May 2001

RuleSpeak"! -- Templates And Guidelines For Business Rules

 

March 2001

Business Rules In Business Processes ~ Title Rules For Process And Rules For Product/Service

 

January 2001

What Is Rule Management About?

 

November 2000

Let's Make a Deal: A Killer App for Business Rules

 

September 2000

The Re's Of Business Rules

 

July 2000

What Are Fact Models And Why Do You Need Them? (Part 2)

 

May 2000

What Are Fact Models And Why Do You Need Them? (Part 1)

 

March 2000

What is a 'Business Rule'?

 

January 2000

Current Thoughts On Expressing Business Rules

 

November 1999

The Fin de Siegle Legacy Mindset
 

September 1999

Analysis Paralysis Just May Save Your Life
 

July 1999

If We Had Started Coding Already...
 

May 1999

Your Core Business Processes Need a Rule Engine
 

March 1999

Who or What is a True Business Analyst?
 

January 1999

Four Things Wrong with the Way We Develop Information Systems

 

 

 

 





[ Home ] [ Staff ] [ About BRC Publications ] [ Editorial Feedback ] [ About BRCommunity ]
[ Contributor's Guidelines ] [ Privacy Policy ] [ Technical Support ]