The Thin Line Between Business Rules & Requirements

Business rules tell a lot about how a process works and serve as sources of requirements. Systems and processes should be designed to support the implementation of business rules and enable their enforcement.

Requirements elicitation sessions typically start with the question, “How do things work?”. By gaining an understanding of what works and what the business rules are, analysts are better positioned to identify the business rules from which requirements may be drawn. Business rules are an excellent source of requirements especially since these rules need to be followed by process participants and enforced by the system. They form the basis for making process decisions, after all.

Requirements may therefore be defined as, “What the business needs (conditions and capabilities) to enable it comply with business rules”. Requirements must therefore be in compliance with business rules and not contradict them.

BABOK defines a business rule as a specific, actionable and testable directive under the control of an organization, which supports a business policy. For example, a business rule may state, “An employee is entitled to 22 annual leave days only per year”. Examples of requirements that may be drawn from this include: 1) System shall allow staff select the type of leave required and 2) System shall allow staff apply for a maximum of 22 annual leave days in a year.

Business rules should be appropriately documented and accessible to everyone since they influence how process decisions and task routings are handled. Introducing new business rules or changing existing ones may trigger the need for new requirements or a change to existing ones so be sure to analyse any proposed changes as this can affect the solution in place.

A quote from Gladys Lam cleverly emphasizes the need to separate business rules from their implementation:

Business rules and requirements, though similar, require different tools and approaches to managing them.