The case for software requirements as rules was recently put to me as follows (paraphrasing):

'Software 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:  (a) the business creates a solution for a business problem, (b) the solution involves automation, (c) decisions made about the automated solution take the form of rules.'

I find that argument flawed and counterproductive.  Here are three basic reasons why.

• To ensure the best communication possible with business people, use of "rule" should be consistent with their real-world understanding of that notion.  Generally, that means "guide for conduct or action" and "criteria for making 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."


• The "no shirt, no service" rule doesn't happen to be automatable.  But many other rules of the business certainly are -- e.g., no credit card, no sale.  When a rule like that is interpreted into an implementation form, it makes good sense to still think of it as a rule (albeit now technology-flavored).  But the same is not true for other things, say processes.  If you are designing a business process for implementation, why would you ever say it now represents "rules"?!  Rules are rules, processes are processes, people are people, etc.  Any of these fundamental components in business engineering may be transformed in expression and purpose through design work, but each remains what it is.  For the primitives of any problem (processes, rules, people, etc.), any other approach will inevitably lead to a break-down in communication and loss of focus.


• An important notion in the business rules approach is that a rule, to be a rule, must be actionable.  The "no shirt, no service" rule probably qualifies by that criteria (I know what to do or not to do when I read it).  Something like "safety always come first," however, is not actionable.  (I can't read it and know exactly what to do or not to do.)  First, I must interpret it into something that is actionable (e.g., a hard hat must be worn in a construction site).  A software requirement, almost by definition, is like "safety always come first."  You must interpret it into something else (i.e., a design) before you (the software designer) can do anything with it.  In short, a software requirement doesn't pass the 'actionable' test for rules.

One last point is this.  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

I don't see anything about "rule" in that definition, do you?!

# # #