Writing a Rule For Specification
When do we use the RuleForInterpreter?
The RuleForInterpreter is used to express concrete and measurable business rules. The business rules are often related to all kind of calculations.
When a table of rule is executed, 
compares the values returned by the system under development against the expected values defined by the Business Expert.
First row: Identification of the Rule For
In a Rule For table, the first row specifies the name of the interpreter and the name of the rules to be tested.
The business expert should be clear in the identification of the set of rules.
- Example Division : A simple system performing divisions. In that particular case, we could define the set of rules as Division which leads to:
- Example Mortgage : A Mortgage management system with the following specifications:
"Whenever the down payment on the property is less than 25% of the sale price, the buyer has to pay a premium for insuring the mortgage. The premium fee amount is 2.5% of the financed amount (which is sale price - down payment)."
For that particular calculation we could identify the set of rules as:
| rule for |
insurance premium fee calculation |
The second row is called the header row and serves to distinguish between the given values and the expected values. Given values serve as inputs to the system, whereas expected values serve as comparison values against values that are actually returned by the system. When a column header ends with special characters ? or (), it denotes an expected value.
- Example Division : The given values for that example are the dividend and the divisor. The expected value is the quotient.
| rule for |
Division |
| dividend |
divisor |
quotient? |
- Example Mortgage : The given values for that example are the sale price and the down payment. The expected value is the premium fee.
| rule for |
insurance premium fee calculation |
| sale price |
down payment |
premium fee? |
Third and following rows: Examples
The remaining rows capture the examples. They are the executable test rows.
Final expression of the Division example
| rule for |
Division |
| dividend |
divisor |
quotient? |
| 6.0 |
2.0 |
3.0 |
| 7 |
2 |
3.5 |
| 18 |
3.0 |
6 |
| 15 |
2 |
8 |
Final expression of the Mortgage example
Specification: "Whenever the down payment on the property is less than 25% of the sale price, the buyer has to pay a premium for insuring the mortgage. The premium fee amounts is 2.5% of the financed amount (which is sale price - down payment)."
| rule for |
insurance premium fee calculation |
| sale price |
down payment |
premium fee? |
| $100,000 |
$15,000 |
$2,125.00 |
| $100,000 |
$30,000 |
$0.00 |
| $100,000 |
$25,000 |
$0.00 |
When there is no expected value specified in a cell, provides the value calculated by the system under development. The business expert could use that functionality to facilitate the comprehension of a rule. In this example, the financed amount of mortgage can be evaluated as an intermediate result.
| rule for |
insurance premium fee calculation |
| sale price |
down payment |
premium fee? |
financed amount? |
| $100,000 |
$15,000 |
$2,125.00 |
|
| $100,000 |
$30,000 |
$0.00 |
|
| $100,000 |
$25,000 |
$0.00 |
|
Execution of specifications
Based on those executable specifications, the developers are now ready to code the functionality and the fixture (the fixture is the link between the system under development and the executable specification). Once this is done, the specification can be executed by clicking on the Execute button on the top of the page.
During execution, colors only the cells of the column "expected values". will color the cell green if the returned value equals the expected value. If the returned value is not the same, will color the cell red and will show the expected and the returned values. Finally, if an expected value is left blank by the business expert, colors the cell in gray to signify that no test was performed and shows the returned value.
