Are requirements and business rules the same thing? Unfortunately, no. But it’s a good question: many people get interested in business rules because they are in the requirements phase of a software project, and they wonder if business rules could help them.

Business rules tell you how a business is intended to be run in its day-to-day operation, independently of projects to make or change software. Many stakeholders other than software suppliers have a potential interest in business rules: operators “on the workfloor”, people who write work instructions, but also process designers, financial and legal advisors, and the quality assurance department.

Requirements tell you what must be done to complete a project (often, a software project) successfully. More precisely, requirements analysis is a structured method of drawing up the right list of prioritized tasks for project execution. Once the project is completed (and documented), requirements are stored in an archive.

You might think that business rules describe the as-is situation and requirements describe the to-be situation, but it’s not as easy as that. You can choose to describe the current business operation or some future, improved way of conducting the business (and by the way, you do need to know which of the two you’re doing), but they’re both business rules.

Another idea that goes around is that business rules are about “the business” and requirements are about “IT”. Politically, that’s not a helpful separation when we’ve all been saying for 30 years to each other that the gap between business and IT must be bridged. Technically, it’s incorrect. IT systems are part and parcel of everyday business operations. You cannot write business rules successfully if you don’t allow yourself to talk about systems and applications. What matters is finding a way to talk about them in terms that all stakeholders can understand.

The secret connection between requirements and business rules is that the information contained in good business rules is of vital importance to requirements analysts. Ideally in their project, they need both: project-independent business rules, and project-specific requirements. Consequently, they need a tool where:

  • They can put both.
  • They can register the connections between the two.
  • They can flag which are the rules and which are the requirements.
  • In the rules, they can flag the ones that lead to project work and the others, which are for information only and which make the reasons for a requirement traceable.

Such a tool should also offer, of course, the goodies expected of any management tool, like reporting options and sound version control.

It all seems like a lot of extra work. The good news is that in practice, you don’t need to translate each and every rule into a separate requirement. In many cases, if you register that the software team must “do” the rule in a project, it’s pretty obvious what it is they need to do. Think of calculations of amounts of money, or privacy restrictions on data entry. And once the project is completed, you can re-use the rules for a next project instead of filing them in an archive. That way, with the next project, there’s no need for another full round of requirements interviews in which departments have to explain yet again how they work.

[su_button url=”” background=”#92b713″ size=”4″ center=”yes” radius=”0″ icon=”icon: envelope”]Leave a reply[/su_button]

Leave a reply