What is a business rule?
Hello there! The word of the day from BABOK® v3 – business rule. It is a specific, practicable, testable directive that is under the control of the business and that serves as a criterion for guiding behavior, shaping judgments, or making decisions.
Business rules are non-functional requirements. That means they are not requirements by themselves but the origin of several types of software requirements. According to BABOK® v3, there are the following categories of business rules:
- Definitional business rule. A rule that indicates something is necessarily true (or untrue); a rule that is intended as a definitional criterion for concepts, knowledge, or information. Also known as a structural rule. These rules state facts that are important for an organization;
- Behavioral business rule. A business rule that places an obligation (or prohibition) on conduct, action, practice, or procedure; a business rule whose purpose is to shape (govern) day-to-day business activity. They are also known as an operative rules. These are do’s and don’ts.
According to Karl Wiegers, Joy Beatty, and “Software Requirements, 3rd Edition”, there are the following categories of business rules:
- Facts. These statements can be proven true when supported by evidence, thus true for everyone. Some examples include: whales are mammals, Kyiv being the capital of Ukraine;
- Constraints. This kind of rule restricts the actions of actors. Here falls organizational policies, government regulations, industry standards;
- Action enablers. They are specific conditions that trigger actors to perform such action or trigger other triggers;
- Inferences, or if / then rules. They are also known as inferred knowledge. They specify that if one fact is actual, we imply another is true. Inferences do not trigger action; they provide knowledge;
- Computations or calculations. These rules describe the transformation of data, like mathematical formulas or algorithms.
Why are business rules so important?
Business rules exist beyond specific software applications as they are real-life facts. However, they dictate the functionality system must include. Or they may become particular quality attributes. As you see, you can trace the origin of implemented requirements to business rules. For example, when a stakeholder describes accountability and responsibility for some activity or cites enterprise policy, they might present a business rule. That’s why I don’t know any other non-functional requirements that usually significantly impact software.
Young business analysts may confuse business rules with business requirements, so I want to stop this right now and once and for all. Business requirements serve as the justification for undertaking a project. They describe activities needed to transform the organization from its current state to its future state, usually by automating business processes. On the other hand, business rules influence business processes from another point of view. Specifically, they define shared vocabulary, restrictions, and policies that guide day-to-day activities, already defined by business requirements.
Having undocumented business rules is a poor choice of keeping them. When a few experts, or sometimes even a single person, has access to some knowledge, it’s a huge problem when they leave an organization and create a void in a particular information space. And still, many companies mistreat their essential business rules. Some units may document their local rules and share them with adjacent units. But that’s not nearly enough if the rest of the organization does not have a single place to keep rules or even document them. Treating this vital information in the heads of individuals instead of being written leads to numerous problems, yet nobody cares.
This causes a lot of headaches for BAs, who need to know who to call to learn about rules, how to handle conflicting understandings of the rules, and how to fix inconsistency or not overlook some rules entirely. That’s why when BA has the influence to initiate the creation of a repository for business rules, that will make it much easier for every project that is affected by specific rules to be implemented most efficiently.
How to elicit business rules?
Top techniques
Business rules analysis is a technique by itself, but it only describes the types and categories of rules. To elicit them, analysts require the help of other techniques:
- Interviews. You may get all kinds of information when eliciting information from people in person. But I suggest you focus on what could be undocumented, like stakeholder know-how, industry-wide business practices, or norms of the corporate culture;
- Workshops. Works best with end users, as during the process of heated discussion, they usually start spilling lots of helpful information;
- Process analysis. A list of business processes is an excellent start to getting an idea of how everything works. Later, when diving into the atomic process and identifying actors, activity, and information flow, analysts definitely will touch lots of rules which support day-to-day operations;
- Document analysis. Grab a bunch of business policies, regulations, employee instructions, onboarding materials, and other things you heard about from previous techniques. Also, you may find industry standards, government regulations, and similar items by researching the subject area;
- Glossary. Making a list of definitions while trying to understand the domain provides a lot of insights during the discussion of what something means;
- Data dictionary. Understanding how their organization stores its data helps with clarification of numerous business policies and restrictions;
- KPI’s. Achieving metrics always requires some process and guidelines to support them. Dive deep, and you will find something.
Examples of questions to elicit business rules
- How do you make that decision?
- Who is responsible for approving the decision?
- What guidelines do you use to perform this activity?
- Are there any employee instructions?
- What are specific rules which apply to your business?
- Does your business fall by any government regulations?
- Is there a possibility of violating the law if activities are performed inaccurately?
- Are there industry standards?
- How do you calculate this?
- What happens if you do/ignore this activity/fact?
Examples of business rules
- Policies:
- All employees must have an ID card;
- All employees must keep an ID card visible while at the office;
- Guidelines:
- All business processes must be documented;
- Documented business processes must follow the default template;
- Regulations:
- Software in the pharmaceutical domain must be documented;
- Such documentation must be HIPPA-compliant.
- Restrictions:
- Access to the office is available only by and with an ID card;
- Guests must be accompanied by an employee that invited them, guests.
Strengths and limitations of the technique
Strengths:
- Business rules establish a systematic approach to govern business behaviors;
- In a single authorized entity implements case rules within the organization, changes to business rules may improve business processes and result significantly;
- Business rules are a vast source of information about organizational structure, business processes, actors, and their responsibilities.
Limitations:
- More bureaucratic organizations tend to produce so many business rules that they start being counterproductive;
- Business rules may conflict with each other or produce unwanted results when used in combination;
- Require validation before application, as wrongly identified rules may cause more bad than good.
That is your first visit to Passionate BA?
If you just started reading my blog, I have to indicate that you can find many articles on a blog page. You will find my digests, glossary definition reviews, and much more! Enjoy!
Що таке бізнес-правило?
Привіт! Слово дня з BABOK® v3 – бізнес-правило. Це конкретне, придатне до реалізації і тестування правило, що контролюється бізнесом і що слугує критерією для поведінки, формування суджень або прийняття рішень.
Бізнес-правила – це нефункціональні вимоги. Це означає, що вони не є вимогами самі по собі, проте є джерелом кількох типів вимог до програмного забезпечення. Згідно BABOK® v3 існують такі категорії бізнес-правил:
- Визначальне бізнес-правило. Правило, яке вказує на те, що щось є обов’язково вірним (або не вірним); правило, яке виконує роль дефініційного критерію для концепцій, знання або інформації. Також відоме як структурне правило. Ці правила визначають факти, що є важливими для організації;
- Поведінкове бізнес-правило. Правило, що зобов’язує (або забороняє) певну поведінку, дію, практику чи процедуру; правило, що визначає (регулює) підприємницьку діяльність. Також відоме, як операційне правило. Це те, що можна та чого неможна робити.
Згідно з Каарлом Вігерсом, Джой Бітті та “Вимоги до програмного забеспечення, 3 видання”, є такі категорії бізнес-правил:
- Факти. Правдивість цих тверджень можна підтвердити, якщо є докази. Якщо є, то ці твердження є вірними для всіх. Ось деякі приклади: кити – ссавці, Київ – столиця України;
- Обмеження. Таке правило обмежує дії акторів. Сюди входять організаційна політика компанії, державні постанови, галузеві стандарти тощо;
- Активатори дій. Це конкретні умови, які спонукають акторів виконувати якусь дію або запускають інші тригери;
- Висновки, або якщо/то правила. Вони також відомі як передбачувані знання. Вони вказують, що якщо один факт дійсний, ми маємо на увазі, що інший є істинним. Висновки не викликають дії; вони дають знання;
- Обчислення або розрахунки. Ці правила описують перетворення даних, наприклад математичних формул або алгоритмів.
Чому бізнес-правила настільки важливі?
Бізнес-правила існують за межами конкретних програм, оскільки вони є реальними фактами. Однак вони диктують функціональність, яку система повинна включати. Або вони можуть стати атрибутами якості. Тому ви можете простежити походження реалізованих вимог до бізнес-правил. Наприклад, коли зацікавлена сторона описує звітність і відповідальність за певну діяльність або цитує політику підприємства, вона може як раз проговорювати бізнес-правило. Ось чому я не знаю жодних інших нефункціональних вимог, які б більше за інших впливають на програмне забезпечення.
Молоді бізнес-аналітики можуть плутати бізнес-правила з бізнес-вимогами, тому я хочу зупинити це раз і на завжди. Бізнес-вимоги служать обґрунтуванням для реалізації проекту. Вони описують діяльність, необхідну для перетворення організації з поточного стану до майбутнього, зазвичай шляхом автоматизації бізнес-процесів. Бізнес-правила ж впливають на бізнес-процеси з іншої точки зору. Зокрема, вони визначають спільний словник, обмеження та політику, якими керуються актори в повсякденних дях, визначені вимогами бізнесу.
Наявність недокументованих бізнес-правил є поганим вибором для їх збереження. Коли кілька експертів, а іноді навіть одна людина, мають доступ до певних знань лише в пам’яті, то величезна проблема, коли ці люди залишають організацію та створюють порожнечу в конкретному інформаційному просторі. Тим не менш, досі багато компаній неправильно поводяться зі своїми основними бізнес-правилами. Деякі підрозділи можуть документувати свої локальні правила та іноді ділитися ними з сусідніми підрозділами. Але цього недостатньо, якщо решта організації не має єдиного місця для зберігання правил або навіть їх документування. Обробка цієї життєво важливої інформації в головах людей замість того, щоб її записувати, призводить до численних проблем, але це чомусь нікого не хвилює.
Це спричиняє багато головного болю для бізнес-аналітиків, яким потрібно знати, кого шукати, щоб дізнатися про правила, як впоратися з суперечливим розумінням правил і як виправити невідповідність або не пропустити деякі правила повністю. Ось чому, коли аналітик матиме вплив на створення репозиторію для бізнес-правил, це значно полегшить найефективнішу реалізацію кожного проекту, на який впливають певні правила.
Як виявляти бізнес-правила?
Найпотужніші техніки
Аналіз бізнес-правил — це сама по собі окрема техніка, але вона лише описує типи та категорії правил. Щоб виявити їх, аналітики потребують допомоги інших методів:
- Інтерв’ю. Ви можете отримати будь-яку інформацію, дізнавшись інформацію від людей особисто. Але я пропоную вам зосередитися на тому, що може бути незадокументованим, як-от ноу-хау зацікавлених сторін, бізнес-практики в галузі чи норми корпоративної культури;
- Майстер-класи. Найкраще працює з кінцевими користувачами, оскільки під час бурхливого обговорення вони зазвичай починають виливати багато корисної інформації;
- Аналіз процесу. Перелік бізнес-процесів є чудовим початком для отримання уявлення про те, як все працює. Пізніше, занурюючись в атомарний процес і визначаючи акторів, діяльність та потік інформації, аналітики обов’язково торкнуться багатьох правил, які підтримують повсякденні операції;
- Аналіз документів. Візьміть купу бізнес-політик, нормативних актів, інструкцій для працівників, навчальних матеріалів та інших речей, про які ви почули від стейкхолдерів. Крім того, ви можете знайти галузеві стандарти, державні постанови тощо, дослідивши предметну область;
- Глосарій. Складання списку визначень під час спроби зрозуміти домен дає багато розуміння під час обговорення того що є що;
- Словник даних. Розуміння того, як організація зберігає свої дані, допомагає роз’яснити численні бізнес-політики та обмеження;
- KPI. Досягнення показників завжди вимагає певного процесу та вказівок для їх підтримки. Пірніть глибоко, і ви щось знайдете.
Приклади питань для виявлення бізнес-правила
- Як ви приймаєте рішення?
- Хто несе відповідальність за затвердження рішень?
- Які вказівки ви використовуєте для виконання цієї діяльності?
- Чи є якісь інструкції для працівників?
- Які конкретні правила застосовуються до вашого бізнесу?
- Чи підпадає на ваш бізнес будь-яке державне регулювання?
- Чи існує можливість порушення закону при виконанні завдань чи розробці проектів?
- Чи існують галузеві стандарти?
- Як ви це обчислюєте?
- Що станеться, якщо ви зробите/ігноруєте цю дію/факт?
Приклади бізнес-правил
- Політики:
- Всі працівники повинні мати посвідчення;
- Усі працівники повинні тримати на видному місці посвідчення особи під час перебування в офісі;
- Рекомендації:
- Усі бізнес-процеси мають бути задокументовані;
- Документовані бізнес-процеси повинні відповідати шаблону документування бізнес-правил;
- Правила:
- Програмне забезпечення у фармацевтичній сфері має бути задокументовано;
- Така документація має відповідати вимогам HIPPA.
- Обмеження:
- Доступ до офісу можливий лише за посвідченням особи;
- Гості повинні супроводжуватися працівником, який їх запросив.
Це ваш перший візит до Passionate BA?
Якщо ви тільки починаєте читати мій блог, то просто мушу звернути вашу увагу на свої попередні статті, в т.ч. BA-дайджести, де зібрані різноманітні корисні матеріали!