⁞⁞⁞⁞ Specifying Entities and Attributes

The analysis documentation should clearly state the rules.  The rules must only be expressed in the names of entities and attributes in the Fact Model. Reason: any extraneous business terms are likely to cause development errors and delays.

Examples:

BAD:  Check each customer’s balance on the client record, and if the amount is not in credit…

GOOD: when, for every client, the client.account.balance field is less than zero then… 

⁞⁞⁞⁞ Specifying Matches

Any rule must specify exactly the data it applies to.  Where entities in the FM are being matched, the exact keys for the match must be specified.

Examples:

BAD:  match customer and car records, and, for cars more than 10 years old…

GOOD: when, for every client, select ALL car records with car.account.id = client.account.id, and for each car.age < today minus 10 years  then…

⁞⁞⁞⁞ Missing Records

The way DROOLS handles missing records is counter-intuitive: generally a missing record means a rule does not get fired.  For DROOLS the analysis documentation must specifically cover all cases where a record might not be present.
In the example below, based on the BA’s rule, a developer might well implement a rule that allows customers to make sales even though they have no credit card.

 BAD:  Stop the sale with Error if customer.credit_card is not active …

GOOD: when customer.credit_card.active=false OR no customer.credit_card    then Error = stop_the_sale

.