Юзкейс — це структурований опис того, як людина або зовнішня система взаємодіє з продуктом, щоб досягти однієї конкретної мети. Він відповідає на три запитання: хто діє, чого хоче і як система реагує на кожен крок — і на успіх, і на збій.
Це не список фіч, не макет екрана і не технічне завдання «зробити оплату». Це сценарій із правилами: актор, тригер, передумови, основний потік, альтернативи й постумови. Поки вимога звучить розмито, кожен уявляє своє; щойно з’являється юзкейс, з’являється спільна мова.
У 2026 році юзкейси живуть і в класичному UML, і в Agile через слайси Use-Case 2.0, і в регульованих продуктах, де без повного потоку подій аудит не пропускає вимогу. Нижче — робоче пояснення, а не словникова довідка.
За моїм досвідом, слово «юзкейс» у командах часто означає все підряд: від стікера на дошці до 12-сторінкового документа. Через це люди або пишуть занадто сухо і ніхто не читає, або взагалі відмовляються від формату на користь коротких user story. Обидва крайнощі шкодять. Юзкейс потрібен там, де треба побачити поведінку системи як історію з варіантами, а не як набір екранів.
Українською його ще називають сценарієм використання або прецедентом використання. У бізнес-аналізі частіше кажуть «юзкейс», у документації за ДСТУ й університетських курсах — «прецедент». Суть одна: зафіксувати цінну для актора поведінку системи як послідовність кроків, яку можна обговорити, оцінити, реалізувати й протестувати.
Звідки взявся юзкейс і чому формат не помер разом із «важким» UML
Історія юзкейсу починається не в Agile-спільноті й не в Figma. Шведський інженер Івар Якобсон сформулював текстову й візуальну техніку опису використання системи ще 1986 року, працюючи в Ericsson над телеком-системами. Шведською це називалося användningsfall — буквально «випадок використання». Англійською спочатку пробували usage case, потім скоротили до use case. 1987-го Якобсон представив підхід на конференції OOPSLA. Ідея була проста й зухвала для того часу: описувати систему ззовні, як чорну скриньку, з погляду того, хто нею користується, а не з погляду внутрішніх модулів.
1992 року вийшла книга Object-Oriented Software Engineering – A Use Case Driven Approach, яка зробила юзкейси мовою функціональних вимог. 1995-го Якобсон об’єднався з Грейді Бучем і Джеймсом Рамбо: так з’явилася UML, а діаграма прецедентів стала одним із найупізнаваніших її видів. OMG стандартизувала UML 1997-го. 2001-го Алістер Коберн у Writing Effective Use Cases дав практичний шаблон — від короткого абзацу до «повністю одягненого» документа з гарантіями, розширеннями й рівнями цілей. 2011-го Якобсон, Ян Спенс і Курт Біттнер опублікували Use-Case 2.0: юзкейс розрізають на тонкі слайси й ставлять у беклог поруч із user story.
Хронологія. 1986 — техніка в Ericsson. 1987 — доповідь на OOPSLA. 1992 — книжка про use-case driven розробку. 1995–1997 — UML і стандарт OMG. 2001 — шаблон Коберна. 2011 — Use-Case 2.0 зі слайсами для Agile. 2020-ті — юзкейси в регульованих доменах, у бізнес-аналізі й як каркас для генерації тестів і чернеток за допомогою ШІ.
Чому це важливо саме зараз: ринок 2026-го знову вимагає простежуваності. Банк, медична платформа, державний сервіс на кшталт «Дії» не можуть жити самими стікерами «як користувач хочу». Регулятор, аудитор і служба безпеки питають: хто ініціює дію, які передумови, що відбувається при відмові, яка постумова. Юзкейс дає цю рамку без потреби писати роман.
Мікроісторія з практики. Команда фінтех-гаманця описала переказ коштів одним рядком у Jira. У проді вилізли 3-D Secure, денний ліміт, заморожений рахунок, AML-перевірка й таймаут банку. Кожен із цих шляхів — не «дрібниця UI», а окремий потік одного юзкейсу. Якби сценарій зібрали до розробки, інцидент коштував би кілька стендапів, а не нічний хотфікс і лист комплаєнсу. Wikipedia фіксує ту саму логіку: юзкейс — це поведінка системи у відповідь на запит зовнішнього актора заради конкретної мети.
Типова помилка історичного сприйняття — вважати юзкейс «пережитком водоспаду». Use-Case 2.0 прямо заточений під інкременти. Інша помилка — малювати лише чоловічків і овали, забуваючи текст. Діаграма показує карту; цінність ховається в оповіді кроків. У 2026-му сильні команди тримають діаграму на одну сторінку, а деталі — у коротких текстових картках, які ростуть лише там, де є ризик.
Анатомія юзкейсу: з чого він складається і навіщо кожна частина
Гарний юзкейс читається як п’єса з чіткими ролями. Є сцена (межі системи), головний актор, його мета, подія, що запускає дію, умови «до», послідовність реплік «актор — система», розвилки, коли щось іде не так, і стан світу «після». Якщо викинути будь-який із цих елементів, документ починає брехати: або ховає ризик, або роздувається до внутрішньої реалізації.
Актор — це роль, не прізвище співробітника. «Касир», «гість», «платіжний шлюз», «модуль Нової Пошти». Людина, зовнішня система, навіть таймер, якщо сценарій стартує за розкладом. Головний актор ініціює юзкейс і отримує цінність. Другорядний — допомагає системі (банк, SMS-провайдер, реєстр). Мета формулюється дієсловом з об’єктом: «оформити лікарняний», «підписати документ Дія.Підписом», «скасувати доставку». Назва «робочий кабінет» — це екран, не юзкейс.
Тригер — іскра. Клієнт натискає «Оплатити», лікар зберігає прийом, крон о 03:00 запускає звірку реєстрів. Передумови — те, що вже має бути істинним, і що сам юзкейс не перевіряє з нуля: користувач автентифікований, у кошику є товар, рахунок не заблокований. Постумови фіксують стан після успіху (і, окремо, мінімальні гарантії після збою): замовлення створене, залишок списано, лист надіслано; або — платіж не пройшов, кошик збережено.
| Елемент | Що фіксує | Живий приклад |
|---|---|---|
| Актор | Хто хоче результат | Пацієнт у Helsi |
| Мета | Цінність одним рядком | Записатися до терапевта |
| Тригер | Подія старту | Натискання «Записатися» |
| Основний потік | Щасливий шлях | Слот вільний, запис підтверджено |
| Альтернативи | Відхилення й помилки | Слот зайняли, декларації немає |
Таблиця навмисно суха: її сила — у повноті, не в красі. Коли в юзкейсі є лише основний потік, тестувальники вигадують альтернативи самі, розробники — інакше, підтримка — утретє. Саме розгалуження роблять документ тестованим. Коберн радить нумерувати кроки 1, 2, 3, а розширення — 3a, 3b, щоб гілка завжди вказувала, звідки вона відгалужується.
Повний шаблон додає ще рівень цілі (підсумок, ціль користувача, підфункція), обсяг (яка система є чорною скринькою), стейкхолдерів і їхні інтереси, мінімальні гарантії та список технологічних варіацій. Для внутрішнього стартапу на п’ять людей це надмір. Для платіжного сервісу, де в одному сценарії сходяться клієнт, антифрод і банк-еквайєр, — гігієна. У нашій практиці повний шаблон вмикаємо, коли ціна помилки вимірюється грішми клієнта, персональними даними або ліцензією.
Приклад «лікарняний через корпоративний чат-бот». Актор — співробітник. Мета — оформити лікарняний. Тригер — відкриття діалогу. Передумова — людина є в HR-системі. Основний потік: бот питає дати, співробітник підтверджує, система пише запис, надсилає підтвердження. Альтернатива: дати в минулому, перетин із відпусткою, відсутність електронного лікарняного в реєстрі. Постумова успіху — запис збережено, керівник бачить статус. Без цих рядків «чат-бот для лікарняних» лишається слоганом.
Бізнес-юзкейс, системний юзкейс і діаграма: три шари однієї історії
Плутанина типів — друга за частотою причина, чому юзкейси «не заходять». Бізнес-юзкейс описує роботу організації: клієнт отримує посилку, пацієнт проходить прийом, громадянин реєструє ФОП. Усередині «системи» тут можуть бути люди-виконавці: оператор кол-центру, кур’єр, нотаріус. Системний юзкейс звужує чорну скриньку до ПЗ: мобільний застосунок, кабінет, API. Той самий бізнес-сценарій «отримати посилку» розпадається на системні: створити ТТН, оплатити післяплату, відкрити клітинку поштомату, підтвердити видачу кодом.
Візьмімо Rozetka або інший маркетплейс. Бізнес-юзкейс «покупець оформлює замовлення з доставкою» цікавить продакта й операційного директора. Системний «оплатити замовлення карткою» цікавить бекенд, антифрод і QA: токенизація, 3-D Secure, повторна спроба, часткове списання. Якщо змішати шари, отримаєте документ, який бізнес не розуміє через поля API, а інженери ігнорують через фрази на кшталт «клієнт має бути щасливим».
Діаграма прецедентів — це мапа, не роман. Прямокутник меж системи, чоловічки-актори зовні, овали-юзкейси всередині, лінії асоціацій. Між овалами живуть три стосунки, які постійно плутають. Include — обов’язковий спільний фрагмент: «оформити замовлення» завжди включає «автентифікувати користувача». Extend — необов’язкове або умовне розширення: «застосувати промокод» може розширити оплату, якщо клієнт його ввів. Узагальнення — спеціалізація: «оплатити» як батько, «оплатити карткою / Apple Pay / післяплатою» як діти. Стрілка include йде від базового до фрагмента, extend — від розширення до бази. Переплутали напрям — і схема бреше.
- Бізнес-шар відповідає на «яку цінність отримує організація й клієнт».
- Системний шар відповідає на «які кроки робить ПЗ із актором».
- Діаграма відповідає на «що входить у межі релізу і хто з ким розмовляє».
- Текст юзкейсу відповідає на «що саме відбувається крок за кроком, якщо пощастить і якщо ні».
Ці чотири відповіді не замінюють одна одну. Команда, яка намалювала 40 овалів і зупинилась, має красиву картинку без тестованих вимог. Команда, яка написала 40 полотен без діаграми, губить межі: раптом «надіслати податковий звіт» опиняється всередині застосунку доставки. У 2026-му зручна зв’язка виглядає так: одна діаграма на продукт або підсистему, текстові картки лише для юзкейсів поточного кварталу, решта імен лишається на мапі як нагадування про обсяг.
Окремий вид — essentіal use case Ларрі Константайна: наміри актора без прив’язки до кнопок і полів. «Ідентифікувати себе», а не «ввести пароль у форму логіна». Це рятує від раннього замикання на UI. Підводний камінь протилежний: надто абстрактний текст неможливо оцінити в сторі-поінтах. Баланс 2026 року — намір плюс один конкретний канал: «підтвердити особу Дія.Підписом», не «пройти складну форму з 14 полями».
Як написати юзкейс: робочий порядок, шаблон і живі приклади
Писати юзкейс «з середини екрана» — майже гарантована помилка. Порядок інший. Спочатку проведіть межу системи: що всередині, що зовні. Потім зберіть акторів — ролі людей і зовнішні системи. Далі для кожного актора запишіть цілі, які дають йому відчутний результат. Кожна ціль користувацького рівня — кандидат у юзкейс. Підфункції на кшталт «перевірити формат ІПН» самі по собі юзкейсами не стають: їх вшивають у кроки або виносять через include.
Далі пишіть основний потік так, ніби всесвіт доброзичливий: кожен крок — дія актора або видима відповідь системи. Ніяких «система перевіряє в базі індекси й кеш Redis». Потім від кожного кроку, де життя вміє вдарити, відводьте гілку: немає слота, картка відхилена, ТТН уже створена, код з SMS протух. Наприкінці прогоніть сценарій із розробником, тестувальником і людиною з бізнесу. Якщо хоч один каже «а в нас ще буває ось таке» — це не «потім у чатику», це новий рядок розширення.
Чек-лист перед тим, як вважати юзкейс готовим
- Назва — дієслово + об’єкт, без назви екрана.
- Є один головний актор і явна мета.
- Передумови не дублюють кроки основного потоку.
- Основний потік має 3–12 кроків, не 40.
- Кожна критична відмова має гілку з номером кроку.
- Постумова успіху перевіряється тестом.
- Немає деталей UI, кольорів кнопок і полів CSS.
- Межі системи не проковтнули сусідній продукт.
Чек-лист здається дріб’язковим, доки ви не побачите юзкейс на 47 кроків «Користувач працює в кабінеті». Це не сценарій, це посадова інструкція. Дробіть. «Змінити пароль», «завантажити акт», «відкликати запрошення» — три юзкейси, три оцінки, три набори тестів. Занадто короткі теж бувають: один крок «система все робить» ховає всю складність у магію.
Повний приклад. UC-07. Клієнт створює експрес-накладну. Актор: відправник. Система: кабінет перевізника. Передумови: користувач увійшов, у профілі є відправник. Тригер: команда «Створити ТТН». Основний потік: 1) відправник вказує отримувача; 2) система підказує відділення; 3) відправник обирає габарити й оголошену вартість; 4) система рахує тариф; 5) відправник підтверджує; 6) система видає номер ТТН і QR. Розширення 2а: адреси немає в довіднику — пропонує адресну доставку. 4а: тариф недоступний для габариту — просить змінити параметри. 5а: клієнт скасовує — чернетка зберігається. Постумова: ТТН існує в статусі «створена», відправник бачить номер.
Другий приклад — державний сервіс. Підписати заяву Дія.Підписом. Актор: громадянин. Передумова: Дія.Підпис активовано. Кроки: вибір документа, запит на підтвердження в застосунку, біометрія, штамп підпису, фіксація часу. Альтернативи: підпис прострочений, телефон офлайн, документ уже підписано, відмова користувача. У 2026-му такі сценарії ще й годують журнал аудиту: кожна гілка має лишати слід. Третій приклад — monobank-подібний переказ за номером. Основний шлях короткий. Справжня робота сидить у гілках: ліміт, антифрод, нічний тариф, отримувач у санкційному списку. Якщо гілок немає в тексті, їх «відкриють» клієнти.
Інструмент не священний. Комусь підходить сторінка в Confluence, комусь — картка в Jira з шаблоном полів, комусь — файл поруч із OpenAPI. Важливо, щоб юзкейс був видимий тій самій команді, що пише код і тести, і щоб зміна гілки не ховалась у приватній нотатці аналітика.
Юзкейс, user story, сценарій і тест-кейс: де проходить межа
Найчастіше юзкейс плутають із user story, бо обидва говорять про користувача й мету. Різниця не в «водоспаді проти скраму», а в роботі, яку артефакт виконує. User story — коротка заявка на розмову: «Як відправник, я хочу створити ТТН, щоб віддати посилку без черги». Вона тримає цінність і пріоритет. Юзкейс — креслення поведінки: кроки, відмови, гарантії. Сценарій (scenario) — один конкретний прохід юзкейсом, одна нитка. Тест-кейс — перевірка, що ця нитка справді працює на збірці.
| Артефакт | Питання | Обсяг | Коли брати |
|---|---|---|---|
| User story | Навіщо і для кого? | 1–3 речення + критерії | Беклог, спринт, цінність |
| Юзкейс | Як система поводиться? | Потік + гілки | Складні взаємодії, ризик |
| Сценарій | Що саме сталось цього разу? | Один шлях | Демо, грумінг, приклад |
| Тест-кейс | Чи виконується очікування? | Кроки + очікуваний результат | QA, регресія, аудит |
Таблиця не означає, що треба вести всі чотири стоси паперів на кожну дрібницю. Для «змінити аватар» вистачить story з критеріями прийняття. Для «виплатити відшкодування страхового випадку» story буде обгорткою, юзкейс — кістяком, сценарії — прикладами (ДТП, лікування, відмова через прострочений поліс), тест-кейси — сіткою перевірок. Коберн порівнював user story з юзкейсом «на двох бітах точності»: ім’я й головний шлях. Далі додаються відмови, дані, гарантії.
Міфи vs реальність. Міф: юзкейси — для водоспаду, story — для Agile. Реальність: Use-Case 2.0 ріже юзкейс на слайси й кладе їх у спринт. Міф: діаграма і є юзкейс. Реальність: овал без тексту не тестується. Міф: юзкейс замінює прототип. Реальність: він описує поведінку, а не композицію екрана. Міф: чим довше, тим серйозніше. Реальність: зайві кроки ховають ризик краще за мовчання.
Міфи живучі, бо кожен бачив поганий зразок. Хтось колись написав 80 сторінок «Use Case Specification» шрифтом 10, і команда справедливо втекла до стікерів. Ліки не в забороні формату, а в дозуванні. У розподіленій команді, у аутсорсі, у продукті з підрядником-еквайєром юзкейс зменшує ціну непорозуміння. У трьох людей в одній кімнаті, які пишуть внутрішній інструмент, достатньо story і розмови біля дошки — за умови, що дошка не зітреться до релізу.
Ще одна межа — нефункціональні вимоги. Юзкейс погано тримає «відповідь API < 200 мс» або «доступність 99,9%». Це декларації, не історії взаємодії. Їх ліплять поруч: як обмеження до сценарію, як SLO, як окремий розділ. Спроба запихнути перфоманс у крок 4 основного потоку народжує гібрид, який ніхто не виконує. У 2026-му, коли частина сценаріїв іде через ШІ-агентів, з’являється новий актор — модель. Її теж варто називати актором, а не ховати всередині кроку «система відповідає розумно».
Типові помилки, підводне каміння і ціна пропущеної гілки
Перша отрута — юзкейс як переказ макета. «Користувач бачить синю кнопку в хедері, клікає, відкривається модалка з двома табами». Це вже дизайн, і він згорить після першого редизайну, тоді як мета «порівняти два тарифи» житиме роками. Пишіть наміри й відповіді системи. Екран згадуйте лише якщо без нього не зрозуміти канал: банкомат, кіоск, IVR, чат.
Друга — бог-юзкейс, який ковтає весь продукт. «Користувач користується особистим кабінетом» неможливо оцінити, реалізувати за спринт і прийняти. Дробити треба по цілях актора, не по розділах меню. Меню — це навігація. Цілі — «скачати акт звірки», «додати торгову точку», «закрити зміну». Третє — відсутність альтернатив. Основний потік малює щасливу рекламу. Гроші, довіра й нерви підтримки сидять у 3a і 4b. Команда доставки, яка не описала «отримувач не відчинив», дізнається про це від кур’єрів у Telegram о 21:40.
Четверте — змішані рівні. У одному тексті крок 1: «директор затверджує стратегію лояльності», крок 2: «система пише рядок у таблицю promo_codes». Це різні висоти польоту. Коберн розділяє summary, user goal і subfunction. Тримайте один юзкейс на одному рівні. П’яте — актори-прізвища. «Олена з бухгалтерії» звільниться. «Бухгалтер із правом підпису» залишиться. Шосте — передумови, які насправді є першими кроками. Якщо юзкейс починається з «користувач логіниться», а логін — окрема ціль, зробіть include, не прикидайтеся, що сесія завжди є як закони фізики.
- Описали UI замість мети — документ помре на наступному редизайні.
- Зліпили весь кабінет в один овал — оцінка й тести розсипаються.
- Забули відмови — їх знайде прод, не QA.
- Змішали бізнес-рівень і SQL — ні бізнес, ні інженери не підпишуться.
- Не назвали зовнішні системи акторами — інтеграції «вигулькнуть» у середині спринту.
Цей список — не мораль, а карта шрамів. У нашій практиці найдорожчим був пункт про зовнішні системи: платіжний шлюз, реєстр, SMS, антифрод. Поки їх немає серед акторів, ніхто не планує таймаути, ідемпотентність і повторні спроби. Щойно шлюз стає другорядним актором, з’являються кроки «система надсилає запит» і гілки «немає відповіді за 8 секунд», «прийшов duplicate», «відмова емітента».
Емоційний акцент тут сухий, але чесний: пропущений юзкейс рідко виглядає як драма на стендапі. Він виглядає як «ну клієнт якось сам розбереться» — і далі як черга в підтримці, як штраф за прострочену фіскалізацію, як зірваний SLA з маркетплейсом. Тому аналітик, який наполягає на гілці 5a, не бюрократ. Він купує команді спокій. У 2026-му, коли реліз їде щотижня, дешевше витратити годину на текст, ніж добу на інцидент із неповним сценарієм повернення коштів.
Юзкейси у 2026: слайси, регулятори, ШІ й межі формату
Use-Case 2.0, описаний на ivarjacobson.com, дав сучасну відповідь на докір «це занадто товсто для скраму». Юзкейс лишається одиницею цінності для користувача, але робота йде слайсами: тонкий наскрізний шмат, який можна спроєктувати, написати, протестувати й показати. Перший слайс майже завжди — основний потік у найбіднішому вигляді. Наступні додають промокод, розстрочку, антифрод, іншу мову. Беклог складається не з овалів, а зі слайсів. Діаграма тримає велику картину, щоб команда не забула, навіщо ці шматки.
Регульовані домени в Україні й ЄС у 2026-му підігрівають попит на простежуваність. Платіж, медичний запис, податкова накладна, ідентифікація особи — тут юзкейс стає мостом між вимогою регулятора й тестом. Аудитору байдуже до стікера «як клієнт хочу швидко». Йому потрібен ланцюжок: актор, згода, перевірка, відмова, журнал. Те саме в продукті з кібербезпеки: юзкейс «адмін відкликає сесії» має гілку «адмін уже не адмін» і постумову «всі токени недійсні».
Зміни 2026. Юзкейси знову в моді не через ностальгію за UML, а через три зсуви. По-перше, слайси остаточно примирили формат зі спринтом. По-друге, ШІ добре генерує чернетку основного потоку з бріфа, але системно губить гілки відмов — людина лишається редактором ризику. По-третє, продуктові команди все частіше ставлять зовнішні API й агентів окремими акторами, бо інтеграційна складність переїхала з «внутрішньої функції» в екосистему.
ШІ-асистент у 2026-му корисний як прискорювач першої версії: ви кидаєте мету й акторів, отримуєте скелет кроків. Користь зникає, щойно ви приймаєте чернетку як істину. Модель підставить щасливий шлях із рекламного ролика й забуде про «отримувач помер», «картка корпоративна з двома підписами», «документ уже в Дії зі статусом відхилено». За моїм досвідом, найкращий робочий цикл такий: людина задає межі й акторів, модель пропонує основний потік, аналітик із QA дописують розширення, розробник викреслює внутрішню реалізацію, яку модель любительськи вигадує.
Межі формату теж треба назвати вголос. Юзкейс слабкий для алгоритмів без актора, для чистої аналітики, для графічних редакторів, де «ціль» розмазана по безперервній маніпуляції. Там краще працюють правила, приклади даних, state machine, job story. Не треба рятувати самолюбство методу: якщо історія взаємодії не існує, не видумуйте актора «Користувач хоче, щоб система порахувала матрицю». Поверніться до специфікації обчислення.
Практичний нюанс на кінець десятиліття: тримайте юзкейси живими. Мертвий документ у wiki, який не відкривали після релізу 2024-го, шкодить більше за відсутність документа — він бреше з авторитетом. Правило просте. Змінилась гілка в проді — того ж тижня оновіть розширення. З’явився новий другорядний актор — додайте його на діаграму. Слайс вийшов у прод — позначте стан «verified». Тоді юзкейс лишається інструментом, а не експонатом.
Вердикт. Юзкейс варто писати, коли ціна непорозуміння вища за годину на текст: є кілька акторів, зовнішні системи, гроші, персональні дані, відмови, які не можна імпровізувати на ходу. Його не варто розводити на кожну дрібну кнопку. Найточніше визначення лишається практичним: юзкейс — усі способи використати систему, щоб конкретний актор досяг конкретної мети, разом зі шляхами, де мета зривається. Діаграма тримає карту, текст тримає правду кроків, слайс тримає реліз. Якщо після читання сценарію бізнес, інженер і тестувальник кивають на ті самі гілки — юзкейс виконав роботу.
Leave a Reply