Business Rules in Requirements Analysis

Ralph   Nijpels
Ralph Nijpels Business Analyst, Air France - KLM. Read Author Bio || Read All Articles by Ralph Nijpels

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). 

  1. The requirements description describes the requirement in the customers' terms.  
  2. The rationale explains why this requirement is important.
  3. The fit criteria state how fulfillment of the requirement is checked.
  4. 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

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

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).[1]  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.

Business Rules

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.

Conclusion

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.

References

[1]  For information on FCO-IM visit www.fco-im.com/FCO-IM.html.  For information on ORM visit www.orm.net/.  return to article

# # #

Standard citation for this article:


citations icon
Ralph Nijpels, "Business Rules in Requirements Analysis" Business Rules Journal, Vol. 6, No. 12, (Dec. 2005)
URL: http://www.brcommunity.com/a2005/b259.html

About our Contributor:


Ralph   Nijpels
Ralph Nijpels Business Analyst, Air France - KLM.

After having worked as a Lead Software Engineer for a large software company for 10 years and Product Controller for a niche software company for 3 years, Ralph Nijpels is now Business Analyst for the Cargo Business of the largest Airline in Europe: Air France - KLM.

Within the Cargo Business, Ralph specializes in the Commercial Processes, which includes pricing, capacity control, order taking, invoicing, and accounting. He has had both the Requirements Analyst and Implementation Manager roles in defining and implementing custom-made software for KLM Cargo in the last 5 years.

He introduced the combination of business process modelling, fact based data modelling, and business rule management as a basis for requirements analysis within KLM Cargo.

Read All Articles by Ralph Nijpels
Subscribe to the eBRJ Newsletter
In The Spotlight
 John A. Zachman
';
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1
 Silvie  Spreeuwenberg
The BRSolutions Professional Training Suite

BRSolutions Professional Training Suite

All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.