Вторая часть цикла Владимира Зуева из Axenix посвящена этапу, который в корпоративной разработке часто пропускают или делают наспех: сбору и систематизации требований перед проектированием архитектуры. На примере системы управления беспилотным грузовым транспортом автор показывает, как ИИ помогает справляться с объёмными нормативными документами.
Отправная точка — закон Бёма, который описывает экспоненциальный рост стоимости исправления ошибок по мере продвижения проекта. Ошибка в требованиях, найденная на этапе анализа, обходится в 1 условную единицу. На этапе проектирования — уже 3–6 единиц, при тестировании — 10–20, а в работающей системе — 60–100 единиц и выше. Это делает тщательную проработку требований в начале экономически оправданной, даже если она занимает дополнительное время.
| Этап проекта | Стоимость исправления ошибки в требованиях |
|---|---|
| Анализ требований | 1 условная единица |
| Проектирование | 3–6 единиц |
| Тестирование | 10–20 единиц |
| Работающая система (после внедрения) | 60–100 единиц и выше |
В проекте используется метод обратного инжиниринга требований (Requirements Reverse Engineering). Классический подход предполагает, что функциональные требования формируются из прецедентов использования: сначала описываются сценарии работы системы, затем из них выводятся конкретные функции. Однако в государственных и крупных корпоративных проектах заказчик нередко передаёт уже готовый список требований — в виде таблиц, нормативных ссылок или длинного текста. Тогда задача разработчика — восстановить прецеденты в обратном направлении, чтобы понять логику заказчика, проверить полноту сценариев и подготовить основу для тестирования.
Метод обратного инжиниринга требований позволяет восстановить прецеденты использования из готового списка требований заказчика.
Для анализа нормативной базы автор использовал GenAI: PDF-файл проекта Федерального закона «О высокоавтоматизированных транспортных средствах» (ВАТС) был загружен в инструмент с промптом, запрашивающим перечень требований к оператору беспилотной грузовой перевозки. Законопроект разграничивает понятия «водитель» — лицо в салоне, активирующее систему — и «оператор сервисного обслуживания» — юридическое лицо или ИП, осуществляющее дистанционный контроль. При отсутствии водителя в кабине (ч. 2 ст. 12) именно оператор становится ключевым субъектом обеспечения безопасности движения.
GenAI выделил четыре группы требований. Организационно-правовые: обязательное лицензирование деятельности по сервисному обслуживанию ВАТС (ст. 15), включение в реестр операторов Единой автоматизированной информационной системы ВАТС (ст. 20), наличие в штате квалифицированных техников-мехатроников. Функциональные обязанности при эксплуатации: исключительное право на активацию и дезактивацию беспилотного режима (ст. 11, 13), обязанность взять управление или обеспечить безопасную остановку при отключении автоматического режима, контроль среды штатной эксплуатации и запрет активации за её пределами. При нештатных ситуациях оператор обязан деактивировать режим, установить связь с людьми в транспортном средстве и организовать прекращение эксплуатации при угрозе безопасности (ст. 26).
Подход демонстрирует практическую ценность ИИ-инструментов не в генерации кода, а в обработке объёмных документов: вместо ручного разбора многостраничного законопроекта аналитик получает структурированный перечень требований с привязкой к конкретным статьям. Это особенно актуально для российских проектов в регулируемых отраслях — транспорте, финансах, здравоохранении, — где нормативная база объёмна и постоянно обновляется. Нотация ArchiMate при этом служит языком для перевода этих требований в архитектурные решения: бизнес-слой, прикладной слой и технологический слой описываются в единой системе обозначений, что упрощает коммуникацию между бизнесом и разработчиками.
