Чим бізнес-вимоги відрізняються від функціональних

На рев’ю вимог сперечаються не про суть. Сперечаються про те, куди що покласти.

Аналітик пише: «скоротити час обробки заявки з трьох днів до чотирьох годин». Керівник проєкту закреслює і пише своє: «система автоматично підтягує дані клієнта з профілю». Обидва рядки правильні. Обидва про один і той самий проєкт. Тільки перший — про результат для бізнесу, а другий — про поведінку системи, і стоять вони на різних поверхах.

Межа між бізнес-вимогами і функціональними проходить не по формулюванню, а по рівню питання. Бізнес-вимога відповідає «навіщо»: який результат ми вважаємо успіхом. Функціональна відповідає «що робить рішення»: яку поведінку цей результат забезпечує. Одна бізнес-вимога зазвичай розкривається кількома функціональними, і тримається цей зв’язок на трасуванні.

Це вся відповідь. Далі — два тести, які розводять рівні за хвилину, і те, що ламається, коли рівні змішані в одному списку.

Чотири рівні, а сперечаються завжди про два

У зводі знань BABOK вимоги розкладені за типами, і типів чотири: бізнес-вимоги, вимоги стейкхолдерів, вимоги до рішення — функціональні та нефункціональні — і перехідні, які потрібні лише на час переходу і після нього відмирають. Третє видання вийшло 2015 року і досі актуальне, тож схема ця не вчорашня новинка.

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

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

Функціональна вимога — не «докладніша» бізнес-вимога. Це відповідь на інше питання, поставлене іншій людині.

Докладніше про сам звід знань та його будову — в окремому розборі: що таке BABOK.

Бізнес-вимога: тест на зміну рішення

Перший тест займає секунди. Замініть рішення повністю і подивіться, що з написаного виживе.

«Скоротити час обробки заявки з трьох днів до чотирьох годин» переживе зміну CRM, відмову від пошти і перехід на іншого підрядника. Це бізнес-вимога. «Система надсилає лист при зміні статусу» помре того дня, коли лист замінять пушем. Це функціональна.

Другий тест ще коротший. Приберіть із формулювання все, що говорить про систему. Залишилося щось осмислене для бізнесу — рівень верхній. Не залишилося нічого — рівень нижній. «Надсилати лист» без системи не значить нічого. «Обробляти заявку за чотири години» значить усе.

Звідси наслідок, який зазвичай і проґавлюють. Поки бізнес-вимогу не сформульовано, функціональну нема чим обґрунтувати: незрозуміло, чому обрано саме таку поведінку і що вважатиметься успіхом. Не «документ не за формою» — просто нема чим відповісти на питання «а навіщо».

Функціональна: поведінка, а не будова

Функціональна вимога описує, що рішення робить: яку операцію, за якої умови, з яким результатом. «Система формує рахунок при закритті замовлення». «Користувач може скасувати заявку до підтвердження оплати». Перевіряється просто: результат або є, або немає.

Тут своя пастка, і в неї з’їжджають частіше, ніж у плутанину з бізнес-рівнем. Формулювання непомітно переповзає з поведінки на будову. «Модуль валідації звертається до довідника» — це вже архітектура, а не вимога. Різниця не в педантизмі: поки написано поведінку, реалізацію можна міняти, не переписуючи вимоги. Щойно написано будову, будь-яка заміна бібліотеки тягне за собою правку документа.

Проста ознака: якщо з формулювання зрозуміло, як це влаштовано всередині, а не що побачить користувач або суміжна система, — ви описали рішення, а не вимогу до нього. Записують функціональні вимоги по-різному — короткою історією з критеріями приймання або сценарієм з усіма гілками; чим ці форми відрізняються, — у статті User Story і Use Case: чим відрізняються і що писати.

Як сформулювати саму функціональну вимогу, щоб її зрозуміли однаково, — формула, шаблон для копіювання і розбір однієї фрази через правки у статті функціональні вимоги: як писати, приклад і шаблон.

Хто висуває і що переживає запуск

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

Останній рядок найчастіше і ламає реєстр. Перехідні вимоги виглядають як звичайні, лежать у загальному списку — і залишаються там назавжди. Через рік ніхто не пам’ятає, що «завантажити залишки зі старої системи» було потрібно рівно один раз.

Перевірка межі: пройти за зв’язками

Формулювання брешуть, зв’язки — ні. Тому рівень перевіряється трасуванням, а не редагуванням.

Стандарт ISO/IEC/IEEE 29148 прямо перелічує, куди вимога зобов’язана трасуватися: вниз — до вимог нижчого рівня, до архітектури, до елементів системи, які його реалізують, і до сутностей верифікації, які його перевіряють; вгору — до батьківських вимог, з яких його виведено, або до потреб стейкхолдерів. Саме двосторонній зв’язок і варто перевіряти.

На практиці це дві хвилини роботи. Візьміть функціональну вимогу і піднімайтеся вгору, поки не впретеся в бізнес-вимогу або потребу стейкхолдера. Дійшли — межа на місці. Обірвалося на «так захотів замовник» або «так історично склалося» — перед вами рішення без мети, і його нікому захистити при скороченні бюджету.

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

У BABOK у зв’язків є свої імена. Їх рівно чотири: derive, depends, satisfy і validate. Для нашого завдання важливий перший: функціональна вимога виводиться з бізнес-вимоги, а не навпаки. Як вести такі зв’язки, щоб вони не перетворилися на мертву таблицю, — окремий розбір: матриця трасування вимог.

Три помилки, які видно в документі

Обидва рівні в одному списку. Сусідні рядки: «скоротити час обробки заявки вдвічі» і «кнопка збереження блокується, поки не заповнено поле ІПН». Поки вони лежать поруч, зміна мети ламає половину тексту, і ніхто не розуміє, що саме переписувати. Лікується не редагуванням, а рознесенням за розділами.

Функція без батька. Поведінку описано, мету не названо. Таку вимогу неможливо ні пріоритизувати, ні захистити: незрозуміло, що станеться, якщо її викинути. Перевірка одна — спробуйте піднятися вгору. Не виходить — вимога висить у повітрі.

Мету змінили, функції залишилися. Найдорожча з трьох, бо непомітна. Команда продовжує робити те, що більше не потрібно, і дізнається про це на демо. Одностороннє трасування цю помилку не ловить: зв’язок униз є, а сигналу «батько змінився» немає.

Різні типи вимог спокійно живуть в одному документі — це нормально і так зазвичай і буває. Ненормально, коли вони лежать в одному списку впереміш. Про те, який документ яке питання закриває, є окремий розбір: BRD, FRD і SRS.

Як це звучить на співбесіді

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

Сильна відповідь коротша і тримається на прикладі. Одна пара формулювань із вашого проєкту — мета і функція, яка її забезпечує. Далі фраза про те, як ви перевіряєте рівень: замініть рішення і подивіться, що виживе. І, якщо запитають глибше, про зв’язок знизу вгору: функція без батька — привід поставити питання, а не рядок у реєстрі.

Різницю між практиком і переказом чути саме тут. Переказ знає визначення. Практик знає, що робити, коли в чужому документі рівні переплутані.