We had a great interview with James Taylor a couple weeks ago, where we talked about his new book, Smart (Enough) Systems, co-authored with Neil Raden.
James is an expert on decision management systems. I spent the late 1990s working on “rules-centric” software systems that allowed us to isolate rules and manage them seperately from other software requirements.
Traditional structured requirements approaches focus on the gathering and management of software requirements, but they gloss over the gathering and management of business rules.
James and I are exploring the best ways to bring these two points of view together.
As part of this study, one of the first things we can do is describe the areas of overlap, or rather, how the two worlds (business rules and requirements) interact. From a requirements-centric perspective, one place business rules live is within the decisions that we discover when gathering requirements.
Use cases and process flows involve decisions. In use cases, these are often represented as alternate flows and exceptions. In process flows, they are represented with the familiar diamond shaped box. Conceptually, there are one or more rules that combine to make a decision. And in requirements documents, you often see convoluted language, well-organized tables, or other representations of those rules.
These documents embed the rules within the requirements. And that leads to the rules being validated, verified, implemented, and tested within the greater context of the requirements.
Another example of decisions can be seen easily when using UML statecharts. These decisions are somewhat implicit – as they are defined as the criteria for, or ability to change the state of business objects. In other words, the conditions that allow change are in effect decisions. While it may be harder to find them, these decisions can also be found in use cases. But there are good arguments for using both use cases and UML statecharts together.
What’s The Problem?
As James points out in his new book, one of the worst things you can do is embed the implementation of business rules within a software application. So there’s a fundamental flaw in embedding business rules within requirements.
Requirements management approaches tend to either embed business rules within other artifacts. At the same time, rules-management systems are optimized for the management of rules, with little focus on requirements. Each approach is designed to solve a single problem, and neither sufficiently addresses the challenge of getting the best of both worlds.
James and I will be exploring the issue of how best to bring these two worlds together over the next few months.