Business Rules And Requirements

What is the difference between a business rule and a business requirement? Does the difference matter? A business requirement is something that is multi-customer, and a business rule represents a single customer’s approach to meeting that requirement. Product managers and analysts care about both, but product managers emphasize requirements, and analysts focus more on rules.

A Simple Example

We’ll set the stage for discussion by showing a requirement, a rule, and a design and implementation.

• Requirement – The building will provide a measure of protection against fire damage.
• Rule – Firefighters will be assured access to the building to enable extinguishing of any fires.
• Design – The street near the fire hydrant and main entry of the building will be reserved for exclusive use of firefighters.
• Implementation – A sign will be posted in a visible location, instructing people not to park in the reserved location.

Background

The debate about requirements versus design, and the level of detail of specification has been an active one over the past year. We’ve written about how you can imagine software as an onion, where implementation is wrapped in design, which is wrapped in requirements. When we include awareness of business processes as part of what we’re doing, we can add another layer – business rules.

One point of confusion may be that many contracts are described as “gather requirements” when in reality, the work is “define rules appropriate to a set of predefined requirements.” This inconsistency leads to many debates that include arguments like “that isn’t a requirement, therefore it must be design” with the response of “that isn’t design.”

Ideation

Moving from each layer to the next involves ideation, and exhibits concreteness. For a given requirement, an approach can be defined for meeting that goal, and with that approach comes rules. For each rule, a design can be selected, and for each design, an implementation is created.

Each step involves ideation – making inventive choices about how to achieve that next step. Consider our example. We have the requirement of providing protection against fire damage. We could choose to achieve this requirement by mandating that only non-flammable materials be used in the construction of the building, or by integrating fire suppression equipment in the building, or by optimizing the access for firefighters to the building. Once we make that choice – an ideation step – we define the rules that express how we will achieve our goal with the selected approach. Our rule is assured access in this example. The design approach is to reserve the street near the main entry to the building. The implementation of this “reservation” is a sign. It could be special barricades that block access to anyone who isn’t a firefighter.

The point is that there are choices at each step of the way.

Each step becomes more concrete, more focused, and more narrowly applicable.

Product Managers Are Market-Centric

As a product manager, when interacting with customers to better define the needs of the market, we need to recognize that the rules are not the requirements. In the example, access for firefighters isn’t the requirement, protection against fire damage is the requirement. This is the level of abstraction that can be used to describe market needs.

Business Analysts Are Customer-Centric

A business analyst needs to understand the requirement (protection), but only in so much as it affects her company. This allows her to explore alternative rules (access, suppression, prevention, etc.) that will achieve the requirement.

Requirements Elicitation Can Fall Short
When we interview people to gather requirements, they will usually talk about implementation, design, and rules. Rarely will they describe requirements. Users and subject matter experts (SMEs) generally talk about implementation and design (“We have a sign, because the street needs to be reserved.”). Our elicitation techniques and listening methods help us identify rules by asking “Why?“ (“To assure access to the building for the firefighters.”). Without those techniques, we will only uncover implementation and design.

Getting to Requirements From Rules

To get to the requirements, we need to keep asking why. (“To provide protection against fire damage.”) If we keep asking “Why?” we will eventually get to a useless “primary goal.” And by useless, we mean that it is a goal that is too nebulous to drive anything actionable. Consider these possible chains of why questions and answers for our example:

• Why provide protection against fire damage? To allow us to meet city codes. Why does that matter? So that we can legally rent out space in the building. Why does that matter? Because we need to rent the space to make a profit. Why does that matter? Because our shareholders demand it.
• Why provide protection against fire damage? To allow us to charge higher rent to tenants. Why does that matter? Because we need to maximize our profits. Why? Shareholders.

Part of the art of product management is knowing when to stop. “Protection” is actionable. “Satisfying shareholders” and “Profit”, while laudable goals, do not provide the needed direction and detail to be actionable.

Summary

The line between requirements and design is broad, and is more of a region than a line. Rules live in that region – from one perspective they embody a design approach to achieving a requirement. From the other perspective, they represent the business requirement, in more detail. Use elicitation techniques and ask why to uncover the rules and requirements.