Use Case помогает:
· говорить с бизнесом, аналитиками, разработчиками и тестировщиками на одном языке шагов, а не абстракций;
· уменьшить количество дефектов: сценарии, ошибки и исключения заранее проговорены и зафиксированы;
· легко конвертировать сценарий в тест‑кейсы и критерии приёмки: каждый шаг Use Case — почти готовый тест.
Минимальный шаблон Use Case для 1С
Ниже компактная структура, которую можно применять для 1С:ERP, УТ, УНФ, отраслевых решений.
1. Шапка
· ID: UC‑[МОДУЛЬ]‑[НОМЕР], например UC‑PUR‑001.
· Название: коротко и по сути, например «Автосогласование договора закупки».
· Приоритет: Must / Should / Could (MoSCoW), чтобы понимать, что обязательно, а что «хорошо бы».
2. Акторы
· Основной актор: ключевая роль в 1С (Закупщик, Кладовщик, Менеджер по продажам).
· Вторичные акторы: другие роли и подсистемы (Директор, Бухгалтерия, уведомления).
· Внешние системы: ЕГАИС, маркетплейсы, ЭДО и т.п.
3. Предусловия (Preconditions)
· Что обязательно должно быть выполнено до начала сценария: авторизация в нужной роли, нужный статус документа, заполненные справочники и настройки.
4. Основной сценарий (Happy Path)
· Последовательность шагов «актор → система» без ошибок и исключений.
· Каждый шаг отвечает на вопрос «кто что делает / что отвечает система».
5. Исключения и альтернативные потоки
· Что происходит, если лимит превышен, лимит не найден, справочник не настроен, внешний сервис недоступен.
· Удобно заводить отдельные ID: UC‑EX1, UC‑EX2 и привязывать их к шагам основного сценария.
6. Постусловия (Postconditions)
· Что гарантированно верно после выполнения сценария: статусы документов, записи в регистрах, созданные задачи, отправленные уведомления.
7. Нефункциональные требования (NFR)
· Требования к времени отклика, допустимой нагрузке, доступу по ролям, логированию, аудиту изменений.
8. Критерии приёмки (Acceptance Criteria)
· Набор проверяемых «если… → тогда…», по сути — готовые тест‑кейсы:
o AC‑001: условие → ожидаемый результат;
o AC‑002: условие → ожидаемый результат;
o плюс пограничные случаи и ошибки.
Пример Use Case для 1С:ERP (таблица)
Ниже пример Use Case для сценария автоматического согласования договора закупки по лимитам.
Блок | Содержание |
ID | UC‑PUR‑001 |
Название | Автоматическое согласование договора закупки по лимитам |
Приоритет | Must Have |
Модуль | Закупки → Договоры |
Акторы | Основной: Закупщик; Вторичный: Директор по закупкам; Внешний: сервис уведомлений (email/Telegram) |
Предусловия | 1) Пользователь авторизован как «Закупщик»; 2) Договор в статусе «Черновик»; 3) Справочник «Лимиты закупок» заполнен; 4) Контрагент активен |
Основной сценарий (Happy Path) | 1) Закупщик открывает форму договора; 2) Система показывает данные; 3) Закупщик нажимает «Отправить на согласование»; 4) Система сравнивает сумму договора с лимитом роли; 5) Если сумма ≤ лимита, система устанавливает статус «Согласовано автоматически»; 6) Записывает событие в историю согласования; 7) Показывает сообщение «Договор согласован автоматически»; 8) Закупщик может создать заказ поставщику |
Исключение UC‑EX1 (сумма > лимита) | На шаге 4 система видит, что сумма > лимита; устанавливает статус «На согласовании у директора»; отправляет уведомление директору со ссылкой на договор |
Исключение UC‑EX2 (лимит не найден) | На шаге 4 система не находит лимит; показывает ошибку «Не настроен лимит для роли Закупщик»; договор остаётся в статусе «Черновик» |
Постусловия | 1) Договор в статусе «Согласовано автоматически» или «На согласовании у директора»; 2) В истории согласования есть запись; 3) Для UC‑EX1 уведомление директору отправлено |
NFR | Время обработки шагов 3–5 — не более 2 секунд при 50 одновременных пользователях; сценарий доступен только ролям «Закупщик» и «Директор по закупкам»; все действия логируются |
Критерии приёмки | AC‑001: сумма < лимита → статус «Согласовано автоматически», запись в историю, ошибок нет; AC‑002: сумма > лимита → статус «На согласовании у директора», уведомление отправлено; AC‑003: лимит отсутствует → ошибка «Не настроен лимит…», статус не меняется; AC‑004: при 50 пользователях время отклика ≤2 секунд |
Такую таблицу удобно хранить в Confluence, Notion или Excel и линковать к задачам в трекере, ЧТЗ и тест‑кейсам.
Как встроить Use Case в поток работы 1С‑аналитика
Use Case будет живым инструментом, если встроить его в обычный рабочий цикл, а не писать «для галочки».
Короткий алгоритм:
· Сначала понять реальный процесс: наблюдение, короткое интервью с пользователем, разбор проблемных мест.
· Затем описать Use Case по компактной структуре: шапка, акторы, предусловия, основной сценарий, исключения, постусловия, NFR, критерии приёмки.
· Согласовать сценарий с бизнесом: один понятный документ видят аналитик, заказчик, разработчик и тестировщик.
· Привязать к Use Case: задачи в трекере, частные ТЗ (ЧТЗ), тест‑кейсы, сценарии UAT и критерии приёмки.
В результате Use Case становится опорной точкой требования: от него удобно строить ТЗ и ЧТЗ, писать тесты, готовить демонстрации и разбирать дефекты, а риски недопонимания в 1С‑проектах заметно снижаются.
