Archive of Business Rules Articles

We know to treat business rules and business requirements differently. One example - treat external government regulations as rules (because they are less subject to change than requirements). When you have multiple systems in an architecture, while “rules” makes sense for one system, “requirements” make sense for another. What do you do?

Some books on how to write and manage requirements mention using a glossary. Most books on requirements don’t go into enough detail about either the importance of a glossary of terms, or the precise use of the glossary of terms. Or if they do, they under-emphasize the benefits of a well-defined glossary of terms. Walking a day in the moccasins of a business rules analyst helps us all appreciate the importance of a well-managed glossary of terms.

We’ve written before about the importance of separating rules from requirements, particularly in use cases. We wrote that with the goal in mind of reducing the costs of system maintenance. Low-level rules like decision, calculation and inference rules tend to change frequently - and independently of other requirements. So a documentation approach that separates these rules from requirements can both reduce implementation costs (by encouraging separated implementation) and reduce the time required to manage and approve changes.

There are also benefits to abstracting high-level, or procedural rules, when dealing with global business requirements.

Each elicitation technique we have in our toolbox is a tool. But not every elicitation job is the same. If we have a hammer, we might be working with nails, or screws, or even an egg. In our analysis, we have to develop a deep understanding of our customer’s business(es). And that means we need to understand not only the goals and ROI, but the processes, rules, and requirements. Which is the right tool for each job?

Separation of business rules from requirements is a good thing. Not because of semantic distinctions, but because it allows you to write better software, write it faster, and change it more easily. This article is a response to an excellent comment on our recent article about hidden business rules. Thanks for challenging the idea - it either eliminates it from discourse or makes it stronger, and we all benefit. Here’s an attempt to make it stronger.

The 10th International Business Rules Forum is coming up fast in October 2007. Scott Sehlhorst and James Taylor will be presenting Getting it Right. Rules and Requirements in Software on Thursday at the conference. The articles on rules and requirements that he and I have been publishing on our blogs for the last few months are leading to this presentation. The IBRF has graciously offered a 10% registration discount code to readers of Tyner Blain. Read on to get it.

Business rules are not requirements. Yet they are often gathered at the same time as requirements, from the same sources, by the same business analysts. And unfortunately, often documented in the same artifacts. In this article we look at some of the ways that business rules are commonly hidden inside use cases.

In our ongoing exploration of how to meld the worlds of business rules and requirements, we look at an example use case and see how to extract the business rules.

We’ve written in the past about why it is important to gather and manage requirements. In short, you avoid some costly mistakes, and fix others before they become too expensive. We’ve also started exploring how business requirements and business rules live and play together. But why should we bother to separate business rules from requirements? One reason is to increase your company’s agility.