УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ В СЕТЕВОЙ КОНФИГУРАЦИИ IT-ПРОЕКТОВ: ПРИНЦИП ВСТРЕЧНОЙ НАПРАВЛЕННОСТИ ПОТОКОВ И ТРЁХУРОВНЕВАЯ ПРОСЛЕЖИВАЕМОСТЬ

АННОТАЦИЯ

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

Ключевые слова: управление требованиями; инженерия требований; сетевая разработка; прослеживаемость требований; White-label; IT-проект; бизнес-информатика.

Современный этап развития информационных технологий характеризуется тем, что конечному пользователю всё чаще поставляется не монолитный программный продукт одного разработчика, а составное решение, формируемое несколькими юридически независимыми компаниями. Особенно заметна эта тенденция в системах управления транспортом: по оценкам аналитиков, мировой рынок систем управления автопарком устойчиво растёт двузначными темпами [1], а установленная база подключённых транспортных средств продолжает увеличиваться [2]. Одновременно сохраняется проблема низкой результативности IT-проектов: значительная их часть завершается с превышением сроков и бюджета либо не достигает заявленных целей, причём для крупных проектов доля успешных исходов особенно мала [3]. Ключевым фактором, определяющим исход проекта, традиционно признаётся качество управления требованиями [4].

Классические подходы к управлению требованиями исходят из предпосылки о единой организации-разработчике либо о диадной схеме взаимодействия «заказчик — исполнитель». В таких рамках описаны базовые активности работы с требованиями — выявление, анализ, спецификация, верификация и управление изменениями [5], а также процессы инженерии требований, закреплённые в международных стандартах [6] и сводах знаний по бизнес-анализу [7]. Отдельным направлением исследований выступает проблема прослеживаемости требований, сформулированная ещё в работах по трассируемости [8] и сохраняющая актуальность в условиях распределённой разработки. Вместе с тем перенос этих подходов на сетевую конфигурацию наталкивается на существенное ограничение.

Анализ современных публикаций по управлению требованиями в крупномасштабной гибкой разработке [9], по практикам гибкой инженерии требований [10] и по глобально распределённой разработке [11] показывает, что фокус исследований смещён на координацию множества команд внутри одной организации либо на территориальную и временну́ю распределённость команд. Ситуация, при которой над единым продуктом работают несколько юридически независимых компаний, а требование к выходному визуальному артефакту проходит через несколько звеньев интерпретации, систематически не проработана. Дополнительным источником сложности является интеграция в продукт модуля стороннего разработчика по модели White-label: требования к визуальным артефактам (дашбордам, отчётам, презентациям) формируются на стыке компетенций нескольких компаний и не выделяются в существующих методиках в самостоятельный класс. Указанный пробел определяет цель настоящего исследования — разработку способа оптимизации управления требованиями в сетевой конфигурации IT-проектов.

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

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

Важной особенностью способа является переносимость его ядра. Принципы встречной направленности потоков и трёхуровневой прослеживаемости не зависят от конкретной юрисдикции, тогда как нормативные требования выносятся в отдельный подключаемый слой соответствия. В качестве граничного условия в работе рассмотрено законодательство Республики Узбекистан о персональных данных [12], а также подзаконные акты, регулирующие порядок обработки персональных данных [13]. При тиражировании решения в другой юрисдикции заменяется только слой соответствия, а ядро методики и инструментальная конфигурация остаются неизменными. Для формального описания процессов управления требованием в исходном и целевом состояниях применялась нотация моделирования бизнес-процессов [14].

Апробация предложенного способа выполнена на системе управления автопарком, в которую по модели White-label интегрирован модуль визуализации стороннего разработчика. Сравнение процесса управления требованием в исходном (AS-IS) и целевом (TO-BE) состояниях показало сокращение продолжительности цикла обработки требования с четырнадцати до шести рабочих дней и уменьшение среднего числа итераций согласования с 2,7 до 1,4 на требование. Эффект достигается за счёт введения общего реестра требований как единого источника правды, восстановления сквозной трассируемости и выделения требований к визуальным артефактам в самостоятельный класс. Полученные результаты подтверждают работоспособность способа в реальной сетевой конфигурации.

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

Список литературы:

1. Fleet Management Market — Global Forecast to 2030 [Электронный ресурс]. — MarketsandMarkets, 2025. — URL: https://www.marketsandmarkets.com (дата обращения: 28.05.2026).
2. The installed base of fleet management systems in North America to reach 33 million units by 2029 [Электронный ресурс] // Berg Insight. — 2024. — URL: https://www.berginsight.com (дата обращения: 28.05.2026).
3. Standish Group. CHAOS Report [Электронный ресурс]. — The Standish Group International, 2020. — URL: https://www.standishgroup.com (дата обращения: 28.05.2026).
4. Вигерс К., Битти Дж. Разработка требований к программному обеспечению. — 3-е изд. — М.: Русская редакция; СПб.: БХВ-Петербург, 2014. — 736 с.
5. Соммервилл И. Инженерия программного обеспечения. — М.: Вильямс, 2002. — 624 с.
6. ISO/IEC/IEEE 29148:2018. Systems and software engineering — Life cycle processes — Requirements engineering. — Geneva: ISO, 2018. — 104 p.
7. A Guide to the Business Analysis Body of Knowledge (BABOK Guide). — 3rd ed. — Toronto: IIBA, 2015. — 514 p.
8. Gotel O. C. Z., Finkelstein A. C. W. An Analysis of the Requirements Traceability Problem // Proceedings of the First International Conference on Requirements Engineering. — 1994. — P. 94—101.
9. Kasauli R., Knauss E., Horkoff J. et al. Requirements engineering challenges and practices in large-scale agile system development // Journal of Systems and Software. — 2021. — Vol. 172. — Art. 110851.
10. Schön E.-M., Thomaschewski J., Escalona M. J. Agile Requirements Engineering: A systematic literature review // Computer Standards & Interfaces. — 2017. — Vol. 49. — P. 79—91.
11. Yaseen M., Ali A., Ullah N. et al. Requirements engineering in global software development: a systematic literature review // Journal of Software: Evolution and Process. — 2024.
12. Закон Республики Узбекистан от 02.07.2019 г. № ЗРУ-547 «О персональных данных» [Электронный ресурс]. — URL: https://lex.uz (дата обращения: 28.05.2026).
13. Постановление Кабинета Министров Республики Узбекистан от 05.10.2022 г. № 570 «Об обработке персональных данных» [Электронный ресурс]. — URL: https://lex.uz (дата обращения: 28.05.2026).
14. Business Process Model and Notation (BPMN). Version 2.0 [Электронный ресурс]. — Object Management Group, 2011. — URL: https://www.omg.org/spec/BPMN/2.0 (дата обращения: 28.05.2026).