ТЗ на разработку ПО для БПЛА: что подготовить заказчику

Техническое задание на ПО для БПЛА начинается с задачи заказчика: какие данные система должна получить, что сделать с ними и какой результат передать человеку или другой системе. Перечень технологий и пожелание «добавить автономность» сами по себе не определяют объём разработки.

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

1. Опишите задачу и границы проекта

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

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

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

2. Соберите сведения о платформе

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

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

3. Определите входные и выходные данные

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

4. Заранее договоритесь, как проверять результат

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

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

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

5. Зафиксируйте состав передачи

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

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

Короткий бриф для первого обсуждения

1. Задача и ожидаемый результат.
2. Пользователь системы и рабочий сценарий.
3. Платформа, оборудование и версии ПО.
4. Документация интерфейсов и разрешённые примеры данных.
5. Ограничения и открытые технические вопросы.
6. Критерии приёмки и доступное оборудование для проверки.
7. Состав передачи и пожелания к сопровождению.

Этот бриф можно использовать для обсуждения разработки ПО для БПЛА и БАС. Если конфигурация ещё не определена, начните с границ системной интеграции: это поможет не смешивать разработку ПО с подбором и заменой оборудования.

Передать задачу на разработку ПО