As a Developer
I want to understand how to document business rules
So that we can increase the speed of delivery

Another of the more difficult capabilities in data warehousing is the definition and documentation of business rules.  And if it is hard when we have months to do it in a waterfall project it is even harder when we have to do it as a small part of a three week iteration.

In the past we have written large documents with a mass of words that ecapulates the business rules.  Long strings of text that are hard for both the the business user and the developer to understand and which stil require a larg amount of interpretation.

We would often use a Psuedo Code approach.  This is where we write the SQL code for the rule and then rewrite it in a document in a way that makes it slightly more consumable and understandable by the user.  Or we would write the business rule document, then the Psuedo Code then the developer would write the production SQL code,  All involving latency and interpretation both which introduce risk of misunderstanding and rework.

In some extreme cases I have seen the technical business analyst write code as the requirements and this code was then cut and pasted into the ETL tool and pushed to production.

Again we are able to reuse some concepts and templates from readily available and mature discipline, in this case business rule notation and business rule engines.

Businesss rule notation and business rules engines are used to define the business rules required for operational processes.  For example to determine when to approve an insurance application and when not to.

Business rule notation gives us a quasi language for defining the rules and the business rules engines give us processes or patterns when can use to code these rules.

One of the primary templates this approach uses is Decision tables.  Another, and perhaps better name for these is “Rules with Data”.

– Rule with Data

[[background for decision tables]][[show the rules using data]][[humans can see patterns easier]][[users can point to a column and point toi a value to discuss, no need to interprete what they are talking about, reduces latency and misunderstanding]][[case study where key stakeholder fund a gap in the pattern]]

Another template we can use is business rule notation.

– Business Rule Notation


The last approach we can adopt is business rule classification.

I don’t use this approach a lot, as I find the the Rules with Data and Business Rule Notation suffice to get the job done.

[[7 types of rules classification]][[example classification]]