Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>27 ноя 2025</li>

3 <li>0</li>

4 </ul>Учимся на практических примерах.

5 Иллюстрация: Оля Ежак для Skillbox Media

6 Программист, консультант, специалист по документированию. Легко и доступно рассказывает о сложных вещах в программировании и дизайне.

7 Когда компания решает создать новое ПО, ей необходимо заранее понять, какие именно задачи бизнеса и пользователей оно будет решать и каким именно образом. Чтобы разобраться в этом, готовят use case (сценарий использования).

8 В этой статье мы разберёмся, что это за документ, какие задачи он решает и как правильно его составить.

9 Содержание

10 <ul><li><a>Что такое use case и когда он нужен</a></li>

11 <li><a>Этапы создания сценария использования</a></li>

12 <li><a>Какие виды use case существуют</a></li>

13 <li><a>Как составить use case: пошаговая инструкция</a></li>

14 <li><a>Примеры сценарий использования из практики</a></li>

15 <li><a>Популярные сервисы и программы для создания use case</a></li>

16 <li><a>В чём разница между use case и user story</a></li>

17 </ul>Use case (сценарий использования) - это описание того, как пользователь взаимодействует с ПО, чтобы достичь конкретной цели. Он показывает, какие шаги выполняет человек, как на них реагирует программа и к какому результату это приводит.

18 Например, компания решает создать приложение для заказа такси. Use case будет описывать процесс его работы для пользователей - с главного экрана и до завершения поездки с указанием обратной связи. Подробное описание позволяет разработчикам и дизайнерам понять, как должна работать система и какие функции требуется реализовать.

19 В начале разработки use case задаёт общее представление о ПО: что важно для пользователя, какие ограничения стоит учитывать, как именно должно работать приложение или веб-сайт, какие ошибки могут возникнуть и что с ними делать, и многое другое. Позже эти сценарии используются для тестирования - по ним проверяют, выполняет ли система действия так, как нужно пользователям.

20 Посмотрим на несколько ситуаций, в которых используется use case:

21 <ul><li>Создание интернет-магазина. Сценарии будут описывать, как покупатель выбирает товар и оплачивает заказ, что делать, если товар закончился или оплата не прошла. То есть укажет на все возможные варианты развития событий, которые следует предусмотреть в разработке и тестировании.</li>

22 <li>Создание мобильного приложения, например для изучения иностранных языков. Use case будет описывать регистрацию пользователя, вход в систему, восстановление пароля, настройки профиля: текущий уровень владения языком, цель обучения, напоминания о занятиях и тому подобное. Сценарии использования должны включать в себя работу с настройками профиля, отображение ошибок, например когда сервис недоступен, и так далее.</li>

23 </ul>Чтобы написать качественный сценарий использования, полезный на этапах разработки и тестирования, надо пройти четыре последовательных этапа: собрать информацию о ПО, описать задачи в виде общей диаграммы, детализировать сценарии, запланировать их проверку и уточнение при необходимости. Разберём каждый из них подробно.

24 Ключевая задача на старте работы над use case - понять цели бизнеса, то есть то, что важно заказчику разработки. Эту часть обычно формулирует бизнес-аналитик или продакт-менеджер. Например, в ходе сбора информации может выясниться, что сейчас требуется увеличить количество заказов, сократить время обслуживания или повысить удовлетворённость клиентов.

25 Следом переходят к требованиям пользователей - что нужно им самим от нашего ПО: возможность выбора тарифа, быстрой оплаты покупки или что-то другое. Здесь в процесс включается системный аналитик или продакт-менеджер: они проводят интервью с пользователями, изучают, как те будут работать с системой, и превращают эти наблюдения в чёткие формулировки.

26 После анализа собранных данных системный аналитик описывает задачу целиком, указывая возможные сценарии, но без их детализации. Для этого он использует язык UML - набор правил по созданию визуальных схем. Основное преимущество его выбора - графические материалы будут понятны всем, кто знаком с языком. То есть у UML есть определённые правила, по которым применяются все элементы: стрелочки, кружки, квадраты и другие.

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

28 Диаграмма сценариев использования приложения такси - как со стороны клиента, так и со стороны водителя. Мы видим все возможные действия, для которых необходимо продумать конкретные шаги и возможные ошибкиИллюстрация: Майя Мальгина для Skillbox MediaПосле создания диаграммы переходят к подробному описанию каждого сценария в текстовом формате. Use case обычно состоит из нескольких обязательных частей:

29 <ul><li>Заголовок.Краткое описание действия.</li>

30 <li>Акторы.Те, кто взаимодействует с системой. Это может быть человек (например, покупатель в интернет-магазине), другая программа (платёжный сервис) или устройство. Нужно перечислить всех акторов, чтобы понимать, кто и какие действия выполняет, и не пропустить их проработку в дальнейшем.</li>

31 <li>Основной поток событий.Это главный сценарий - то, как система должна работать в обычной ситуации. Например, пользователь вводит логин и пароль → система проверяет данные → открывается личный кабинет.</li>

32 <li>Альтернативные потоки.Это варианты, которые могут отличаться от основного сценария. Например: пользователь вводит неверный пароль → система показывает сообщение об ошибке и предлагает попробовать ещё раз.</li>

33 <li>Предусловия.То, что должно быть выполнено перед началом сценария. Например: "Пользователь зарегистрирован в ПО, имеет логин и пароль".</li>

34 <li>Постусловия.Результат, который должен быть достигнут после выполнения сценария. Например: "Пользователь успешно вошёл в личный кабинет ПО".</li>

35 <li>Исключения и ошибки.Описывают, что происходит в нестандартных ситуациях. Например: сервер недоступен или платёж не прошёл.</li>

36 <li>Триггеры.Это события, которые запускают сценарий. Например: "Пользователь нажал кнопку "Войти“".</li>

37 </ul>После написания сценариев нужно их проверить и убедиться, что учтены все требования к ПО или его части и ожидания от них. Для этого системный аналитик обсуждает use case с заказчиком.

38 После этого сценарии рассматривают вместе с командой: разработчиками, дизайнерами и тестировщиками. Это необходимо для того, чтобы были учтены все возможные шаги пользователей, а также возможные отклонения от основного потока событий.

39 Один и тот же use case можно описать как с точки зрения бизнеса, так и с позиции системы в целом.

40 Бизнес-сценарийпоказывает задачу глазами заказчика и пользователей. В нём описывается цель и результат без технических деталей, чтобы было понятно, что нужно бизнесу. Например: "Покупатель оформляет заказ в интернет-магазине: выбирает товар, оплачивает и получает подтверждение". Здесь не указывается, как технически работает платёжная система или какой код выполняется: важен только итог.

41 Системный сценарийпредназначен для разработчиков и тестировщиков. Он показывает, что происходит внутри ПО: какие проверки реализованы и проводятся, куда отправляются запросы, как приложение или веб-сайт реагируют на ошибки. Вот как может выглядеть формулировка: "Система проверяет наличие товара на складе, рассчитывает доставку, передаёт данные в платёжный шлюз, обрабатывает ошибки и верстает письмо с подтверждением".

42 Коротко:бизнес-сценарий показывает то, какие задачи будет решать продукт, а системный - как будет реализовано их решение.

43 Кроме этого, сценарии можно разделить по глубине проработки на два варианта:

44 <ul><li>высокоуровневые описывают общую идею без подробной проработки;</li>

45 <li>детализированные разбирают каждый шаг пользователя и реакцию системы, в том числе редкие случаи и ошибки.</li>

46 </ul>Как выбрать формат?В начале проекта пишут бизнес-сценарии: они помогают договориться с заказчиком о требованиях и ожиданиях и согласовать их с ним. Когда начинается разработка, переходят к системным и детализированным сценариям: по ним программисты и тестировщики понимают, что и как нужно делать.

47 Стандартных шаблонов для сценария использования нет - разные компании оформляют их по-своему, опираясь на специфику разрабатываемого ПО. Главное, чтобы в итоге получился структурированный документ, который позволяет команде разработки одинаково представлять конечный результат или по отдельным функциям приложения или веб-сайта, или в целом.

48 Рассмотрим основные элементы, которые обычно включают в описание use case.

49 Сначала системный аналитик определяет, за что отвечает система, а что выходит за её рамки. Это необходимо для того, чтобы понять, какие функции она выполняет и с кем или чем взаимодействует: с пользователями, другими сервисами или устройствами.

50 Границы помогают не уходить в лишние детали и не тратить ресурсы на их проработку. Например, в приложении такси в границах use case может быть заказ поездки, оплата и карта города, а управление автопарком или маршрутизацию описывать необязательно.

51 Нужно чётко определить, кто участвует в сценарии использования. Есть первичные акторы (они начинают процесс, и конечный результат важен для них) и вторичные (те, кто подключается позже). Актором может быть не только человек, но и, например, платёжная система.

52 После того как акторы определены, нужно понять, чего они хотят. Цель должна быть конкретной и полезной для акторов. Часто её формулируют как"глагол + объект": например, "оформить заказ", "авторизоваться в программе" или "запросить поддержку".

53 Цель помогает сосредоточиться на основной задаче сценария и не уходить в технические детали.

54 Это стандартный путь, когда всё идёт без ошибок. Шаг за шагом аналитик описывает действия акторов и реакцию ПО.

55 Несколько советов по проработке основного сценария:

56 <ul><li>Используйте нумерованный список.</li>

57 <li>Каждый шаг - простое действие: "Пользователь вводит адрес", "Система проверяет наличие машины поблизости" и тому подобное.</li>

58 <li>Ошибки пока не учитываются. Мы игнорируем то, что они могут появиться.</li>

59 <li>Сценарий должен логично завершаться - цель пользователя достигнута.</li>

60 </ul>Здесь учитываются отклонения от основного пути: ошибки, отмены и другие возможные варианты событий. Для каждого шага аналитик продумывает, что может пойти не так и как система должна реагировать на это.

61 Важно всегда указывать условия перехода к альтернативному сценарию и то, как вернуться к основному или завершить работу пользователя с ошибкой.

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

63 Сначала оценивают, насколько согласованы акторы и границы системы: нет ли действий, которые выполняют пользователи, не имеющие к этому доступа? Затем смотрят, все ли возможные ситуации учтены: предусмотрены ли ошибки или непредвиденные сбои?

64 После этого аналитик проверяет переходы между ветками сценария: если пользователь может вернуться из альтернативного пути в основной, это должно быть явно описано. Каждый сценарий обязан завершаться определённым состоянием системы - успешным или с ошибкой.

65 После этого use case показывают команде: разработчикам, тестировщикам и заказчику, чтобы заметить нестыковки, которые можно пропустить. Наконец, важно убедиться, что сценарий читается легко, иначе его лучше разделить на несколько связанных use case или подзадач - так описание останется понятным и управляемым.

66 Посмотрим на упрощённые примеры сценариев использования из разных сфер: корпоративной системы, интернет-магазина и мобильного приложения.

67 Название:Авторизация пользователя.

68 Акторы:

69 <ul><li>пользователь;</li>

70 <li>система аутентификации.</li>

71 </ul>Предусловия:

72 <ul><li>пользователь зарегистрирован или ему разрешено войти как гостю;</li>

73 <li>нужные данные (логин/пароль или токен) доступны.</li>

74 </ul>Основной сценарий:

75 <ul><li>Пользователь открывает экран входа на веб-сайте.</li>

76 <li>Вводит логин и пароль.</li>

77 <li>Система проверяет данные.</li>

78 <li>Если данные корректные - система переводит пользователя на главную страницу.</li>

79 <li>Сценарий успешно завершён.</li>

80 </ul>Альтернативные сценарии:

81 <ul><li>Если пользователь вводит неверный пароль, то программа показывает сообщение об ошибке и предлагает повторить ввод.</li>

82 <li>Если пользователь забыл пароль, то может нажать на кнопку "Забыли пароль" и выполнить восстановление через электронную почту, которая уже зарегистрирована в системе.</li>

83 </ul>Постусловия:

84 Пользователь либо авторизован и может использовать функции корпоративной системы, либо получил понятное сообщение об ошибке с вариантами её устранения.

85 Название:Оформление заказа.

86 Акторы:

87 <ul><li>клиент (покупатель);</li>

88 <li>система магазина;</li>

89 <li>служба доставки;</li>

90 <li>система оплаты.</li>

91 </ul>Предусловия:

92 <ul><li>клиент вошёл в аккаунт или сделал заказ как гость;</li>

93 <li>товары, которые требуется заказать, добавлены в корзину;</li>

94 <li>способы оплаты и доставки доступны в регионе клиента.</li>

95 </ul>Основной сценарий:

96 <ul><li>Клиент проверяет корзину и подтверждает состав товаров.</li>

97 <li>Выбирает адрес доставки.</li>

98 <li>Выбирает способ оплаты.</li>

99 <li>Система рассчитывает стоимость доставки и итоговую сумму.</li>

100 <li>Клиент подтверждает заказ.</li>

101 <li>Система отправляет запрос в платёжную систему.</li>

102 <li>После подтверждения платёжной системы заказ обозначается как оплаченный, происходит уведомление склада и службы доставки. Подтверждение оплаты обязательно направляется клиенту по email или в приложении.</li>

103 </ul>Альтернативные сценарии:

104 <ul><li>Если один из товаров отсутствует на складе, то система предлагает удалить его или выбрать аналог.</li>

105 <li>Если оплата отклонена, то пользователь получает уведомление и предложение попробовать другую карту или способ оплаты.</li>

106 <li>Если адрес доставки введён некорректно, то появляется сообщение об ошибке и окно для корректировки адреса.</li>

107 </ul>Название:Отправка push-уведомления пользователю.

108 Акторы:

109 <ul><li>приложение (серверная часть);</li>

110 <li>пользователь (устройство).</li>

111 </ul>Предусловия:

112 <ul><li>пользователь установил приложение;</li>

113 <li>разрешил получение push-уведомлений в настройках операционной системы;</li>

114 <li>имеется событие, которое должно вызвать вызов уведомления, например новое сообщение, акция или другое.</li>

115 </ul>Основной сценарий:

116 <ul><li>Событие генерируется на сервере (например, новая акция или сообщение).</li>

117 <li>Сервер формирует содержимое уведомления: заголовок, текст, ссылку и так далее.</li>

118 <li>Сервер отправляет уведомление через push-сервер (FCM, APNS и другие).</li>

119 <li>Устройство пользователя получает уведомление.</li>

120 <li>На устройстве отображается уведомление.</li>

121 <li>Пользователь нажимает на уведомление.</li>

122 <li>Открывается приложение с соответствующим экраном, например с информацией про акцию.</li>

123 </ul>Альтернативные сценарии:

124 <ul><li>Если пользователь отключил уведомления, то устройство не получает уведомление. Возможно, ПО будет логировать то, что уведомление отправлено, но не доставлено.</li>

125 <li>Если устройство находится вне зоны доступа или не подключено к Сети в момент отправки, то уведомление доставляется, когда устройство снова будет доступно.</li>

126 <li>Если уведомление имеет неправильный формат данных для отображения на устройстве, то оно не отображается. Сервер должен логировать это событие для последующего решения бага.</li>

127 </ul>Упрощённая UML-диаграмма для use case с отправкой push-уведомления в мобильном приложенииИллюстрация: Майя Мальгина для Skillbox MediaСоставлять сценарий использования удобнее всего при помощи специализированных сервисов. Они позволяют быстро строить диаграммы, используя принципы UML, хранить их в проекте и совместно работать над ними с командой.

128 <a>Draw.io</a> - бесплатный онлайн-редактор диаграмм, у которого есть десктопная версия. Работает прямо в браузере и не требует регистрации, хотя с аккаунтом можно подключить синхронизацию через Google Drive или другие облачные сервисы.

129 В библиотеке Draw.io есть готовые элементы для UML: символы для акторов, овалы для конкретных действий, рамка системы и стрелки со связями. Можно нарисовать схему вручную или взять готовый шаблон, чтобы упростить работу. Ограничение одно: поддерживать актуальность сложной документации придётся вручную, без автоматического внесения изменений в созданные диаграммы.

130 <a>Lucidchart</a> - это облачный сервис для команд, где можно строить UML-диаграммы и сразу делиться ими с коллегами. В Lucidchart есть готовые шаблоны и возможность создавать диаграммы из текста. Например, аналитик пишет описание шагов, а система автоматически собирает из него последовательную диаграмму.

131 Инструмент интегрируется с Google Drive, Confluence и Jira. Благодаря этому его часто используют в больших командах, где важна интеграция с другими сервисами. Большая часть функций доступна только на платных тарифах.

132 <a>PlantUML</a> - это инструмент для тех, кто предпочитает текст графическим элементам. Здесь диаграммы описываются кодом - короткими строками вроде actor User, usecase "Login", User --> (Login). А сервис перестраивает это в UML-диаграмму. Подробная документация доступна на сайте ПО.

133 Схемы в PlantUML можно хранить в репозитории вместе с кодом, разделять на отдельные версии и обновлять автоматически. Минус в том, что графического интерфейса нет: придётся учить синтаксис, а визуально схемы в итоге выглядят проще, чем в специализированных редакторах.

134 Каждый инструмент решает свои задачи. Draw.io подойдёт, если нужно быстро и бесплатно построить диаграмму use case. Lucidchart - выбор для команд, когда важна интеграция и совместная работа. PlantUML - хороший вариант, если диаграммы должны храниться рядом с кодом и аналитик предпочитает описывать действия текстом, а не работать с визуальными инструментами.

135 Часто два этих понятия путают, но это разные инструменты, которые решают разные задачи.

136 User story(пользовательская история) - это короткое описание того, что нужно пользователю от продукта и зачем. Она помогает сформулировать задачу с точки зрения человека - чтобы команда понимала, какую пользу несёт отдельная функция или ПО в целом.

137 Структура у user story простая:"Как [роль] я хочу [цель], чтобы [результат]".Например: "Как покупатель я хочу сохранять товары в избранное, чтобы вернуться к ним позже". Для user story, в отличие от use case, не прорабатывают пошаговые сценарии и не строят для них диаграммы. Основной акцент делают на коротком описании желаемого для пользователя результате.

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

139 На практике use case и user story хорошо сочетаются. User story задаёт направление: что нужно пользователю и зачем. А use case раскрывает детали: как именно система должна реагировать на действия пользователя и какие исключения нужно учесть.

140 <a>Курс с трудоустройством: "Профессия Разработчик + ИИ" Узнать о курсе</a>