Business rules vs requirements, with examples

Published 22 October 2026

A business rule is a policy the business follows with or without software: only users with the Billing role may pay an invoice; invoices are due 30 days after the invoice date. A requirement says what a system must do — and some requirements exist only to enforce a rule. The rule belongs to the business and changes when the policy does; the requirement belongs to the system and changes when the design does. Below are the difference in one table, business rule examples by type, how to tell a rule from a requirement, how rules relate to functional requirements, business logic and acceptance criteria, a business rules template, and how to keep rules apart on a project.

The important point to remember is that the business rules are what we need to guide behavior. However you choose to implement or enforce those rules is a different matter. Do not confuse the two.

— Gladys S.W. Lam, Business Rules vs. Business Requirements, Business Rules Journal, 2024

Business rules vs requirements: the difference

In Lam’s words, “Business rules are lists of statements that tell you whether you may or may not do something, or … that give you the criteria and conditions for making a decision.” Ronald Ross puts the test plainly: “Business people would need business rules to operate the business even if there were no systems” (Business Rules Journal, 2013).

Karl Wiegers gives the cue for spotting one: when someone says that “only certain user classes can perform an activity under specific conditions”, they might be describing a business rule. Functional requirements can be derived to enforce it, but “As stated, though, business rules are not functional requirements” (Jama Software).

Whether a business rule is a kind of requirement is argued both ways. The Business Rules Manifesto opens with “Rules are a first-class citizen of the requirements world” (Business Rules Group); Ross, who edited it, calls the question “really a judgment call”. What matters in practice is keeping the two apart, so that each can change for its own reasons.

Business rule examples

The customer portal from the other templates on this site, where customers see and pay their company’s invoices. The rules belong to the client’s finance department; the portal is one of the places where they apply.

RULE-07 is the one behind the Pay button in the functional specification; RULE-06 is behind FR-016, the payment reminder; RULE-05 and RULE-08 came with the part payments change (CR-10). None of them mentions a screen.

Types of business rules

Wikipedia, following a white paper by the Business Rules Group, sorts business rule statements into four categories (Wikipedia):

Facts are the borderline case: “To say that a customer can place an order is NOT a business rule, but a fact,” the article says. They still belong in the same list, because the rules are built on them — in the Manifesto’s words, “Rules build on facts, and facts build on concepts as expressed by terms.” Wiegers’ phrases to listen for — “Must comply with”, “If (some condition is true), then (something happens)”, “Must be calculated according to (some formula)” — are in types of requirements.

How to tell a business rule from a requirement

1. Would it still be true without the software? One answer on Stack Exchange says business rules “are the things you would still have to apply if you were doing this transaction or whatever 100 years ago (manually)” (Stack Exchange, 2014).
2. Who can change it? If the finance department can change it without asking the project, it is a rule.
3. Does it name a screen, a button, an email or a field? Then it is a requirement — at most, a requirement that enforces a rule.
4. Does it hold beyond this system? “Rules apply across processes and procedures,” says the Manifesto. RULE-01’s 30 days apply whether an invoice is paid in the portal or by bank transfer.

Business rules vs functional requirements

One rule can be enforced in several ways. Lam’s example is a driver’s licence, checked by a police officer, a scanner or a card reader at a checkpoint: “Any one of these requirements can enforce the above 2 rules with different degrees of efficiency and effectiveness.” For RULE-07, the portal could hide the Pay button, refuse the payment on the server, or let anyone start a payment and have the finance team approve it by hand. The project chose the first two:

RULE-07  Only users with the Billing
         role may pay an invoice.
Source:  finance policy
Owner:   finance lead

Enforced by
FR-012  The Pay button is shown only
        to users with the Billing
        role.
FR-013  The portal refuses a payment
        request from a user without
        the Billing role.

FR-014, paying an open invoice by card, stays as it is; the rule narrows who can use it. The Manifesto states the principle: “A rule is distinct from any enforcement defined for it.” And the direction runs one way. “Rules shouldn’t be changed to fit requirements,” Lam writes (Business Rules Journal, 2020): a rule that is hard to enforce is a reason to choose another way of enforcing it, not to bend the rule.

Keeping them apart pays off when the policy changes. If the finance department decides that the account owner may pay too, the change starts at RULE-07 and follows its links to FR-012 and FR-013. If the rule had been written only as FR-012, someone would have to find FR-013 by reading every requirement — and the code.

Business rules vs business requirements

A business requirement is a goal the project must reach: BR-03, shorten the time invoices stay unpaid, from 41 to 30 days. A business rule describes how the business works, before the project and after it: RULE-01, invoices are due in 30 days. Business requirements are met; business rules are followed.

Business rules vs business logic

“Business rules encoded in computer code in an operational program are known as business logic,” in Wikipedia’s definition. One Stack Exchange answer: “‘Business logic’ is the part of your code that specifically implements business rules” (Stack Exchange, 2021). Another notes what survives a rewrite in a new language: “what remains constant is the business rule about an invoice having at least one line item” (Stack Exchange).

The trouble starts when the code is the only place a rule is written. One Hacker News commenter on why old mainframes stay in service: the software on them “often implements very complex business rules that are otherwise undocumented (the code is the documentation)” (Hacker News, 2009). Another, on legacy code in 2025, lists among the real challenges “understanding implicit business rules, and inferring undocumented contracts and invariants” (Hacker News). A rule written where the business can read it, with an ID that the code and the tests point to, is one that someone can still check when the people who wrote the code have gone.

Business rules vs acceptance criteria

Acceptance criteria check that one requirement or story obeys the rule in its own situation; the rule itself is written once. The criteria for FR-012 and FR-013 cite it:

FR-012, FR-013  (enforce RULE-07)

Acceptance criteria
1. A user with the Billing role sees
   the Pay button on an open invoice.
2. A user without the Billing role
   sees the invoice, with no Pay
   button.
3. A payment request from a user
   without the Billing role is
   refused, and nothing is charged.

When the rule changes, the criteria that cite it are the ones to rewrite. The payment reminder shows the chain. Its first rule said “an open invoice”; when customers could pay part of an invoice (CR-10), a partly paid invoice would never have been chased. The finance lead changed RULE-06 to “not paid in full” (decision D-7 in the decision log), FR-016 went to version 1.4, and its acceptance criteria gained a fourth case.

Business rules template

Copy it into a document or a spreadsheet, one block per rule. Square brackets are yours to fill in.

BUSINESS RULES
Project:   [name]
Version:   [x.y], [date]

RULE-[n]  [the rule, in one sentence a
          business person can check]
Type:      [definition / fact /
           constraint / derivation]
Source:    [policy, law, contract,
           standard, person]
Owner:     [who may change it]
Version:   [n], since [date]; [decision
           or change request]
Enforced:  [requirement IDs, or
           "outside this system"]
Notes:     [examples; exceptions, as
           other rules]

Two rules from the portal, filled in:

RULE-06  An invoice not paid in full
         gets one payment reminder,
         seven days after its due
         date.
Type:     constraint
Source:   finance policy on late
          payment
Owner:    finance lead
Version:  2, since 16 June (D-7);
          version 1 said "an open
          invoice"
Enforced: FR-016 (version 1.4)

RULE-01  Invoices are due 30 days
         after the invoice date.
Type:     derivation
Source:   standard terms of sale
Owner:    finance director
Version:  1
Enforced: outside the portal: the
          accounting system sets the
          due date; FR-010 shows it

How to keep business rules apart on a project

1. Give rules a list and a prefix of their own (RULE-), separate from the requirements: a section of the functional specification or the SRS, or a catalog of their own when there are many.
2. Write each one as a statement, in the business’s words. “Rules should be expressed declaratively in natural-language sentences for the business audience,” says the Manifesto — not as “the system shall”.
3. One rule per statement. Exceptions are rules too: “Exceptions to rules are expressed by other rules.”
4. Record the source and the owner — the policy or law it comes from, and the person who can change it.
5. Link each rule to what enforces it: requirements, stories and tests. The traceability matrix can carry the rule IDs.
6. Start every change at the rule, then follow its links. Ivan Walsh’s warning: “The smallest change in the wording of the business rule can have significant impacts on other business processes” (Business Rules Journal, 2012). A change impact analysis is where those impacts are listed.
7. Keep the list short. “‘More rules’ is not better,” as the Manifesto puts it.

On agile teams, rules are easy to lose. The person who started a thread titled “Help! Management thinks agile means no documentation!” described a project “pretty complicated with lots of business rules which aren’t documented because ‘agile means no documentation.’” (r/businessanalysis, 2019). Stories close; rules outlive them. A rule written only in one story’s acceptance criteria drops out of sight when the story is done, so keep the rules on a page the team and the business can both read, and refer to them from stories by ID — see managing requirements in Jira.

Where Specroot fits

This is the problem Specroot works on: business rules kept as items of their own, linked to the requirements and acceptance criteria that enforce them, so that when a policy changes, everything built on the old rule is found. Specroot for agencies and consultancies.