A colleague and I were recently discussing business rules. In the course of conversation he used this example: A customer may have only one address. Hold on! That’s not a business rule. Rather, it’s a design decision (probably a poor one) some IT person made in creating a system model. The business wouldn’t (and couldn’t!) make a real-world business rule about customers having only one address. But a design decision might be made to record only one (in a system). Eventually we agreed the desired business rule probably was: A customer may have only one preferred address.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from Building Business Solutions: Business Analysis with Business Rules (2011). See:  http://www.brsolutions.com/b_building_business_solutions.php

This is an excerpt from our new book: Building Business Solutions: Business Analysis with Business Rules coming out in October. Watch for it! “Requirements are rules.” Perhaps you’ve heard the argument. Maybe you’ve even made it yourself. Are they? No! Basic reasons why requirements are not rules:  Business people don’t naturally think of a ‘requirement’ as a ‘rule’. To ensure the best possible communication with business people, use of ‘rule’ should remain 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’. Many ‘requirements’ never become rules. 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, the business rules ideally should still be recognizable as a form of rule. 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 operational business design any other way inevitably leads to a break-down in communication and needless complexity.  Avoid confusing business people or IT professionals – or yourself – by calling requirements ‘rules’. Requirements are not rules! But Are Business Rules ‘Requirements’?? Clearly, requirements are not rules. What about the reverse question? Can it be helpful to think of business rules as requirements? To answer it’s essential to keep in mind what business rules are about. In plain English, business rules are about guiding and shaping day-to-day operations of the business. Business people would need business rules to operate the business even if there were no systems. The business rules just are what they are. And if well-specified, they essentially speak for themselves. All the following, though, are certainly true about business rules:

• They should arise from, or at least be approved by, business people.  
• They should be considered very carefully in designing a system.  
• They should be automated whenever possible.

All said and done, whether business rules are a form of requirement is really a judgment call. The best answer is whichever is likely to prove most productive for your work.

Some professionals view the interrogatives what and how as peers, each addressing a distinct area of engineering solutions (e.g., designing systems). Other professionals characterize ‘requirements’ as the what, and the design for a system as the how. Contradiction? No, just a bit of confusion over perspective. 

• From the perspective of designing a system, both what (data) and how (processes) must be addressed. Both interrogatives (as well as the other four – where, who, when, and why) are essential for engineering a complete, robust solution.  
• From the perspective of IT methodologies, requirements are always incomplete, so what the requirements say must be transformed into a system model that indicates how the requirements will be supported. 

In other words, the former use of what and how is based on an engineering point of view; the latter use is based on an IT-methodology point of view. Don’t confuse business people or IT professionals – or yourself – by failing to make the distinction.