This is the first post in the Business Rules and SDLC series. My purpose is to explain why Business Rules must not be treated as software requirements.

Introduction & Definition

So, what are what Software Requirements?.

• Software Requirements provide a detailed description of what a software system should do.
• Who owns such Requirements? Developers, of course
• What will this description include.? It might include the behavior of the backend, the UI,etc.
• Requirements drive Software Behavior

Looking at the above statements, one might be tempted to infer that Business Rules are also requirements as they describe how the system must take decisions.

Now, let me assert what are Business Rules

Business Rules represent organization policies that form the basis of operational decision making .

• Business Rules represent organizational policies
• Who owns Business Rules? The Business, of course, and not IT
• Examples of Business Rules? Product Pricing, Product Configuration, Underwriting Rules etc.
• Business Rules drive Business behavior

How are Business Rules & Requirements related?

Now, if you think a little about it, you will realize that Software Requirements Must refer to Business Rules, and NEVER the other way round.

For example, a Credit Decisioning Service can have multiple clients in a described architecture. And the Credit Decisioning Service’s runtime behavior is determined by the Credit Decisioning Policies in force on a given day.

But the Service signature, its availability method, deployment platform, performance considerations are all software Requirements.

Now that we have established clear definitions, it is clear that Business Rules and Software Requirement must at least be thought of, and managed separately. But, that is not the end of the story.

Who are the Owners?

The answer is obvious, to the point of being trivial.

IT Personnel own software Requirements. Business Personnel own Business Rules.

This answer is important to know & realize, because the different ownerships, might lead to huge communication gaps, and turnaround times when the Business requires the systems to change. More on that in the Change Management section

And Talking of Change

Change requests to Business Rules and to System Requirements come for completely different reasons and from different quarters.

For example, Business Rules change because of competitive pressures, regulation changes. These change requests are always driven by Business Requirements.

Software Requirements, on the other hand, never change as fast as Business Rules, and are always IT driven. Performance Improvements, bug fixes, module redesign, UI Improvements are some examples of Requirements change

Managing Change

New Change Requests to Software Requirements typically follow the SDLC cycle used in an organization. But trying to retrofit Business Rule Change Requests into such an SDLC will only delay implementation.

This is because the business rules are best known only to the business personnel (Analysts, Business Managers). Any Change Management process Must allow for these Business Personnel to participate easily in the System implementation Process.

Business Rules, when externalized using commercial BRMS like QuickRules & QuickRules.NET exactly allow for such a scenario. English like Rules for easy consumption by Business personnel, simple and logical rule representation using constructs like Flow Charts and Decision Tables simplify the Business Rules capture, implementation and Change Processes and times.

Business Rules should be defined separate from code. Then their evolution can be managed independent of system change to a large extent. Managing change includes such activities like versioning, change approval mechanisms and tools, retrospective Rules etc.

Summary & Final Words.

• Business Rules ARE NOT Requirements
• Software Requirements Must refer to Business Rules, and NEVER the other way round
• Business Rules evolve independent of Requirements
• Business Rules changes are driven by the Business, and not IT
• Business Rules Cannot be Managed using a conventional Requirements Management tools. You need a BRMS provide those capabilities.