Начните со сценариев применения
Требование должно объяснять, какое наблюдаемое событие важно для объекта, в каких условиях оно происходит и какое решение необходимо поддержать. Одинаковое слово «дальность» может означать разные режимы, вероятности и условия испытаний.
- типы контролируемых зон;
- обычный фон и ожидаемые помехи;
- время, доступное оператору для подтверждения;
- допустимые и недопустимые действия после обнаружения.
Запрашивайте условия каждого показателя
Число без методики трудно сравнивать. Для ключевых характеристик полезно запрашивать режим, тип цели, высоту, скорость, фон, погоду, вероятность обнаружения, ложные сигналы, время обновления и способ подтверждения результата.
Проверяйте систему, а не отдельный компонент
Ценность определяется тем, проходит ли информация от наблюдения до ответственного пользователя без потери смысла. Необходимо проверить интерфейсы, временную синхронизацию, журналирование, доступ, состояние связи и поведение при отказе.
Включите эксплуатацию и жизненный цикл
Оценка должна учитывать монтаж, обучение, обновления, запасные части, поддержку, диагностику, кибербезопасность и повторную проверку после изменений. Низкая цена поставки не означает низкую стоимость владения.
Отделяйте документы от доказательств
Техническое описание поставщика является исходным утверждением, а не результатом приёмки. Сертификаты, протоколы и демонстрации следует связывать с конкретной моделью, версией, режимом и согласованным сценарием. Отсутствующие данные лучше фиксировать как вопрос, а не заполнять предположением.
Проведите отдельную нормативную проверку
Товарный код или маркетинговое название сами по себе не устанавливают режим ввоза, контроля или применения. Для конкретной конфигурации необходимы подтверждённые характеристики и соответствующие официальные определения или разрешения, если они требуются.