Business rules and system requirements in IT | 2022

How to describe business rules. Differences between business rules and system requirements

Work on any IT product/system always starts with gathering requirements.

In an ideal universe, a business analyst works on the side of a business representative to collect the wishes and requirements of customers and form them into business rules. Then a systems analyst works on business rules, forming requirements to the system. But often the position of “business analyst” is omitted: in business this position is absent, in IT team this role is combined by system analyst. Many people have a question, how to allocate business rules correctly, how they differ from the requirements to the system, and why allocate them at all, can’t we start forming requirements to the system at once?

To begin with, let’s define the concepts of “Business Rules” and “System Requirements”.

The Business Rules Group (2012) defined business rules from both a business and information systems perspective.

From a business perspective: “a business rule is an indication of an obligation to behave, act, adopt a procedure or procedure in a particular activity or industry.

• From an information system perspective: “a business rule is a statement that defines or restricts a particular aspect of business. It is intended to establish a business structure or to manage and influence business activities.”
• System requirements, according to Carl Wiegers, define what a product’s behavior should be under certain conditions. System requirements are described in the form of traditional statements with the words “shall” and “must”.

Identify business rules are necessary in the first phase of work on the product:

• Identify the business rules;
• Document;
• Agree with the business.

Let’s take a closer look at how to properly describe the business rules. To do this, the following rules can be applied:

1. Business rules should be formulated in the language of the business. Technical terms should not be used in describing business rules.
2. The language of business rules should be understandable to a member of the business who is not an IT expert. After describing the business rules, try to abstract away from your technical knowledge and put yourself in the shoes of a business representative, the head of the company for which you are developing the product. Do you understand the written document? Does the document not contain technical terms, references to systems and programming languages?
3. A business rule should describe a business rule, not how the system works. A business rule description should describe the business requirements that the system must solve, but without describing how the system works. For example, a business has a rule: “Keep track of employee arrival and departure times at the workplace.” Business rule should not describe how to achieve compliance with this rule: whether the employee will be recorded in the logbook coming and going, or at the entrance will be an automatic pass system, which will record the time.
4. The business rule should describe the restrictions: which operations cannot be performed.
5. Restrictive business rules can define user restrictions. For example: “An insurer can write no more than 5 drivers into a MTPL policy”; “Only a customer of the company can place an order online”.
6. Business rule is subject to business: accept, change, cancel.

Business representatives can change business rules, amend or cancel.

The example shows the difference between the formulation of business rules and system requirements. One may wonder, what role do business rules play if their content is less disclosed than the description of requirements? Do business rules need to be described at all?

Business rules exist to clearly define the goals of the business.

Business understands the language of business rules. The language of the system requirements description is not clear to business. At the coordination stage of BP business can understand if their wishes and requirements are correctly fixed.

Business rules are the basis for writing the requirements for the system. One business rule can be a source for several requirements for the system.

Correctly recorded business rules reduce development risks. Do not forget the golden rule: “The earlier inaccuracies in the requirements are identified the cheaper it is to fix them!

Collect business rules, create products that meet customer requirements!