A Taxonomy of Business Rules · Business Analysis Notes

Key ideas#

What a business rule is#

Business rules include corporate policies, government regulations, industry standards and calculation methods. They apply even when the process is entirely manual. A rule is not a business process (a sequence of steps) and not a business requirement (an objective). It shapes processes by defining vocabulary, imposing restrictions, triggering actions and governing calculations.

One rule, many kinds of requirements#

A rule can produce requirements at any level. A new regulation can create the business objective for a whole project. A privacy policy can define which users may do what. A rule can call for a specific system function. Safety regulations can become quality attributes.

The types#

Facts — statements that are true about the business at a point in time, usually relating terms: “every container has a unique barcode”. A company has endless facts; collect only those tied to your scope.
Constraints — what the system or its users must or must not do; look for “must”, “must not”, “only”. Keep them apart from project constraints (budget, schedule) and design constraints. A roles and permissions matrix (roles against operations) records role-based constraints compactly.
Action enablers — “if this condition or event, then do this action”. Put complex combinations of conditions in a decision table or tree.
Inferences — also “if… then…”, but the result is a new fact rather than an action: “if payment is not received within 30 days, the account is overdue”.
Computations — formulas or algorithms that produce new information. Put tiered calculations in a table and make sure the ranges do not overlap (with 1–5 and 5–10, where does 5 go?).

Alongside these sit terms: key business words, phrases and abbreviations, best kept in a glossary or data dictionary.

Atomic rules#

Do not pack several rules into one sentence. Wiegers and Beatty cite a guideline from von Halle: no OR on the left side of an if/then rule, and no AND on the right side. Atomic rules change independently. Give them hierarchical IDs such as Booking.Cancel.FreeWindow, which also makes tracing easier.

The rule catalog#

Keep at least these columns: ID, rule text, type, static or dynamic, and source. Static/dynamic matters to developers: rules likely to change belong in configuration or data, not in code. The book tells of an air traffic control system where separation intervals were wrongly assumed static and hard-coded, leading to costly rework. Maintain the catalog at enterprise level, owned by the business, not inside one project’s documents, or each system will implement the same rule differently.

Where to find rules#

Long-serving employees, legacy systems (reverse-engineer requirements or code), process models (look for a rule at each step), documents (old specifications, regulations, contracts), data (object states and what triggers transitions), and compliance departments. “What are your business rules?” does not work. Ask targeted questions: What causes this status to change? How is this value calculated? What do regulators require? What may the user do next?

Link, do not copy#

Link a requirement to its rule through a “source” attribute in your requirements tool, a traceability matrix, or hyperlinks between IDs (which break when documents move). The specification points to the master copy in the catalog, so when a rule changes you can find every dependent requirement. When one rule produces several similar requirements, show them as a table with ID suffixes.

How to apply it#

Collect candidate rules from the sources above and write each one atomically.
Classify each by type; the type tells you how to model it (matrix, decision table, formula table, glossary entry).
Record each rule once in the catalog with source and static/dynamic flag.
Link requirements to rule IDs; never paste rule text into the specification.
Ask developers to keep dynamic rules configurable.
Review the catalog with the rule owners, not just the project team.

Example#

The Workshop, a fictional bike-repair chain, starts with one compound rule: “A booking can be cancelled free of charge up to 24 hours before the slot and rescheduled once, unless a part has already been ordered for it.” Split atomically, it becomes three rules: free cancellation window, reschedule limit, and the parts-ordered exception, each with its own ID.

Template#

Template

| ID | Rule | Type | Static / dynamic | Source |
|----|------|------|------------------|--------|
| Bike.FrameNumber | Every bike accepted for repair has a recorded frame number. | Fact | Static | Operations policy |
| Discount.Approval | Only a workshop manager may approve a discount above 10% of the job total. | Constraint | Dynamic | Owner |
| Parts.AutoOrder | If a repair job needs a part that is out of stock, a parts order is raised with the supplier. | Action enabler | Static | Parts procedure |
| Job.Abandoned | If a bike is not collected within 30 days of the ready notice, the job is considered abandoned. | Inference | Dynamic | Terms and conditions |
| Labour.Charge | Labour charge = hours worked × hourly rate for the job's labour tier. | Computation | Dynamic | Price list |

Pitfalls#

Collecting every fact in the company. Stay within scope.
Compound rules. Split them; otherwise one change forces a rewrite of the whole statement.
Hard-coding rules that change. Flag dynamic rules and make them configurable.
Copying rule text into requirements. Copies drift; link to the catalog instead.
A catalog owned by IT alone. Business units must own their rules.

Sources and further reading#

K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 9.
IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.9 “Business Rules Analysis”.