ТЗ на ПО для сенсорного киоска: требования, структура и приемка

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

Короткий ответ: в ТЗ нужны семь обязательных частей: сценарии пользователей, оборудование и ОС, touch-интерфейс, данные и интеграции, offline-режим, kiosk mode с восстановлением, измеримые критерии приемки. Макетов без этих условий недостаточно для надежного публичного терминала.

Почему обычного ТЗ на сайт недостаточно

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

Поэтому в проекте появляются требования, которых обычно нет у корпоративного сайта:

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

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

1. Паспорт проекта и границы системы

Начните ТЗ с короткой таблицы. Она защищает проект от разных трактовок слов «панель», «приложение» и «админка».

Параметр	Что зафиксировать
Назначение	Навигация, каталог, регистрация, очередь, презентация, оплата или другой сценарий
Место работы	Выставка, улица, офис, торговый зал, аэропорт, медицинская организация
Пользователи	Посетитель, оператор, администратор контента, технический специалист
Оборудование	Модель, диагональ, разрешение, ориентация, тип сенсора, компьютер
ОС	Windows, Android, Linux, версия и политика обновлений
Сеть	Постоянная, нестабильная, закрытый контур или полное отсутствие интернета
Периферия	Принтер, камера, сканер, NFC, платежный терминал, датчики
Управление	Локальная админка, облачная панель, API или загрузка файлов

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

2. Пользовательские сценарии

Для каждого типа пользователя опишите цель, точку входа и завершение. Вместо «пользователь смотрит каталог» нужна последовательность:

1. Киоск показывает стартовый экран.
2. Посетитель выбирает категорию.
3. Открывает карточку объекта.
4. Смотрит галерею или видео.
5. Оставляет контакт либо возвращается к списку.
6. После завершения или бездействия приложение очищает сессию и возвращается на старт.

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

Таблица сценария для ТЗ

Поле	Пример формулировки
Триггер	Пользователь нажал «Найти объект»
Предусловие	Загружен локальный справочник объектов
Основной путь	Фильтр → список → карточка → маршрут
Ошибка	Сервер недоступен
Поведение	Показать локальные данные и отметить время последней синхронизации
Завершение	Возврат на старт через заданный период бездействия

Такую таблицу можно проверять тестом. Фраза «интерфейс должен быть удобным» приемочного критерия не создает.

3. Требования к touch-интерфейсу

Сенсорный интерфейс проектируют для пальца, а не для курсора. В нем нельзя полагаться на hover, мелкие иконки или точное попадание в текстовую ссылку.

В WCAG 2.2 минимальная цель для веб-интерфейса описана как область 24 на 24 CSS-пикселя либо достаточное расстояние от соседних целей. Усиленный критерий использует 44 на 44 CSS-пикселя. Эти числа полезны как отправная точка, но не заменяют проверку на физическом устройстве: киоск может стоять под углом, использовать крупный экран или обслуживать людей с разными возможностями.

В ТЗ зафиксируйте:

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

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

4. Kiosk mode и восстановление

Kiosk mode должен ограничивать публичного пользователя приложением и обеспечивать предсказуемый запуск устройства.

Microsoft разделяет Windows-конфигурации на single-app kiosk и ограниченный multi-app сценарий. В single-app режиме назначенное приложение работает полноэкранно, а пользователь не получает обычный рабочий стол. Для desktop-приложений и UWP/Edge используются разные механизмы, поэтому режим выбирают после определения типа приложения и редакции Windows.

На Android для выделенных устройств применяется Lock Task Mode. Он требует управляемой конфигурации устройства и списка разрешенных приложений; простой полноэкранный режим не дает того же уровня ограничения.

В ТЗ ответьте на вопросы:

• кто и как входит в сервисный режим;
• запускается ли приложение автоматически;
• что происходит после аварийного завершения;
• можно ли открыть системные настройки;
• как устанавливаются обновления;
• где хранятся логи;
• кто получает уведомление о недоступности;
• как вернуть предыдущую версию.

Не привязывайте решение к слову «киоск» без проверки ОС и типа приложения. Настройка, доступная на одной редакции системы, может отсутствовать на другой.

5. Offline-режим и синхронизация

Требование «должно работать без интернета» нужно разложить на функции. Не все операции обязаны быть доступны офлайн.

Функция	Возможный режим без сети	Что определить в ТЗ
Каталог и медиа	Локальная копия	Объем, формат и правила обновления
Поиск	Локальный индекс	Какие поля доступны, как часто обновляется
Форма заявки	Очередь на отправку	Шифрование, повторная отправка, удаление
Карта	Предзагруженные данные	Масштаб, маршруты, актуальность
Оплата	Обычно требует отдельного сценария	Поведение при недоступности провайдера
Аналитика	Локальный буфер событий	Лимит, дедупликация, время синхронизации

Обязательно опишите конфликт данных. Если контент обновился на сервере, а киоск отправляет отложенную заявку, система должна понимать, что можно объединить, а что требует ручной проверки.

В кейсе интерактивной карты для аэропорта можно посмотреть пример проекта, где важны полноэкранный touch-интерфейс, карта, мультимедийный контент и управление данными. Для дорожного проекта мы использовали локальную и облачную логику приложения для сенсорной панели.

6. Интеграции и данные

Для каждой интеграции перечислите систему, протокол, направление обмена и ответственного владельца. Формулировка «интеграция с CRM» не объясняет, какие данные и в какой момент передаются.

Минимальное описание интеграции содержит:

• источник и получателя;
• метод авторизации;
• состав полей и обязательность;
• частоту или событие обмена;
• тайм-аут и повторные попытки;
• идентификатор для защиты от дублей;
• журнал ошибок;
• тестовый контур и контакты владельца API.

Если терминал собирает персональные данные, отдельно определите согласие, срок локального хранения, передачу, очистку после сессии и доступ технического персонала. Не оставляйте эти решения только на уровне текста политики: они влияют на архитектуру приложения.

7. Администрирование и обновления

Контент публичного киоска меняется после запуска. В ТЗ заранее укажите, кто сможет:

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

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

8. Критерии приемки

Каждое важное требование превратите в наблюдаемый тест. Пример блока приемки:

1. После подачи питания приложение открывается без действий оператора.
2. Пользователь не может выйти на рабочий стол штатными жестами и клавишами.
3. При отключении сети каталог и поиск продолжают работать на локальных данных.
4. Заявка сохраняется в локальной очереди и отправляется после восстановления связи один раз.
5. После периода бездействия приложение очищает введенные данные и возвращается на стартовый экран.
6. После аварийного закрытия приложение автоматически восстанавливается.
7. Администратор видит версию контента и время последней синхронизации.

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

Что передать разработчику до оценки

Для первичной оценки достаточно собрать:

1. Описание задачи и места эксплуатации.
2. Фото или точную модель оборудования.
3. Один главный и несколько вторичных сценариев.
4. Черновой список экранов.
5. Требования к offline и kiosk mode.
6. Список интеграций и контакты владельцев API.
7. Форматы контента и пример объема данных.
8. Срок пилота и критерии успешности.

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

FAQ

Нужен ли прототип до разработки ПО для киоска

Да. Кликабельный прототип позволяет проверить последовательность экранов и расположение действий до программирования. Но финальный touch-UX все равно проверяют на устройстве нужного размера.

Что выбрать для киоска: веб-приложение или desktop-приложение

Веб-приложение удобно для обновления и интеграций, desktop-приложение дает больше контроля над устройством и локальными ресурсами. Выбор зависит от ОС, offline-требований, периферии и способа централизованного управления, а не от моды на стек.

Можно ли сделать киоск на обычном сайте

Можно для простого каталога, если сайт адаптирован под touch, полноэкранный режим и нестабильную сеть. Для периферии, локального хранения, надежного восстановления и закрытого контура обычно нужна отдельная программная оболочка или приложение.

Нужно ли описывать в ТЗ конкретную модель панели

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

Как проверить offline-режим

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

Что сильнее всего влияет на стоимость разработки

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

Полезно по теме

• Разработка ПО для сенсорных панелей и киосков
• Как выбрать интерактивную панель для выставки
• Кейс: интерактивная карта для аэропорта
• Кейс: приложение для сенсорной панели дорожного проекта

Источники

• Microsoft Learn: варианты настройки Windows kiosk
• Android Developers: Lock Task Mode
• W3C WCAG 2.2: минимальный размер цели касания
• W3C WCAG 2.2: расширенный размер цели касания