Как подготовить техническое задание на систему защиты от БПЛА

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

Начните с назначения объекта

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

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

Описывайте функции, а не торговые названия

ТЗ должно отвечать на вопросы:

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

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

Требования к обнаружению

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

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

Требования к реагированию

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

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

Инфраструктура и интеграция

Проекту нужны питание, резервирование, сеть, серверные ресурсы, места установки и защищённые каналы связи. Поэтому в ТЗ включают:

1. точки подключения к ЛВС;
2. требования к информационной безопасности;
3. электропитание и резерв;
4. климатические условия;
5. молниезащиту и заземление;
6. допустимые места монтажа;
7. интерфейсы с видеонаблюдением и ситуационным центром;
8. требования к хранению журналов.

Приёмочные испытания

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

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

Документы и обучение

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

Типичные ошибки

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

Частые вопросы

Кто должен готовить ТЗ?

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

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

Можно сделать предварительный документ, но точки установки и часть параметров останутся допущениями.

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

Бюджет помогает определить этапность, но не должен подменять функциональные требования.