Requirements are Rules: True or False?
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.
Tags: business analysis, business requirements, Business Rules, requirements, Rules, system design
Ronald G. Ross
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.
David Morris
| #
Great article, thanks for sharing.
It does, however, seem to be predicated on the assumption that requirements are for software projects only. In fact any business change initiative, whether it’s organizational restructures, new business processes, or software development, always has requirements and some of those will definitely be rules that exist solely outside if software systems (exactly like “no tie, no service”).
Ronald G. Ross
| #
@David – I agree with you. In our approach, we actually avoid the word “requirement” as much as possible. For the parts of projects that do involve automatation, we say “ability statement” … which is like ‘functional requiement’ except always derived from a business model. Every business initiative should create a business model and business rules, whether the initiative involves automattion or not.
Jeremy
| #
Ronald…..”we actually avoid the word “requirement” as much as possible” …. Does this mean you “break out” the traditional requirement statements into lower level statements, ie “ability statement?” I am struggling with a list of 200 requirements for a new system, because many of the requirements are rules, many are actual system requirements (system should verify xyz), and many are things that the system should “allow a user to do” (add a trainer to a class section.) So, would that last one be an example of an “ability statement?” It is more of a user action than a system requirement, in my opinion, and therefore it will be a use case at some point, but I think the business people are having trouble understanding this as a system requirement, to your point.
Wayne Simacek
| #
In the agile world at Wells Fargo, we think of requirements more in terms of Stories and Story Tests. When your application passes all of your story tests, it’s done. …time to move on.