Business Rule vs Business Requirement? “Requirement” is defined by the International Institute of Business Analysis (IIBA) as enumerated below:
- A condition or capability needed by a stakeholder to solve a problem or achieve an objective
- A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.
- A documented representation of a condition or capability as in (1) or (2).
This definition is based on two constructs: capability and condition. Even though both produce the desired business outcome, they are fundamentally different. In principle, “capability” produces a measurable outcome (i.e., system function). It requires an input(s), which is processed to produce the desired outcome. Multiple instances of the outcome are possible. The inherent unpredictability of an outcome arises from the parameter that dictates the behaviour of a function. However, “condition” has only two predicted outcomes: true or false. Requirements are “what”, “how”, and “when”. However, business rules are a “must”.
What Is a Business Requirement?
“Capacity” describes the ability to do something to perform a specified function that will produce a desired outcome. It is measurable, and every instance of an eventual outcome is pre-defined. The implementation of the “capability” could take various forms. In principle, there is no single perfect solution to build a function.
- “Customer’s ability to apply for a loan”
- “Borrower’sability to repay the loan on a monthly basis”
In the instance of the requirements above, the first requirement has multiple possible outcomes. The loan application can either be accepted, rejected, or referred to the underwriting department for further assessment. However, the second requirement could have only one specific outcome based upon a formula to deduce the repayment capacity of the borrower.
What Is a Business Rule?
A business rule is the “condition” that governs business capabilities. The rule assesses the input, whether it obeys a specific mandate, satisfies a prerequisite, and meets the requirements of a policy and/or a specific compliance criteria. “Capability” functions are similar to a processing line that processes to transform the input to produce the desired outcome. During the processing of the input, there are checks that apply the rules to the input being processed. Rules are positioned to define the path of the enabling process to eventually produce the desired outcome.
The following rules can be laid out to ascertain the “customer’s ability to apply for a loan”:
- First Rule: The customer must have an annual income of 50K before tax.
- Second Rule: The customer must have a full-time job at the time of the application.
- Third Rule: The customer must have a valid residential address at the time of the application.
Thus the function of processing a loan application has rules embedded throughout the process that enable efficient transformation of input to produce predefined output.
The business rules can be broadly classified into the following categories:
- Obligation: The input or an element of the input must meet the obligation.
- Prerequisite: An element of the input must satisfy the prerequisite in order for the function to continue processing the input.
- Constraint must be used in the form or either Policy (a specific decision or set of decisions and related actions adopted by the organization) or Compliance (to a regulation or a governing body requirement).
In reference to the business requirement of “borrower’s ability to repay the loan on a monthly basis”, the following rules can be laid out to drive all the way to compliance:
- Obligation: “The payment must be received by the last business day of the month.”
- Prerequisite: “Repayment must be accepted only if the loan has an outstanding balance.”
- Policy: “Cash repayment must not be accepted.”
- Compliance: “The repayment must be received from the borrower directly.”
The Relationship Requirement and Rules Relationship
The interrelation evolves out of multiple factors that drive the business logic. Moreover, each business requirement is unique and limited with constraints of a dynamic business environment. For instance, the business requirement of “customer’s ability to apply for a loan” may have varied rules that are applicable to specific scenarios. A “loan repayment” is successful when it fulfils all the rules described above in the form of Obligation, Perquisite, Policy, and Compliance.
The language used to define business requirements and rules is essential to effectively communicate and distinguish amongst them. Thus requirements and rules should be stated differently to clearly bring out the meaning and highlight the difference. “Must” indicates an obligation; hence it is recommended to be used for rules. “Should”, “Will”, and “Shall” are recommendatory in nature and better aligned to business requirements. However, it is recommend to use “Shall” as it commends that something is required and associated with a degree of probability.
Why Distinguish Business Requirements from Business Rules?
Validation: Rules and requirements are measured differently. Validating a capability requires testing the function’s behaviour for every possible scenario. Wherein a capability requires an input to produce an outcome, then the outcome should is measured. However, rules require an input, and the outcome is a result of two mutually exclusive states, either a ‘false’ or ‘true’. Every requirement and rule relationship must be tested in isolation for the two possible scenarios of ‘true’ or ‘false’. In addition, every combination of rules constitutes a possible scenario to test.
Structure: Requirements and rules should be stated independently. This has the following advantages:
- Differentiate: We are able to clearly appreciate the “capability” and the rules associated with it.
- Articulating requirement and rules together in one statement makes it convoluted and sometimes difficult to validate, thus making it ambiguous; it runs the risk of missing out on validation of a scenario.
If we were to merge and articulate the requirements and rules for the example discussed in the previous section, it would appear somewhat as follows: “Borrower’s ability to repay the loan on a monthly basis, received by the last business day of the month. Cash must not be accepted, and payment accepted only when there is an outstanding balance. The borrower must make the payment.”
The determination of requirements, while an important process in and of itself, is only part of the requirement process. Requirements communication is a critical part of the process of developing requirements. Understanding and interpreting requirements occurs through their communication, either verbal or written. The manner in which they are articulated and structured is fundamental to their understanding.