The problems of requirements definition, providing the necessary properties and characteristics of the requirements, their documentation and requirements management at the enterprise which creates complex engineering products. Аннотация. Рассмотрены вопросы определения требований, обеспечения необходимых свойств и характеристик требований, документирования и управления требованиями на предприятии, создающем сложную инженерную продукцию.
Промышленные системы разных типов и назначения, в том числе
информационные, характеризуются длительным жизненным циклом (ЖЦ) и высокой
сложностью [
В работе рассматриваются основные проблемы, возникающие в жизненном цикле системы требований, направления и возможности их разрешения современными средствами инженерии требований, обсуждаются проблемы совершенствования инструментальных средств и технологий работы с требованиями.
Казалось бы, в чем вопрос: на практике на любую систему есть документ:
техническое задание или тактико-технические требования или заменяющие их
документы, описывающие согласованное представление заказчика системы и
генподрядчика (подрядчика) о будущей системе. Но это обычно требования
довольно высокого уровня, так называемые Stakeholder Requirements
Specification (StRS) [
Архитектура - требования - конфигурация
Проект любой системы всегда включает концептуальную и логическую
архитектуры системы. При декомпозиции (проектировании) эти архитектуры
преобразуются в конфигурацию системы, то есть набор составных частей, из которых
формируются элементы архитектуры. Концептуальная архитектура разных
систем (например, самолетов определенного типа) может быть унифицирована.
В нее включены крупные системы (например, фюзеляж, двигатель, крыло и
т.п.). Однако особенности конкретного изделия определяются его
конфигурацией, то есть набором атрибутов и свойств взаимосвязанных элементов (узлов,
деталей), в совокупности реализующей функциональные и нефункциональные
свойства элемента архитектуры, обладающей конкретными характеристиками,
соответствующими архитектурным системным требованиям к изделию [
По умолчанию часто предполагается, что в процессе работ исходной точкой являются требования, а деятельность ведется «сверху-вниз». На практике, например в автомобильной или авиационной промышленности, этот порядок, как правило, не соблюдается, а исходной точкой является слабодетализированная архитектура целевой системы, в составе которой определены ключевые системы и связи между ними. Таким образом, работа с требованиями строится сразу в двух направлениях «снизу-вверх», т.е. от архитектуры к требованиям, и «сверху-вниз», т.е. от архитектуры к элементам конфигурации. В этом случае процесс инженерии требований по существу накладывается на процесс управления конфигурацией, эти процессы выполняются в неразрывной связи между собой, а важнейшим элементом работы становятся функциональный анализ и привязка требований в сочетании с обеспечением безусловной трассируемости требований.
Требования к элементам конфигурации определяют различные атрибуты этих элементов, важных с точки зрения функциональных, нефункциональных, технологических свойств создаваемой системы. При реализации конфигурации ее элементы могут строиться из COTS-продуктов, которые закуплены на рынке, обладают свойствами, соответствующими функциональным и нефункциональным требованиям к рассматриваемому элементу, однако эти требования задавались не в рамках проекта данной системы, а исходя из каких-то других целей. В результате покупные изделия могут иметь функциональные возможности, превышающие те, что необходимы в данной системе или обладать свойствами близкими, но не в точности соответствующими требованиям, предъявляемым к данной продукции. Некоторое функциональное требование может реализовываться не одним, а несколькими покупными изделиями в совокупности. Таким образом, требования могут охватывать Элемент Конфигурации (ЭК) полностью, частично или реализовываться несколькими ЭК. Проблема состоит в установлении соответствия между ЭК и требованиями к отдельным элементам. Для ее решения предприятие должно запустить хорошо формализованные процессы формирования иерархической структуры функций целевой системы и деления целевой системы на части. Причем в рамках этих процессов должна быть формально описана процедура привязки функциональных требований к ЭК и обеспечения полноты этих требований. Это особенно важно если на протяжении ЖЦ предполагается неоднократная модернизация «целевой» системы. .В технических заданиях на «целевые» системы (в нашем примере самолет) и входящие в их состав (под)системы (например, крыло, двигатель и т.п.) зачастую указываются требования достаточно высокого уровня, или требования к «внешним» характеристикам изделия, определяющим его функциональное назначение, возможности и эксплуатационные характеристики. В процессе проектирования системы возникает необходимость декомпозировать эти требования на более детальные, реализация которых требует применения конкретных методов, технологий и установления различных видов связей между составными частями системы при реализации ее «внешних» свойств. При этом на каждом этапе реализации системы декомпозированные требования должны быть проверяемыми как автономно, так и во взаимосвязи с другими требованиями или составными частями системы. Возникает необходимость в прослеживании взаимосвязи как самих требований, так и связи требований с реализующими их ЭК. Если рассматривать совокупность требований и связей между ними как граф требований, то говорят о трассируемости требований, то есть о необходимости построения маршрутов или подграфов графа требований, связывающих два или более требований между собой. Прослеживаемость требований позволяет создать основу для их верификации: подграф обладает меньшей размерностью и более пригоден к анализу, чем граф требований в целом.
Размерность набора требований к системе Практически значимые системы обладают весьма большой размерностью. Она может составлять порядка 105 – 106 требований для «целевой» системы и 103 104 требований для подсистем. Наборы требований к программному обеспечению, входящему в состав систем, обладают аналогичными размерностями с теми лишь отличиями, что между такими требованиями может быть больше связей как по передаче управления, так и по передаче информации. Необходимость установления связей между требованиями и ЭК приводит к формированию при описании требований дополнительных атрибутов, характеризующих по результатам проектирования каждое требование атрибутом с именем (индексом, номером) ЭК, который реализует данное требование. Это означает, что при работе с требованиями нужна не просто трассировка самих требований, но трассировка по требованиям и видам связей или по требованиям и типам атрибутов – или по совокупности свойств. Следует отметить также, что в отличие от трассировки требований к программному обеспечению, трассировка требований к системам приводит к построению «очень длинных» трасс – в сотни и тысячи взаимосвязанных вершин, что вызывает необходимость создания специальных средств документирования и анализа трасс.
Особенностью требований к системам как к серийным изделиям является и то, что для сложных технических систем в связи с особенностями производства и сборки систем могут быть опциональные требования к экземплярам серийных изделий, которые также должны отражаться в атрибутах требований.
С учетом анализа функционального состава и опыта использования имеющихся на рынке инструментальных средств инжиниринга требований следует признать, что наиболее приемлемым является совместное использование инструментальных средств инженерии требований, управления конфигурациями и систем управления знаниями для конкретной предметной области (например, система управления знаниями в самолетостроении, содержащая онтологию летательных аппаратов разных типов и типовую архитектуру их бортового оборудования). Это позволит установить единые правила индексации составных частей «внешней» системы для требований, архитектуры и конфигурации. 4
Обеспечение качества требований
Типовые характеристики качества требований, такие как независимость от
реализации, непротиворечивость, полнота, прослеживаемость и т.п.
определены как в стандартах системной и программной инженерии, например, [
Требования в проекте
Наличие репозитория требований и возможностей его анализа является мощной
возможностью при управлении проектами. Действительно, менеджеру
программы работ или проекта важно знать, каким содержанием наполнено событие
(milestone), которое он планирует или оценивает (например, степень реализации
проектного решения в текущий момент или к заданному сроку). Самым
естественным и важным критерием является состав реализованных требований к ЭК
или их совокупности, которые должны быть реализованы в заданный срок.
Ввиду того, что в проекте могут быть установлены состояния готовности ЭК,
они подлежат учету в репозитории, для каждого требования могут быть
установлены достигнутые состояния и проверено их соответствие плановым
состояниям. По результатам сравнения менеджер может судить о качестве сдаваемого
ЭК или их совокупности, ожидаемых к реализации в milestone.
Направления борьбы с размерностью требований
в жизненном цикле системы.
Уменьшить суммарное количество требований к системе вряд ли удастся,
поскольку сложность системы это объективно присущая ей характеристика. Для
целей практического использования средств автоматизации для работы с
требованиями в ЖЦ систем нужно группирование и упорядочение требований для их
последующего использования. Заметим, что для имеющихся в настоящее время
инструментальных средств работы с требованиями [
В настоящее время серьезных отечественных исследований в этой области практически не встречается, поэтому ограничимся перечнем направлений упорядочения и группирования, которые вытекают из опыта нашей работы с требованиями: • Группирование требований по отношению к объектам концептуальной архитектуры системы • Агрегирование требований, относящихся к отдельным системам в составе «внешней» системы • Агрегирование требований по отношению к ЭК • Использование механизмов формирования проектов для локализации требований • Формирование на предприятии системы обеспечения качества требований и ее настройка в согласовании с системой управления конфигурацией 9
Заключение Для критических и ответственных систем различного назначения авиакосмических, энергетических, транспортных, крупномасштабных автоматизированных систем, в частности для государственных нужд, банковской сферы и других отраслей, характерны высокая длительность жизненного цикла продукции или создаваемых систем. В обоих случаях с целью сокращения рисков и удешевления проводимых работ для этих видов проектов и продукции в целом необходима четкая постановка процессов инженерии требований и управления ими в ЖЦ.
Практика различных отечественных и зарубежных компаний показывает, что без нормативно-методической документации по инженерии требований, конкретизирующей и адаптирующей действующие международные стандарты в этой области к условиям конкретного предприятия, кооперации предприятий или проекта, а также без средств автоматизации процессов инженерии требований заметного прогресса в этой области добиться маловероятно. При реализации средств автоматизации инженерии требований следует учитывать, что они обладают наибольшей эффективностью, если с их помощью одновременно решаются задачи индексации, поддержки и управления конфигурацией «триады»: архитектура системы – требования к системе – элементы конфигурации системы на всем ЖЦ системы (продукции).