Техническое задание на автоматизацию парковки: структура и приёмка

Коротко

ТЗ на парковку часто начинается с перечня: распознавание номеров, шлагбаумы, свободные места, табло, оплата, аналитика. Такой список удобно включить в закупку, но трудно принять. Что значит «система распознаёт»? На какой выборке? Что происходит при потере связи? Кто отвечает за ошибочный номер? Когда место считается свободным? Какая система имеет право открыть шлагбаум?

Проверяемое ТЗ связывает каждую функцию с входными данными, владельцем решения, ожидаемым результатом и тестом — включая негативный сценарий.

Что нужно получить до написания ТЗ

Паспорт объекта

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

• адрес и тип объекта: БЦ, ЖК, ТЦ, платная или ведомственная парковка;
• количество въездов, выездов, уровней, зон и мест;
• односторонние участки, рампы, тупики и ограничения высоты;
• категории мест: обычные, МГН, EV, резерв, гости, арендаторы;
• расчётный и пиковый поток автомобилей;
• режим работы и часы пик;
• операторские посты, диспетчерская и точки обслуживания;
• доступные серверные, сети, электропитание и шкафы;
• внешние системы: СКУД, АПС, 1С/ERP, CRM, BMS, пожарная автоматика, эквайринг.

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

Карта пользовательских потоков

Опишите минимум пять путей:

1. сотрудник или постоянный пользователь;
2. заранее заказанный гость;
3. незарегистрированный посетитель;
4. служебный/аварийный транспорт;
5. оператор при отказе камеры, сети или контроллера.

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

Владельцы решений

Составьте простую таблицу ответственности:

Главный вопрос: какая система является source of truth для каждого поля. Если два контура одновременно могут изменить право доступа или сумму, конфликт проявится уже на объекте.

Границы системы

Нарисуйте контекстную схему из пяти блоков:

оборудование → gateway → бизнес-ядро → пользовательские интерфейсы → внешние системы.

Для каждого перехода укажите:

• протокол и версию;
• инициатора;
• идентификатор и idempotency key;
• timeout/retry;
• подпись/аутентификацию;
• допустимую задержку;
• поведение при дубле и нарушении порядка;
• журнал, по которому расследуется ошибка.

Фраза «интеграция по API» без этой информации непринимаема.

Рекомендуемая структура ТЗ

1. Назначение и цели

Цель должна быть измерима. Плохо: «повысить эффективность парковки». Лучше:

• сократить p95 времени поиска места с исходного значения до целевого значения в согласованный период;
• обеспечить отображение доверенного статуса не менее согласованная целевая доля мест, отдельно считая unknown;
• сократить median времени взятия инцидента в работу с исходного значения до целевого значения;
• сформировать единый журнал passage/access/parking session с корреляционным ID.

Бизнес-эффект и технический SLO — разные требования. Быстрая доставка события не гарантирует короткую очередь, если геометрия въезда неудачна.

2. Термины и модель данных

Определите:

• объект, уровень, зона, место, въезд, полоса;
• free, occupied, reserved, out_of_service, unknown;
• событие идентификации, решение доступа, команда, подтверждение прохода;
• парковочная и тарифная сессии;
• инцидент и доказательные материалы;
• источник времени и timezone;
• правила нормализации ГРЗ;
• срок актуальности статуса.

Особенно важно определить unknown. Система не должна превращать отсутствие свежих данных в свободное место.

3. Роли и права

Укажите роли не только по должностям, но и по действиям:

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

Отдельно задайте object scope: должен ли оператор объекта A видеть номера, фото или инциденты объекта B?

4. Топология и цифровая схема

Требования могут включать:

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

Приёмка: на тестовом уровне изменить геометрию, сохранить сцену, проверить права, опубликовать граф, получить маршрут, выполнить rollback и подтвердить аудит.

5. Состояние машиномест

Опишите не только «контроль занятости», но и:

• источник и формат события;
• связывание камеры/канала с местом;
• freshness TTL;
• confidence и порог;
• конфликт двух источников;
• неизвестный код места;
• повтор и порядок сообщений;
• ручную коррекцию и её приоритет;
• историю;
• media retention;
• метрику качества и процедуру разметки контрольной выборки.

Приёмочный набор должен включать свободное/занятое место, no-data, дубли, задержанное событие, неизвестный код и потерю брокера.

6. Оборудование

Для каждого класса зафиксируйте manufacturer/model/версию встроенного ПО и матрицу возможностей:

«Поддерживает ONVIF» или «поддерживает Modbus» недостаточно: нужны конкретный профиль, direction, payload, timeout и испытанная версия.

7. Инциденты

Укажите:

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

Приёмка должна доказать полный lifecycle одного ручного и одного автоматического инцидента, а не только создание записи.

8. Навигация и табло

Разделите четыре расчёта:

1. доверенный статус места;
2. агрегат свободных мест;
3. достижимость из конкретного въезда;
4. представление на табло/маршрут.

Опишите поведение при unknown, перекрытии зоны, пожарном режиме, потере связи с экраном и изменении конфигурации во время движения.

9. Интеграции

Для REST и webhooks задайте:

• OpenAPI/schema и versioning policy;
• scopes/object policy/IP allowlist;
• пагинацию и фильтры;
• idempotency;
• подпись webhook;
• retry/backoff/dead-letter или delivery log;
• replay;
• корреляционный ID;
• маскирование ГРЗ/media;
• rate limits;
• тестовый sandbox/emulator;
• совместимость версий и deprecation.

Для СКУД отдельно согласуйте ownership субъектов, пропусков, зон, квот и anti-passback.

10. Аналитика и отчёты

Для каждого KPI задайте формулу, источник, знаменатель, окно и timezone. Например:

occupancy = occupied / (eligible - unknown?).

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

Нужны как минимум current summary, trend, история места, visits, export и контроль полноты входных событий — если это входит в scope.

11. Безопасность и данные

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

• модель угроз и сетевые зоны;
• TLS termination;
• управление секретами;
• RBAC/object scope;
• MFA/OTP, если требуется;
• журнал административных действий;
• retention ГРЗ, кадров, видео и логов;
• presigned links вместо публичного media bucket;
• резервное копирование и защита backup;
• обработку персональных данных, роли оператора/обработчика и основания;
• обезличивание тестовых и маркетинговых данных;
• порядок устранения уязвимостей.

Юридическую часть по 152-ФЗ, локальным актам и коммерческой тайне утверждает профильный специалист, а не интегратор в одиночку.

12. Развёртывание и эксплуатация

Укажите:

• supported OS/architecture;
• on-prem/cloud/air-gap;
• состав контейнеров/сервисов;
• внешние зависимости;
• required CPU/RAM/disk/network;
• сертификаты и DNS;
• NTP;
• миграции схемы;
• backup/restore;
• мониторинг, метрики, логи, алерты;
• RPO/RTO/SLO;
• обновление, rollback и совместимость данных;
• demo/clean поставку;
• обучение и регламенты L1/L2/L3.

Требование «резервное копирование есть» принимается только успешным восстановлением в изолированном окружении.

Как написать измеримое требование

Используйте шаблон:

При предусловие роль/система действие; система в течение согласованного времени возвращает/фиксирует результат; это подтверждается API/UI/log/physical доказательные материалы. При отказ система безопасное поведение и создаёт диагностический след.

Пример:

При недоступности NATS Gateway сохраняет уже принятые валидные события на локальном диске; после восстановления публикует их без потери и без неконтролируемого дубля. Испытание: остановить брокер, передать N событий, восстановить связь, сопоставить event IDs и materialized state.

Матрица трассировки требований

Замените примеры реальными ID и требованиями. Для каждого P0/P1 укажите критерий остановки приёмки.

План приёмки

До объекта

• schema/OpenAPI contract tests;
• unit и integration tests;
• emulator цепочки;
• security negative tests;
• чистая установка и upgrade существующей базы;
• backup/restore;
• browser/viewports/accessibility для критичных экранов.

На объекте

• инвентаризация exact версию встроенного ПО/config;
• end-to-end цепочка каждого класса оборудования;
• поток в часы нагрузки;
• отказ сети/брокера/камеры/табло/контроллера;
• ручной fallback;
• аварийный режим;
• измерение latency p50/p95/p99;
• контрольная выборка accuracy;
• сменный прогон и подпись ролей.

Документы результата

• exact versions/SHA и конфигурация;
• перечень пройденных/непройденных тестов;
• P0/P1/P2 дефекты;
• скриншоты, логи, видео и checksums;
• ограничения и исключения;
• решение «принято/частично/отклонено»;
• подписи заказчика, эксплуатации, ИБ и поставщика.

Что запросить у кандидата-поставщика

1. Демо на ваших исходных данных, а не только записанное видео.
2. Матрицу поддержанных моделей и версию встроенного ПО с датой испытания.
3. OpenAPI/event schemas и политику версий.
4. Негативные тесты и failure matrix.
5. Процедуру backup/restore и доказательные материалы последнего прогона.
6. Состав внешних зависимостей для on-prem/offline.
7. Матрицу ролей и object scope.
8. Retention и модель доступа к ГРЗ/media.
9. Нагрузочный профиль с понятным железом и dataset.
10. Список исключений: платежи, касса, vendor connectors, мобильное приложение, поддержка 24×7.

FAQ

Можно ли взять типовое ТЗ без обследования?

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

Нужно ли указывать конкретные модели оборудования?

Для закупки — либо конкретные модели/версию встроенного ПО, либо проверяемые протоколы совместимости и обязанность поставщика провести hardware acceptance до ввода.

Как задать точность распознавания?

Через выборку, условия света/погоды, правила эталонную ручную разметку, обработку unreadable, метрики false positive/false negative и доверительный интервал. Одного процента без методики недостаточно.

Что важнее: API или готовый коннектор?

Готовый принятый коннектор снижает риск запуска. API даёт расширяемость, но не доказывает совместимость с конкретной СКУД. В ТЗ нужны оба уровня, если интеграция критична.

Как принять отказоустойчивость?

Остановить реальные компоненты по сценарию, измерить потерю/задержку, восстановить сервис и сверить состояние. Презентация архитектуры не заменяет испытание.

Какие требования связаны с персональными данными?

ГРЗ, кадры и связанные события следует включить в инвентаризацию данных, определить основания/роли/retention/доступ и провести юридическую и ИБ-оценку. Универсальное заключение без контекста объекта невозможно.

Граница применимости к CShark

Материал описывает проверяемый инженерный подход. Конкретный состав CShark зависит от версии, подключённых источников данных, прав, конфигурации и приёмки оборудования на объекте.

Посмотрите, какие возможности CShark доступны водителю и оператору и как они применяются на парковке, на странице возможностей системы.