Пример юзкейса, который точно прочитают разработчики.

Хабр, привет! Я Ира, бизнес-аналитик в онлайн-кинотеатре Okko.

На работе каждый день я описываю Use Case. Эта техника помогает увидеть путь пользователя от А до Я и не забыть про корнер-кейсы.

За 6 лет и 4 места работы я попробовала разные форматы и шаблоны описания юзкейсов. И недавно пообещала написать статью с примерами и картинками. Значит, поехали.

Сценарий использования (use case) — это набор действий пользователя в формате «действие → результат».

Зачем нужен Use Case

Юзкейсы обычно — это часть ТЗ или другого артефакта, который выходит из-под руки бизнес-аналитика.

Для кого пишут юзкейсы:

1. Системные аналитики — для проектирования бэкенда команде нужно понимать путь пользователя. Чем подробнее расписаны сценарии, тем меньше вопросов на следующих этапах проектирования.

2. Разработчики — если разработчик прочитал вашу доку и оставил комментарии, поздравляю! Вы достигли успеха в карьере. Сценарии должны быть короткими, понятными и чёткими, чтобы с ними можно было работать.

3. Тестирование — каждый сценарий, по сути, это готовый тест-кейс. В задачах по багам тестировщик будет ссылаться на вашу доку и сценарий как на источник истины.

Юзкейсы в документации позволяют написать функциональные требования так, чтобы их прочитали.

Содержание Use Case

Про элементы юзкейсов написаны хорошие статьи. Например, вот эта или вот эта.

Ниже — список элементов, которые использую я. На примере фичи загрузки файлов в фильм (видео, субтитров, постеров).

• Название — кратко описываю, что происходит в сценарии. Например: «Выбор файлов для загрузки».

• Акторы — действующие лица. Обычно это пользователь или его роль (например, контент-менеджер).

• Точка входа — как из UI интерфейса попасть в сценарий. Пример: В сущности перейти в раздел «Загрузки».

• Предусловие — условия, которые должны быть выполнены до начала сценария. Пример: «Доступна загрузка файлов в выбранную сущность».

• Успешный сценарий — пошаговое описание действий пользователя и реакции системы. Например: «Нажал кнопку "Загрузить" → отобразился поп-ап загрузки файлов».

• Результат — что пользователь сможет сделать после выполнения сценария. «Пользователь может загрузить файлы в сущность».

• Альтернативные сценарии — кейсы, когда что-то идёт не так. Или действия пользователя, которые не входят в стандартный флоу. Например, «Нажал кнопку крестика в поп-апе → Поп-ап закрылся без сохранения».

• Исключения и ограничения — фиксирую дополнительные условия, логику бэкенда или связи с другими задачами. «Общие ошибки сервиса загрузок описаны в документе N».

Шаблонные Use Case

В статьях, что привела выше, юзкейсы описаны в виде таблицы с 10–11 строками:

Use Case на практике

Формат ниже основан на опыте работы в разных компаниях. Спасибо лидам, которые делились знаниями. И валиден для процесса: бизнес-требования → дизайн → Use Case → системный анализ → разработка → тестирование.

Для описания сценариев нужно минимум два блока:

1. Действующие лица и точки входа

2. Сами сценарии

Для примера беру написание комментариев под фотками ВК. User Story:

Я, как пользователь ВК, хочу оставлять комментарии под фотографиями, чтобы поделиться своим ценным мнением.

Фича для незарегистрированных юзеров уже давно сделана. А вот для зарегистрированных есть новый интерфейс, который подготовил дизайнер:

Первый блок я бы написала так:

• На каждый сценарий — своя строка с точкой входа.

• Если точка входа одна и та же, то перечислите сценарии через запятую: Сценарий 1, 2

• Если акторы разные на каждый сценарий, добавьте слева столбик с ролью.

Шаблон гибкий. Подстраивайте его под свои потребности.

Акторы и точки входа вынесены «за скобки» сценария, отдельным блоком — так экономим строки у юзкейсов.

Далее — сценарии.

Допустим, Сценарий 1 уже написан. Переходим к Сценарию 2.

• Главный принцип — пишем так, чтобы было понятно. Короткие предложения, только суть.

• Используйте списки — нумерация помогает отслеживать шаги и ссылаться на конкретные пункты.

• Исключения и ограничения отмечайте ⚠️ прямо внутри сценария.

• Ограничения, общие для всех сценариев, лучше вынести в отдельный раздел.

• Подведите итог строкой «Результаты». Так тестировщики быстро увидят финал успешного сценария.

Параллельно успешному сценарию пишем альтернативные:

• Альтернативные сценарии раскрывают корнер-кейсы, которые пригодятся на этапах проектирования и разработки. Тестировщики по ним смогут дополнить тест-кейсы.

• Если фича где-то повторяется, то вынесите её в отдельную доку и дайте ссылку. Чем меньше дублирования, тем легче актуализация.

• Не забудьте про ошибки системы.

А где макеты?

Холиварная тема ?

Когда я пришла в Okko, удивилась, что в документации моей команды отсутствовали картинки из макетов. Была только общая ссылка на Figma.

Я решила провести эксперимент и предложила добавить картинки к сценариям, так как, на мой взгляд, без них сложно понять, как выглядит путь пользователя в UI. Да, можно открыть Figma на втором экране. Но макет перед глазами улучшает восприятие.

Свою доку я написала с картинками. А через две недели макеты устарели, потому что поменялась дизайн-система... И пришлось выделять время на их обновление.

Вывод: вставляйте макеты, если есть ресурс на их актуализацию.

С картинками сценарий выглядел бы так:

Одна и та же фича будет выглядеть по-разному в разных операционных системах. Поэтому столбцов с макетами может быть несколько.

Спасибо за прочтение! В моём тг есть бонусный материал: как нумеровать альтернативные сценарии.

Пишите в комментариях, любите ли вы макеты в документации.
А бизнес- и системные аналитики по шкале от 1 до 10 пусть отметят своё удовольствие от их актуализации.