The importance of business rules is obvious for business analysts. However, how to document the business rules identified is often not that obvious. The truth is that it can be done in many different ways.
A lot of great tools exist for documenting business rules, managing business, simulating business rules etc. Elaborating on the business rules tools is the scope for another post. In this post I will describe some tips on how to document the business rules e.g. by using Microsoft Excel. The advantage of using Microsoft Excel is, that it is easy to use, probably already installed on your machines, and most important; both the business analysts and the end users are familiar with Excel.
Before digging into the process of documenting the business rules some concepts needs to be in place. Business rules is an integrated part of specifying use cases and the business rules as such are documented directly in the use cases. If you are using word for specifying use cases you need
1) business rules documented with a unique ID, and placed at the relevant use case steps as shown below (use case specification screen dump):
…. and
2) You need an overview of the relationships between use cases and business rules. In the above picture it is documented that, that specific use case is using/related to business rule FR1, FR2, FR3, FR4. However, it might be that another use case is also related to e.g. FR2 and FR3.
Creating a Use Case ß à Business Rule Matrix in Microsoft Excel could look like illustrated in the picture above.
The Use Case ß à Business Rule Matrix gives you an overview of which business rules are used in a use case and in which use cases a specific business rule is used. An overview like that is a must have, if the number of business rules is high and/or if the business rules are likely to change frequently.
If your business rules are facilitated during requirements workshops and the business rules are relevant for the use cases only, you are probably all set with the approach described so far. However business rules management is sometimes a complicated act.
If the business rules are extracted from plain text e.g. from guidelines, law text, union agreements or similar, it is necessary to document traceability from the plain text to business rules to be implemented and finally to a business rules matrix.
Let’s look at an example. Imagine having a law text, a union agreement or another document describing rules in a plain text unstructured manner. One way to extract the business rules from such a document is to simply cut ‘n paste the text in small pieces one piece at a time and label each piece with a unique ID. For example you could end up with the rules “Plain text – X”, “Plain text – Y”, “Plain text – Z”, and “Plain text – Q”.
Those plain text rules are not ready to be implemented by the developers. First, they are probably ambiguous or hard to interpret. Second, it might be, that the rules “Plain text – X”, “Plain text – Y”, and “Plain text – Z” and all saying the same thing, just in different words or even in the same words captured from different places in the original law text document.
What needs to be done in order to document the business rules is to map the pseudo rules to (implementation) Business Rules. This needs to be done because the pseudo rules might be redundant and not probably defined for implementation.
In the figure below the business rules copied from plain text (orange) are individually mapped into pseudo rules (described like pseudo code – e.g. “If date = 1/5 Then Salary Supplement X is granted”). The Pseudo rules then needs to be mapped into Business Rules ready for implementation. If “Plain text – X”, “Plain text – Y”, and “Plain text – Z” and all saying the same thing they are all mapped to the same Business Rule (in this case Business Rule -1). By doing it this way you’ll get the following advantages:
1) If a pseudo rule changes, it can be documented even if the change has no impact on the Business Rules.
2) If a pseudo rule is deleted the implementation is still valid
3) If several pseudo rules are saying the same thing, you only implement the Business Rule realization once
When the pseudo rules are mapped properly to Business Rules, the next step is to document the rule flow. The rule flow specifies in what sequence the business rules are triggered, and if business rules can co-exist or excludes each other. For example if Business Rule – 1 is specifying a supplement being granted for each hour worked on Sundays and Business Rule – 2 is specifying a supplement being granted for each hour worked on the date 1/5. The question is then; If an employee is working 1/5 and it just happens that 1/5 is a Sunday, should the employee have Business Rule -1 triggered, Business Rule – 2 triggered, or both Business Rule -1 and Business Rule – 2 triggered?
The answer to such questions should be documented in rule flows. An example of a rule flow reflecting the example is illustrated below.
To summarise, the following rule of thumbs exist:
1) Business Rules must be documented
2) Business Rules must have a unique ID
3) Business Rules usage must be documented e.g. in a matrix
4) Business Rules originating from plain text must be documented if plain text, pseudo rules and mapped to business rules
5) Business Rules involving context conditions must be documented in rule flows
