Від бізнес-правил до вимог

Бізнес-правила не є вимогами до програмного забезпечення, але вони суттєво впливають на функціональність, яку ви створюєте.

Це переклад оригінальної статті Карла Вігерса на ресурсі  Medium

Бізнес-правила справляють значний вплив на практично всі програмні системи. Самі по собі вони не є вимогами до ПЗ. Як правило, правила існують поза межами будь-якої конкретної програмної системи й застосовуються навіть тоді, коли бізнес-операції виконуються вручну. Проте політики, регламенти, стандарти та обчислювальні алгоритми є важливими джерелами вимог до ПЗ. Розглянемо, як бізнес-аналітик (БА) може визначити вимоги, щоб забезпечити відповідність програмного продукту релевантним правилам та їх дотримання.

Виявлення бізнес-правил

Так само як запитання «Які ваші вимоги?» мало допомагає під час виявлення (elicitation) вимог користувачів, запитання «Які ваші бізнес-правила?» також не дасть значного результату. Іноді люди вигадують бізнес-правила на ходу, іноді про них згадують під час обговорення вимог, а іноді аналітику доводиться влаштовувати на них справжнє «полювання». Поширені місця та способи пошуку правил включають:

• «Загальні знання» організації: часто збираються від співробітників, які працюють у компанії тривалий час і знають, як функціонує бізнес.

• Застарілі (Legacy) системи: бізнес-правила в них закладені у вимогах та коді. Їх розшифрування потребує зворотного інжинірингу (reverse-engineering) логіки вимог або коду для розкриття відповідних правил. Це може дати неповні знання про правила.

• Моделювання бізнес-процесів: допомагає аналітику визначити обмеження, ініціюючі події (тригери), обчислення та відповідні факти, що впливають на кожен крок процесу.

• Наявна документація: зокрема вимоги попередніх проєктів, нормативні акти, галузеві стандарти, корпоративні політики, контракти та бізнес-плани.

• Аналіз даних: наприклад, вивчення різних статусів об’єкта даних та умов, подій або осіб, які можуть ці статуси змінювати.

• Рівні привілеїв доступу та дозволи на використання: визначають, хто може виконувати певні операції.

• Відділи комплаєнсу (відповідності нормам): у компаніях, що створюють регульовані продукти.

Те, що ви знайшли певні бізнес-правила, ще не означає, що вони досі актуальні або застосовні до вашого поточного продукту. Наприклад, формули обчислень, реалізовані в застарілому коді, можуть бути застарілими. БА має підтвердити, чи потребують оновлення правила, вилучені зі старих документів та застосунків.

Під час сесій виявлення вимог аналітик повинен досліджувати логічне обґрунтування потреб, які представляють користувачі. Ці обговорення часто виводять бізнес-правила на поверхню як першопричину або джерело певних вимог та обмежень.

Бізнес-правила та вимоги до ПЗ

Бізнес-правила іноді виглядають як функціональні вимоги. Проте насправді правила — це зовнішні обмеження, які програмне забезпечення має забезпечувати, що і зумовлює функціональність системи. Аналітику потрібно вивести функціональність, необхідну для дотримання кожного правила, що залежить від операційного контексту додатка.

Ось приклад: Розглянемо систему відстеження запасів хімікатів у дослідницьких лабораторіях компанії. Політика стверджує, що особа повинна пройти відповідне навчання, перш ніж зможе замовити певні небезпечні хімікати. Це правило діє незалежно від того, чи замовляє хтось хімікат особисто на складі, чи через інформаційну систему.

Аналітик специфікує різну функціональність для виконання цього правила залежно від того, чи має система відстеження доступ до бази даних результатів навчання. Якщо має, система може перевірити записи про навчання користувача і вирішити, чи приймати запит. Якщо ж записи недоступні онлайн, система може тимчасово зберегти запит і надіслати повідомлення координатору з навчання, який потім схвалить або відхилить запит. Правило однакове в обох ситуаціях, але функціональність системи залежить від її середовища.

Для ілюстрації розглянемо ще два правила:

• Правило №1: «Якщо термін придатності контейнера з хімікатами закінчився, повідомити особу, яка наразі володіє цим контейнером». [бізнес-правило, що активує дію — action-enabling]

• Правило №2: «Контейнер із хімікатом, що може утворювати вибухонебезпечні продукти розпаду, стає протермінованим через рік після дати виробництва». [бізнес-правило, що констатує факт — stating a fact]

На основі цих правил БА розуміє, що система повинна моніторити контейнери з терміном придатності та інформувати відповідних осіб. Це призводить до створення системної функції (feature) «Сповіщення власника про закінчення терміну». БА може написати кілька (досить розлогих) функціональних вимог для цієї функції:

• Expired.Notify.Before. Якщо контейнер із хімікатом, що має термін придатності, не перебуває у статусі «Утилізовано» (Disposed), система повинна сповістити поточного власника контейнера за тиждень до дати закінчення його терміну придатності.

• Expired.Notify.Date. Якщо контейнер із хімікатом, що має термін придатності, не перебуває у статусі «Утилізовано» (Disposed), система повинна сповістити поточного власника контейнера в день закінчення його терміну придатності.

• Expired.Notify.After. Якщо контейнер із хімікатом, що має термін придатності, не перебуває у статусі «Утилізовано» (Disposed), система повинна нагадати поточному власнику контейнера про це через тиждень після дати закінчення терміну придатності.

• Expired.Notify.Manager. Якщо контейнер із хімікатом, що має термін придатності, не перебуває у статусі «Утилізовано» (Disposed), система повинна сповістити менеджера поточного власника контейнера через два тижні після дати закінчення терміну придатності.

Ці вимоги передають необхідну інформацію, але у досить незграбний спосіб. Щоразу, коли ви стикаєтеся з набором подібних вимог, оформлюйте їх у вигляді таблиці. Таблиця компактніша, її легше переглядати, розуміти та редагувати, ніж громіздкий та одноманітний список вимог із подібними формулюваннями. Вона також забезпечує лаконічний спосіб маркування вимог, оскільки в таблиці потрібно вказати лише суфікси, які додаються до ідентифікатора батьківської вимоги.

Ось простіший альтернативний варіант представлення цього ж набору вимог:

Expired.Notify. Якщо контейнер із хімікатом, що має термін придатності, не перебуває у статусі «Утилізовано» (Disposed), система повинна сповістити осіб, зазначених у наступній таблиці.

ID вимоги	Кого сповістити	Коли сповістити
.Before	Поточного власника контейнера	За тиждень до дати закінчення терміну придатності
.Date	Поточного власника контейнера	У день закінчення терміну придатності
.After	Поточного власника контейнера	Через тиждень після дати закінчення терміну придатності
.Manager	Менеджера поточного власника контейнера	Через два тижні після дати закінчення терміну придатності

Поєднання елементів докупи

Як і вимоги, бізнес-правила мають бути десь задокументовані. Крім того, правила можуть змінюватися з часом — наприклад, коли податкова служба (IRS) змінює податкове законодавство або компанія переглядає свої бізнес-політики. Щоб запобігти надмірності та застаріванню даних, не дублюйте пункти з вашого каталогу бізнес-правил у документації вимог проєкту. Натомість посилайтеся на конкретні правила як на джерело певної функціональності або обчислень.

Ви можете визначити логічні зв’язки між вимогою та її батьківськими бізнес-правилами різними способами:

1. • У паперовому середовищі або при використанні стікерів: фіксуйте унікальний ідентифікатор (ID) вихідного бізнес-правила разом із вимогою або користувацькою історією (user story), щоб читач знав, де його шукати.

   • При використанні інструментів управління вимогами: створіть атрибут вимоги під назвою «Джерело» (Origin) та вкажіть правило як джерело походження вимоги.

   • У матрицях: фіксуйте зв’язки між функціональними вимогами та пов’язаними з ними бізнес-правилами в матриці відстеження вимог (requirements traceability matrix) або матриці відповідності вимог.

   • У цифровому середовищі: якщо бізнес-правила та вимоги зберігаються онлайн, створюйте гіперпосилання від згадок бізнес-правил у вимогах до описів правил, що зберігаються в іншому місці.

Використання таких посилань замість дублювання формулювань правил дозволяє підтримувати вимоги в актуальному стані при зміні правил, оскільки вимога завжди вказуватиме на поточну версію правила. Якщо правило змінюється, ви можете пройти за посиланнями між ним та пов’язаними вимогами, щоб визначити функціональність, яку, можливо, потрібно оновити.

Недоліком використання посилань на бізнес-правила є те, що розробник або тестувальник, який читає вимоги, мусить переходити за перехресним посиланням, щоб отримати доступ до деталей правила. Це компроміс, який виникає щоразу, коли ви обираєте повторне використання інформації замість її тиражування.

Компаніям варто розглядати свої бізнес-правила як інтелектуальний актив рівня підприємства, оскільки вони можуть впливати на розробку та поведінку багатьох програмних додатків. Якщо ви будете активно шукати, фіксувати та застосовувати бізнес-правила під час дослідження вимог, логічне обґрунтування більшої частини функціональності вашої системи стане зрозумілішим для всіх зацікавлених сторін.