CC BY
166
УДК 303.732.4 Ю.П. Ехлаков
Шаблоны бизнес-требований
и требований пользователей к программному обеспечению производственно-технологического типа
Предложен подход к разработке шаблонов бизнес-требований и требований пользователей к программному продукту, основанный на использовании содержательных моделей системного анализа. Представлены содержательные модели декомпозиции элементов жизненного цикла: бизнес-процессов материального производства конечного продукта, информационной поддержки управления бизнес-процессами, обработки информации при информационной поддержке управления бизнес-процессами; содержательные модели декомпозиции элементов состава экономических показателей: ресурсов, результативности, качества, эффективности управления производством. Описаны элементы языка проектирования шаблонов, приведены варианты шаблонов описания: проблем, бизнес-требований, пользовательских и функциональных требований. В качестве примера приведены шаблоны требований к информационной системе поддержки управления бизнес-процессами распределительного центра.
Ключевые слова: системный анализ, модели декомпозиции, жизненный цикл, бизнес-процессы, шаблоны проектирования требований. ао1: 10.21293/1818-0442-2019-22-1-77-82
В настоящее время разработка и продвижение на рынок прикладных программных продуктов (1111) реализуются по двум бизнес-моделям: разработка рыночного (тиражного) программного продукта или разработка уникального ПП «под заказ» для решения конкретных проблем, возникающих в системах управления производством. При создании тиражного ПП велика вероятность разработать продукт невостребованный на рынке, возможны ошибки при выборе целевых сегментов, каналов и инструментов маркетинговых коммуникаций. При использовании заказной модели разработки ПП основные проблемы связаны с тем, насколько точно и корректно разработчики смогли выделить потребности всех заинтересованных лиц, сформулировать и согласовать их в виде требований, которые в свою очередь определяют состав и содержание моделей бизнес-процессов производства конечных продуктов и/или услуг компании [1, 2].
В общем случае в литературе требования определяются как условия или возможности, которыми должна обладать программная система или ее отдельные компоненты для решения конкретных проблем потенциальных пользователей, сформулированные в виде целей, задач и функционала будущего ПП, которые должны быть надлежащим образом представлены и оформлены в виде технического задания или иного документа. Виды, типы и методы выявления и анализа требований достаточно подробно описаны в технической литературе [3-5].
Для стандартизации и унификации процессов разработки и управления требованиями широко используются шаблоны проектирования. В отечественной литературе достаточно подробно описаны шаблоны для разработки функциональных, нефункциональных и системных требований [3-7], основанные на использовании стандартов на жизненный цикл и качество разработки программных продуктов
[8-10], и отсутствуют какие-либо формализованные варианты шаблонов по выявлению бизнес-требований и требований пользователей.
Основным источником выявления бизнес-требований и требований пользователей являются сведения, основанные на диалоге разработчиков ПП с потенциальными потребителями, а также пользовательские мнения о программных продуктах, размещенных в сети Интернет. Для выявления требований используются, как правило, следующие эвристические процедуры: метод мозгового штурма, метод Делфи, метод разработки сценариев, метод морфологического анализа (интервьюирование, наблюдение, анкетирование, проведение совместных семинаров). При таком подходе велика зависимость результатов от уровня квалификации сторон, от того, каким языком описано требование, насколько оно четко и точно отражает потребности пользователей. Последнее часто приводит к тому, что требования бывают сложными, противоречивыми, плохо структурированными, дублирующимися, слабо связанными с запросами и потребностями заинтересованных сторон, отражают нереалистические ожидания пользователей, часто изменяются или изменяются без необходимости [3]. Эти проблемы остро стояли и перед коллективом разработчиков, возглавляемых автором при создании и продвижении на рынок ряда программных продуктов [11].
В данной статье для устранения отмеченных недостатков предлагается формализованная процедура описания шаблонов бизнес-требований и требований пользователей, основанная на использовании содержательных моделей декомпозиции, предложенных томской школой системного анализа [12].
Содержательные модели декомпозиции требований к программному продукту
Для дальнейшего изложения материала введем следующие определения. Декомпозиция - процедура
разбиения сложного понятия на составляющие его элементы (разбиение целого на части). Модель декомпозиции - набор формальных элементов, обеспечивающих однозначное разбиение целого на части. В данном случае в качестве сложных понятий будем рассматривать бизнес-требования и требования пользователей, а в качестве моделей декомпозиции - модель «жизненного цикла» и модель «состава». Под моделью «жизненного цикла» будем понимать строго упорядоченную совокупность элементов, описывающих эволюционное преобразование исходных ресурсов в конечные результаты системы, под моделью «состава» - набор формальных элементов системы [13].
Внутреннее содержание каждой модели определяется соответствующим классификатором, элементы которого однозначно определяют сущности элементов понятия. «Глубина» декомпозиции определяется размерностью используемого классификатора и предполагает декомпозицию до получения простого, понятного, заведомо выполнимого результата. Например, при декомпозиции бизнес-процесса получения конечных продуктов производственной системы в качестве модели декомпозиции «жизненный цикл» можно использовать классификатор, состоящий из трех элементов: <снабжение, производство, реализация>, либо более подробный, состоящий из семи элементов: <определение потребности в продукции, закупка сырья, хранение сырья, производство продуктов, контроль качеств производства продуктов, хранение готовых продуктов, реализация> [13]. С учетом вышеизложенного для описания шаблонов бизнес-требований и требования пользователей будем использовать следующие модели «жизненного цикла» и «состава».
Модели декомпозиции элементов «жизненного цикла»:
- бизнес-процессов основного производства материальных конечных продуктов компании: «маркетинг, снабжение, производство, реализация»;
- информационной поддержки управления бизнес-процессами: «прогнозирование, планирование, мониторинг, учет, контроль, анализ, регулирование»;
Шаблоны описания требований
Одной из первых работ описания шаблонов как средства разработки и проектирования является монография, в которой изложена концепция языка
- обработки информации при информационной поддержке управления бизнес-процессами: «регистрация, сбор, передача, обработка, хранение, защита, архивирование, уничтожение».
Модели декомпозиции элементов «состава» производственно-экономических показателей производства материальных конечных продуктов:
- результативности производства: «доходы от основных видов деятельности, доля рынка, емкость рынка, выручка, объем продаж, прибыль»;
- ресурсных показателей производства: «основные средства, оборотные средства»;
- качества управления производством в целом и отдельными бизнес-процессами: «затраты на производство и реализацию продукции по статьям калькуляции, производственные расходы, общепроизводственные расходы (накладные расходы), себестоимость, загрузка оборудования, межоперационные запасы сырья и комплектующих, потери от брака»;
-эффективности управления производством: «рентабельность реализованной продукции, рентабельность использования основных средств (фондоотдача), рентабельность оборачиваемости активов».
Модели «состава» показателей программного продукта:
- оценки качества программного продукта: «функциональная пригодность, надежность, эффективность, переносимость, применяемость, сопрово-ждаемость»;
- оценки качества обработки информации: «полнота, достоверность, глубина ретроспективы, оперативность, актуальность, защищенность»;
- архитектуры программного продукта «программный продукт, программный комплекс, программа».
Варианты использования моделей для разработки шаблонов бизнес-требований и требований пользователей представлены в таблице.
Очевидно, что состав классификаторов в каждой из представленных моделей может уточняться в зависимости от предметной области и мнений участников процесса разработки требований.
шаблонов как «структурированного подхода к описанию эффективных методов проектирования в контексте накопленного опыта» [14]. В данном случае в основу языка разработки шаблонов требований по-
Варианты использования моделей для разработки шаблонов требований к программному продукту
Модели Шаблоны
Бизнес-требования Требования пользователей Функциональные требования Нефункциональные требования
ЖЦ бизнес-процессов производства + + +
ЖЦ управления бизнес-процессами + + +
ЖЦ обработки информации + +
Состав показателей результативности + +
Состав показателей качества управления + +
Состав показателей эффективности управления +
Состав показателей ресурсов + +
Состав показателей качества ПП +
Состав архитектуры ПП + + +
Состав показателей БД +
ложена совокупность классификаторов моделей, характеристик ее атрибутов, а также семантических единиц (слов, фраз), используемых для описания шаблона. Структура шаблона состоит из декларативного и атрибутивного описания, это позволяет разделить «тело» шаблона на две части: структуру и атрибуты. Для формализованного описания элементов структуры шаблонов вводятся следующие метасимволы: модели и их атрибуты - [квадратные скобки]; характеристики атрибутов - <треугольные скобки>, семантические единицы предлагается выделять жирным шрифтом. Характеристики атрибутов модели определяют качественные или количественные показатели свойств: «низкий - средний - высокий уровень», «до ?? процентов, в ?? раза». Для описания семантических единиц, характеризующих шаблоны выявления проблем, предлагается использовать следующие лексические конструкции (ключевые фразы): выделите проблемы на этапе..., связанные с ... уровнем показателей. Содержание семантических единиц описания шаблонов требований зависит от типа требований: для описания атрибутов моделей бизнес-требований - повысить, снизить, сократить, увеличить и т.д.; для описания атрибутов моделей требований пользователей - должен иметь возможность; для описания атрибутов моделей функциональных требований - должен(на) обеспечить. С учетом вышеизложенного шаблон описания требования задается структурированной последовательностью различных комбинаций лексических конструкций, сгруппированных в зависимости от вида требований.
Состав и содержание бизнес-требований должны определяться исходя из выявленных проблем в управлении бизнес-процессами. Определим проблему как степень несоответствия: между желаемым и действительным состоянием бизнес-процессов; между потребностями и возможностями пользователей при управлении бизнесом. Явная и четкая формулировка проблем позволит разработчику реализовать только необходимый функционал, обеспечивающий информационную поддержку управления бизнес-процессами. При этом следует выделять как проблемы компании, возникающие при ее взаимодействии с внешними структурами (территориальными и федеральными органами власти и управления, потребителями, поставщиками, партнерами, конкурентами), так и проблемы, связанные с неэффективной организацией управления бизнес-процессами по производству конечного продукта и/или оказанию услуги. Участниками процесса выявления и анализа проблем являются руководители компании, системный аналитик. Ниже приведены некоторые варианты шаблонов вопросов при интервьюровании или анкетировании руководителей компании и шаблонов выявления и описания проблем.
Шаблоны выявления проблем:
- выделите проблемы на этапе [маркетинг -снабжение - транспортировка - производство - реализация], связанные «с низким - высоким» уровнем
показателей [результативность - ресурсы -эффективность - качество управления];
- выделите проблемы, связанные «с низкими» уровнем качества [прогнозирование, планирование, мониторинг, учет, контроль, анализ, регулирование] на этапе [маркетинг - снабжение - транспортировка - производство - реализация].
Шаблоны описания проблем:
- «низкий - высокий» уровень показателей [результативность - ресурсы - эффективность - качества управления] на этапе [маркетинг - снабжение - транспортировка - производство - реализация];
- «низкий» уровень качества [прогнозирование, планирование, мониторинг, учет, контроль, анализ, регулирование] на этапе [маркетинг - снабжение - транспортировка - производство - реализация].
При анализе и описании выявленного множества проблем необходимо четко сформулировать сущность проблемы и описать ситуацию, при которой проблема имеет место. Состав и содержание бизнес-требований должны определяться исходя из выявленных проблем в управлении бизнес-процессами производства конечных продуктов. Реализация бизнес-требований в составе ПП должна обеспечить достижение конкретных целей (результатов), которые руководство собирается получить от использования программного продукта. Формулировка целей может выражаться как в качественной, так и в количественной форме, должна быть четкой и компактной, носить повелительный характер (снизить, повысить, сократить, увеличить, обеспечить и т.д.). Участниками процесса выявления и анализа бизнес-требований также являются руководители компании и системный аналитик. Ниже приведены некоторые варианты шаблонов описания бизнес- требований:
- «повысить, снизить, сократить, увеличить» уровень показателей [результативность - ресурсы -эффективность - качество управления] на этапе [маркетинг - снабжение - транспортировка - производство - реализация];
- «повысить, снизить, сократить, увеличить» уровень показателей [результативность - ресурсы -эффективность - качество управления] на этапе [маркетинг - снабжение - транспортировка - производство - реализация] «на до [число] процентов»;
- «повысить, увеличить» уровень качества [прогнозирование, планирование, мониторинг, учет, контроль, анализ, регулирование] на этапе [маркетинг - снабжение - транспортировка - производство -реализация].
Пользовательские требования должны быть ориентированы на выполнение бизнес-требований и описывать задачи (возможности), которые программный комплекс позволит решить пользователям в рамках своих служебных обязанностей (должностных инструкций). Участники: сотрудники компании (потенциальные пользователи ИТ, архитектор ИТ, системный аналитик). Варианты представления шаблонов пользовательских требований выглядит следующим образом:
- [тип пользователя] должен иметь возможность решать задачи [прогнозирование, планирование, мониторинг, учет, контроль, анализ, регулирование] на этапе [маркетинг - снабжение - транспортировка - производство - реализация];
- [тип пользователя] должен обеспечить возможность [регистрация, сбор, передача, обработка, хранение, защита, архивирование, уничтожение] информацию при решении задач [прогнозирование, планирование, мониторинг, учет, контроль, анализ, регулирование] на этапе [маркетинг - снабжение - транспортировка - производство - реализация].
Структуризация требований пользователей осуществляется при помощи функциональных требований к системе, которые определяют функциональные возможности программного обеспечения, методы передачи и преобразования входных данных в результаты, которые разработчики должны реализовать, чтобы выполнить бизнес-требования и требования пользователей. Участники: сотрудники компании, архитектор ИТ.
Вариант представления шаблона функциональных требований:
- [система, подсистема, программный комплекс, программа] должен(на) обеспечить [регистрация, сбор, передача, обработка, хранение, защита, архивирование, уничтожение] информацию при решении задач [прогнозирование, планирование, мониторинг, учет, контроль, анализ, регулирование] на этапе [маркетинг - снабжение - транспортировка - производство - реализация].
С учетом вышеизложенного процесс разработки требований можно представить в виде следующей последовательности этапов: определение состава системных моделей и их атрибутивного описания; разработка шаблонов выявления и описания проблем; выявление, описание и согласование перечня проблем; разработка шаблонов описания бизнес-требований; разработка бизнес-требований; разработка шаблонов описания требований пользователей; разработка пользовательских требований; разработка шаблонов описания функциональных требований; разработка функциональных требований; формирование и согласование требований к 1111. Описанная последовательность этапов положена в основу разработки рекомендательной системы информационной поддержки деятельности системных аналитиков и архитекторов программного обеспечения.
Ниже приводятся результаты апробации описанного подхода при разработке требований к информационной системе поддержки управления бизнес-процессами распределительного центра.
Пример разработки шаблонов требований к информационной системе поддержки управления бизнес-процессами распределительного центра
Распределительный центр (РЦ) является важным структурным подразделением складского хозяйства крупной промышленной компании и предназначен как для приема, размещения и хранения товаров (готовой продукции, исходного сырья, полу-
фабрикатов), так и для комплектации заказов из полуфабрикатов и продуктов разных категорий для реализации потребителям [15]. Бизнес-процесс приема и размещения товара состоит из следующего набора операций: прием товаров, определение места хранения и размещение товара; учет и контроль наличных запасов на складе. В свою очередь бизнес-процесс комплектации, с учетом особенностей РЦ, представляют в виде следующего набора операций: отбор товара в зону комплектации; комплектация заказов товара для конкретного клиента; доставка в зону отгрузки [16].
На первом этапе системным аналитиком на основе предварительного анализа деятельности РЦ были сформированы следующие содержательные модели: модель жизненного цикла бизнес-процессов РЦ: «снабжение - хранение - реализация»; модель бизнес-процессов «снабжение - хранение»: «прием исходного сырья, полуфабрикатов, готовой продукции - определение мест и размещение на хранение -учет и контроль наличных запасов на складе»; модель бизнес-процесса «реализация»: «отбор товара в зону комплектации - комплектация заказов товара для конкретного потребителя - доставка в зону отгрузки»; модель жизненного цикла информационной поддержки управления РЦ: «планирование, мониторинг, учет, контроль, анализ»; модель жизненного цикла обработки информации при информационной поддержке управления бизнес-процессами: «регистрация, сбор, передача, обработка, хранение, защита, архивирование, уничтожение»; модель состава ресурсных показателей и качества управления РЦ: «объем оборотных средств, затраты трудовых ресурсов».
Далее на основе шаблонов выявления проблем: выделите проблемы на этапе [снабжение - хранение - реализация], связанные «с высоким» уровнем показателя [ресурсов и качества управления]; выделите проблемы, связанные «с низкими» уровнем качества [планирование, мониторинг, учет, контроль, анализ] на этапе [снабжение - хранение -реализация] - была разработана анкета и проведено анкетирование руководителей РЦ.
После обработки и анализа содержания анкет на основе шаблонов описания проблем и шаблонов описания бизнес-требований были выделены следующие проблемы в управлении РЦ и соответствующие бизнес-требования к программному комплексу информационной поддержки управления РЦ.
Проблемы:
- «высокий» уровень показателя [объем оборотных средств] на этапе [хранение товаров];
- «высокий» уровень показателя [затраты трудовых ресурсов] на этапах [хранение товара и комплектация заказов];
- «низкий» уровень качества [планирование, мониторинг, учет контроля, анализ] на этапах [снабжение - хранение - реализация товаров].
Бизнес-требования:
- «сократить» уровень показателя [объем оборотных средств] на этапах [хранение товаров и комплектация заказов] (БТ-1);
- «снизить» уровень показателя [затраты материальных и трудовых ресурсов] на этапах [хранение товаров и комплектация заказов] «на [10] процентов» (БТ-2);
- «повысить» уровень качества [планирование, мониторинг, учет контроля, анализ] на этапах [снабжение - хранение - реализация товаров] (БТ-3).
На следующем этапе системный архитектор на основе анализа бизнес-требований, шаблонов пользовательских требований и служебных обязанностей персонала РЦ сформировал следующий набор пользовательских требований:
- [персонал службы производственного отдела] должен иметь возможность решать задачу [планирование размеров производственных запасов исходного сырья и полуфабрикатов с учетом ограничений на объемы оборотных средств и обеспечения непрерывности и ритмичности производства готовой продукции] (ТП-1);
- [персонал службы приема и хранения] должен иметь возможность решать задачу [планирование приема, размещение и хранение товара на складе с учетом сокращения затраты трудовых ресурсов] (ТП-2);
- [персонал службы комплектации и отгрузки] должен иметь возможность решать задачу [планирование отбора, комплектация и доставка в зону отгрузки товара для конкретного потребителя] (ТП-3);
- [персонал службы мониторинга] должен иметь возможность решать задачу [мониторинг, учет и контроль движения товара на складе] (ТП-4).
Разработка функциональных требований к программному комплексу осуществляется системным архитектором на основе анализа и детализации требований пользователей с учетом модели жизненного цикла обработки информации и шаблона разработки функциональных требований:
- программный комплекс [ПК1] должен обеспечить [сбор, обработку, хранение, защиту] информации при решении задачи [планирования размеров производственных запасов исходного сырья и полуфабрикатов] (ФТ-ПК1);
- программный комплекс [ПК2] должен обеспечить [регистрацию*, сбор, передачу, обработку, передачу**, хранение, защиту] информации при решении задачи [планирование, размещение и хранение товара на складе] (ФТ-ПК2);
программный комплекс [ПК3] должен обеспечить [сбор, обработку, передачу** хранение, защиту] информации при решении задачи [планирование отбора, комплектации и доставки в зону отгрузки товара для конкретного потребителя] (ФТ-ПК3);
- программный комплекс [ПК4] должен обеспечить [регистрацию*, сбор, передачу, обработку, передачу*, хранение, защиту, архивирование] информации при решении задачи [мониторинг, учет и контроль движения товара на складе] (ФТ-ПК4).
Логические взаимосвязи между требованиями представлены на рис. 1.
Рис. 1. Структура взаимосвязей между требованиями
Заключение
Предложенный подход к разработке бизнес-требований и требований пользователей к программному продукту, основанный на использовании содержательных моделей системного анализа и шаблонов проектирования содержания требований в контексте накопленного опыта, ориентирован на решение важной (с точки зрения автора) задачи снижения рисков программных проектов. Использование шаблонов: бизнес-требований, требований пользователей - позволяет унифицировать структуры документов работы с требованиями и процессы разработки требований, облегчить понимание содержательного смысла требований всеми заинтересованными лицами. Представленные результаты апробации предложенного подхода на примере шаблонов требований к информационной системе поддержки управления бизнес-процессами распределительного центра позволяют сделать вывод о пригодности предложенного подхода для решения практических задач. Полученные результаты могут быть полезны специалистам мелких IT-компаний (руководителям проектов, архитекторам программного обеспечения, системным аналитикам) при проведении обследований объектов автоматизации и формировании технических заданий.
Работа выполнена в рамках государственного задания Министерства образования и науки РФ, проект № 8.8184.2017/8.9.
Литература
1. Автоматизированная программная система управления бизнес-процессами предприятия: задачи, описание, структура / М.Ю. Катаев, А.А. Емельяненко, В.А. Емелья-ненко и др. // Доклады ТУСУР. - 2011. - № 2(24) - Ч. 2. -С. 282-289.
2. Катаев М.Ю. Диагностика деятельности предприятия, основанная на оценке эффективности бизнес-процессов / М.Ю. Катаев, А.А. Емельяненко, О.А. Жолобов // Управление экономическими системами: электронный научный журнал. - 2013. - № 10(53) - С. 53.
3. Hull E. Requirements engineering / E. Hull, K. Jackson, J. Dick. - London [etc.]: Springer Science+Business Media, 2005. - 229 p.
4. Вигерс К. Разработка требований к программному обеспечению: пер. с англ. - М.: Русская редакция, 2004. -576 с.
5. Фатрелл Р. Т. Управление программными проектами. Достижение оптимального качества при минимуме затрат: пер. с англ. / Р.Т. Фатрелл, Д.Ф. Шафер, Л.И. Шафер. - М.: Вильямс, 2004. - 1136 с.
6. Гранд М. Шаблоны проектирования в Java: пер. с англ. - М.: Новое знание, 2004. - 559 с.
7. Ларман К. Применение UML и шаблонов проектирования: введение в объектно-ориентированный анализ и
проектирование: учеб. пособие: пер. с англ. - М.: Вильяме, 2001. - 496 с.
8. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. - М.: Стандартинформ, 2011. - 105 с.
9. IEEE-1074-1997 IEEE Standard for Developing Software Life Cycle Processes [Электронный ресурс]. -Режим доступа: https://standards.ieee.org/standard/1074-2006.html, свободный (дата обращения: 09.03.2019).
10. ГОСТ 28806-90. Качество программных средств. Термины и определения. - М.: Изд-во стандартов, 1991. - 8 с.
11. Ехлаков Ю.П. Модели и процедуры продвижения программных продуктов на рынок корпоративных продаж / Ю.П. Ехлаков, Д.Н. Бараксанов, Е.К. Малаховская // Доклады ТУСУР. - 2017. - Т. 20, № 3. - С. 90-97.
12. Перегудов Ф.И. Основы системного анализа: учеб. / Ф.И. Перегудов, Ф.П. Тарасенко. - 3-е изд. - Томск: Изд-во НТЛ, 2001. - 396 с.
13. Ехлаков Ю.П. Теоретические основы автоматизированного управления. - Томск: Том. гос. ун-т систем управления и радиоэлектроники, 2001. - 337 с.
14. Alexander C. A pattern language: Towns, buildings, construction / C. Alexander, S. Ishikawa, M. Silverstein. -N.Y.: Oxford University Press, 1977. - 1171 p.
15. Тюльменков В.Н. Математическая модель и алгоритм решения оптимизации размещения товара на распределительном центре с адресной системой хранения /
B.Н. Тюльменков, Ю.П. Ехлаков, О.М. Замятина // Изв. Том. политехн. ун-та. - 2008. - Т. 313, № 5. - С. 173-176.
16. Ехлаков Ю. П. Проблема автоматизации и оптимизации деятельности распределительного центра предприятия // Доклады ТУСУР. - 2011. - № 2(24), ч. 3. -
C. 114-116.
Ехлаков Юрий Поликарпович
Д-р техн. наук, профессор каф. автоматизации обработки информации (АОИ) Томского государственного университета систем управления и радиоэлектроники (ТУСУР) Ленина пр-т, 40, г. Томск, Россия, 634050 Тел.: +7-913-829-55-42 Эл почта: [email protected]
Ehlakov Y.P.
Business and user requirements patterns for engineering and manufacturing type software
An approach based on the system analysis conceptual model is proposed for the development of patterns of business and user requirements for a software product. The following conceptual models of life cycle elements decomposition are presented: business process of final product production, business process management information support, and information processing during business process management information support. In addition, conceptual models of the economic indicators decomposition are described: resource, performance, quality, efficiency of manufacturing management. The authors describe elements of pattern creation language and provide patterns variants for description of problems, business requirements, user and functional requirements. Patterns of requirements for information system for distribution center business process management support presented as example. Keywords: system analysis, decomposition model, life cycle, business processes, requirements design patterns. doi: 10.21293/1818-0442-2019-22-1-77-82
References
1. Kataev M.Y., Emelyanenko A.A., Emelyanenko V.A, et al. Automated software system for business processes management of enterprise: tasks, description, structure. Proceedings of TUSUR University, 2011, no. 2(24), pt. 2, pp. 282-289 (in Russ.).
2. Kataev M. Y., Emelyanenko A. A., Zholobov O.A. Enterprise activity diagnostics based on the assessment of business processes effectiveness. Management of economic systems: scientific electronic journal, 2013, no. 10(53), pp. 53 (in Russ.).
3. Hull E., Jackson K., J. Dick Requirements engineering. London [etc.], Springer Science+Business Media, 2005, 229 p.
4. Wiegers K. Razrabotka trebovanij k programmnomu obespecheniyu [Software Requirements]. M., Russkaya redak-ciya, 2004, 576 p.
5. Futrell R.T., Shafer D.F., Shafer L.I. Upravlenie-programmnymi proektami dostizhenie optimalnogo kachestva-ri minimum zatrat [Quality Software Project Management]. M., Williams, 2004, 1136 p.
6. Grand M. Shablony proektirovaniya v Java [Patterns in Java], M., Novoe znanie, 2004, 559 p.
7. Larman C. Primenenie UML i shablonov proektirovaniya Vvedenie v obektno-orientirovannyj analiz i proektiro-vanie ucheb posobie [Applying UML and patterns: An introduction to Object-Oriented analysis and Design and Unified Process]. M/, Williams, 2001, 496 p.
8. GOST R ISO/ IEC 12207-2010 Information technology. System and software engineering. Software life cycle processes. Moscow, Standartinform, 2011, 105 p. (in Russ.).
9. IEEE-1074-1997 IEEE Standard for Developing Software Life Cycle Processes. Available at: https://standards.ieee.org/ standard/1074-2006.html (accessed: March 9, 2019).
10. GOST 28806-90 Software quality. Terms and Definitions. Moscow, Standards Publ., 1991. 8 p. (in Russ.).
11. Ehlakov Y.P., Baraksanov E.K., Malahovskaya E.K. Models and procedures for promoting software products to the corporate sales market. Proceedings of TUSUR University, 2017, vol. 20, no. 3, pp. 90-97 (in Russ.).
12. Peregudov F.I., Tarasenko F.P. Osnovy sistemnogo analiza: Uchebnik [Basics of system analysis: Textbook], 3-rd ed. Tomsk, NTL Publ., 2001, 396 p.
13. Ehlakov Y.P. Teoreticheskie osnovy avtomatizirovan-nogo upravleniya [Theoretical bases of automated control]. Tomsk, Tomsk State University of Control Systems and Ra-dioelectronics, 2001, 337 p.
14. Alexander C., Ishikawa S., Silverstein M. A pattern language: Towns, buildings, construction. N.Y., Oxford University Press, 1977, 1171 p.
15. Tyulmenkov V.N., Ehlakov Y.P., Zamyatina O.M. Mathematical model and algorithm for optimizing the placement of goods at a distribution center with an address storage system. Bulletin of the Tomsk Polytechnic University, 2008, vol. 313, no. 5, pp. 173-176 (in Russ.).
16. Ehlakov Y.P. The problem of automation and optimization of the enterprise distribution center. Proceedings of TUSUR University, 2011, no. 2(24), pt. 3, pp. 114-116 (in Russ.).
Ehlakov Yuri P.
Doctor of Engineering, Assistant Professor,
Department of Automation of Information Processing,
Tomsk State University of Control Systems
and Radioelectronics (TUSUR)
40, Lenin pr., Tomsk, Russia, 634050
Phone: +7-913-829-55-42
Email: [email protected]
