Business Rules in Requirements Analysis
What does the organization need?
There is one clear giveaway that something is wrong with the capability of an organization to accurately describe what it needs: the stack of change requests appears as soon as a project is done. Unfortunately a lot of organizations instinctively jump to the conclusion that the change process is forming a bottleneck, and they resort to ever more sophisticated change management processes. However, this is unsuccessful because they essentially are fighting the symptoms instead of the disease -- even if projects are delivered on time and within budget, if the subsequent result is a big pile of requests for reasonable changes then that project did not do a very good job in solving the problem it set out to solve. To address this problem correctly the question is not "how do I manage this pile change requests?" but, instead, it's "how do we improve our capability to determine what is needed?"
Requirements Analysis is the process of determining what is needed and it is (or should be) part of every change project if the project is to stand half a chance of being successful. Most organizations know this and perform some form of Requirements Analysis when creating business cases. However, few organizations go beyond creation of the 2-4 page description needed to obtain offers from vendors who will fill in the numbers on the business case form. Indeed, this is a form requirements analysis and it could be argued that some analysis is far better than none at all. But in reality this form is too shallow and, at the time of implementation, will result in the thankless job of fighting the fires whilst blaming the vendor for delivering sloppy products. A good Requirements Analysis process is a thorough one.
What are requirements?
A requirement is a statement or brief description of the services and qualities a customer would like included in a product. Every requirement consists of four key parts (plus some version control stuff).
- The requirements description describes the requirement in the customers' terms.
- The rationale explains why this requirement is important.
- The fit criteria state how fulfillment of the requirement is checked.
- Lastly, the priority states how happy the customer would be if this requirement were fulfilled (or how unhappy if…).
Regardless of what the organization is buying there are six types of requirements, split into two main groups. The first group -- functional requirements -- consists of
- process requirements,
- information rules, and
- business rules.
The group of non-functional requirements consists of
- look & feel requirements,
- performance & operational requirements, and
- maintainability & supportability requirements.
Although all types are equally important this article focuses only on the first group, functional requirements.
Process requirements are found while exploring the business process the product is supposed to support. For example, when renting a car the process can be: booking of a car, picking up a car, and returning a car. In this case, an example of a requirement could then be "The product must be able to register the booking of a car" because "Rentals may be booked in advance." Process requirements are usually fairly high level and focus on the key functions of the product.
The requirements description of each of the requirements can be put into RuleSpeak™ format. The benefit of doing this is that the requirements become more direct and less ambiguous. Process requirements typically start with "The product must...." All business rule do's and don'ts apply: a rule must be atomic; a rule must be a rule (and not an enforcement); no AWOL subjects.
An important notion is that the rationale of a process requirement is a business rule, albeit one on more of a strategic level. If no such business rule can be found to support a requirement then there is no ground for having the requirement in the first place. Uncovering those business rules is important because this knowledge can be used as a filter to weed out the obsolete "it's always been that way…" stuff that no longer contributes to the product.
Information rules are found by examination of the paperwork going into and coming out of a process. For example, in renting a car the paperwork may consist of the booking requests and the schedule holding the reservations. Part of this information may be recorded in current automated systems; e-mail correspondence between parties in the process may hold evidence of information that is missing from the current system. It is important to obtain filled-in examples of all communication; screen dumps can be very useful for the 'paperwork' that has been automated.
These requirements are extracted by a process called verbalization and leads to structural rules such as "A single customer rents one or more cars." Verbalization is part of information modeling techniques like FCO-IM (Fully Communication Oriented Information Modeling) or ORM (Object Role Modeling). The quality of the rule will improve if it is written down in present time and appropriate quantifiers are added. These rules build on 'facts' and appear in a requirements description without a rationale or fit criterion.
Requirements based on business rules are found by further exploration of the business process requirements. A typical approach consists of exploring business scenarios with a group of stakeholders. A rule of thumb is that business rules are found when you establish the reasons for stopping a scenario. 'Stopping a scenario' includes stepping into an alternate scenario or an exception scenario. For example, a rule that governs an exception scenario for renting a car might be "An alternative car must be offered if the requested car is unavailable." Business rule techniques help in the discovery of derivation and calculation rules; the above rule implies that something exists called an 'alternative car'. Hence there must be a (set of) rules that explain what it is that makes a given car eligible to be an 'alternative'.
The second important way to find business rules requirements is by reviewing the information rules. The typical approach is to establish the boundaries of the different terms and quantifiers used in the structural rules. For example, a rule that limits the number of cars rented by a single customer could be: "A customer may not rent more than 3 cars at the same time." This becomes part of the requirements description component of the requirement.
Business rule techniques also assist in finding an appropriate enforcement of the rule. Enforcement does not stop at printing error messages; it may include reporting afterwards, warning a supervisor, or obtaining explicit authorization. This enforcement information is part of the fit criteria of the requirement.
Business Rules are an integral part of the Requirements Analysis process -- both as a subject on its own and as a way to sharpen the results of the other analysis techniques. A combination of Business Process Modeling, Business Rules Management, and Conceptual Data Modeling forms a holy threesome that is uniquely capable of completely and accurately describing the Business Model underpinning the Requirements.
# # #