Юзкейс — это структурированное описание того, как человек или внешняя система взаимодействует с продуктом, чтобы достичь одной конкретной цели. Он отвечает на три вопроса: кто действует, чего хочет и как система реагирует на каждый шаг — и на успех, и на сбой.
Это не список фич, не макет экрана и не техническое задание «сделать оплату». Это сценарий с правилами: актор, триггер, предусловия, основной поток, альтернативы и постусловия. Пока требование звучит размыто, каждый представляет своё; как только появляется юзкейс, появляется общий язык.
В 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-м удобная связка выглядит так: одна диаграмма на продукт или подсистему, текстовые карточки только для юзкейсов текущего квартала, остальные имена остаются на карте как напоминание об объёме.
Отдельный вид — essential 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» десятым кеглем, и команда справедливо сбежала к стикерам. Лекарство не в запрете формата, а в дозировке. В распределённой команде, на аутсорсе, в продукте с подрядчиком-эквайером юзкейс снижает цену недопонимания. У троих людей в одной комнате, которые пишут внутренний инструмент, достаточно 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». Тогда юзкейс остаётся инструментом, а не экспонатом.
Вердикт. Юзкейс стоит писать, когда цена недопонимания выше часа на текст: есть несколько акторов, внешние системы, деньги, персональные данные, отказы, которые нельзя импровизировать на ходу. Его не стоит разводить на каждую мелкую кнопку. Самое точное определение остаётся практическим: юзкейс — все способы использовать систему, чтобы конкретный актор достиг конкретной цели, вместе с путями, где цель срывается. Диаграмма держит карту, текст держит правду шагов, слайс держит релиз. Если после чтения сценария бизнес, инженер и тестировщик кивают на одни и те же ветки — юзкейс выполнил работу.
Добавить комментарий