Business Rules Analysis · Business Analysis Notes

What it is#

A business rule is an explicit, checkable statement of how the business must or must not operate, or of how it classifies and calculates things. Rules come from corporate policies, regulations, industry standards and agreed calculation methods. Wiegers and Beatty stress that rules exist outside any software system; they apply even if the work is done entirely by hand. Yet they are one of the main sources of software requirements. A rule is not a process (a sequence of steps) and not a business requirement (a high-level goal); it shapes processes by defining terms, setting limits, triggering actions and governing calculations.

The BABOK® Guide divides rules into two kinds:

Definitional rules shape knowledge: they define what something is or how it is derived. They cannot be broken, only applied wrongly. Example: “A repair is an express repair if the customer paid the express fee.”
Behavioral rules govern what people do. They can be broken, and each has an enforcement level ranging from strictly enforced to merely advisory.

Wiegers and Beatty offer a finer taxonomy that is handy when writing requirements:

Facts: true statements about the business (“every container has a unique barcode”).
Constraints: what the system or users may not do, often signaled by “must”, “must not” or “only”.
Action enablers: “if this condition, then do this action”.
Inferences: “if this condition, then this new fact is true” (for example, an invoice unpaid after 30 days is overdue).
Computations: formulas or algorithms that transform data.
Terms, kept separately, often in a glossary or data dictionary.

When to use it#

When policies, regulations or calculations drive what a solution must do.
When the same rule appears in several processes or systems and must behave consistently.
When rules change often and you want changes to be cheap.
During elicitation, requirements maintenance, tracing and change assessment.

When not to use it, or what to add: if the logic is a repeatable decision with many interacting conditions, model it with Decision Modelling (decision tables) rather than long rule lists. The BABOK Guide warns that rules can end up ambiguous or contradictory if they are not checked carefully or if the business vocabulary is weak, so pair this technique with a Glossary.

How to do it#

Elicit rules from several sources. Wiegers and Beatty list long-serving staff, existing systems (reverse engineering), process models (look for a rule at every step), documents such as policies, contracts and old specifications, data analysis (what causes an object to change state), and compliance departments. Asking “What are your business rules?” rarely works; ask targeted questions instead: “What makes this status change?”, “How is this value calculated?”, “What do regulators require?”, “What is the user allowed to do next?”
Separate rules from requirements and processes. State each rule declaratively, independent of who enforces it or which screen shows it.
Classify each rule (definitional or behavioral; fact, constraint, action enabler, inference or computation).
Make rules atomic. Split compound statements. Wiegers and Beatty cite von Halle’s guidance: avoid “or” in the condition part of an if-then rule, and avoid “and” in the result part.
Catalog them. For each rule record an ID (hierarchical IDs such as Booking.Lead-Time help tracing), the statement, its type, whether it is static or dynamic, and its source.
Use tables for complex logic. For calculations with ranges, use a table and make sure ranges do not overlap. For many combined conditions, use a decision table or tree.
Link requirements to rules by reference, through a source attribute, a trace matrix or links. Do not copy rule text into requirements; when a rule changes, you then find every affected requirement at once.
Assign ownership. Wiegers and Beatty recommend that the catalog be owned at enterprise level by the business, not by one project or the IT department, so that one rule is not implemented differently in different systems.

Example#

Part of a rule catalog for The Workshop (a fictional chain of 12 bike-repair shops):

ID	Rule	Type	Static or dynamic	Source
Booking.Lead-Time	An online booking must start at least two hours after it is made.	Constraint (behavioral)	Dynamic	Operations manager
Customer.Plan-Holder	A customer with an active service package is a plan holder.	Fact / definition	Static	Service package terms
Repair.Ready-Notice	If a repair is marked complete, the customer is notified.	Action enabler	Static	Customer service policy
Repair.Overdue	If a repair is not complete by the promised date, it is overdue.	Inference (definitional)	Static	Customer service policy
Price.Labour	Labour charge equals hours worked times the workshop’s hourly rate.	Computation	Dynamic	Price list

A requirement such as “The system shall send a message when a repair is marked complete” then refers to Repair.Ready-Notice instead of restating it. Because the lead time and labour rate are dynamic, the analyst records that they must be configurable, not built into code. Wiegers and Beatty describe a case where a rule wrongly assumed to be static was hard-coded and later required major rework.

Common mistakes#

Rules buried in requirement or process text → extract them into the catalog and reference them.
Compound rules → split into atomic rules with their own IDs.
Asking stakeholders to list their rules → ask targeted questions about states, calculations, permissions and regulations.
Overlapping ranges in calculation tables (1–5, 5–10) → define boundaries so each value falls in exactly one range.
Hard-coding dynamic rules → mark rules static or dynamic and make dynamic ones configurable.
A separate catalog per project → keep one business-owned catalog.

Checklist#

Rules were sought from people, documents, systems, processes and data.
Each rule is declarative, atomic and uses glossary terms.
Each rule has an ID, type, static or dynamic flag, and source.
Complex logic is in tables, with no overlapping ranges.
Requirements reference rules instead of copying them.
Rules were checked for conflicts and gaps.
A business owner maintains the catalog.

Sources and further reading#

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”.
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Ch. 9 (rule taxonomy, atomic rules, rule catalog, sources of rules, linking rules to requirements).