Requirement Statement vs. Rule Statement

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal , and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross

In this one-per-month special 'notepad' series, I am taking a quick look at important issues facing practitioners who are seeking to understand and apply the business rule approach for capturing business requirements and developing business systems.

A recent email exchange proposed the following statement as a rule.  My evaluation of this statement follows below.

The system shall have the capability to record rules and use them to guide its behavior, and shall include among those rules this rule: R.

My response was that in addition to this "rule" I would want to add the following five statements about the system[1], which seem equally important.

What:  The system shall have the capability to record data and use that data to guide its behavior, and shall include among that data, data such that the system suits this requirement:  R1.

How:  The system shall have the capability to execute processes and use them to effect its behavior, and shall include among those processes ones that give the system the capability to suit this requirement:  R2.

Where:  The system shall have the capability to communicate between locations and use this ability to support its behavior, and shall include among those capabilities the ability to communicate this requirement:  R3.

Who:  The system shall have the capability to interact with users and support them in achieving desired behavior, and shall include among those interactions the capability to query and modify this requirement:  R4.

When:  The system shall have the capability to schedule execution of processes and use such schedules to trigger its behavior, and shall include among those processes the capability to schedule processes in such a way that the system suits this requirement:  R5.

To complete the set, I would reword the original statement as follows.

Why:  The system shall have the capability to evaluate rules and use them to guide its behavior, and shall include among those rules this requirement:  R6.

My point is that what the original statement R described as a 'rule' is really not a rule at all.  Rather, it is simply one of the six innate areas of capability that any complete system should offer.  A well-balanced system, in fact, should provide all six kinds of capabilities in primitive fashion.  This idea, of course, comes straight from Zachman.

Zachman sheds a great deal of light on the issue.  First he says there are six basic varieties of requirement -- corresponding to the six interrogatives.  These are the columns in his Framework.  (Actually, you might say there are twelve because each interrogative has a two-part generic model.  However, that's a little deeper than we need to go here.)  Rule statements fall under the 'why' interrogative.

Second, Zachman says there are distinct viewpoints for which the requirements need to be expressed/developed -- business viewpoint, system viewpoint, class-of-platform viewpoint, and platform-specific viewpoint.  For rule statements, this means there is not just a single variety of rule statement, but actually four.  (There are six rows in the Framework, but in the present context, only four viewpoints mentioned really matter.)  The Zachman answer is simple, elegant and powerful.

By the way, the real sleeper among the above requirements is R4.  Note the prescription " users can query and modify ".  Extrapolating a bit, this means that the users of the system can report on and change the very requirements for the system.  The class-of-platform implication is that the system must be able to modify itself to suit the changed requirements.

Think of rules as one variety of business requirement that can be externalized (from processes, to users) such that users can change them directly -- and have the system itself instantaneously "changed" (in terms of the logic it will use).  That's the very potent message of the business rule approach.

By the way, we could also talk about externalizing (the specification of) schedules, interfaces, distribution specifications, etc. -- but for now, I'll settle for the rules (business logic).  By using rule engines to run the business logic directly, the rules become highly visible (directly accessible) to authorized parties.  That's the giant step forward that businesses today need desperately!

Notes

[1]  By 'system' in this discussion, I mean a knowledge/record-keeping system to support business requirements.  return to article

# # #

Standard citation for this article:


citations icon
Ronald G. Ross , "Requirement Statement vs. Rule Statement" Business Rules Journal Vol. 4, No. 8, (Aug. 2003)
URL: http://www.brcommunity.com/a2003/b144.html

About our Contributor:


Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal , and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the IPSpeak methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:


Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997., now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on http://www.brsolutions.com/category/blog/. For more information about Ron visit www.RonRoss.info. Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross
Subscribe to the eBRJ Newsletter
In The Spotlight
 John A. Zachman
';
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1
 Ronald G. Ross

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.