St. Petersburg, Russian Federation
Russian Federation
The article is devoted to the problem of formalization of requirements for various objects and systems. Such a rigorous recording of requirements will allow not only to form their necessary and sufficient set, but also to choose the optimal order of their fulfillment – that is, to solve the problem of ranking. For this purpose, a review of relevant scientific publications of Russian scientists is carried out, in which the point of view on the formal form of recording such requirements is presented. The results of the review are systematized in tabular form. All years of publications have a range of 15 years, the field of application of requirements presents a great variety from design of information systems and mechanical devices in spacecraft to educational planning, and the proposed forms of recording consist of separate formulas and text descriptions to full-fledged models and programming languages. According to the results of the review, appropriate conclusions are drawn, namely the following: the relevance of the problem (at least for the last 15 years), the lack of quality solutions, a multitude of proposed forms of record with a small predominance of analytical models and programming languages, poor automation of work with requirements. It is concluded that there are no solutions, even potentially applicable for the formation of a system of requirements for information security of information systems in a unified notation. The necessity of creation of own mathematical toolkit is substantiated both for unified formalization of all requirements of various types and purposes, and for carrying out optimization measures over them on the choice of the list and order of execution. In conclusion the novelty of the conducted research, theoretical and practical significance of the work are indicated.
information systems, requirements, formalization, record form, mathematical apparatus, information security
Современные информационные системы (ИС) постоянно подвергаются атакам, целью которых является реализация угроз нарушения конфиденциальности, целостности и доступности ее информационных ресурсов [1, 2]. Для противодействия этому создается система обеспечения информационной безопасности (СОИБ), к которой предъявляются соответствующие требования, направленные на предотвращение вышеотмеченных нарушений. Однако современные нарушители используют все множества каналов атаки, включая сетевые (например, сниффинг), физические (например, несанкционированное проникновение в серверную), социальные [3] (например, выведывание пароля администратора средствами социальной инженерии) и др. [4]. Такое многообразие угроз приводит и к качественно разным типам требований, например, может потребоваться одновременно установка антивирусного программного обеспечения (ПО) на сервер, системы контроля и управления доступом (СКУД) в серверную, решеток на окна ее помещения и огнетушителей внутри и по периметру.
А исходя из очевидной сложности и многогранности любой ИС и обеспечивающих ее работоспособность и устойчивое функционирование средств (например, источников питания, обслуживающего персонала и т.п.), количество требований оказывается внушительным. Для выполнения каждого такого требования необходимо определенное количество ресурсов (например, финансовых или человеческих), оно имеет сроки выполнения, которые не всегда могут укладываться в допустимые (например, требуется согласование закупки средства защиты, его установка и настройка занимают длительное время), а также приводит к качественному или количественному результату (например, устанавливается новый брандмауэр [5], или закрываются порты на старом), что с неизбежностью ведет к некоторой внутренней коллизии (аналогично взаимодействию организмов живой природы [6–9]) требований в достижении единой цели СОИБ – обеспечению информационной безопасности ИС. И все это в условиях дефицита времени, кадров и средств. Отсюда возникает задача ранжирования требований, включая обоснованный выбор последовательности их выполнения [10, 11].
Решение указанной задачи усложняется следующими причинами. Во-первых, возможная противоречивость некоторых требований в принципе не позволит их выполнить напрямую (например, наличие решеток на окнах серверной, с одной стороны, не позволит туда попасть злоумышленнику, а с другой стороны, окажется препятствием для покидания помещения персоналом в случае пожара). Во-вторых, требования, если их рассматривать как некоторые математические множества X и Y, могут находиться в следующих отношениях: отсутствие пересечения – выполнение X не влияет на выполнение Y; равенство – выполнение X автоматически приведет к выполнению Y и наоборот; собственное включение – выполнение X приведет к частичному выполнению Y, однако выполнение Y приведет к полному выполнению X; пересечение (без их равенства и включения) – выполнение одного из X и Y приведет к частичному выполнению другого и наоборот. Ситуация окажется сложнее и менее предсказуема, когда в комбинировании участвуют несколько пересекающихся требований-множеств [12], потребляющих разные ресурсы и имеющих различные дедлайны (от англ. deadline – крайний срок выполнения), с учетом того, что совместное выполнение комбинаций группы требований будет приводить к выполнению других требований (например, что эффективнее – внедрить полноценную систему защиты информации от сетевых атак или установить несколько подсистем, обеспечивающих защиту в своих секторах?); а для выбора «идеального» их состава необходимо будет применять соответствующие оптимизационные методы. В-третьих, формулировка требований на различных понятийных аппаратах в принципе не позволит осуществлять какие-либо совместные логические операции (например, защита от сетевых атак может оперировать понятиями логических потоков и портов, а защита от проникновения – субъектами и характеристиками их физического перемещения в пределах контролируемой зоны). И, в-четвертых, следуя общепринятой практике, формирование и выбор требований часто ложится на плечи экспертов, которые в принципе не могут быть специалистами в различных областях (тех, к которым относятся угрозы ИС) [13] и, следовательно, при совмещении соответствующих требований могут быть допущены критические ошибки.
Исходя из вышеизложенных причин, для взаимоувязывания всех требований по обеспечению информационной безопасности ИС, а также определения рационального (в идеале – оптимального) состава и порядка их выполнения требуется создание некоторого формализованного вида, который позволит как записывать все разнородные требования в единой нотации, так и проводить над ними строгие (то есть лишенные влияния субъективизма) оптимизационные мероприятия, что и является задачей текущего исследования.
В интересах этого произведем аналитический обзор научных публикаций российских ученых на предмет различных подходов к формальной записи требований к различным объектам и системам. Анализ результатов обзора позволит понять текущее состояние поставленной задачи и возможности по ее решению.
Обзор релевантных работ
Для обзора работ, посвященных различным аспектам формализации требований, воспользуемся базой РИНЦ. Формализации требований посвящено множество работ – журнальных статей, диссертаций, монографий, научных отчетов, докладов на конференциях, патентов: согласно поисковому запросу в научной электронной библиотеке eLIBRARY.RU – 10 341 (из 44 943 243 хранящихся в ней публикаций). Это говорит о значительном научном интересе к поднятому в статье вопросу и актуальности проводимого исследования. Произведем выборку 10 наиболее релевантных работ из найденных по поисковому запросу «формализация требований».
Статья Р.Д. Гутгард, Е.И. Провилкова [14] посвящена формализации функциональных требований, предъявляемых к ИС при их создании. В ней приводится анализ ряда соответствующих подходов, и делаются следующие выводы. Во-первых, применение языка UML позволит формализовать задачи для разработчиков ПО, вплоть до уровня формата входных и выходных параметров, а также алгоритмов их преобразования. Во-вторых, использование карты влияний (в англоязычной литературе – Impact Mapping) и карты историй (Story Mapping) позволит упростить сам процесс разработки функциональных требований. Суть первой карты заключается в определении цели проекта и анализе того, какие изменения необходимы для ее достижения, суть же второй – в организации, визуализации и приоритизации пользовательских историй (применяется, как правило, при разработке ПО). В-третьих, разработка требований должна быть в форме, понятной как пользователям (то есть находящимся с внешней стороны ПО), так и разработчикам (то есть находящимся с внутренней стороны ПО). Сама формализация требований имеет вид нескольких таблиц, например, содержащей алгоритмы обработки информации. Указывается, что данный подход подойдет для случая слабой взаимной зависимости требований. В-четвертых, применение шаблонов может также частично решить задачу формализации требований. Приводятся следующие примеры шаблонов (жирным шрифтом отмечены переменные): типичное требование – «пользователь имеет возможность»; ограничительное требование – «пользователь не попадает под действие закона», «система выполняет функцию не менее чем число объектов, функционируя в условиях»; периодически-ограничительное требование – «система выполняет функцию каждые число единица измерения периода». В-пятых, классическим является документирование требований, для чего могут быть использованы следующие элементы: внешние и внутренние интерфейсы, бизнес-процессы и иная сложная логика, состояния системы и ее объектов, пользовательские задачи, нефункциональные показатели. И, в-шестых, рекомендуется строгое следование документу IEEE 830-1998, специфицирующему структуру и содержание документации с требованиями к ПО. Также в документе говорится о языках формализации требований, частично уменьшающих неоднозначность трактовки описаний на естественном языке. Авторы статьи предлагают следующую поэтапную последовательность формализации требований: 1) выявление информации о требованиях; 2) получение из информации формальных текстовых конструкций; 3) формирование функциональной части требований; 4) составление спецификации из атомарных действий.
Автор статьи М.В. Харлов [15] исследует проблему несоответствия между уровнем подготовки специалистов и предъявляемым к ним требованиями. Модель данной предметной области анализируется на предмет формализации таких требований (в виде уровней усвоения учебной информации). Предлагается графическая схема порядка формализации, состоящая из пяти следующих этапов, на каждом из которых присутствует от одного до нескольких параллельно выполняемых шагов: 1) анализ предметной области деятельности и нормативно-квалификационных документов; 2) создание информационной модели предметной области; 3) определение весов связей в модели; 4) определение значимости уровней усвоения учебной информации; 5) формализация требований и их согласование.
Диссертация М.Л. Глухарева [16] ставит своей целью «повышение оперативности и полноты выявления недекларированных возможностей в ограничениях целостности и триггерах реляционных баз данных». В интересах этого предлагается применять формализацию требований реляционных баз данных, для чего разрабатывается соответствующий научно-методический аппарат. Используемая для этого метамодель позволяет формировать требования двух классов – к состоянию и переходу. Каждое требование в метамодели характеризуется множеством таблиц – T, и конкретных столбцов – C. При этом требования к состоянию характеризуются множеством C, включающим только основные таблицы БД. Требования к переходу также характеризуются множеством T, но могут включать еще и псевдотаблицы с информацией о модифицированных строках. Также требование к переходу включает множество операций вставки/обновления/удаления строки, которые и активизируют переход.
Общие вопросы формализации требований, предъявляемых к ИС экономической сферы, рассматриваются в статье [17]. Указывается, что собственно задача формализации сводится к применению уже известных методик проектирования и управления требованиями в области ПО; однако подчеркивается, что такой подход впоследствии приводит к необходимости постоянной доработки разработанных программных средств. Указывается одна из основных причин – формирование требований к ИС в виде требований к параметрам ее объектов, а именно – невозможность составления списка таких параметров, которые бы не менялись за короткий промежуток времени. При этом требуется хранение «исторических» значений этих параметров, отражая тем самым динамичность реального мира, свойства которого они содержат. В качестве решения предлагается учесть такие изменения при создании спецификации, которые априори не должны быть фиксированными.
В статье В.В. Андреевой [18] для формирования требований к ПО предлагается использовать дивергентный подход, применяемый к квалификациям программистов. В его рамках вводится понятие «задача» в виде процесса разработки с неограниченным количеством применяемых решений, имеющего следующие компоненты: исходные данные – I, процесс получения результата – D и достижение цели – R. Каждый из компонентов может решаться как единственным вариантом (закрытый тип – С), так и их множеством (открытый тип – O). Путем некоторых комбинаций компонентов задач и вариантов решения (вида , где – компонент, – вариант) вводятся несколько уровней знаний, умений и навыков разработчиков – ученический (), алгоритмический (), эвристический (), исследовательский (, где – новое, полученное в процессе деятельности) и творческий (). Указывается снижение эффективности ПО вследствие противоречивости предъявляемых к нему требований (например, уменьшения доступной для использования памяти при повышении общей производительности работы). Также упоминается и то, что ошибки в требованиях могут приводить к отказам ПО.
Похабов Ю.П. рассматривает вопрос формализации требований надежности, предъявляемых к механическим устройствам, применимым на космических аппаратах. Приводится большое разнообразие таких требований (массогабаритных, жесткость, прочность, стойкость к воздействиям и т.п.); при этом подчеркивается, что их выбор делается на основании квалификации и опыта экспертов, а также ряда «Best Practices». Для безотказного функционирования автор указывает на необходимость установки требований в виде качественных и количественных критериев. Трактовка надежности как непрерывной работоспособности детали, всесторонне испытанной перед и правильно используемой во время эксплуатации, закладывается в основу формализации требований [19].
Статья [20] посвящена задаче тестирования ПО, для чего необходимо формирование требований к его составу и функциональным возможностям. Подчеркивается важность формы изложения требований, поскольку она используется разработчиками при непосредственном использовании языков программирования. В частности, формализация исходных данных (как основы требований) сделает документ спецификации более понятным конечному пользователю-читателю. В качестве положительных сторон данного документа указывается использование диаграмм, логических условий и математических формул, а в качестве отрицательных – использование естественного языка. Перечисляются основные инструменты, позволяющие частично снизить недостатки получаемых требований: Unified Modeling Language (язык для визуализации и документирования объектно-ориентированных систем и бизнес-процессов), UNIMOD (система для применения аппаратной парадигмы программирования), SDL (язык для разработок систем на базе конечных автоматов), ДРАКОН (язык визуального моделирования, позволяющий одновременно разрабатывать продукты инженерам и программистам).
Авторы статьи [21] исследуют проблему оформления текстовых документов согласно заданным нормам, для чего определяют основные этапы алгоритма по формализации требований к ним. Суть алгоритма заключается в обработке текстового представления документа определенного стандарта, и всех на которые он ссылается, выявлении в стандартах требований к оформлению текстов, классификации структурных элементов документов (например, с применением машинного обучения), сопоставлении всех выявленных требований и элементов, систематизации и формализации результатов, а также создании итогового, уже программного алгоритма проверки по полученным результатам. Тем самым текстовое описание требований, собранное из множества стандартов и систематизированное по разделам посредством алгоритма, может быть переведено в соответствующее программное средство.
Статья [22] посвящена упрощению и ускорению производства деталей на металлорежущих станках путем концентрации операций – то есть обработки множества различных деталей на одном станке различными инструментами. Для этого требуется задание требований к геометрии деталей с прямыми цилиндрическими поверхностями в формализованном виде. Приведены три примера, в которых сопряжение присоединяемой детали к базовой возможно: 1) без переустановки и нарушения целостности; 2) c переустановкой, но без нарушения целостности; 3) с нарушением целостности (переустановка тут может не рассматриваться). Требования к сопрягаемой поверхности детали даются в формализованном виде с помощью системы математических функций поверхностей для каждого участка Z-оси станка и деталей. Проверка факта сопряжения для каждого из примеров осуществлялась путем исследования указанных функций по «классической» методике, изложенной в работе [23].
В статье [24] описывается формализация основной группы требований к учебному расписанию вузов в виде математических соотношений. В предлагаемую аналитическую модель, описывающую учебный процесс, вводятся следующие параметры (и их типы): группа (индекс) и ее студенты (число); группа (бинарная матрица); поток (матрица); аудитория (индекс), ее вместимость (число) и тип (перечисление); количество всех аудиторий (число); пара в неделю (порядковый номер) и их максимальное количество в день (число); преподаватели (индекс) и их общее количество (число); факт проведения преподавателем определенного занятия у подгруппы в аудитории. Затем выделяются четыре класса нормативно-ограничительных и внутривузовских требований: обязательные, важные, эффективностные и рекомендательные. Используя параметры модели, все указанные классы переводятся в формализованную форму (в статье рассматривается только первый класс). В рамках первого класса рассмотрены такие требования, как «Законодательные и нормативные ограничения» и «Ограничения, связанные с работой руководства вуза». Так, например, приводится запись требования о максимальной недельной загрузке студентов путем суммирования всех пар за неделю для всех подгрупп и преподавателей и сравнения результата с числом, указанным в образовательном стандарте и/или другом нормативном документе.
Анализ результатов
Систематизируем результаты обзоров релевантных работ в табличном виде (табл.) и произведем их анализ по ряду параметров. Для этого, помимо названий статей и годов публикаций, будем указывать область применения требований, форму их записи (а в случае отсутствия – ключевые особенности) и степень автоматизации при составлении требований. В случае нескольких значений параметра в одной статье – укажем их через запятую.
Таблица
Систематизация результатов обзора релевантных работ
|
Ссылка |
Год публикации |
Предметная область |
Форма/особенность записи |
Степень автоматизации |
|
[14] |
2019 |
Проектирование ИС |
Диаграмма Карта Таблица Текстовый шаблон Текстовое описание Частичная формализация |
СредняяНизкая Низкая Средняя Низкая Средняя |
|
[15] |
2019 |
Подготовка специалистов |
Информационная модель |
Низкая |
|
[16] |
2011 |
Безопасность БД |
Аналитическая модель |
Высокая |
|
[17] |
2007 |
Экономическая сфера |
Учет темпоральности |
Средняя |
|
[18] |
2005 |
Разработка ПО |
Схема, частичная формализация |
Низкая |
|
[19] |
2012 |
Механические устройства (в космических аппаратах) |
Качественные и количественные критерии |
Низкая |
|
[20] |
2013 |
Тестирование ПО |
Языки визуализации и визуального программирования. Аппаратная парадигма программирования. Язык разработки на базе конечных автоматов |
Средняя
Средняя
Средняя |
|
[21] |
2021 |
Нормоконтроль документов |
Ручная программная модель |
Низкая |
|
[22] |
2015 |
Производство металлодеталей |
Математические функции |
Высокая |
|
[24] |
2019 |
Составление учебного расписания |
Аналитическая модель |
Средняя |
Результаты анализа (табл.) позволяют сделать следующие предварительные выводы. Во-первых, у публикаций (с учетом того, что, согласно поисковой выдаче, они являются наиболее релевантными к запросу) разброс годов публикаций достаточно большой – от 2005 до 2019, то есть около 15 лет, что говорит о постоянной актуальности решаемой задачи. При этом какого-либо существенного изменения в данном «тренде» не наблюдается; всплеск интереса в 2019 г. (когда было опубликовано сразу три работы вместо одиночных или их отсутствия в другие годы) можно считать статистическим «выбросом» (или совпадением). Во-вторых, затрагиваемые в статье области являются достаточно разнородными, хотя и с некоторым преобладанием сферы информационных технологий. Однако какого-либо единого или хотя бы обобщающего подхода как для формирования требований, так и для их записи обнаружено не было. В-третьих, применяемые или предлагаемые формы записи требований состоят из следующих: схемы различного рода, информационные и аналитические модели, категорирование, различные текстуальные и визуальные языки, базовая математическая логика и анализ; а в качестве особенностей записи можно отметить темпоральность (в части учета исторических изменений) и применение текстовых шаблонов. Отмечается некоторое преобладание аналитических моделей и программных языков, что, впрочем, нельзя считать «панацеей». И, в-четвертых, общую степень автоматизации при составлении требований в формализованной форме можно отметить как недостаточную: два подхода имеют высокий уровень, два – среднюю и семь – низкую. При этом подходы с высоким уровнем автоматизации (работы [3, 9]) относятся к узким областям применения.
Заключение
Исходя из произведенного обзора, можно заключить, что предлагаемые подходы к формализации требований имеют, как правило, достаточно ограниченную область действия, высокую степень субъективности и с трудом поддаются применению строгих математических аппаратов. Как результат, ни один из них нельзя использовать для управления сложными процессами, состоящими из множества гетерогенных элементов – такими, как обеспечение информационной безопасности ИС. Таким образом, требуется создание нового подхода к формализации, по возможности учитывая озвученные выше наработки.
Новизной проведенного исследования можно считать «пионерскую» попытку сбора и анализа накопленного научного опыта по решению указанной задачи с целью создания единой модели, что отличает исследование от аналогичных, направленных сразу на решение практических задач своей области по формированию требований. Теоретическая значимость работы заключается в базовой систематизации релевантных работ с целью последующего сравнения. Практическая значимость, уступая теоретической, также присутствует и заключается в формировании некоторых предпосылок для создания будущего метода (и, возможно, его реализации в виде программного средства) по переводу требований в полностью формальный вид.
Продолжением исследования должно стать создание собственного математического инструментария как для единой формализации всех требований различного вида и назначения, так и для проведения над ними оптимизационных мероприятий по выбору перечня и порядка выполнения.
1. Cifrovye tekhnologii i problemy informacionnoj bezopasnosti: monografiya / T.I. Abdullin [i dr.]. SPb.: SPGEU, 2021. 163 s.
2. Zashchita informacii v komp'yuternyh sistemah: monografiya / M.V. Bujnevich [i dr.]. SPb.: SPGEU, 2017. 163 s.
3. Yaroshenko A.Yu. Formirovanie trebovanij k organizaciyam dlya protivodejstviya atakam na informacionnye resursy metodami social'noj inzhenerii // Aktual'nye problemy infotelekommunikacij v nauke i obrazovanii: sb. nauch. statej X Mezhdunar. nauch.-tekhn. i nauch.-metod. konf. SPb., 2021. S. 452-456.
4. Yaroshenko A.Yu. Predposylki k neobhodimosti nepreryvnogo ranzhirovaniya trebovanij pozharnoj bezopasnosti // Nacional'naya bezopasnost' i strategicheskoe planirovanie. 2021. № 3 (35). S. 100-105.
5. Yaroshenko A.Yu. Sistemnyj podhod k vnedreniyu i nastrojke mezhsetevyh ekranov v gosudarstvennyh informacionnyh sistemah // Aktual'nye problemy infotelekommunikacij v nauke i obrazovanii: sb. nauch. statej V Mezhdunar. nauch.-tekhn. i nauch.-metod. konf. SPb., 2016. S. 551-554.
6. Bujnevich M.V., Izrailov K.E. Antropomorficheskij podhod k opisaniyu vzaimodejstviya uyazvimostej v programmnom kode. Ch. 1: Tipy vzaimodejstvij // Zashchita informacii. Insajd. 2019. № 5 (89). S. 78-85.
7. Bujnevich M.V., Izrailov K.E. Antropomorficheskij podhod k opisaniyu vzaimodejstviya uyazvimostej v programmnom kode. Ch. 2: Metrika uyazvimostej // Zashchita informacii. Insajd. 2019. № 6 (90). S. 61-65.
8. Maksimova E.A. Aksiomatika infrastrukturnogo destruktivizma sub"ekta kriticheskoj informacionnoj infrastruktury // Informatizaciya i svyaz'. 2022. № 1. S. 68-74.
9. Maksimova E.A. Infrastrukturnyj destruktivizm sub"ektov kriticheskoj informacionnoj infrastruktury: M.; Volgograd: Volgogradskij gos. un-t, 2021. 181 s.
10. Bujnevich M.V., Ahunova D.G., Yaroshenko A.Yu. Kompleksnyj metod resheniya tipovoj zadachi risk-menedzhmenta v infologicheskoj srede (na primere ranzhirovaniya trebovanij pozharnoj bezopasnosti). Chast' 1 // Nauch.-analit. zhurn. «Vestnik S.-Peter. un-ta GPS MCHS Rossii». 2020. № 3. S. 88-99.
11. Bujnevich M.V., Ahunova D.G., Yaroshenko A.Yu. Kompleksnyj metod resheniya tipovoj zadachi risk-menedzhmenta v infologicheskoj srede (na primere ranzhirovaniya trebovanij pozharnoj bezopasnosti). Chast' 2 // Nauch.-analit. zhurn. «Vestnik S.-Peter. un-ta GPS MCHS Rossii». 2020. № 4. S. 78-89.
12. Yaroshenko A.Yu. Ranzhirovanie trebovanij informacionnoj bezopasnosti dlya vysokoprioritetnyh ob"ektov organizacionnoj sistemy zashchity // Informatizaciya i svyaz'. 2022. № 5. S. 30-41.
13. Osnovnye principy proektirovaniya arhitektury sovremennyh sistem zashchity / M.V. Bujnevich [i dr.] // Nacional'naya bezopasnost' i strategicheskoe planirovanie. 2020. № 3 (31). S. 51-58.
14. Gutgarc R.D., Provilkov E.I. O formalizacii funkcional'nyh trebovanij v proektah po sozdaniyu informacionnyh sistem // Programmnye produkty i sistemy. 2019. № 3. S. 349-357.
15. Harlov M.V. Posledovatel'nost' formalizacii trebovanij k urovnyu podgotovki specialistov // Dnevnik nauki. 2019. № 8 (32). S. 15.
16. Gluharev M.L. Metod verifikacii i analiza zashchishchennosti baz dannyh na osnove formalizacii trebovanij celostnosti: dis. ... kand. tekhn. nauk. SPb.: PGUPS, 2011. 132 s.
17. Komissarenko I.V., Kuznecov R.V., Gumenyuk R.R. Voprosy formalizacii trebovanij k uchetnym informacionnym sistemam dlya hozyajstvenno-ekonomicheskih zadach // Rossijskij ekonomicheskij internet-zhurnal. 2007. № 4. S. 34.
18. Andreeva V.V. Formalizaciya trebovanij k proektirovaniyu programm i harakteristikam programmista na osnove divergentnogo podhoda // Vestnik Samarskogo gosudarstvennogo tekhnicheskogo universiteta. Ser.: Tekhnicheskie nauki. 2005. № 32. S. 29-32.
19. Pohabov Yu.P. Podhod k formalizacii trebovanij nadezhnosti dlya mekhanicheskih ustrojstv odnorazovogo srabatyvaniya kosmicheskih apparatov // Bezopasnost' i zhivuchest' tekhnicheskih sistem: trudy IV Vseros.j konf. Krasnoyarsk, 2012. S. 192-196.
20. K voprosu o formalizacii trebovanij k programmnomu obespecheniyu v iskhodnyh dannyh / A.I. Bubenshchikov [i dr.] // Raketno-kosmicheskaya tekhnika. 2013. T. 1. № 1 (2). S. 5.
21. Algoritm formalizacii trebovanij k oformleniyu dokumentov dlya servisa avtomatizirovannogo normokontrolya / E.A. Kobec [i dr.] // Sovremennaya nauka: aktual'nye problemy teorii i praktiki. Ser.: Estestvennye i tekhnicheskie nauki. 2021. № 7. S. 89-95.
22. Malyshev E.N., Bysov S.A. Formalizaciya trebovanij k geometrii detalej, soedinyaemyh vdol' osi simmetrii // Yuzhno-Sibirskij nauchnyj vestnik. 2015. № 4 (12). S. 18-22.
23. Korn G., Korn T. Spravochnik po matematike dlya nauchnyh rabotnikov i inzhenerov. M.: Nauka, 1977. 640 s.
24. Hasuhadzhiev A.S.A. Formalizaciya normativnyh i obshchesistemnyh trebovanij k uchebnomu raspisaniyu tipovogo vuza // Inzhenernyj vestnik Dona. 2019. № 9 (60). S. 36.
