4.1.10 Prioritizing Business Rules

Further to those identified so far, we might easily imagine many other real-world business rules that might logically govern the population of a town. We could be tempted to write all possible business rules down. During our qualitative system dynamics modelling we may have identified many more influencing factors which we could state in a set of business rules much more comprehensive than the short list above. There are very good reasons why we must limit the number of business rules we include in any model:

Some business rules are essential: without them the model will not behave in a way that replicates real world behaviour sufficiently.
Many of the possible rules we might identify do not influence the behaviour of the model to any significant extent. They just complicate things. To determine the extent to which rules govern behaviour we must formulate those rules and then test them, being careful not to add any rules that we cannot completely test.
Some rules are redundant: creating a longer list of governing rules in an attempt to achieve completeness is very likely to result in the re-statement of rules already identified.
Incorporating large numbers of governing rules in our models will result in models that are both complex and, therefore, are difficult to diagnose and much more likely to contain errors.
Human capacity to fully understand feedback dynamics is limited. Adding apparent elegance and sophistication to our models by incorporating large numbers of governing rules is likely to result in mis-interpretation, at least, and at worst, confusion. Even the most experienced modellers will mis-interpret the behaviour of models with any more than a small number of feedback loops. There is considerable evidence in the system dynamics literature to this effect.

The primary goal here is to build models that work, keeping them as simple as possible. Only once they have been tested to ensure they work as intended should they be enhanced to include greater functionality.

Business rules should be prioritized for inclusion according to being critically tested by following questions:

Must the rule be included? Can it be omitted? If the rule is omitted, does the model still respond to input in a logical way that sufficiently represents observed real-world behaviour. If the rule is omitted and the model no longer makes sense, then it must be reinstated.
Can the rule stand alone? Does it need other rules to exist before the rule makes sense?
Can other rules be omitted without affecting the functioning of this particular rule?
Does this rule still make sense if extreme values are inserted?

A practical approach to imposing a strategy for including business rules in any particular model is to categorise them as being:

Primary—contributing essential functionality to the model: without this rule the model will not work.
Secondary—important to the functioning of the model: the model may still work without this rule, though specific and detailed testing may be required to determine the need for this rule to be included in the model.
Unnecessary—contributes no observable or significant function to the model: exclusion of this rule is unlikely to impact on important model functions.

All business rules (and the rationale behind each) must be fully documented because it is unlikely that complete categorization can be applied without error first time around. The case for inclusion of any specific business rule must be made on the basis of the extent to which it contributes to functioning of the model. If there is doubt about any rule, do not include it! There will always be an opportunity to add more rules later. The temptation to retain a rule already built into a model can be very strong, even when it is suspected that the rule may be erroneous or redundant.