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.
Decisions
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.
Moving Forward
James and I will be exploring the issue of how best to bring these two worlds together over the next few months.
Yes, decision points in Process Flows and in determining the scenario path of a Use Case are the two primary examples of where one sees Business Rules. The issue is: what about the business is a software requirement, and what is an aspect of the business irrespective of software?
I have reached the conclusion, aided by good discussions in person and over the web with many smart folks, that Business Rules are not a software requirement; they exist irrespective of whether they can be automated in an information system. Further, Business Processes are the same. The overiding requirement in both these cases is not that a certain process or set of Rules be automated, but that the creation and changing of any process or rule be automated.
This is not dissimilar to the rise of Database Management Systems in days gone by; no project has “automate the storage of data items” as a requirement anymore, it is pretty much assumed that a DBMS will be used.
Thus, the more recent rise of Business Process Management and Business Rule Engine products. Assuming your software is a callable component or service, then a running Business Process can invoke the appropriate software as needed, within which the software can provide data to a BRE to test a rule and resume execution based on the results.
Where does this leave software requirements? The main CRUD functions for managing data are still there to be defined, to me the most important part of an Information System to get right; parsing out process and rules allows us to concentrate even more on the core data management functions. After that, it is everything else that makes up a system, like interfaces (online and batch).
My two cents for today, anyway… d wright
Thanks David!
This is definitely the crux of the challenge – as you point out, rules and requirements are distinct entities. When creating software, you uncover both rules (implicit in decisions) and requirements. The requirements must be satisfied by people following processes, and those processes are subject to the rules.
Managing them distinctly has benefits – but uncovering them collectively seems to be the norm. That’s part of the challenge James and I are tackling – to discover them together, then implement them separately. What’s the best way to manage them, given their tight cohesion (at least in the minds of subject matter experts)?
I agree, rule discovery during requirements analysis happens a lot, probably more so than any in other activity over the long run.
Like many other things, though, SOX and other compliance requirements have had an impact, getting companies to document their rules, as well as policies and procedures if they weren’t documented earlier, without necessarily any IT involvement. They need this with or without systems. As yet another source of information going into Requirements Analysis, I recommend searching out the procedures and rules that may already be documented.
If one’s company has done this compliance work already, its possible the perception of cohesion between rules and requirements may be relaxed somewhat.In this case, the Rules become another aspect of the business that may or may not be automated; not all Rules have to be automated, many important ones aren’t.
James’ first article, and the next one in this ongoing discussion, is Rules and requirements – what do YOU think.
Hi Scott
When writing requirements docs in the past I have sections in a master requiremenst doc that included business processes, business rules, contraints, use cases and non functional specs. It made for a thick doc but provided a holistioc view of the business problem.
THe solution architect would then work with me to carve out which compoenents would be solved with IT and which ones would be better dealt with in the non-technical part of the solution.
It was an iterative process with at least two passes, but seemed to work well. It allowed for a discussion of what rules and processes should be computerised and which system would deal with which parts.
Regards
Craig