“Requirements are rules.” Perhaps you’ve heard the argument. Maybe you’ve even made it yourself. Are they? No! Read this article to find out why.
The case for viewing requirements as rules was recently put to me as follows:
“Requirements are rules. They arise from business models, but they are different from those business models. They rather interpret certain aspects of those business models into rules for the behavior of the target software system. Here’s how it happens: (1) The business creates a solution for a business problem. (2) The solution involves automation. (3) Decisions made about the automated solution take the form of rules.”
This reasoning is deeply flawed – just plain wrong. It is also highly counterproductive. Here are three basic reasons why:
Reason 1. To ensure the best possible communication with business people, use of ‘rule’ should be consistent with the real-world understanding of ‘rule’. Say ‘rule’ to business people and they will naturally think “guide for conduct or action” or “criteria for making judgments or business decisions.” If a business person says ‘rule’ he/she almost certainly means a rule for the business (e.g., no shirt, no service), not ‘requirement for a software system’.
Reason 2. The “no shirt, no service” rule doesn’t happen to be automatable (at least easily). Many other rules of the business are – e.g., no credit card, no sale. When interpreted into an implementation form (e.g., under a rule engine), ideally the business rules should still be recognizable as a form of rules. The same cannot be said, however, for other aspects of a business model, say processes. In designing a business process for implementation, why would you ever say, ‘Now it represents rules.’?!
Rules are rules, processes are processes, locations are locations, people are people. Each can be cast into some design-level counterpart (e.g., GUIs can substitute for face-to-face communication between people.) Nonetheless, each retains some sense or reflection of what it was originally (or should anyway). Looking at primitive constructs of operational business design any other way inevitably leads to a break-down in communication and needless complexity. More on this point momentarily.
Reason 3. To represent a true business rule, guidance must be practicable. Generally, practicable means you know what to do or not to do when you read it. “No shirt, no service” probably qualifies as a business rule by that criteria. “Safety always come first” probably doesn’t. Guidance that is not practicable must be interpreted into a more concrete form before it’s ready for prime time (deployment to the business) – e.g., A hard hat must be worn in a construction site.
A requirement, almost by definition, is like “safety always comes first.” You must interpret or transform it into something else (i.e., some aspect of a design) before a software developer can do anything with it. In short, requirements don’t pass the ‘practicable’ test for business rules.
What Requirements Should Cover
Over the years I’ve seen a great many of these requirements-are-rules arguments. To speak frankly, they’re simply nonsense. Another recent e-mail exchange proposed the following statement as a rule.
R: The system shall have the capability to record business rules and use them to guide its behavior, and shall include among those rules this rule (R).
That’s not a rule, that’s a requirement. By the way, it’s an excellent requirement, one that every business capability should support. It’s called rulebook management.
My response to the e-mail was that in addition to business rules, a complete system design must address the following six areas of requirements (primitive constructs of operational business design).
What: The system shall have the capability to record data and use that data to guide its behavior by evaluating the then-current business rules.
How: The system shall have the capability to execute processes and use those processes to create value-add according to the then-current business rules.
Where: The system shall have the capability to address geographical distribution, and organize logistics and business communications, all according to the then-current business rules.
Who: The system shall have the capability to interact with users and support them in achieving desired behavior as permitted and guided by the then-current business rules.
When: The system shall have the capability to orchestrate the states of things in the business, and to schedule the execution of processes, all according to the then-current business rules.
Why: The system shall have the capability to demonstrate that business goals are being met, that business risks are being mitigated, and that the then-current business rules are achieving the desired business ends.
As indicated by the original requirement (R), the business rules should not be embedded in design artifacts for any of the six individual areas, or in any composite artifacts covering more than one. Instead, they should be externalized from all such artifacts.
The resulting rule independence permits business people and Business Analysts to change the business rules directly – thereby continuously evolving the business logic of the system. Support for continuously changing business rules, by the way, is the reason for including the all-important modifier the then current before “business rules” in the description for each of the six areas above.
How About Constraints on a System Design?
The requirements-are-rules argument views rules as any constraint placed on a system design. Constraining a system design, however, is simply not what business rules are about. Instead, business rules are what business people would need to run the business day-to-day even if there were no systems. Here are some sample business rules to illustrate:
-
A group must not include both union members and non-union members.
-
A poor-risk customer must not place a rush order.
-
A truck carrying hazardous material must not be routed through a downtown street.
-
A trainee must not send a memo to a manager without permission of his/her supervisor.
-
A person must be considered a woman, if the person is female and is over 21 years of age.
Do these business rules represent constraints to be imposed on a system design? All requirements are ‘constraints’ on a system design in that sense. A more accurate view of business rules is that they are constraints on business operation that should be supported by a system design (if automatable).
How the system supports automatable business rules is a class-of-platform issue. Naturally we prefer direct implementation of rules by a rule engine (i.e., declarative implementation) rather than procedural implementation (using programming languages).
A Final Thought
Merriam-Webster's Unabridged Dictionary defines requirement as follows: something required: a: something that is wanted or needed b: something called for or demanded : a requisite or essential condition : a required quality, course, or kind of training.
Do you see anything at all about ‘rule’ or ‘constraint’ in that definition?!
Author: Ronald G. Ross - Featured Speaker, www.AttainingEdge.com. Ron is also Co-Founder & Principal, Business Rule Solutions, LLC
Chair, Business Rule Forum, BBC Conference 2011.
For more about the author, see www.RonRoss.info.
Article photo © 74774154 - Fotolia.com