Systems analysts have long been able to describe enterprises in terms of the structure of the data those enterprises use and the organization of the functions they perform, but have tended to neglect the constraints under which the enterprise operates. Frequently these are not articulated until it is time to convert them into program code. While rules which are represented by the structure and functions of an enterprise have been documented to a degree, others have not been articulated as well, if at all.

A developers experience of working with ILOG JRules for two years. The good things he found, the problems he encountered and his general views on rule engines.

Last time, we covered the second of the three layers (cost reduction, revenue growth, and strategic control) that can contribute value to your ROI calculation. In this installment we explain the third one, strategic control. The third way in which enterprise decision management can show a return is in strategic control. Although putting a monetary value on this control can be hard, organizations adopting this approach can gain a measure of strategic control over their information systems that can offer increased value.

I am asked this all the time. What is the difference between a business rule and a business requirement? It is simple, really. Business rules are lists of statements that tell you whether you may or may not do something, or give you the criteria and conditions for making a decision. One factor of a business requirement is what you need to do to enable the implementation of and compliance with a business rule.

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.