=Paper=
{{Paper
|id=Vol-1989/paper36
|storemode=property
|title=Моделирование процесса инженерии требований на промышленном предприятии (Requirements engineering process modeling for industrial enterprises)
|pdfUrl=https://ceur-ws.org/Vol-1989/paper36.pdf
|volume=Vol-1989
|authors=Victor Batovrin,Kirill Gaydamaka
}}
==Моделирование процесса инженерии требований на промышленном предприятии (Requirements engineering process modeling for industrial enterprises)==
https://ceur-ws.org/Vol-1989/paper36.pdf
Моделирование процесса инженерии требований
на промышленном предприятии
Батоврин В.К.1, Гайдамака К И.2
1
Московский Технологический Университет (МИРЭА), Москва, Россия
vkbat@mail.ru
2
Московский Технологический Университет (МИРЭА), Москва, Россия
k.gaydamaka@gmail.com
Abstract. This paper presents some special aspects of requirements engineering
process modeling for enterprises creating complex technical products.
Аннотация. В докладе рассмотрены особенности моделирования процес-
са инженерии требований в условиях предприятия, создающего сложную
техническую продукцию.
Ключевые слова: системная инженерия, инженерия требований, качество
требований.
1 Введение
Важнейшей составляющей деятельности по созданию сложных инженерных
объектов является работа с требованиями. Практически все крупные компании,
занятые созданием сложной техники, признают, что налаженная инженерия
требований критически важна для успеха проектов и является одним из ключе-
вых элементов повышения конкурентоспособности предприятий и их продук-
ции на мировом рынке.
Для установления на предприятии зрелого процесса инженерии требований, а
также для его поддержки инструментальными средствами, требуется модель
процесса инженерии требований. Общепризнанной модели процесса инженерии
требований, пригодной к адаптации к условиям деятельности произвольного
предприятия, сегодня не существует. Поэтому на каждом предприятии, созда-
ющем сложные системы, приходится налаживать свой уникальный процесс
инженерии требований, отвечающий особенностям предметной области и кон-
кретного бизнеса. Процесс инженерии требований является комплексным и
сложным, поэтому, возможны ситуации, когда предприятию приходится вы-
страивать отдельный процесс инженерии требований, адаптированный для кон-
кретного проекта, например, компания Airbus налаживала подобный процесс
при реализации проекта по созданию самолета A 380 [4]. Цель работы – анализ
существующих моделей процесса инженерии требований и выявление принци-
402
пов, которые могут быть положены в основу выполнения работ по моделирова-
нию этого процесса на промышленном предприятии.
2 Существующие рекомендации и модели
В научно-технической литературе представлены рекомендации и ряд моделей
процесса инженерии требований, устанавливающих как состав процессов инже-
нерии требований, так и порядок их выполнения, а также описывается возмож-
ная связь процессов инженерии требований с другими процессами жизненного
цикла.
При формировании модели состава процесса инженерии требований за осно-
ву могут быть взяты процессы, описанные в международных стандартах
ISO/IEC 15288 «Системная и программная инженерия. Процессы жизненного
цикла систем» [7] и ISO/IEC/IEEE 29148 «Системная и программная инжене-
рия. Управление жизненным циклом. Инженерия требований» [8]. Эти стандар-
ты не содержат описания модели процесса как таковой, однако предлагают
набор процессов, которые пригодны для ее построения, а именно:
• Процесс анализа хозяйственной деятельности или комплекса решаемых задач
(Business or mission analysis process).
• Процесс определения нужд и требований заинтересованных сторон
(Stakeholder needs and requirements definition process);
• Процесс определения требований к системе (System requirements definition
process).
Кроме того, упомянутые стандарты включают описание процессов, тесным об-
разом связанных с инженерией требований, но не предполагающих получение
требований в качестве основного результата, в том числе:
• Процесс определения архитектуры (Architecture definition process).
• Процесс определения проектно-конструкторских решений (Design definition
process).
• Процесс верификации (Verification process).
• Процесс валидации (Validation process).
Наконец, в указанных документах можно найти описание процессов, необходи-
мых для управления требованиями, в частности:
• Управление изменениями (Change management).
• Измерения (Measurement for requirements).
Примеры комплексных моделей процесса инженерии требований содержатся в
ряде публикаций, например, [3, 10, 13, 17]. Ключевое отличие модели, предла-
гаемой в [17], состоит в выделении отдельных процессов инженерии требова-
ний в области проблем и в области решений, а также в тесной увязке процесса
инженерии требований с процессом моделирования интересующей системы
403
посредством операций анализа и выработки вариантов проектного решения.
Подобная модель позволяет получить наглядное представление о взаимосвязи
между исходными и производными требованиями и облегчить формирование
стратегии проверки соответствия.
К. Поль, в свою очередь, предлагает при моделировании процесса инженерии
требований использовать три точки зрения: процесс, уровни абстракции, типы
артефактов [13]. При этом в качестве ключевых действий процесса инженерии
требований выделяется выявление, документирование и согласование требова-
ний с добавлением сквозных действий по валидации и управлению требования-
ми. Модель также определяет типовые артефакты инженерии требований: Цели,
Сценарии и Требования к решению (Solution-oriented requirements).
В ряде отраслей промышленности, в частности в авиации, сформировались
свои подходы к моделированию инженерии требований, см., например, [5, 6]. В
основу подобных моделей положена практика организации производственных
процессов, сложившаяся на зарубежных предприятиях в течение десятков лет,
что затрудняет прямую адаптацию содержащихся в документах рекомендаций к
условиям отечественного предприятия.
Таким образом, адаптация имеющихся рекомендаций по моделированию
процесса инженерии требований к условиям конкретной организации должна
выполняться в два этапа:
• Первый этап – адаптация рекомендаций международных стандартов для кон-
кретной отрасли или предприятия, например, авиационной, атомной, меди-
цинской, военной. На этом этапе главным образом определяются состав, цели
и результаты процессов.
• Второй этап – адаптация отраслевых или корпоративных стандартов для кон-
кретного проекта или контракта. На этом этапе в основном определяются
особенности и порядок реализации деятельности по инженерии требований
на отдельном предприятии или в конкретном проекте.
Выполненный нами применительно к авиационной отрасли анализ норматив-
ных и методических документов, а также отраслевых стандартов показал, что
сегодня необходимо сосредоточиться на первом этапе работ. Это обусловлено
тем, что адаптация международных рекомендаций по инженерии требований
повлечет за собой необходимость коренной перестройки традиционных инже-
нерных и управленческих процессов на предприятии. Важнейшим результатом
подобной работы должна стать контекстная диаграмма, учитывающая цели
процесса инженерии требований и содержащая описание его состава, входов и
выходов, а также факторов управления, имеющихся ресурсов и ограничений.
3 Инженерия требований и разработка архитектуры
Общепризнанно, что существует глубокая и неразрывная связь между процес-
сом инженерии требований и процессом определения архитектуры. При этом в
литературе можно встретить утверждение, что создание системы начинается с
404
выяснения нужд и обоснования требований, на основе которых, в свою очередь,
определяется архитектура. В действительности связь между требованиями и
архитектурой намного сложнее.
Основная особенность взаимосвязи между требованиями и архитектурой за-
ключается в том, что даже на самых ранних этапах жизненного цикла у создате-
лей системы всегда имеется унаследованное представление о ее архитектуре.
Кроме того, в процессе разработки могут быть установлены требования, кото-
рые не получены от заказчика или пользователей, а определяются именно архи-
тектурными решениями [13]. Таким образом, вне зависимости от типа создава-
емой системы отдать явное предпочтение определенной парадигме проектиро-
вания: «требования-архитектура-требования» или «архитектура-требования-
архитектура» – бывает затруднительно. Подобная ситуация характерна не толь-
ко для автомобилестроения или авиакосмической техники, но и для других от-
раслей, например, сферы телекоммуникаций, где рекомендованные решения
относительно архитектуры часто содержатся в телекоммуникационных стандар-
тах [17]. Причем, в тех случаях, когда в отрасли сложилось устоявшееся пред-
ставление о типовой архитектуре целевой системы, оно начинает оказывать
заметное влияние и на структуру предприятия и на структуру отрасли в целом,
например, специализации поставщиков авиационных систем соответствуют
элементам типовой архитектуры воздушных судов.
В авиастроении сложившиеся представления об архитектуре нашли отраже-
ние в таких стандартах как ATA 100 [2] и S1000D [14]. При этом попытка опти-
мизации архитектуры изделия без учета типовой архитектуры (с чистого листа)
приводит к необходимости решения множества организационных и техниче-
ских трудностей, как это было в проекте Boeing 787 Dreamliner [11].
Описанное положение хорошо иллюстрируется «моделью двух вершин»
(Рис. 1), из которой следует что разработка требований и архитектуры – два
параллельных, неразрывно связанных между собой процесса [12].
Укрупненно
Специфицирование
Уровень
детальности
Требования Архитектура
Детально
Не зависит Зависит
Зависимость от реализации
Рис. 1. Модель двух вершин [11]
405
Анализ практики западных компаний, занятых созданием сложной техники
показал, что в настоящее время при моделировании процесса инженерии требо-
ваний за основу всегда берется типовая, признанная в отрасли иерархическая
структура целевой системы [4], которую принято называть схемой разукруп-
нения продукции (PBS, The Product Brakedown Structure), где за каждым уров-
нем иерархии закрепляется свое название. Например, в Airbus принято исполь-
зовать четырехуровневую схему: самолет, система самолета, подсистема, агре-
гат [9]. Кроме того предполагается, что процесс инженерии требований приме-
няется рекурсивно на каждом иерархическом уровне, а жесткие ограничения на
сроки реализации программы заставляют широко использовать параллельное
проектирование когда разработка ведется на всех уровнях декомпозиции изде-
лия одновременно [1]. Отметим, что имеется отечественная практика использо-
вания уровней разукрупнения инженерных объектов с учетом функциональной
и конструктивной сложности [18]. Однако эта практика увязывается главным
образом с проблемами документирования и стандартизации, а не с решением
задачи обеспечения гарантированной взаимосвязи и прослеживаемости в тре-
угольнике «требования-архитектура-объекты конфигурации».
В качестве примера можно привести отечественное предприятие, разрабаты-
вающее авиационную технику. Игнорирование типовой архитектуры в качестве
основы для построения процесса инженерии требований привело к трудностям
при организации прослеживания требований: требования к элементам структу-
ры изделия второго уровня не были документированы, а обеспечить прослежи-
ваемость требований между уровнем изделия (первый уровень) и уровнем под-
систем (третий уровень) оказалось затруднительно ввиду чрезмерно большого
количества связей. Отсутствие адаптации рекомендаций международных стан-
дартов к особенностям отрасли, отсутствие гармонизации процессов инженерии
требований с процессами управления конфигурациями (вариативность испол-
нения изделия) и использование для работы с требованиями распространенного
программного продукта, привело к необходимости перестройки процесса инже-
нерии требований и значительной доработки программных средств по работе с
требованиями на поздних стадиях авиационной программы.
Таким образом, в основу модели процесса инженерии требований должно
быть положено критически осознанное представление о взаимосвязи между
процессами определения архитектуры и определения требований. В свою оче-
редь, формирование адекватного представления об этой взаимосвязи невозмож-
но без углубленного анализа сложившейся мировой практики и отраслевых
стандартов, а также применения утвержденных в установленном порядке, обя-
зательных для всех участников работ моделей иерархической структуры целе-
вой системы.
4 Функциональный анализ и привязка требований
Еще одним важным аспектом моделирования процесса инженерии требований
представляется определение процедуры функционального анализа и привязки
406
требований (functional analysis and allocation). Важным ограничением здесь яв-
ляется то, что русскоязычное нормативное и методическое обеспечение подоб-
ной процедуры практически отсутствует. Кроме того, обзор русскоязычных
публикаций, а также результаты консультаций со специалистами показали, что
практика подобной деятельности на отечественных промышленных предприя-
тиях не сложилась и ее придется формировать по существу с нуля. Дополни-
тельно осложняет ситуацию необходимость автоматизации указанных процедур
при создании сложных систем, поскольку консультанты и поставщики про-
граммного обеспечения склонны к использованию типовых решений и их адап-
тации за счет заказчика, что повышает вероятность ошибок.
В основу функционального анализа и привязки требований может быть поло-
жено итеративное применение процедур синтеза, анализа и оценки, как мы пред-
лагали в [15, 16]. В рамках синтеза происходит преобразование практических
целей в описание функций, подлежащих выполнению, в процессе анализа выпол-
няется функциональная декомпозиция с привязкой функций к подсистемам на
основании описания функциональных взаимодействий и формирование на этой
основе представления о конфигурации системы, наконец, оценка предполагает
валидацию решений с использованием базовых процедур валидации требований,
описанных в литературе, см., например, [13]. Одним из важнейших результатов
функционального анализа является получение исходных данных для прослежива-
ния функциональных требований. Прослеживаемость функциональных требова-
ний снизу-вверх дает, в частности, возможность получения объективных свиде-
тельств того, что создаваемая система позволит удовлетворить нужды заинтере-
сованных сторон. Прослеживаемость сверху-вниз помогает выделить объекты
конфигурации, получить представление об их функционировании и заложить
основы для налаживания процедуры управления конфигурацией.
На начальном этапе при формировании практической процедуры функцио-
нального анализа целесообразно взять в качестве прототипа зарубежные реко-
мендации, например, Обобщенный метод инженерии требований корпорации
Airbus (Method for Common Airbus Requirements Engineering, CARE) [4] Модели,
описанные в подобных источниках, прошли апробацию в соответствующих
отраслях, что снижает риски отечественных предприятий на первых этапах
налаживания зрелого процесса инженерии требований.
Среди базовых принципов, реализованных в CARE, можно выделить:
• Использование типовой структуры деления изделия на части;
• Использование определенной иерархической структуры требований, вклю-
чающей указание типов требований;
• Применение функционального анализа для обеспечения целостности и пол-
ноты требований;
• Документирование требований с использованием типовых спецификаций;
• Ориентация на работу с данными, а не с документами;
• Необходимость обеспечения прослеживаемости требований.
407
5 Заключение
При моделировании процесса инженерии требований его необходимо рассмат-
ривать в неразрывной связи с процессом описания архитектуры целевой систе-
мы и процессом управления конфигурацией, причем, в зависимости от особен-
ностей конкретного проекта в качестве исходного может служить любой из
названных процессов. Среди важнейших принципов моделирования следует
выделить:
1. Адаптацию рекомендаций международных стандартов системной инженерии
и инженерии требований к условиям отечественного предприятия с акцентом
на состав и контекст использования типовых процессов, что предполагает
перестройку традиционных инженерных и управленческих процессов на
предприятии, т.е. даже хорошая модель процесса инженерии требований ма-
лоэффективна в отрыве от налаживания других ключевых процессов систем-
ной инженерии.
2. Использование при моделировании в качестве основы критически осознанно-
го представления о взаимосвязи между процессами определения архитектуры
и определения требований, в частности, при наличии общепризнанной, типо-
вой архитектуры моделировать процесс инженерии требований следует в
привязке к этой архитектуре с выделением обязательной иерархической
структуры целевой системы.
3. Формирование на предприятии типовой процедуры функционального анали-
за и привязки требований, основанной на итеративном применении процедур
синтеза, анализа и оценки с акцентом на обеспечении двусторонней просле-
живаемости и использованием в качестве прототипа известных зарубежных
отраслевых рекомендаций по определению функциональных требований.
4. Осторожность при выборе программных средств, реализующих функцио-
нальные возможности по работе с требованиями, т.е. сначала предприятие
должно определить свои процессы работы с требованиями, а потом выбрать
средства автоматизации.
5. Необходимость обязательной гармонизации между собой моделей процессов
инженерии требований и управления конфигурацией.
Литература
1. Altfeld, Hans-Henrich. Commercial aircraft projects: managing the development of highly
complex products. – Ashagate, 2010.
2. ATA Specification 100 – Specification for Manufacturers’ Technical Data, Revision No.
37, Air Transport Association of America, 1999.
3. Batra M. A Comparative Study of Requirements Engineering Process Model // Int. J. Adv.
Res. Comput. Sci. 2017. Т. 8. № 3. С. 740–745.
4. Boulanger J.-L. (Ed.) Formal Methods Applied to Industrial Complex Systems. – London:
Wiley-ISTE. – 2014.
408
5. DOT/FAA/AR-08/32 Requirements Engineering Management Handbook 06/2009 URL:
https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/AR-08-32.pdf
6. FAA Systems Engineering Manual. Version 1.1. September 2015. – URL:
https://sep.faa.gov/policy_and_guidance/main
7. ISO/IEC/IEEE 15288:2015 "Systems and software engineering – System life cycle pro-
cesses".
8. ISO/IEC/IEEE 29148:2011 Systems and software engineering. Life cycle processes. Re-
quirements engineering. – URL: http://www.iso.org/iso/ru/catalogue_detail.htm?csnumber
=45171
9. Lauzier C.-A., AIRBUS. Requirements management and MOD closure process study on
the A330 WV80 project Master thesis report // 2014.
10. Lehto, Jari, M. Pentti, Decision-based requirement engineering process, Proc. of the 6th In-
ternational Conference on Product Focused Software Process Improvement, Oulu, Fin-
land, 2005.
11. Norris G., Wagner M. BOEING 787 DREAMLINER. , 2009. 160 с.
12. Nuseibeh B. Weaving Together Requirements and Architectures // Computer (Long.
Beach. Calif). 2001. Т. 34. № 3. С. 115–117.
13. Pohl К. Requirements Engineering. – Springer-Verlag Berlin Heidelberg 2010.
14. S1000D, "International specification for technical publications using a common source
database". 2016. Issue 4.2. URL: http://public.s1000d.org.
15. Батоврин В.К. Современная системная инженерия и ее роль в управлении проектами
(Часть 2)// Управление проектами и программами. 2015. № 4(44). С. 276-289.
16. Батоврин В.К., Гайдамака К.И. Инженерия требований – ключевой фактор успеха
проектов // Управление проектами и программами. 2017. Т. 1. № 49. С. 6–20.
17. Халл Э. и др. Инженерия требований. – М.: ДМК Пресс, 2017.
18. ГОСТ Р 52003-2003 Уровни разукрупнения радиоэлектронных средств. Термины и
определения. – М.: Стандартинформ. – 2003