November 5, 2019 – QRA Team


Business Rules and Requirements Aren’t the Same – Here’s How to Separate the Two

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.

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.

Download the Printable Article

Printable version now available for engineering professionals!

   

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

All users need a valid email address.

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:

An email is considered valid if the user can prove they have access to the email address associated with the user account.

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.

For more on business rules, it’s worth taking a look at the Business Rules Journal.

   

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 examples

The enrollment system shall include a mandatory email input on the user enrollment form page.

If the Submit button is pressed on the user enrollment form page and all mandatory fields are present, the enrollment system shall send a confirmation email to the email address provided.

If the acknowledgement link within the confirmation email is clicked, the enrollment system shall create a new user account using confirmed enrollment details.

   

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

Employee hours must be tracked.

Requirement

Each employee shall sign in when starting their shift and sign out when ending their shift.

Or, alternatively:

Managers shall note all employee start and finish times throughout the manager’s shift.

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!

Download the Printable Article

Printable version now available for engineering professionals!

  

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.

The systems admin shall receive daily server usage statistics at the end of each working day.

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.

The enrollment system shall allow the user to upload an optional avatar for association with the user account.

  

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.

If you’d like to learn more about QVscribe then make sure to get in touch with us for a demo.


Share this Story

 

Get the Latest Updates

If you're part of an engineering team, tech company, or just like to be at the bleeding edge of innovation

Rethink Requirements Today

Put QVscribe to the test on your documents to see how much time and rework you could be saving.


Learn About QVscribeSchedule a Demo