Business Rules and Requirements Aren't the Same
INTRODUCTION
Both business rules and requirements are necessary for fully scoping a system, but what is the difference between the two? When nailing down your requirements doc, it’s important to not muddy the two terms. Let’s get started with some definitions so we can clearly see where business rules and requirements differ.
WHAT IS A BUSINESS RULE?
A business rule is a constraint of the business itself that may guide system development. It is a rule that must be followed, no matter what else is happening. It often involves very specific criteria or conditions for compliance.
Basic Business Rule Example
This is a business rule that requires all users to have an associated email address. The criterion is that it must be valid, however, we don’t outline the validation process here. A secondary rule might be:
Perhaps, in the old system, a person walked up and dictated their details to a receptionist who entered the new user data into the system, then sent through a welcome email. If the person then showed the receptionist the welcome email came through on their phone, it was considered valid.
However, perhaps the new system is online self-enrollment.
Both the old system and the new system would comply with both business rules, there would just be different requirements for the system to implement it.
WHAT IS A REQUIREMENT?
A requirement outlines a singular, specific system behaviour; something that the system will (or will not) do. Requirements often support business rules.
Note that there are also functional vs non-functional requirements, but you can read more on the difference between these two here.
Basic Requirement Example
What is the difference between a Business Rule and a Requirement?
Let’s forget about software-based requirements for a minute. Let’s take a look at a requirement example. You might use requirements to scope out a system that doesn’t necessarily involve technology.
Business Rule
Requirement
Or, alternatively:
These requirements simply outline two different processes that could be used to fulfil the business rule, neither necessarily requiring technology. They could both be done on paper, although we highly recommend against it!
CAN YOU HAVE BUSINESS RULES WITHOUT REQUIREMENTS?
Absolutely. You may have a whole list of only business rules when first scoping a project, or describing current system logic.
However, without detailed requirements to guide system build, it will be up to the engineers to build it as they wish.
Here’s an example.
It doesn’t say how this will be done. Will there be an email sent? Will daily stats available by dashboard? And how will information be collected?
Without requirements to back up the business rule, complying with the rule could be done in a million different ways. These need to be explicitly outlined so the customer knows what they’re in for.
CAN YOU HAVE REQUIREMENTS WITHOUT BUSINESS RULES?
Sure, but they’re not necessary unless detailed by the customer. Engineers may suggest requirements that are usually detailed in projects that a customer may miss (and later argue about!), for instance, specifying uptimes or response rates.
For instance, here’s a requirement that may be specified by a customer that (probably) wouldn’t have an associated business rule.
BEST PRACTICES FOR BUSINESS RULES AND REQUIREMENTS
- Determine business rules when starting a project.
- Ensure every business rule has a list of detailed, associated requirements to fulfil a purpose.
- Negotiate any requirements not covered by business rules.
- Write requirements using an authoring system, such as The Easy Approach to Requirements Syntax.
- Check over requirements with a tool like QVscribe to ensure quality and compliance.
