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

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

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

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

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

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

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

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

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

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