Верификация требований к имитационной модели производственного предприятия Текст научной статьи по специальности «Компьютерные и информационные науки»

Верификация требований к имитационной модели производственного предприятия

Т.К. Кравченко

доктор экономических наук

профессор, заведующая кафедрой бизнес-аналитики

Национальный исследовательский университет «Высшая школа экономики» Адрес: 101000, г. Москва, ул. Мясницкая, д. 20 E-mail: tkravchenko@hse.ru

Н.И. Голов

старший преподаватель кафедры бизнес-аналитики

Национальный исследовательский университет «Высшая школа экономики» Адрес: 101000, г. Москва, ул. Мясницкая, д. 20 E-mail: ngolov@hse.ru

А.В. Фомин

старший преподаватель кафедры бизнес-аналитики

Национальный исследовательский университет «Высшая школа экономики» Адрес: 101000, г. Москва, ул. Мясницкая, д. 20 E-mail: afomin@hse.ru

А.Ю. Липатников

выпускник магистратуры

Национальный исследовательский университет «Высшая школа экономики» Адрес: 101000, г. Москва, ул. Мясницкая, д. 20 E-mail: lipatnikov94@gmail.com

Аннотация

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

Для построения имитационной модели, необходимой для определения вариантов сценариев развития и охватывающей финансовые потоки типового производственного предприятия, определен перечень верифицируемых требований. В качестве критериев верификации требований предложены не только критерии приемки, но и фреймворк Graphical Requirements Analysis (GRA-фреймворк), используемый для верификации функциональных требований. В отличие от других нотаций, представление требований в нотации GRA позволяет понять их структуру и внутреннюю логику, а также выявить эмерджентные эффекты. Результатом выявления критериев верификации является построение матрицы верификации требований (Verification Cross Reference Matrix, VCRM), которая включает в себя все требования, методы и критерии. На заключительном этапе приведен пример диаграммы для одного из функциональных требований.

■ Верифицированные требования должны быть использованы на различных этапах построения имитационной модели, ориентированной на разработку вариантов сценариев достижения производственным предприятием предпочтительного будущего финансового состояния. Моделирование сценариев будущего развития предприятия типа «Что будет, если?» и «Что делать, чтобы достичь цели?» с использованием систем имитационного моделирования позволит существенно повысить качество принимаемых решений.

Ключевые слова: требования, верификация требований, критерии верификации, имитационная модель, сценарный анализ, критерии приемки требований, GRA-фреймворк.

Цитирование: Кравченко Т.К., Голов Н.И., Фомин А.В., Липатников А.Ю. Верификация требований к имитационной модели производственного предприятия // Бизнес-информатика. 2018. № 2 (44). С. 65-78. DOI: 10.17323/1998-0663.2018.2.65.78.

Введение

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

Структура реализуемого решения и особенности предметной области его использования оказывают существенное влияние на процедуру верификации требований, ключевым элементом которой являются критерии верификации. Таким образом, формирование перечня критериев верификации требований с учетом специфики конкретного решения приобретает первостепенную роль во всем процессе верификации и обеспечивает его успешное завершение.

Типовое производственное предприятие нуждается в поддержании высокого уровня финансовой стабильности. Управленческие решения, направлен -ные на финансовое развитие предприятия, должны формироваться в результате анализа различных сценариев его функционирования в будущем. Для подготовки сценариев развития предприятия требуется разработка его имитационной модели. Верификация требований к имитационной модели должна быть направлена на проверку их корректности и возможности реализации. Формирование списка требований должно опираться на набор критериев верификации, для выявления которых требуется использовать ряд методов бизнес-анализа.

Объектом исследования является типовое производственное предприятие. Предмет исследования — финансовые характеристики основной деятельно-

сти предприятия. Цель исследования — определение списка требований к имитационной модели типового производственного предприятия для управления его финансовыми характеристиками, верифицированных с использованием различных критериев.

1. Имитационное моделирование

производственного предприятия

Сценарное планирование будущего состояния производственного предприятия может быть выполнено с использованием различных методов имитационного моделирования, например, методов системной динамики [1, 2] и агентного моделирования [1, 3]. В настоящее время имитационное моделирование широко применяется для рационального планирования и управления важнейшими характеристиками предприятий, например, для сценарного прогнозирования динамики добычи нефтяной компании [4], сценарного планирования экологической модернизации предприятий [5], формирования инвестиционных портфелей вертикально-интегрированных нефтяных компаний [6], а также для сценарного управления характеристиками кредитно-финансовых учреждений [7] и предприятиями ТЭК [8].

Важными требованиями, предъявляемыми к имитационным моделям производственного предприятия, являются возможность применения в рамках одной модели различных методов (например, методов системной динамики и агентного моделирования), а также возможность варьирования управляющими параметрами. Не менее значимой считается поддержка методов класса Монте-Карло и генетических оптимизационных алгоритмов. Верифицируе-мость результатов имитационного моделирования, интегрируемость модели с базами данных и возможность визуализации результатов моделирования также являются существенными требованиями [1].

В статье рассматривается типовое производственное предприятие с дискретным процессом производства. Под сценарием развития такого предприятия следует понимать последовательность выполнения контрактов в течение определенного периода, с целью получения прибыли. Выполнение каждого контракта связано с формированием входящих и исходящих денежных потоков. Если в определенный момент времени накопленная сумма совокупного исходящего денежного потока становится больше накопленной суммы совокупного входящего денежного потока, у предприятия возникает кассовый разрыв, и оно теряет возможность выполнять свои текущие обязательства. Предпочтительное будущее финансовое состояние предприятия характеризуется отсутствием кассовых разрывов и максимально возможным значением прибыли, полученной в результате выполнения контрактов, выбранных из общей совокупности доступных контрактов. Соответственно, сценарное планирование должно быть направлено на формирование производственной программы, позволяющей минимизировать сумму кассовых разрывов и максимизировать прибыль в течение заранее определенного периода, с учетом имеющихся ограничений.

Поскольку контракт представляет собой отдельную сущность с индивидуальными характеристиками, для имитационного моделирования следует применить агентно-ориентированный подход. Создание агента типа «Контракт» в ходе моделирования является началом выполнения контракта, а его ликвидация — завершением работ по контракту. Ряд систем агентного имитационного моделирования позволяет не только выполнять сценарное планирование с помощью варьирования управляющих параметров и многократного прогона имитационной модели, но и проводить эксперименты, направленные на поиск условно оптимальных решений задач многокритериальной оптимизации. Кроме того, модель должна поддерживать импорт входных параметров и экспорт выходных показателей во внешние прикладные программы, а также иметь панель управления, необходимую для задания части начальных параметров и визуализации динамики финансовых характеристик.

Таким образом, требования, предъявляемые к имитационной модели типового производственного предприятия для управления его финансовыми характеристиками, а также критерии их верификации должны учитывать следующие особенности имитационного моделирования:

♦ использование агентно-ориентированного подхода;

♦ применение сценарного планирования путем изменения управляющих параметров;

♦ поддержка генетических оптимизационных алгоритмов;

♦ возможность импорта начальных параметров и экспорта результатов моделирования;

♦ наличие панели управления для ручного ввода значений начальных параметров модели;

♦ визуализация динамики финансовых характеристик предприятия.

2. Понятие критериев верификации требований к имитационной модели производственного предприятия

Критерием верификации является характеристика требования к решению, наличие которой обеспечивает его корректность и возможность дальнейшего использования [9]. Если требование сформулировано некорректно, содержит ошибки и не согласуется с другими требованиями к имитационной модели, оно должно быть изменено или вовсе исключено из списка требований.

Предлагается ряд стандартных характеристик требований, которые можно использовать в качестве критериев их верификации [9]:

Ф атомарность: требование автономно и доступно для понимания вне зависимости от других требований;

Ф полнота: полная и детализированная формулировка требования, которую можно использовать в дальнейшей работе;

Ф согласованность: соответствие выявленным потребностям заинтересованных сторон и отсутствие противоречия другим требованиям;

Ф конкретность: требование не содержит лишней информации;

Ф реализуемость: требование должно и может быть реализовано с учетом рисков, сроков и бюджета;

Ф однозначность: четкое определение требования должно обеспечивать понимание того, удовлетворяет ли решение конкретную потребность, ассоциированную с ним;

Ф возможность тестирования: определение факта выполнения конкретного требования;

Ф ясность: представление требования с использованием общепринятой терминологии.

Помимо перечисленных характеристик требований, можно выделить ряд критериев верификации требований к имитационной модели, обеспечивающих более полное раскрытие и детализацию стандартных критериев [10—12]:

♦ четкое разграничение успеха и неуспеха: тестирование выполнения требования может иметь только два взаимоисключающих результата — «выполнено» или «не выполнено»;

♦ отсутствие агрегации: требование не должно представлять собой результат объединения нескольких требований;

♦ отражение связей: если некоторое требование имеет связь с другим требованием, то его спецификация должна включать характеристику данной зависимости;

♦ отсутствие рекомендаций относительно конкретной реализации: если требование связано со специфическим набором технологий, его уровень адаптации к изменениям крайне низок.

3. Критерии приемки и оценки верификации требований

Одним из стандартных методов верификации требований, представленных в модели компетенций бизнес-аналитика, является использование критериев приемки и оценки [13].

Критерии приемки представляют собой набор характеристик, которыми должны обладать требования для того, чтобы быть принятыми всеми стейкхолде-рами. В большинстве случаев результат выполнения отдельного критерия приемки имеет бинарный тип, соответственно, может принимать одно из двух противоположных значений «да / нет», «истина / ложь».

В процессе использования критериев приемки, в первую очередь, необходимо определить набор характеристик, которые будут использоваться при формальной инспекции требований к имитационной модели. Затем каждое требование должно быть проанализировано с целью выявления результатов соответствия критериям приемки. Если требование не соответствует хотя бы одному критерию, оно должно быть скорректировано или исключено из списка верифицируемых требований.

Необходимость использования критериев оценки в процессе верификации требований к имитационному моделированию отсутствует, поскольку критерии оценки целесообразно использовать при сравнении альтернативных вариантов одного и того же

требования для выбора наиболее предпочтительной альтернативы.

4. Концептуальные основы фреймворка «Graphical Requirements Analysis» (GRA)

Фреймворк «Graphical Requirements Analysis» (GRA) [14—16] считается полуформальным методом верификации требований [16]. Данный метод позволяет производить оценку корректности требований путем их представления в графическом формате. Концептуальные основы фреймворка GRA заимствованы из методологии функционального моделирования, определение которой представлено в стандарте IEEE 610.12 [17]. Однако фреймворк GRA охватывает некоторые подходы к проектированию систем и программного обеспечения: теорию иерархий, парадигму диаграмм функциональных блоков, модульное программирование и процедуру для определения функциональной сложности COSMIC-FFP [18]. В рамках применения фреймворка GRA рекомендуется выполнить ряд шагов: декомпозицию отдельного функционального требования к имитационной модели на множество компонентов, идентификацию входов, выходов и функциональных блоков, определение связей между компонентами.

Фреймворк GRA применяется для детализации функциональности с помощью множества графических примитивов, каждый из которых используется для визуализации определенного компонента функционального требования [19].

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

В результате анализа множества нотаций [20] выделено три группы:

♦ нотации, позволяющие моделировать бизнес-правила (IDEF3, BPMN, ARIS eEPC) [21];

♦ нотации для создания описаний на базе блок-схем (Basic Flowchart, Cross Functional Flowchart) [22];

♦ нотации, основанные на использовании объектно-ориентированного подхода (Unified Modeling Language, UML) [23].

Преимущество использования фреймворка GRA по сравнению с нотациями моделирования бизнес-

процессов IDEF3, BPMN и ARIS eEPC заключается в отсутствии избыточного количества графических объектов. Это позволяет разрабатывать диаграммы, понятные не только специалистам в сфере бизнес-анализа, но и заинтересованным сторонам, не обладающим специализированными знаниями.

Нотации, предназначенные для создания описаний на базе блок-схем (Basic Flowchart, Cross Functional Flowchart), направлены на детализацию обособленных последовательностей преобразования данных и не предусматривают интеграцию нескольких функциональных требований пользователя посредством соединения выходов одних диаграмм с входами других диаграмм. Что касается нотации GRA, то она позволяет производить синтез низкоуровневых требований для формирования требований более высокого уровня, которые не содержат избыточной детализации и могут быть согласованы с заказчиком.

Семейство нотаций на базе унифицированного языка моделирования (UML) предназначено для моделирования компонентов сложных систем на основе объектно-ориентированного подхода.

Отличия фреймворка GRA от трех групп нотаций моделирования бизнес-процессов позволяют выбрать его для визуального представления функциональных требований к имитационной модели с целью завершения их верификации. Для верификации требований к имитационной модели типового производственного предприятия рекомендуется последовательно использовать метод критериев приемки и оценки (для проверки корректности всех требований) и фреймворк GRA (для анализа функциональных требований).

5. Спецификация требований к имитационной модели производственного предприятия

Ряд мероприятий, включающих проведение анализа текущего финансового состояния типового производственного предприятия, интервью с экспертами предметной области и анализ документов, регулирующих основную деятельность предприятия, является основой для подготовки спецификации требований к имитационной модели, представленных в таблице 1. Уникальный идентификатор

Таблица 1.

Спецификация требований к имитационной модели

ID требования Требование

R1 Имитационная модель должна учитывать финансовые потоки предприятия, связанные с его основной деятельностью.

R2 Отдельный контракт на выполнение производственных работ, создаваемый в ходе имитационного эксперимента, должен являться самостоятельной сущностью.

R3 Сценарий, получаемый в результате однократного прогона имитационной модели, должен представлять собой план последовательного выполнения фиксированного числа контрактов в течение определенного периода времени.

R4 Имитационная модель должна быть представлена в отдельном файле с возможностью запуска на различных персональных компьютерах.

R5 Пользовательский интерфейс модели в режиме отдельного прогона должен представлять собой панель с набором элементов управления входными параметрами и совокупностью диаграмм для визуализации динамики целевых показателей деятельности предприятия.

R6 Период прогона имитационной модели - один календарный год с шагом модельного времени, составляющим один день.

R7 Имитационная модель должна обеспечивать формирование портфеля контрактов в соответствии с критерием максимизации годовой прибыли предприятия.

R8 Имитационная модель должна предусматривать возможность проведения эксперимента, направленного на минимизацию кассовых разрывов предприятия в течение периода прогона модели.

R9 Источник загрузки пула контрактов в среду функционирования имитационной модели - файл MS Excel.

R10 Источник структуры портфеля контрактов и годового плана их выполнения - текстовый файл.

R11 Целевые показатели оптимизационного эксперимента - сумма плановых месячных кассовых разрывов предприятия и сумма ежемесячного изменения остатков денежных средств в течение планового периода.

R12 Входящие денежные потоки предприятия по его основной деятельности - авансовый платеж и выплата остатка стоимости контракта по завершении производственных работ. Исходящие денежные потоки предприятия по его основной деятельности -оплата материальных ресурсов, оплата труда, общепроизводственные и общехозяйственные платежи.

R13 Рекомендуемые системные требования к среде функционирования имитационной модели: ОС Microsoft Windows Vista SP2, x86-32 или x64, ОЗУ 2Гб, 500Мб свободного места на жестком диске.

R14 Имитационная модель должна поддерживать экспорт порядковых номеров контрактов, включаемых в план производства, во внешнюю электронную таблицу и их запись в строки, обозначающие соответствующие контракты.

R15 Множество диаграмм панели управления имитационной модели должно быть представлено календарным планом-графиком выполнения контрактов, графиком динамики остатка денежных средств предприятия, графиком динамики накопленной суммы кассовых разрывов предприятия.

(ID) каждого требования формируется путем соединения символа «R» («Requirement») и порядкового номера требования.

Сценарии функционирования типового производственного предприятия, для получения которых планируется использование агентно-ориентированной имитационной модели [24], должны предусматривать решение задачи многокритериальной оптимизации, направленной на максимизацию прибыли организации и одновременную минимизацию ее кассовых разрывов за период планирования, составляющий один календарный год. Жесткое ограничение, накладываемое на продолжительность периода сценарного планирования, обусловлено дискретным характером производства, а также высокой степенью неопределенности относительно состава потенциальных контрактов в долгосрочной перспективе.

При составлении требования к среде функционирования имитационной модели (R13) учитывались требования, необходимые для корректной работы современных систем имитационного моделирования, поддерживающих агентно-ориентированный подход к имитационному моделированию и имеющих встроенный модуль проведения оптимизационных экспериментов (AnyLogic, iThink/STELLA).

В ходе выявления критериев верификации требований к имитационной модели типового производственного предприятия необходимо учитывать их вид. Требования с идентификаторами R7, R9—R11 и R14 формируют подмножество функциональных требований, поскольку они используются для характеристики последовательности преобразования информации в отдельных функциональных блоках. Соответственно, требования с идентификаторами R1—R6, R8, R12, R13 и R15 относятся к подмножеству нефункциональных требований, поскольку они предназначены для спецификации бизнес-правил (ограничений, накладываемых предметной областью) и отдельных свойств имитационной модели, технических особенностей ее реализации, а также характеристик панели управления, служащей для инициализации входных параметров и анализа результатов моделирования.

6. Выявление критериев

верификации требований

Множество критериев верификации требований к имитационной модели, полученных в результате объединения стандартных критериев приемки

и специализированных критериев верификации, представлено в таблице 2. Уникальный идентификатор (ID) каждого критерия верификации формируется путем соединения символов «AC» («Acceptance Criterion») и порядкового номера критерия.

Для завершения верификации подмножества функциональных требований R7, R9—R11 и R14 с позиции их полноты недостаточно использования критерия приемки «Полнота». Это обусловлено тем, что функциональное требование к имитационной модели, представленное в текстовом формате, не позволяет корректно определить входные и выходные параметры, а также в явном виде задать последовательность выполнения функциональных блоков по преобразованию информации. Следовательно, в целях проверки корректности требований R7, R9-R11 и R14 необходимо дополнительно применить фреймворк GRA, что позволит завершить оценку этих требований в части полноты.

Матрица верификации (Verification Cross Reference Matrix, VCRM) [25], включающая все требования, а также методы и критерии их верификации, представлена в таблице 3. Третий столбец таблицы используется для перечисления уникальных идентификаторов тех критериев верификации, которые следует использовать для проверки соответствующего требования.

Таблица 2.

Критерии приемки требований к имитационной модели

ID критерия Критерий верификации

AC1 Атомарность

AC2 Полнота

AC3 Согласованность

AC4 Конкретность

AC5 Реализуемость

AC6 Однозначность

AC7 Возможность тестирования

AC8 Ясность

AC9 Взаимоисключающие результаты тестирования

AC10 Отсутствие агрегации

AC11 Отражение связей

AC12 Отсутствие конкретных рекомендаций относительно используемых технологий

Матрица верификации

Таблица 3.

ID требования Метод верификации ID критериев верификации

R1 Критерии приемки AC1-AC12

R2 Критерии приемки AC1-AC12

R3 Критерии приемки AC1-AC12

R4 Критерии приемки AC1-AC10, AC12

R5 Критерии приемки AC1-AC12

R6 Критерии приемки AC1-AC12

R7 Критерии приемки, ОЯД- фреймворк AC1-AC12

R8 Критерии приемки AC1-AC12

R9 Критерии приемки, ОЯД- фреймворк AC1-AC12

R10 Критерии приемки, ОЯД- фреймворк AC1-AC12

R11 Критерии приемки, ОЯД- фреймворк AC1-AC12

R12 Критерии приемки AC1-AC12

R13 Критерии приемки AC1-AC10, AC12

R14 Критерии приемки, ОЯД- фреймворк AC1-AC12

R15 Критерии приемки AC1-AC12

Следует отметить, что критерий приемки «Отражение связей» (AC11) не может быть применен в процессе верификации требований R4 и R13. Первое требование (R4) используется для описания формата хранения имитационной модели, а второе (R13) представляет собой множество программных и аппаратных требований, предъявляемых к среде

ее функционирования. Каждое из этих двух требований содержит техническую информацию и не может иметь связей с другими требованиями, которые используются для характеристики ограничений предметной области и функциональных возможностей имитационной модели. Следовательно, необходимость в проверке корректности требований R4 и R13 с помощью критерия AC11 отсутствует. При этом критерий AC11 необходимо использовать для проверки корректности остальных требований, поскольку каждое из них имеет, по крайней мере, одну связь с другим требованием. Что касается критериев приемки AC1—AC10 и AC12, то они подходят для верификации всех требований.

7. Верификация требований к имитационной модели

Анализ результатов верификации требований с помощью критериев приемки (таблица 4) позволяет сделать вывод о том, что ни одно из требований не получило положительные оценки одновременно по всем критериям. Поскольку исключение любого требования из спецификации помешает успешной реализации имитационной модели, список всех требований должен быть сохранен, однако их формулировки должны быть модифицированы.

Конечной целью модификации каждого требования является получение формулировки, удовлетворяющей критериям приемки из таблицы 2. В

Результат инспекции требований с использованием критериев приемки

Таблица 4.

AC1 AC2 AC3 AC4 AC5 AC6 AC7 AC8 AC9 AC10 AC11 AC12

R1 Да Да Да Да Да Да нет Да нет Да нет Да

R2 Да нет Да Да Да нет Да Да Да Да нет Да

R3 Да нет Да Да Да Да Да Да Да Да нет Да

R4 Да нет Да Да Да Да Да Да Да Да - Да

R5 Да нет Да Да Да Да Да Да Да Да нет Да

R6 Да Да Да Да Да Да Да Да Да Да нет Да

R7 Да нет Да Да Да Да Да Да Да Да нет Да

R8 Да нет Да Да Да Да Да нет Да Да нет Да

R9 Да нет Да Да Да Да Да Да Да Да нет Да

R10 Да нет Да Да Да Да Да Да Да Да нет Да

R11 Да нет Да Да Да Да Да нет Да Да нет Да

R12 Да нет Да Да Да Да Да нет Да Да нет Да

R13 Да нет Да Да Да нет Да Да Да Да - Да

R14 Да нет Да Да Да нет Да Да Да Да нет Да

R15 Да нет Да нет Да Да Да Да Да Да нет Да

качестве примеров можно рассмотреть изменение нескольких требований, для которых в таблице 4по разным критериям указано значение «нет». Например, требование R1 не удовлетворяет таким критериям, как AC7 («Возможность тестирования»), AC9 («Взаимоисключающие результаты тестирования») и AC11 («Отражение связей»). Для того чтобы обеспечить возможность тестирования требования по критерию AC7, следует конкретизировать понятие денежного потока, используемого в его спецификации. При оценке выполнения требования достаточно удостовериться в присутствии в имитационной модели входящих и исходящих денежных потоков. Выполнение критерия AC7 автоматически позволяет добиться удовлетворения критерия AC9, согласно которому результат тестирования должен представлять собой бинарную переменную. Действительно, в процессе выявления факта описания моделью входящего или исходящего денежного потока возможно лишь два взаимоисключающих исхода: присутствие потока в модели или его отсутствие. Наконец, обеспечение отражения связи требования R1 с требованием R12 достигается путем явного указания в тексте требования R1 ссылки на требование R12, специфицирующее входящие и исходящие денежные потоки предприятия. В результате скорректированное требование R1 признается принятым по всем критериям. Обновленный идентификатор модифицированного требования приобретает значение RA1, сформированное путем соединения символов «RA» («Requirement Accepted») и порядкового номера исходного требования.

Требование R2 не удовлетворяет критериям AC2 («Полнота»), AC6 («Однозначность») и AC11 («Отражение связей»). Для детализации требования необходимо подробно раскрыть понятие сущности, которой должен являться каждый контракт, создаваемый в ходе имитационного моделирования. Потребность, для удовлетворения которой разработано требование R2, заключается в отслеживании динамики выполнения контракта. Добавление данной потребности в требование позволяет выполнить критерий AC6. Отражение связи требования R2 с требованиями R9 и R10 достигается путем явного указания ссылки на требование R2 в связанных с ним требованиях. Обновленный идентификатор модифицированного требования приобретает значение RA2, сформированное путем соединения символов «RA» и порядкового номера исходного требования.

Процедуре коррекции, рассмотренной на приведенных выше примерах, подвергаются все требования, для которых указано значение «нет» хотя бы по одному критерию верификации.

Требования, модифицированные в ходе формальной инспекции с помощью критериев приемки, перечислены в таблице 5. Следует обратить внимание на появление новых терминов «ГОЗ» и «Коммерция» в формулировках требований КА7 и КА8 в результате их коррекции с целью выполнения критерия АС2 («Полнота»). Необходимость использования данных понятий продиктована тем, что в отличие от негосударственных производственных компаний, в основном осуществляющих выполнение коммерческих контрактов (заказы типа «Коммерция»), в портфеле контрактов государственных предприятий, как правило, присутствуют государственные заказы (заказы типа «ГОЗ»). Существенные различия в логике формирования денежных потоков по каждому из двух типов контрактов (порядок авансирования, продолжительность периода образования материальных расходов), является источником потребности в явном указании типа контракта («ГОЗ» или «Коммерция») в требованиях, ассоциированных с данными понятиями. Кроме того, включение подробной характеристики понятия «Тип контракта» в спецификацию требований КА7 и КА8 позволяет обеспечить универсальность и возможность использования модели в процессе сценарного планирования деятельности как государственных, так и коммерческих организаций.

Рассмотрим использование фреймворка GRA на примере верификации требования RA7 (рисунок 1). Процесс построения диаграммы включает идентификацию входных и выходных структур, а также определение функциональных блоков преобразования данных.

Для отображения входных и выходных параметров используются прямоугольники, граница которых изображена двойной линией. Входы размещаются в левой нижней части диаграммы, а выходные параметры — в ее верхней части. Графические примитивы типа «ромб» используются для функциональных блоков, преобразующих входную информацию в выходную. Прямоугольники, граница которых изображена одинарной линией, служат для описания функциональных блоков и используемых ими внутренних параметров. Графические примитивы типа «круг» представляют собой внутренние входы и выходы, а также внешние входы. Внешние входы не имеют порядковых номеров и используются для

Модифицированные требования, удовлетворяющие критериям приемки Таблица 5.

ID модифицированного требования Модифицированное требование ID исходного требования

RA1 В имитационной модели должны быть реализованы два главных вида денежных потоков предприятия, связанных с его основной деятельностью: входящий и исходящий. Источники формирования данных потоков задаются требованием RA12. R1

RA2 Отдельный контракт на выполнение производственных работ, создание которого имитируется в ходе проведения однократного модельного эксперимента, должен являться самостоятельной сущностью -объектом, имеющим логику поведения и характеризующимся набором состояний и показателей, порядок инициализации которых зафиксирован в требованиях RA9 и RA10. Это необходимо для обеспечения отслеживания динамики выполнения контракта. R2

RA3 Сценарий, получаемый в результате однократного прогона имитационной модели, должен представлять собой план последовательного выполнения контрактов, входящих в состав портфеля. Размер портфеля определяется, исходя из трудоемкости общей численности работников основного производства в течение определенного периода. Продолжительность периода прогона модели задается требованием RA6. R3

RA4 Имитационная модель должна храниться в отдельном файле с возможностью запуска на различных персональных компьютерах с помощью выбранной системы имитационного моделирования. R4

RA5 Пользовательский интерфейс модели в режиме отдельного прогона должен представлять собой панель с набором элементов управления входными параметрами (численность сотрудников основного производства, структура портфеля контрактов) и совокупностью диаграмм для визуализации динамики целевых показателей деятельности предприятия, которые перечислены в требовании RA15. R5

RA6 Период прогона имитационной модели - один календарный год, с шагом модельного времени, составляющим один день. Понятие периода прогона модели используется в требованиях RA3, RA8 и RA11. R6

RA7 Имитационная модель должна обеспечивать формирование портфеля контрактов в соответствии с критерием максимизации годовой прибыли предприятия. Вход: структура портфеля контрактов, массив прибыли по каждому контракту из пула в книге MS Excel (RA9). Выход: две популяции сущностей типов «ГОЗ» и «Коммерция». Понятие сущности зафиксировано в требовании RA2. R7

RA8 Имитационная модель должна предусматривать возможность проведения оптимизационного эксперимента, направленного на минимизацию суммы отрицательных приращений остатков денежных средств предприятия в течение периода прогона модели, который задается в требовании RA6. Допускается варьирование дат начала выполнения контрактов и долей контрактов типа «ГОЗ» и «Коммерция» в структуре портфеля. R8

RA9 Должна быть реализована процедура загрузки параметров пула контрактов (сумма контракта без НДС, рентабельность, размер аванса) в среду функционирования имитационной модели для инициализации характеристик объектов, специфицированных в требовании RA2, из книги MS Excel. R9

RA10 Должна быть реализована процедура загрузки структуры портфеля контрактов и порядковых номеров месяцев их выполнения из текстового файла, являющегося источником информации для инициализации характеристик объектов, специфицированных в требовании RA2. R10

RA11 Реализация расчета следующих целевых показателей оптимизационного эксперимента по минимизации суммы плановых месячных кассовых разрывов предприятия и суммы ежемесячных приращений остатков денежных средств предприятия в течение планового периода, который задается в требовании RA6. R11

RA12 Входящие денежные потоки предприятия по его основной деятельности: аванс, остаток стоимости контракта, выплачиваемый по завершению производственных работ. Исходящие денежные потоки предприятия по его основной деятельности связаны с формированием себестоимости готовой продукции. Понятия входящего и исходящего денежных потоков введены в требовании RA1. R12

RA13 Необходимые и достаточные системные требования к среде функционирования имитационной модели для обеспечения ее корректного запуска на ПК заказчика: ОС Microsoft Windows Vista SP2, x86-32 или x64, ОЗУ 2Гб, 500Мб свободного места на жестком диске. R13

RA14 Имитационная модель должна обеспечивать экспорт порядковых номеров контрактов, включаемых в план производства, и их запись в строки, обозначающие соответствующие контракты, в книге MS Excel -источнике импорта информации, специфицированном в требовании RA9. R14

RA15 Множество диаграмм панели управления имитационной модели, специфицированной в требовании RA5, должно быть представлено следующими элементами: календарный план-график выполнения контрактов на проведение производственных работ, временной график динамики остатка денежных средств предприятия, временной график динамики накопленной суммы месячных кассовых разрывов предприятия. R15

представления значений параметров, передаваемых в функциональные блоки. Внутренние входы и выходы выступают в качестве локальных переменных и имеют порядковые номера, которые необходимы для визуализации последовательности преобразования информации в ходе выполнения требования. Каждый функциональный блок имеет уникальный идентификатор. Согласно нотации GRA, диаграмму следует читать слева направо и снизу вверх.

В требовании RA7 явно определено множество начальных параметров — структура портфеля контрактов и прибыль по каждому контракту из пула в книге MS Excel. Также в тексте требования присутствует информация о выходных данных — двух популяциях (множествах) сущностей типов «ГОЗ» и «Коммерция». При укрупненном описании последователь -ности обработки данных необходимо определить основные функциональные блоки преобразования промежуточных входных данных в выходные. Для спецификации функциональных блоков используются отглагольные существительные: расчет, создание, сортировка, инициализация.

Анализ диаграммы на рисунке 1 позволяет пояснить принцип формирования числовых идентификаторов для блоков преобразования информации. Согласно правилу фреймворка GRA, каждый идентификатор образуется путем соединения отсортированных по возрастанию порядковых номеров его входных и выходных параметров. Если одним из входов функционального блока является внешний входной параметр, не имеющий порядкового номера, то для отображения этого входного параметра в идентификаторе функционального блока используется символ «0», который добавляется слева. Кроме того, для исключения повторения идентификаторов функциональных блоков и порядковых номеров внутренних входов и выходов к идентификатору каждого функционального блока слева присоединяется дополнительный символ «1». Таким образом, правило, использующееся для построения идентификаторов функциональных блоков, обеспечивает их уникальность, а также позволяет отображать структуру параметров, используемых в их названиях. Продемонстрируем применение рассмотренного правила на конкретном примере. Идентификатор «123» заключительного функционального блока диаграммы на рисунке 1 представляет собой цепочку из трех символов: дополнительный символ «1», порядковый номер внутреннего входного параметра («2»), порядковый номер внутреннего входного параметра («3»). Поскольку вну-

тренний выходной параметр совпадает с внешним выходным параметром, он не отображается на диаграмме в целях предотвращения дублирования информации.

Верификация функционального требования, представленного в форме диаграммы, в нотации GRA, заключается в проверке выполнения следующих обязательных условий:

♦ каждый внешний входной параметр должен использоваться, по крайней мере, в одном функциональном блоке;

♦ каждый функциональный блок должен иметь, по крайней мере, один входной и один выходной параметр;

♦ внешняя выходная структура, определенная для функционального требования, должна представлять собой множество, являющееся результатом объединения всех внутренних выходных параметров, которые не используются в качестве входов в других функциональных блоках;

♦ минимальная мощность множества выходных параметров, формирующих внешнюю выходную структуру, не может быть равна нулю.

Диаграмма в нотации GRA, представленная на рисунке 1, удовлетворяет всем перечисленным условиям, что позволяет успешно завершить верификацию требования RA7. Текстовая спецификация верифицированного требования и его функциональная диаграмма полностью готовы к использованию в процессе разработки имитационной модели производственного предприятия.

Аналогичным образом осуществляется верификация диаграмм для других функциональных требований RA9-RA11 и RA14. В итоге схемы, созданные с применением правил фреймворка GRA, должны завершить верификацию подмножества функциональных требований RA7, RA9-RA11 и RA14 по критерию приемки «Полнота». Однако это возможно только в том случае, если все они будут включать в себя главные элементы реализации (внешние входы и выходы, промежуточные входы и выходы, функциональные блоки), а также удовлетворять всем условиям, обеспечивающим корректное применение выбранной нотации. Графическое представление требований должно гарантировать их корректность и пригодность для использования в процессе разработки имитационной модели.

Таким образом, результатом верификации исходных требований (таблица 1), является множество модифицированных требований, удовлетворяющих

Популяции контрактов типов «ГОЗ» и «Коммерция», параметры которых инициализированы значениями соответствующих характеристик контрактов с наибольшим размером прибыли

Доля контрактов типа «ГОЗ»

Списки прибыли пула контрактов типов «ГОЗ» и «Коммерция»

О ©

©

101

112

103

123

Число контрактов типов «ГОЗ» и «Коммерция»

Популяции контрактов типов «ГОЗ» и «Коммерция»

Списки значений прибыли по контрактам, отсортированные по убыванию

Расчет числа контрактов типов «ГОЗ» и «Коммерция»

Создание популяций контрактов типов «ГОЗ» и «Коммерция»

Сортировка списков значений прибыли по контрактам по убыванию

Инициализация параметров популяций контрактов значениями соответствующих характеристик контрактов с наибольшим размером прибыли

Рис. 1. Диаграмма в нотации ОЯД для верификации требования ЯД7

критериям приемки (таблица 2) и совокупность диаграмм, визуализирующих процесс преобразования информации для выполнения функциональных требований. Совокупность верифицированных требований к имитационной модели типового производственного предприятия является основой для ее разработки. В свою очередь, имитационная модель используется для подготовки сценариев достижения предприятием предпочтительного будущего финансового состояния и обеспечения высокого уровня его финансовой стабильности.

Заключение

В результате исследования определен список верифицированных требований к имитационной модели типового производственного предприятия, предназначенной для подготовки сценариев достижения предпочтительного будущего финансового состояния.

В процессе верификации требований к имитационной модели произведена их формальная инспекция на предмет соответствия критериям приемки. В случае получения требованием отрицательной оценки по одному или нескольким критериям верификации оно подвергалось модификации.

На заключительном этапе верификации рассмотрен пример построения диаграммы с использованием фреймворка GRA для одного из функциональных требований. Такая диаграмма позволяет детализировать структуру и внутреннюю логику требования и, в итоге, гарантировать его пригодность для дальнейшего использования при разработке имитационной модели предприятия.

Результаты исследования могут быть использованы при проведении многоэтапной верификации требований к имитационным моделям, предназначенным для сценарного планирования финансового состояния производственных предприятий с дискретным процессом производства. ■

Литература

1. Акопов А.С. Имитационное моделирование. М.: Юрайт, 2014.

2. Интеллектуальный анализ динамики бизнес-систем / С.Н. Брускин и [др.]. М.: ИНФРА-М, 2010.

3. Акопов А.С., Хачатрян Н.К. Агентное моделирование: учебно-методическое пособие. М.: ЦЭМИ, 2016.

4. Акопов А.С., Бекларян А.Л., Фомин А.В., Хачатрян Н.К. Система прогнозирования динамики добычи нефти с использованием имитационного моделирования // Информационные технологии. 2017. Т. 23. № 6. С. 431—436.

5. Akopov A.S., Beklaiyan A.L., Saghatelyan A.K., Sahakyan L.V. Control system for ecological modernization of enterprises (on the example of the Republic of Armenia) // Business Informatics. 2016. No. 2 (36). P. 71-78.

6. Akopov A.S. Designing of integrated system-dynamics models for an oil company // International Journal of Computer Applications in Technology. 2012. Vol. 45. No. 4. P. 220-230.

7. Акопов А.С. Системно-динамическое моделирование стратегии банковской группы // Бизнес-информатика. 2012. № 2 (20). С. 10-19.

8. Акопов А.С. Использование средств динамического имитационного моделирования для подготовки управленческих решений в ТЭК // Системы управления и информационные технологии. 2004. № 2. С. 72-79.

9. A Guide to the Business Analysis Body of Knowledge (BABOK Guide). Version 3.0. Toronto: IIBA, 2015.

10. Boehm B.W. Guidelines for verifying and validating software requirements and design specifications. [Электронный ресурс]: http://csse.usc. edu/TECHRPTS/1979/usccse79-501/usccse79-501.pdf (дата обращения 08.05.2018).

11. Heck P., Zaidman E. A quality framework for agile requirements: A practitioner's perspective. [Электронный ресурс]: https://www.researchgate. net/publication/263237832_A_Quality_FIamewoIk_foI_Agile_RequiIements_A_PIactitioneI's_PeIspective (дата обращения 08.05.2018).

12. Lucassen G., Dalpiaz F., van der Werf J.M. E.M., Brinkkemper S. Improving agile requirements: The quality user story framework and tool // Requirements Engineering. 2016. Vol. 21. No. 3. P. 383-403.

13. Business Analysis Competency Model. Version 4.0. Toronto: IIBA, 2017.

14. Kececi N., Halang WA., Abran A. A semi-formal method to verify correctness of functional requirements specifications of complex systems // Design and Analysis of Distributed Embedded Systems (DIPES 2002). / Eds. B. Kleinjohann, K.H. Kim, L. Kleinjohann, A. Rettberg. Boston, MA: Springer, 2002. Vol. 91. P. 61-69.

15. Kececi N., Modarres M., Smidts C. System software interface for safety related digital I&C systems // The 10th European European Conference on Safety and Reliability (ESREL 99). Munich-Garching, Germany, 13-17 September 1999. P. 433-438.

16. Kececi N., Abran A. Analyzing, measuring and assessing software quality in a logic based graphical model // 41th International Conference on Quality and Dependability (QUALITA 2001). Annecy, France, 22-23 March 2001. P. 48-55.

17. Glossary of software engineering terminology. [Электронный ресурс]: http://www.standards.ra/document/ 4552110.aspx (дата обращения 08.05.2018).

18. IEEE standards glossary of software engineering standards / IEEE Std 610.12-1990. IEEE, 1990.

19. Kececi N., Abran A. An integrated measure for functional requirements correctness // 11th International Workshop on Software Measurement (IWSM 2001). Montreal, Canada, 28-29 August 2001. P. 137-150.

20. Pereira J.L., Silva D. Business process modeling languages: A comparative framework // New Advances in Information Systems and Technologies. 2016. Vol. 444. P. 619-628.

21. A Guide to the Business Process Management Common Body of Knowledge (BPM CBOK). Version 3.0. Pensacola, FL: ABPMP, 2013.

22. Wynn D.C., Clarkson P.J. Process models in design and development // Research in Engineering and Design. 2018. Vol. 29. No. 2. P. 161-202.

23. A comparison of BPMN and UML 2.0 activity diagrams / D.C.C. Peixoto [et al.] // VII Simpfcio Brasileiro de Qualidade de Software. Florianopolis, Santa Catarina, Brazil, 30 May 2008. P. 64-75.

24. Борщев А. Как строить простые, красивые и полезные модели сложных систем // Материалы конференции «Имитационное моделирование. Теория и практика» (ИММОД 2013). Казань, 16-18 октября 2013. Т. 1. С. 21-34.

25. Scucanec S.J., van Gaasbeek J.R. A day in the life of a verification requirement // US Air Force T&E Days Conference. Los Angeles, 5-7 February 2008. P. 104-116.

Verification of requirements for the simulation model of a production enterprise

Tatiana K. Kravchenko

Professor, Head of Department of Business Analytics National Research University Higher School of Economics Address: 20, Myasnitskaya Street, Moscow, 101000, Russian Federation E-mail: tkravchenko@hse.ru

Nikolay I. Golov

Senior Lecturer, Department of Business Analytics National Research University Higher School of Economics Address: 20, Myasnitskaya Street, Moscow, 101000, Russian Federation E-mail: ngolov@hse.ru

Aleksey V. Fomin

Senior Lecturer, Department of Business Analytics National Research University Higher School of Economics Address: 20, Myasnitskaya Street, Moscow, 101000, Russian Federation E-mail: afomin@hse.ru

Aleksey Y. Lipatnikov

Graduate of MSс Program

National Research University Higher School of Economics Address: 20, Myasnitskaya Street, Moscow, 101000, Russian Federation E-mail: lipatnikov94@gmail.com

Abstract

Developing variants of scenarios for a production enterprise's achieving a desirable financial position using simulation modeling tools requires a specification and verification of requirements for the simulation model. Availability of such variants of scenarios allows stakeholders to select the most efficient solution. The verification is performed by business analysts and key stakeholders; the aim is to assess readiness of the requirements for final approval and to check that the requirements provide all material information for future work. Verification includes evaluating the requirements regarding their compliance with the company's business analysis standards, as well as assessment of the model's completeness and common terminology used for description of the requirements. Understanding the desired solution, which meets all the stakeholders' requirements, is the most important element in requirements verification.

For developing a simulation model, which is essential for determining variants of development scenarios and covers financial flows of a typical production company, a list of verified requirements is determined. Criteria of requirements verification include not only acceptance criteria, but also the Graphical Requirements Analysis framework (GRA framework), that is used for verification of functional requirements. In contrast with other notations, representation of requirements for using the GRA framework allows one to understand their structure and internal logic, as well as to detect emergent effects. The result of determining the verification criteria is the Verification Cross Reference Matrix (VCRM) that includes all the requirements, methods and criteria. In the final stage, we present an example of a diagram for one of the functional requirements.

The verified requirements should be used at different stages of constructing the simulation model, which is focused on development of scenarios for achieving the production enterprise's desired future financial position. Modeling scenarios of future development of the types "what will happen, if...?" and "what to do to achieve the goal?", using simulation modeling systems allows one to dramatically increase the quality of decision making.

Key words: requirements, verification of requirements, criteria for verification, simulation model, scenario analysis, acceptance criteria, GRA framework.

Citation: Kravchenko TK., Golov N.I., Fomin A.V., Lipatnikov A.Y. (2018) Verification of requirements for the simulation model of a production enterprise. Business Informatics, no. 2 (44), pp. 65-78. DOI: 10.17323/1998-0663.2018.2.65.78.

References

1. Akopov A.S. (2014) Imitatsionnoemodelirovanie [Simulation modeling]. Moscow: Urait (in Russian).

2. Bruskin S.N., Dovzhenko A.Y., Nikolaenko V.A., Petrov L.F., Romanov V.P. (2010) Intellektual'nyy analiz dinamiki biznes-sistem [Intellectual analysis of business systems dynamics]. Moscow: INFRA-M (in Russian).

3. Akopov A.S., Khachatryan N.K. (2016) Agentnoe modelirovanie [Agent based modeling]. Moscow: CEMI (in Russian).

4. Akopov A.S., Beklaryan A.L., Fomin A.V., Khachatryan N.K. (2017) Sistema prognozirovaniya dinamiki dobychi nefti s ispol'zovaniem imitatsionnogo modelirovaniya [A system of oil extraction dynamics forecasting using simulation modeling]. Information Technologies, vol. 23, no. 6, pp. 431-436 (in Russian).

5. Akopov A.S., Beklaryan A.L., Saghatelyan A.K., Sahakyan L.V. (2016) Control system for ecological modernization of enterprises (on the example of the Republic of Armenia). Business Informatics, no. 2 (36), pp. 71-78.

6. Akopov A.S. (2012) Designing of integrated system-dynamics models for an oil company. International Journal of Computer Applications in Technology, vol. 45, no. 4, pp. 220-230.

7. Akopov A.S. (2012) Sistemno-dinamicheskoe modelirovanie strategii bankovskoy gruppy [System dynamics modeling of a banking group's strategy]. Business Informatics, no. 2 (20), pp. 10-19 (in Russian).

8. Akopov A.S. (2004) Ispol'zovanie sredstv dinamicheskogo imitatsionnogo modelirovaniya dlya podgotovki upravlencheskih resheniy v TEK [Using dynamic simulation modeling tools for preparation of management decisions in the field of fuel and energy]. Management Systems and Information Technologies, no. 2, pp. 72-79 (in Russian).

9. IIBA (2015) A Guide to the Business Analysis Body of Knowledge (BABOK Guide). Version 3.0. Toronto: IIBA.

10. Boehm B.W. (1979) Guidelines for verifying and validating software requirements and design specifications. Available at: http://csse.usc.edu/ TECHRPTS/1979/usccse79-501/usccse79-501.pdf (accessed 08 May 2018).

11. Heck P., Zaidman E. (2014) A quality framework for agile requirements: A practitioner's perspective. Available at: https://www.researchgate.net/ publication/263237832_A_Quality_Framework_for_Agile_Requirements_A_Practitioner's_Perspective (accessed 08 May 2018).

12. Lucassen G., Dalpiaz F., van der Werf J.M. E.M., Brinkkemper S. (2016) Improving agile requirements: The quality user story framework and tool. Requirements Engineering, vol. 21, no. 3, pp. 383—403.

13. IIBA (2017) Business Analysis Competency Model. Version 4.0. Toronto: IIBA.

14. Kececi N., Halang W.A., Abran A. (2002) A semi-formal method to verify correctness of functional requirements specifications of complex systems. Design and analysis of distributed embedded systems (eds. B. Kleinjohann, K.H. Kim, L. Kleinjohann, A. Rettberg). Boston, MA: Springer, vol. 91, pp. 61-69.

15. Kececi N., Modarres M., Smidts C. (1999) System software interface for safety related digital I&C systems. Proceedings of the 10th European European Conference on Safety and Reliability (ESREL 99). Munich—Garching, Germany, 13—17 September 1999, pp. 433-438.

16. Kececi N., Abran A. (2001) Analyzing, measuring and assessing software quality in a logic based graphical model. Proceedings of the 41th International Conference on Quality and Dependability (QUALITA 2001). Annecy, France, 22—23 March 2001, pp. 48-55.

17. Standardinform (2002) Glossary of software engineering terminology. Available at: http://www.standards.ru/document/ 4552110.aspx (accessed 08 May 2018).

18. IEEE (1990) IEEE standards glossary of software engineering standards. IEEE Std 610.12—1990. IEEE.

19. Kececi N., Abran A. (2001) An integrated measure for functional requirements correctness. Proceedings of the 11th International Workshop on Software Measurement (IWSM2001). Montreal, Canada, 28-29August 2001, pp. 137-150.

20. Pereira J.L., Silva D. (2016) Business process modeling languages: A comparative framework. New Advances in Information Systems and Technologies, vol. 444, pp. 619-628.

21. ABPMP (2013) A Guide to the Business Process Management Common Body of Knowledge (BPMCBOK). Version 3.0. Pensacola, FL: ABPMP.

22. Wynn D.C., Clarkson P.J. (2018) Process models in design and development. Research in Engineering and Design, vol. 29, no. 2, pp. 161-202.

23. Peixoto D.C.C., Batista V.A., Atayde A.P, Borges E.P, Resende R.F., Padua C.I.P.S. (2008) A comparison of BPMN and UML 2.0 activity diagrams. VII Simp sio Brasileiro de Qualidade de Software, Florianpolis, Santa Catarina, Brazil, 30May 2008, pp. 64-75.

24. Borshchev A. (2013) Kak stroit' prostye, krasivye i poleznye modeli slozhnyh sistem [How to build simple, beautiful and useful models of complex systems]. Proceedings of the Simulation Modeling Theory and Practice Conference, Kazan, 16-18 October 2013, vol. 1, pp. 21-34 (in Russian).

25. Scucanec S.J., van Gaasbeek J.R. (2008) A day in the life of a verification requirement. Proceedings of the US Air Force T&E Days Conference, Los Angeles, 5-7 February 2008, pp. 104-116.