Introduction
One of the most common mistakes that developers and architects of software systems make is to mistakenly assume that the Business Rules in their Applications are a part of the Software Requirements. As a result, Business Rules are treated and managed like Software Requirements. Nothing can be further from the truth. We argue why this is an incorrect approach, and go ahead to suggest a better and more agile method for managing Business Rules.
Software Requirements & Business Rules– A Definition
So, what are Software Requirements? To quote from Wikipedia,
- Software Requirements describe the Behavior of a software System to be developed
- Software Requirements include sets of use cases that describe all the interactions that users have with Software
- Software Requirements include non-functional requirements like quality, performance, design constraints and so on
Developers and Architects use these requirements as inputs to their design and development activities.
Business Rules on the other hand describe or represent constraints on the behavior of the business. Business rules represent the core business logic of each organization; they guide and control the basic business processes that form the back bone of any business transaction
When working with business rules developers have to take into consideration that such rules are inherent in:
- Corporate charters
- Management practices and regulatory forces
- Human resources management
- Marketing strategies
- Pricing policies
- Products and services offerings
- Customer relationship practices
Business rules are the most dynamic component of any application. Therefore their constant and correct identification and externalization improve the organization's adaptability to industry changes and competition.
For a more detailed introduction on the subject of Business Rules, please refer Getting Started with Business Rules management.
Read more to learn about the Rules Vs Requirements Paradox
