Software & Systems

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

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

Часть прикладного ПО (программные средства мультимедиа, СУБД, ПО для работы с текстовой и табличной информацией, ПО для статистической обработки данных и др.) основана на использовании регламентированных по сути алгоритмов и не ориентирована на применение в конкретной предметной области. Типичным примером прикладного ПО данного типа являются программы, предназначенные для создания и редактирования информации в виде плоского текста. Такие программы основаны на правилах лингвистики определенного языка и своеобразии технологий его редактирования, включающих как традиционные ручные технологии, перенесенные в компьютерную среду, так и новые технологии, которые стали возможными только в условиях компьютерной среды.

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

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

Функциональное ПО предназначено для решения задач в конкретной предметной области и обладает определенной уникальностью относительно реализуемых алгоритмов. Это объясняется тем, что разнообразие предметных областей как по сути, так и по масштабу очень велико. Поэтому для них какая-либо алгоритмическая унификация не представляется возможной. Унифицированные решения могут иметь место, но только в избирательных областях и при соблюдении двух типов ограничений для внедрения на реальном объекте автоматизации. Первый тип ограничений касается непосредственной доработки программного кода с учетом уникальных особенностей функционирования объекта, второй связан с ручной настройкой большого количества параметров, которые смогут обеспечить корректную работу ИС в условиях реального объекта или системы. Примерами являются в основном пакеты программ управленческого класса (бухгалтерские системы, CRM-системы, системы управления персоналом, системы управления складом, си- стемы бизнес-аналитики и др.).

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

Особенности и проблемы формулирования требований к ИС функционального назначения

Любой проект по созданию функционального ПО начинается с того, что потенциальные пользователи будущей системы должны объяснить ее разработчику, какие повседневные функции они хотели бы выполнять с ее помощью. Необходимость формализации методов взаимодействия и обеспечения взаимопонимания разработчиков с заказчиком или потенциальными пользователями создаваемого программного средства (ПС) с самого начала проекта с целью конкретизации его функций и уточнения требований к качеству подробно описана в работе [1]. Погрешности, обусловленные разного рода неточностями технических заданий, а также ошибки при спецификации требований могут и должны выявляться на самых ранних стадиях проектирования. Такой подход позволяет ускорить собственно процесс проектирования, а также повысить его качество.

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

Качественный и количественный состав экспертов со стороны заказчика является вариативным и определяется

–     объемом реализуемой в рамках проекта функциональности (то есть количеством решаемых задач);

–     технологическими и (или) управленческими особенностями, характерными для объ- екта автоматизации;

–     особенностями информационно-техно- логического характера, обеспечивающими вза- имодействие объекта автоматизации со смежными ИС;

–     управлением всеми видами работ и ресурсов в рамках проекта;

–     профессионально-квалификационным уровнем специалистов, участвующих в выполнении проекта.

Если представить этап выявления требований как некую начальную точку проекта по созданию ИС функционального назначения, то очевидно, что в качестве конечной точки этого проекта должен быть готовый пакет программ. Но, как известно, в программах могут быть реализованы только формализованные алгоритмы. Это обусловливает один принципиальный момент: любой алгоритм может быть перенесен в компьютерную среду только в том случае, если имеет четко заданную входную и выходную информацию, а также математические и логические правила преобразования входа в выход.

Таким образом, если в процессе выявления требований учитывать эту особенность, то все действия аналитика (подготовка вопросов для интервью и анкетирования, анализ документов и проведение наблюдения) должны быть направлены на то, чтобы иметь возможность обнаруживать в любых формулировках (в широком смысле) зависимости, которые укладываются в схему: входная информация ® алгоритм преобразования ® выходная информация. В соответствии с данной схемой все решаемые в рамках функциональных автоматизированных ИС (АИС) задачи можно разделить на три группы.

1.    Задачи формирования (и редактирования) БД. Эти задачи связаны с наполнением и изменением БД. Как правило, предусматривают при этом возможность просмотра БД по различной совокупности имеющихся в ней полей.

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

3.    Задачи преобразования информации в БД. Основаны на применении расчетных алгоритмов. Это могут быть задачи собственно расчетного характера, а также планирования или прогнозирования. Результаты преобразования в некотором виде могут быть показаны пользователю или не показаны (в этом случае система только сообщит о завершении работы соответствующего ПО). Распечатка результатов реализуется в виде отдельной опции.

В работе [3] утверждается, что термин «требование» является слишком перегруженным и требования необходимо подразделять на три уровня.

Уровень 1. Бизнес-требования. К ним могут относиться, например, оптимизация запасов исходных материалов или результатов производственной деятельности, сокращение сроков каких-либо производственных и (или) управленческих процессов (операций), подготовка аналитической информации с возможностью расчета необходимых показателей, минимизация временны́х рамок, связанных с выполнением заказов, наличие полной и корректной информации об определенных аспектах деятельности и др. Такие требования всегда формулируются в очень общем виде. При этом алгоритмическая составляющая по их реализации фактически не просматривается, так как основывается на решении большого количества взаимосвязанных задач в рамках проектируемой системы.

Уровень 2. Пользовательские требования. Оперируют понятиями, которые схематично можно представить, например, в такой стилистической формулировке: «ввести информацию о…», «вывести отчет о…», «рассчитать показатель…». Их реализация предусматривает определенные алгоритмы и интерфейсы взаимодействия пользователей и системы. Структуризация и формализация в таких требованиях отсутствуют, поэтому они носят описательный характер.

Уровень 3. Функциональные требования. По существу являются детализацией пользовательских требований и определяют поведение системы. Часто функциональные требования тождественны понятию «варианты использования».

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

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

Требования к системе, связанные с хранением, изменением, представлением информации, а также с ее достоверностью, надежностью и другими характеристиками, относятся к организационно-технологическим и должны рассматриваться в рамках документа «Техническое задание» по ГОСТ 34.602-89. Именно в этом документе предусмотрено описание большого числа различных организационных, технических и технологических требований. Стандарт носит рекомендательный характер, но может применяться в качестве шаблона, редактируемого разработчиком по мере необходимости в соответствии со спецификой проектируемой системы. 

На формирование функциональных требований влияют следующие основные факторы:

-     выбранная модель (технология) проектирования (классическая спиральная модель или экстремальное программирование);

-     знание разработчиком особенностей предметной области, для которой осуществляется проектирование (это определяет уровень детализации требований);

-     профессионально-квалификационный уровень экспертов от заказчика, непосредственно участвующих в формировании требований;

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

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

1.    Отсутствие единой терминологии у заказчика и разработчика АИС. Данную проблему поможет решить (хотя бы частично) наличие некоторой универсальной схемы, которая будет понятной обеим сторонам.

2.    Отсутствие четкости, то есть принципов структуризации (объединение или, напротив, чрезмерная дифференциация) в стилистике описания требований. Эта проблема обусловливает излишнюю итерационность в процессе программной реализации требований.

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

В стандарте IEEE 830-1998 говорится о неизбежных ловушках естественного языка в силу его неоднозначности.

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

Формирование требований к автоматизированным системам является наиболее трудной частью проектов, связанных с реализацией АИС, и нередко сопровождается, в частности, следующими проблемами [7]:

–     отсутствие своевременной необходимой и достаточной информации от заказчика для адекватной оценки требований;

–     возможные дублирования и противоречия требований в связи с разным профессионально-квалификационным и должностным статусом экспертов от заказчика;

–     терминологическая особенность, отражающая незнание эксперта от заказчика возможностей (или, наоборот, ограничений) со стороны информационных технологий при реализации требований;

–     неуправляемое количество требований вследствие их различной детализации (при отсутствии унифицированной системы формулирования);

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

В дополнение можно добавить еще ряд проблем, которые приведены в [3].

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

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

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

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

5.    Наличие в требованиях каких-либо излишеств, инициированных по каким-либо причинам разработчиком, но не заявленных заказчиком.

6.    Пропущенные классы пользователей (например, не принимали участие в анкетиро- вании или не были опрошены при проведении интервью).

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

В [9] предлагается подход для формулирования требований, основанный на следующих основных понятиях:

–     действующее лицо – кто-то (или что-то), обладающее поведением;

–     участник – кто-то (или что-то), проявляющий интерес к поведению проектируемой системы;

–     основное действующее лицо – участник, который может инициировать взаимодействие с системой для достижения некоторых целей;

–     вариант использования – сценарий взаимодействия пользователя с системой;

–     область действия – проектируемая система;

–     предусловия и гарантии – то, что должно быть истинным до и после реализации варианта использования;

–     основной сценарий – стандартный вариант решения (основной вычислительный процесс), при котором не возникает никаких ошибок;

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

Авторы [10], рассматривая вопросы, касающиеся принципов работы с требованиями к ПО, используют следующие понятия.

Требование – возможность, которую долж­на обеспечивать система.

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

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

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

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

В работе [3] рассматриваются такие понятия, как варианты использования, сценарии использования, предварительные и выходные условия, функциональные требования, пользовательские истории.

В таблице 1 представлена взаимосвязь отдельных понятий [3].

Таблица 1

Примеры вариантов использования и соответствующих пользовательских историй

Table 1

Examples of use cases and related user stories

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

В [11] был рассмотрен подход, основанный на использовании двухуровневой схемы описа- ния функциональных требований. Первый уро- вень предусматривает формулировку требований в терминах классических функций управления: планирование (расчет, прогноз), учет, контроль, анализ, регулирование. В [12] было показано, что задачи, названия которых могут быть представлены через функции управления, имеют качественную алгоритмическую основу и, следовательно, хорошо приспособлены для автоматизации.

Кроме функции управления, в названии задачи может присутствовать какая-либо технологическая процедура обработки информации (например, поиск, формирование, представление, хранение, передача).

Второй уровень формулирования требований базируется на схеме описания задачи для программирования, составленной на базе рекомендаций РД 50-34.698–90:

–     корректное название собственно задачи;

–     ограничения на решения, исходящие со стороны как смежных задач, так и использования экономико-математических моделей;

–     хронологические особенности;

–     вопросы, связанные с описанием и особенностями информационного обеспечения (с входной и выходной, а также нормативно-справочной информацией);

–     алгоритмическая составляющая.

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

Рекомендация на использование при описании функциональных требований схемы, основанной на приведенном стандарте, может быть только принципиальным ориентиром относительно тех вопросов, которые необходимо выяснять в процессе формулирования требований, а затем учитывать при описании задачи для программирования. Для реальных проектов внимание может быть уделено только отдельным элементам схемы. Кроме того, схема может быть дополнена любыми другими элементами, учитывающими специфику конкретной задачи. Более подробно схема со всеми необходимыми пояснениями и комментариями представлена в [13].

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

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

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

1.    Решаются ли задачи учета? Если «да», то какие объекты (процессы, события, ситуации, явления и т.п.) необходимо учитывать и какие их характеристики (показатели) при этом являются обязательными?

2.    В решении каких задач планирования следует реализовать многовариантные решения?

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

4.    В решении каких расчетных задач необходимо изменить алгоритмы обработки информации и почему?

5.    Существуют ли в настоящее время БД или электронные таблицы, информацию из которых необходимо сохранить в проектируемой АИС? Что отражает такая информация и каков ее объем?

6.    Используется ли в настоящее время какая-либо статистическая информация для решения задач? Если «нет», то существует ли необходимость ее накопления и для каких целей?

7.    Сколько документов имеют исключи- тельно бумажную форму? Какие из них можно перевести в электронный вид?

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

9.    Как часто и для каких целей решаются задачи, связанные с поиском информации?

10. Существует ли деление отчетных документов на обязательные (регламентированные) и необязательные (эпизодические)? Как часто и почему возникает необходимость в составлении разовых отчетов?

11. Все ли отчетные документы находят реальное применение для принятия решений?

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

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

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

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

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

Литература

1.    Липаев В.В. Проблемы развития программной инженерии и некоторые фрагменты их реше- ния // Бизнес-информатика. 2007. № 1. С. 52–63.

2.    Гриб И.И., Вишняков Ю.С., Жижченко А.Б., Поликарпов С.А., Сотников А.Н., Табаченко Н.В. Анализ особенностей процессов управления требованиями к информационным системам государственных структур // Программные продукты и системы. 2017. Т. 30. № 4. С. 790–793. DOI: 10.15827/0236-235X.120.790-793.

3.    Вигерс К., Битти Дж. Разработка требований к программному обеспечению; [пер. с англ.]. М.–СПб, 2014. 716 с.

4.    Кравченко Т.К. Управление требованиями при реализации ИТ-проектов // Бизнес-информатика. 2013. № 3. С. 63–71.

5.    Яловой И. Анализ требований и управление изменениями программных проектов // Инженер. вестн. Дона. 2008. № 11. С. 32–42.

6.    Непомнящих А.В. Методики приоритизации требований при разработке программного обеспечения // Математические структуры и моделирование. 2011. Вып. 23. С. 76–85.

7.    Баронов В.В., Калянов Г.Н., Попов Ю.Н., Титовский И.Н. Информационные технологии и управление предприятием. Саратов: Профобразование, 2017. 327 с.

8.    Халл Э., Кен Дж., Джереми Д. Разработка и управление требованиями; [пер. с англ.]. UK, Telelogic, 2005, 240 с.

9.    Коберн А. Современные методы описания функциональных требований к системам; [пер. Е. Борисова]. М.: Лори, 2002. 263 с.

10. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002. 448 с.

11. Gutgarts R.D. Peculiarities of functional requirements of automated enterprise resource management system. Proc. EpSBS, 2018, vol. L, pp. 477–485. URL: https://www.futureacademy.org.uk/files/images/upload/icRPTSS2018FA057.pdf (дата обращения: 03.01.2019). DOI: 10.15405/epsbs.2018.12.57.

12. Гутгарц Р.Д. Роль бизнес-процессов в формировании требований к ERP-системе // Проблемы теории и практики управления. 2015. № 1. С. 118–126.

13. Гутгарц Р.Д. Проектирование автоматизированных систем обработки информации и управления. М.: Юрайт, 2019. 304 с.

References

1. Lipaev V.V.  Problems of software engineering development and some fragments of their solution. Business Informatics. 2007, no. 1, pp. 52–63 (in Russ.).
2. Grib I.I., Vishnyakov Yu.S., Zhizhchenko A.B., Polikarpov S.A., Sotnikov A.N., Tabachenko N.V. Analysis of the features of requirements management processes in information systems of state structures. Software & Systems. 2017, vol. 30, no. 4, pp. 790–793. DOI: 10.15827/0236-235X.120.790-793 (in Russ.).
3. Wiegers K., Beatty J. Software Requirements. 3rd ed., Microsoft Press, 2013, 672 p. (Rus. ed.: Moscow, BHV Publ., 2014, 716 p.).
4. Kravchenko T.K. Requirements management in the IT project implementation. Business Informatics. 2013, no. 3, pp. 63–71 (in Russ.).
5. Yalovoy I. Requirements analysis and change management for software projects. Engineering J. of Don. 2008, no. 11, pp. 32–42 (in Russ.).
6. Nepomnyashchikh A.V. Methods of requirement prioritization for software development. Mathematical Structures and Modeling. 2011, iss. 23, pp. 76–85 (in Russ.).
7. Baronov V.V., Kalyanov G.N., Popov Yu.N., Titovsky I.N. Information Technologies and Enterprise Management. Saratov, Profobrazobanie Publ., 2017, 327 p.
8. Hull E., Jackson K., Dick J. Requirements Engineering. 2nd ed., Springer Publ., 2005, 198 p. (Rus. ed.: 2nd ed., Telelogic Publ., 2005, 240 p.).
9. Cockburn A. Writing Effective Use Cases. Addison-Wesley Prof. Publ., 2000, 304 p. (Rus. ed.: Moscow, Lori, 2002, 263 p.).
10. Leffingwell D., Widrig D. Managing Software Requirements: A Unified Approach. Addison-Wesley Prof. Publ., 1999, 528 p. (Rus. ed.: Moscow, Vilyams Publ., 2002, 448 p.).
11. Gutgarts R.D. Peculiarities of functional requirements of automated enterprise resource management system. Proc. EpSBS. 2018, vol. L, pp. 477–485. Available at: https://www.futureacademy.org.uk/files/images/upload/icRPTSS2018FA057.pdf (accessed January 3, 2019).
12. Gutgarts R.D. The role of business processes in the formation of requirements for the ERP system. Problems of Management Theory and Practice. 2015, no. 1, pp. 118–127 (in Russ.).
13. Gutgarts R.D. Designing automated information processing and control systems. Moscow, Yurayt Publ., 2019, 304 p.