System Validation aka Business Rule

When designing a system, the normal tendency of business analyst (a person who is collecting requirements from client) (BA) is to define all the possible business validations that system needs to implement. The idea is to prevent user from accidentally performing an invalid operation which would not align with normal business practice or be against it. In the process of building the list of all these business validations, BA essentially identifies two types of rules. There are ones which are essentially required by the client to ensure smooth running of business by its people and prevent them from making an absolute invalid transaction (or commit fraud). These are basic checks and balances which MUST be in place. These are usually very explicit from customer’s requirements. Then there are others, which are theoretical in nature and are not essentially required to be implemented by system, as these would almost never really be triggered in practice (you could argue that some of these would occur, but usually that’s more in theory and less in practice). These validations are usually not explicit from client’s requirements but added by BA (probably to show that he has given due consideration to client’s requirements and identified all business rules).

In the process of designing system, analysts usually make a big assumption that the end users of the system would be EITHER some brainless people who need to be taken care of at every stage and hence, they need to build every possible check into system OR they are some expert users who would try to take application/business for a ride by performing a malicious transaction and hence, they need to prevent them from doing so. There lies the grave problem. Both these assumptions are incorrect and, they create more problems than they solve. Going for either of the extremes would not help, we should strike a balance between essential validations and optional (nice to have) validations by doing cost-benefit analysis.

Essential Validations

This category of validations MUST be implemented by system, let’s see examples of this to better understand this category. We call these as business rules and these MUST be implemented by the system:

1. In case of scheduling system, you cannot assign a job to an engineer after his shift ends.
2. In case of a passenger check-in system, it should not allow passenger check-in if his name figures in the list of terrorists. (A very important validation rule these days)
3. A customer, holding a plumbing policy from an insurance company should not be allowed to raise a claim for other types of damage to house, say glass and locks repair.

Theoretical Validations

For an inventory management application, it need not have a validation to ensure that the stock-in-hand quantity is not going into negative for a given product. In theory, this is a correct validation rule but in practice there would be number of situations which would cause the system to be out of sync with reality, resulting in an incorrect quantity being reported by the system. In such a situation, if it is blocking a stock decrement transaction saying there is not enough quantity in hand, it is only ballooning the problem and making itself (application) less reliable. Often, such issues get into a snow-ball effect and make a far bigger mess to clean up.

Note: The above conclusion is based on understanding that in most cases, IT systems do not cater to ALL of the real-life scenarios but majority of the scenarios. Software applications mature over a period of time as new features are added, and existing functionality improved to align it with the business realities.

Cost of Implementing Validation Rules

We invest lot more effort and time into thinking what all checks system needs to have so that user does not make a mistake or system does not allow user to make one. We document all these and these so called validations are then implemented by developers with great effort and a lot of time is spent by these developers for testing all these so called business validations. Then, the system tester writes all his system test scenarios for further validations based on the checks defined and spends a great deal of time testing and certifying that application is working as per the validations defined.

Hence, it calls for doing a careful cost-benefit analysis for every business rule to determine whether one should be implemented.

Classic Example

Let me present another classic example of validation rules related discussion. Recently, while working on a web application, which had a complaints page where user could enter number of complaints for an engineer, I came across the following discussions:

1. Should we restrict user and not allow entering number of complaints as zero?
2. What if user enters number of complaints as greater than zero but later goes and edits the number to zero, do we need to restrict it there?

In my opinion, as long as your processing logic, which is working on number of complaints, is correctly considering and processing the value zero and is not affected with the sheer presence of a record with value as zero for a given engineer, why bother for all this? The following wastage occurs:

1. Business Analyst documents the validation check as a requirement.
2. Developer spends time on implementing the rules around it (on Add and Edit page)
3. Tester would write test cases for testing the same with boundary value analysis and so on.

At the end of this exercise of building smartness into your application, what is achieved? Absolutely nothing, we just implemented a validation rule in the system which, in practice has almost zero chances of being triggered and, had it not been implemented, we would have lost nothing.

Data Integrity as an Alternative

There is a concept called as data integrity, which is heavily under utilized or not understood by developers and analysts both. Developers need not implement every validation rule in UI screen; they should take advantage of data integrity rules supported by RDBMS and well design databases. A data integrity constraint defined at DB level guarantees correctness of data all the time and has a far lesser cost of implementation as compared to implementing validation rule in UI. Please note, I am not saying that we need to replace UI validation rules with data integrity (CHECK) constraints but in certain situations, we can effectively use data integrity constraints.

Summary

1. There is a huge cost associated with a validation rules defined as part of business requirements. Hence, one should be aware of this cost and accordingly do the cost-benefit analysis to decide whether a particular validation rule should be implemented by the system.
2. Do not spend too much of time and energy on building validation rules into the system but on adding features and functionality.
3. Remember, systems are meant to assist humans and not replace humans by defining all the validations and business rules and enforcing these.

P.S. In addition to blogging, I use Twitter to share tips, links, etc. My Twitter handle is: @girishjjain

CodeProject