Business Rules vs. Requirements

One of the questions I have been asked most often over the years is surprisingly simple:

What is the difference between a business rule and a requirement?

I have taught the formal definitions many times. But one of my favorite ways to explain the difference has nothing to do with a business system, a methodology, or a technology project.

It has to do with my daughter, Vanessa, when she was 16.

The Rules According to Mom

When Vanessa was approaching driving age, I had a problem.

Up until then, I drove her everywhere. She is my only daughter, and I was a protective mother. As she became more independent, I still wanted to know where she was and, more importantly, that she was safe.

So I had rules.

Among them:

• Vanessa must not stay out past 10:30 p.m.
• Vanessa must not let a new driver drive her home without my permission.
• I must know where Vanessa is.
• Vanessa must not get into a car with someone I don't know.
• Vanessa must not go anywhere with a stranger.

You can probably imagine how popular these rules were with a 16-year-old.

Most of her friends were new drivers. I didn't necessarily know everyone she knew. And when I told her she shouldn't go anywhere with a stranger, her response was essentially, “Mom, I'm not stupid.”

But whether Vanessa liked them or not, those were the rules.

Then came the requirement.

Vanessa Had a Requirement

When I tell this story in a workshop, this is where I stop and ask the audience:

“So, what do you think Vanessa's requirement was?”

It usually doesn't take long before somebody calls out:

“A car!”

Exactly.

Vanessa wanted a car.

And suddenly we have a very simple illustration of something organizations struggle with all the time.

My rules were not her requirement.

The rules described the conditions that governed Vanessa's behavior. The car was a potential way to help her operate within those conditions.

That distinction matters.

Suppose we didn't buy Vanessa a car. Did the rules disappear?

Of course not.

She still had to be home by 10:30.

Suppose we did buy her the car. Would that automatically mean she complied with all the rules?

Of course not.

Unless I could somehow program the car to bring her home automatically at 10:30, she could still come home late.

And was buying her a car the only possible way to help her comply with the rules?

No. She could take a bus. I could continue driving her. There could be other alternatives.

That's the point.

The business rules exist independently of the solution we choose to implement.

Now Put This Into a Business Context

Organizations frequently mix rules and requirements together.

A business rule tells us what must or must not happen, what is allowed, what conditions must be satisfied, or what criteria should be used to make a decision.

A requirement tells us what capability is needed.

That capability may make it easier to implement or comply with the business rules. But it isn't the rule itself.

This distinction becomes especially important when we start building systems.

Too often, organizations jump immediately to requirements:

“We need the system to do this.”

“We need an application that does that.”

“We need the ability to…”

Those may all be legitimate requirements.

But I want to ask another question first:

Why?

What business rule is creating the need for that capability?

Think about Vanessa's car.

If the requirement is simply “Vanessa needs a car,” we know what she wants, but we don't understand why.

Once we understand the rules behind it, we understand the business need.

She needs a safe way to get home. She shouldn't depend on inexperienced drivers. She shouldn't ride with people I don't know. She needs to be home by 10:30.

Now we can evaluate whether a car is actually the best answer—or whether there are other ways of satisfying the same need.

Rules Give Requirements Their Context

There is another important difference.

Rules tell us what “correct” looks like.

If the rule says Vanessa must be home by 10:30, then we have a clear criterion. At 10:25 she is complying with the rule. At 10:45 she isn't.

The requirement for a car doesn't tell us that.

The car is an enabler. The rule provides the guidance.

And that means rules also help us understand and justify requirements.

When my husband asked why we needed to buy Vanessa a car, I had an answer.

Not simply:

“Because she wants one.”

I could point to the underlying reasons.

It would give her greater independence while helping her comply with the rules we had established around safety, transportation, and getting home on time.

Suddenly, the requirement has context.

This Is Where Organizations Get Into Trouble

Imagine doing this the other way around.

An organization gathers hundreds of requirements and sends them to a development team. People debate features, screens, workflows, interfaces, and functionality.

But nobody has clearly captured the business rules behind them.

Now someone asks:

“Why do we need this requirement?”

Nobody is quite sure.

“Could we satisfy the business need another way?”

Nobody knows.

“If we change this feature, are we violating a business policy?”

Maybe.

“What is the system actually supposed to enforce?”

Good question.

This is why I have always found the distinction between rules and requirements so important.

Requirements without the underlying business knowledge can quickly become a list of things someone once said the system should do.

The rules tell us more about the business itself.

And Now We Have AI

Today, this distinction matters even more.

We are no longer simply asking people and traditional software systems to execute requirements. Increasingly, we are asking AI to interpret information, make recommendations, assist with decisions, and act on behalf of the business.

We can give AI a requirement:

“Build me an application that does X.”

AI is getting remarkably good at doing that.

But does it understand the business rules that make X correct?

Does it know the conditions under which something is permitted or prohibited?

Does it know why an exception exists?

Does it understand what the business means by the words it is using?

If we haven't made that business knowledge explicit, AI has the same problem our development teams have always had: it has to fill in the gaps.

And AI is very good at filling in gaps.

That doesn't mean it fills them in with your business knowledge.

Start With What the Business Knows

The lesson I learned from that conversation with my 16-year-old daughter still applies.

Don't start by asking only:

“What do you need?”

Ask:

“What rules are driving that need?”

Then you can decide what requirement—or combination of requirements—best enables the business to operate according to those rules.

Sometimes the answer might be a new system.

Sometimes it might be a different process.

Sometimes it might be a change in responsibilities.

And sometimes, apparently, the answer is:

Buy Vanessa a car.

She isn’t 16 anymore.

But I’m still using her story to explain business rules and requirements.

And just to complete the story: Vanessa never did get the car.

The requirement went away. The rules didn’t.

Can your AI distinguish your business rules from your requirements? RonBot helps people learn to uncover and articulate the business knowledge AI needs. Learn about RonBot or See RonBot in Action