Программные продукты и системы, 2019, том 32, № 3

Научно-исследовательский институт

«Центрпрограммсистем»

Программные

продукты и системы

МЕЖДУНАРОДНЫЙ НАУЧНО-ПРАКТИЧЕСКИЙ ЖУРНАЛ

2019, том 32, № 3

(год издания тридцать второй)

И.о. главного редактора

Н.А. СЕМЕНОВ, профессор ТвГТУ

Тверь

SOFTWARE & SYSTEMS

(PROGRAMMNYE PRODUKTY I SISTEMY)

International research and practice journal

2019, vol. 32, no. 3

Acting Editor-in-Chief 

N.A. SEMENOV, Professor TvSTU

Tver

Russian Federation

Research Institute CENTERPROGRAMSYSTEM

© ПРОГРАММНЫЕ ПРОДУКТЫ И СИСТЕМЫ
Международный научно-практический журнал 

2019. Т. 32. № 3
DOI: 10.15827/0236-235X.127

И.о. главного редактора 

Н.А. СЕМЕНОВ,
профессор ТвГТУ (г. Тверь, Россия)

Научные редакторы:
А.П. Еремеев, д.т.н., профессор МЭИ (ТУ) 
(г. Москва, Россия)

К.А. Мамросенко, к.т.н., доцент МАИ 
(г. Москва, Россия)

Издатель НИИ «Центрпрограммсистем» (г. Тверь, Россия)

Учредители: МНИИПУ (г. Москва, Россия),

Главная редакция международного журнала 

«Проблемы теории и практики управления» (г. Москва, Россия),

АОЗТ НИИ «Центрпрограммсистем» (г. Тверь, Россия)

Журнал зарегистрирован в Комитете Российской Федерации

по печати 26 июня 1995 г.

Регистрационное свидетельство № 013831

Подписной индекс в каталоге Агентства «Роспечать» 70799

ISSN 0236-235X (печатн.)
ISSN 2311-2735 (онлайн)

МЕЖДУНАРОДНАЯ РЕДАКЦИОННАЯ КОЛЛЕГИЯ

Семенов Н.А. – д.т.н., профессор Тверского государственного технического университета, заместитель главного редактора 
(г. Тверь, Россия)
Решетников В.Н. – д.ф.-м.н., профессор Московского авиационного института 
(национального исследовательского университета), заместитель главного редактора (г. Москва, Россия)
Арефьев И.Б. – д.т.н., профессор Морской академии Польши (г. Щецин, Польша)
Афанасьев А.П. – д.ф.-м.н., профессор Московского физико-технического института (технического университета), 
заведующий Центром распределенных вычислений Института проблем передачи информации РАН (г. Москва, Россия)
Баламетов А.Б. – д.т.н., профессор Азербайджанского научно-исследовательского и проектно-изыскательского института 
энергетики (г. Баку, Азербайджан)
Батыршин И.З. – д.т.н., профессор Мексиканского института нефти (г. Мехико, Мексика)
Вагин В.Н. – д.т.н., профессор Национального исследовательского университета «МЭИ» (г. Москва, Россия)
Голенков В.В. – д.т.н., профессор Белорусского государственного университета информатики и радиоэлектроники 
(г. Минск, Беларусь)
Еремеев А.П. – д.т.н., профессор Национального исследовательского университета «МЭИ» (г. Москва, Россия)
Котов А.С. – кандидат наук, ассистент профессора университета Уэйна (штат Мичиган) (г. Детройт, США)
Кузнецов О.П. – д.т.н., профессор Института проблем управления РАН (г. Москва, Россия)
Курейчик В.М. – д.т.н., профессор Инженерно-технологической академии Южного федерального университета 
(г. Таганрог, Россия)
Лисецкий Ю.М. – д.т.н., генеральный директор «S&T Ukraine» (г. Киев, Украина)
Мамросенко К.А. – к.т.н., доцент Московского авиационного института (национального исследовательского университета), 
руководитель Центра визуализации и спутниковых информационных технологий НИИСИ РАН (г. Москва, Россия)
Мейер Б. – доктор наук, профессор, заведующий кафедрой Высшей политехнической школы – ETH (г. Цюрих, Швейцария)
Нгуен Тхань Нги – д.ф.-м.н., профессор, проректор Ханойского открытого университета (г. Ханой, Вьетнам)
Николов Р.В. – доктор наук, профессор Университета библиотековедения и информационных технологий Софии
(г. София, Болгария)
Осипов Г.С. – д.ф.-м.н., профессор, заместитель директора Института системного анализа РАН (г. Москва, Россия)
Палюх Б.В. – д.т.н., профессор Тверского государственного технического университета (г. Тверь, Россия)
Рахманов A.A. – д.т.н., профессор, заместитель генерального директора Концерна «РТИ Системы» (г. Москва, Россия)
Серов В.С. – д.ф.-м.н., профессор Университета прикладных наук Оулу (г. Оулу, Финляндия)
Сотников А.Н. – д.ф.-м.н., профессор, Межведомственный суперкомпьютерный центр РАН (г. Москва, Россия)
Сулейманов Д.Ш. – академик АН Республики Татарстан, д.т.н., профессор Казанского государственного технического 
университета (г. Казань, Республика Татарстан, Россия)
Тарасов В.Б. – к.т.н., доцент Московского государственного технического университета им. Н.Э. Баумана 
(г. Москва, Россия)
Татарникова Т.М. – д.т.н., доцент, профессор Санкт-Петербургского государственного электротехнического университета 
«ЛЭТИ» им. В.И. Ульянова (Ленина) (г. Санкт-Петербург, Россия)
Таратухин В.В. – доктор философии, управляющий директор Европейского исследовательского центра 
в области информационных систем (ERCIS) Вестфальского университета им. Вильгельма (г. Мюнстер, Германия)
Хорошевский В.Ф. – д.т.н., профессор Московского физико-технического института (технического университета) 
(г. Москва, Россия)
Язенин А.В. – д.ф.-м.н., профессор Тверского государственного университета (г. Тверь, Россия)

АССОЦИИРОВАННЫЕ ЧЛЕНЫ РЕДАКЦИИ

Национальный исследовательский университет «МЭИ», г. Москва, Россия
Технологический институт Южного федерального университета, г. Таганрог, Россия
Тверской государственный технический университет, г. Тверь, Россия
Научно-исследовательский институт «Центрпрограммсистем», г. Тверь, Россия

АДРЕС ИЗДАТЕЛЯ И РЕДАКЦИИ 
Россия, 170024, г. Тверь, пр. 50 лет Октября, 3а
Телефон (482-2) 39-91-49
Факс (482-2) 39-91-00
E-mail: red@cps.tver.ru
Сайт: www.swsys.ru

Дата выхода в свет 10.09.2019 г.

Отпечатано ООО ИПП «Фактор и К»

Россия, 170028, г. Тверь, ул. Лукина, д. 4, стр. 1

Выпускается один раз в квартал

Год издания тридцать второй. Формат 6084 1/8. Объем 192 стр.

Заказ № 14. Тираж 1000 экз. Цена 330,00 руб.

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

© SOFTWARE & SYSTEMS 
(PROGRAMMNYE PRODUKTY I SISTEMY)
International research and practice journal

2019, vol. 32, no. 3
DOI: 10.15827/0236-235X.127

Acting Editor-in-chief 

N.A. SEMENOV, Professor TvSTU (Tver, Russian Federation)
Science editors:

A.P. Eremeev, Dr.Sc. (Engineering), Professor MPEI
(Moscow, Russian Federation)
K.А. Mamrosenko, Ph.D. (Engineering), Associate Professor
of Moscow Aviation Institute (National Research University)
(Moscow, Russian Federation)

Publisher Research Institute CENTERPROGRAMSYSTEM 

(Tver, Russian Federation)

The Founders: International Scientific 

and Research Institute for Management Issues 

(Moscow, Russian Federation),

the Chief Editorial Board 

of International Magazine Theoretical and practical issues 

of management (Moscow, Russian Federation),
Research Institute CENTERPROGRAMSYSTEM 

(Tver, Russian Federation)
The magazine is on record 

in Russian committee

on press 26th of June 1995

Registration certificate № 013831

ISSN 0236-235X (print)

ISSN 2311-2735 (online)

INTERNATIONAL EDITORIAL BOARD

Semenov N.A. – Dr.Sc. (Engineering), Professor of Tver State Technical University, Deputy Editor-in-Chief
(Tver, Russian Federation)
Reshetnikov V.N. – Dr.Sc. (Physics and Mathematics), Professor of Moscow Aviation Institute 
(National Research University), Deputy Editor-in-Chief (Mosсow, Russian Federation)
Arefev I.B. – Dr.Sc. (Engineering), Professor of Poland Szczecin Maritime Academy (Szczecin, Poland)
Afanasiev A.P. – Dr.Sc. (Physics and Mathematics), Professor of Moscow Institute of Physics and Technology, 
Head of Centre for Distributed Computing of Institute for Information Transmission Problems 
(Moscow, Russian Federation)
Balametov A.B. – Azerbaijan Scientific-Research & Design-Prospecting Power Engineering Institute (Baku, Azerbaijan)
Batyrshin I.Z. – Dr.Sc. (Engineering), Professor of Mexican Petroleum Institute (Mexico City, Mexico)
Vagin V.N. – Dr.Sc. (Engineering), Professor of National Research University “Moscow Power Engineering Institute”
(Mosсow, Russian Federation)
Golenkov V.V. – Dr.Sc. (Engineering), Professor of Belarusian State University of Informatics and Radioelectronics 
(Minsk, Republic of Belarus)
Eremeev A.P. – Dr.Sc. (Engineering), Professor of National Research University “Moscow Power Engineering Institute”
(Moscow, Russian Federation)
Kotov A.S. – Ph.D. (Computer Science), Assistant Professor, Wayne State University (Detroit, MI, USA)
Kuznetsov O.P. – Dr.Sc. (Engineering), Professor of the Institute of Control Sciences of the Russian Academy 
of Sciences (Moscow, Russian Federation)
Kureichik V.M. – Dr.Sc. (Engineering), Professor of Academy of Engineering and Technology Southern Federal 
University (Taganrog, Russian Federation)
Lisetskiy Yu.M. – Dr.Sc. (Engineering), CEO of S&T Ukraine (Kiev, Ukraine)
Mamrosenko K.A. – Ph.D. (Engineering), Associate Professor of Moscow Aviation Institute (National Research
University), Head of Center of Visualization and Satellite Information Technologies SRISA RAS 
(Moscow, Russian Federation)
Meyer B. – Dr.Sc., Professor, Head of Department in Swiss Federal Institute of Technology in Zurich, ETH 
(Zurich, Switzerland)
Nguyen Thanh Nghi – Dr.Sc. (Physics and Mathematics), Professor, Vice-Principal of Hanoi Open University
(Hanoi, Vietnam)
Nikolov R.V. – Full Professor of the University of Library Studies and Information Technology (Sofia, Bulgaria)
Osipov G.S. – Dr.Sc. (Physics and Mathematics), Professor, Deputy of the Principal of Institute of Systems Analysis 
of the Russian Academy of Sciences (Mosсow, Russian Federation)
Palyukh B.V. – Dr.Sc. (Engineering), Professor of Tver State Technical University (Tver, Russian Federation)
Rakhmanov A.A. – Dr.Sc. (Engineering), Professor, Deputy of the CEO of Concern RTI Systems
(Mosсow, Russian Federation)
Serov V.S. – Dr.Sc. (Physics and Mathematics), Professor of the Oulu University of Applied Sciences (Oulu, Finland)
Sotnikov A.N. – Dr.Sc. (Physics and Mathematics), Professor, Joint Supercomputer Center of the Russian Academy 
of Sciences (Moscow, Russian Federation)
Suleimanov D.Sh. – Academician of TAS, Dr.Sc. (Engineering), Professor of Kazan State Technical University
(Kazan, Republic of Tatarstan, Russian Federation)
Tarassov V.B. – Ph.D. (Engineering), Associate Professor of Bauman Moscow State Technical University
(Mosсow, Russian Federation)
Tatarnikova T.M. – Dr.Sc. (Engineering), Associate Professor, Professor St. Petersburg Electrotechnical University 
"LETI", St. Petersburg, Russian Federation
Taratoukhine V.V. – Ph.D. (Engineering), Dr.Ph., Managing Director of the Competence Centre ERP and ERCIS Lab
Russia of the ERCIS (Muenster, Germany)
Khoroshevsky V.F. – Dr.Sc. (Engineering), Professor of Moscow Institute of Physics and Technology
(Moscow, Russian Federation)
Yazenin A.V. – Dr.Sc. (Physics and Mathematics), Professor of Tver State University (Tver, Russian Federation)

ASSOCIATED EDITORIAL BOARD MEMBERS

National Research University “Moscow Power Engineering Institute”, Moscow, Russian Federation
Technology Institute at Southern Federal University, Taganrog, Russian Federation
Tver State Technical University, Tver, Russian Federation
Research Institute CENTERPROGRAMSYSTEM, Tver, Russian Federation

EDITORIAL BOARD AND PUBLISHER OFFICE ADDRESS 
50 let Oktyabrya Ave. 3а, Tver, 170024, Russian Federation
Phone: (482-2) 39-91-49  Fax: (482-2) 39-91-00
E-mail: red@cps.tver.ru
Website: www.swsys.ru

Release date 10.09.2019

Printed in printing-office “Faktor i K”

Lukina St. 4/1, Tver, 170028, Russian Federation

Published quarterly. 32th year of publication

Format 6084 1/8. Circulation 1000 copies

Prod. order № 14. Wordage 192 pages. Price 330,00 rub. 

Вниманию авторов

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

Решением Президиума Высшей аттестационной комиссии (ВАК) Министерства образования и науки РФ меж
дународный журнал «Программные продукты и системы» внесен в Перечень ведущих рецензируемых научных 
журналов и изданий, в которых должны быть опубликованы основные научные результаты диссертаций на соискание ученых степеней кандидата и доктора наук.

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

Условия публикации

К рассмотрению принимаются оригинальные материалы, отвечающие редакционным требованиям и соответ
ствующие тематике журнала (специализация – информатика, вычислительная техника и управление, отрасли 
науки – 05.13.01; .06; .11; .12; .15; .17; .18).

Работа представляется в электронном виде в формате Word. При обилии сложных формул обязательно наличие 

статьи и в формате PDF. Формулы должны быть набраны в редакторе формул Word (Microsoft Equation или 
MathType). Объем статьи вместе с иллюстрациями – не менее 10 000 знаков. Диаграммы, схемы, графики должны 
быть доступными для редактирования (Word, Visio, Excel). Все иллюстрации для полиграфического воспроизведения представляются в черно-белом варианте. Цветные, тонированные, отсканированные, не подлежащие редактированию средствами Word рисунки и экранные формы следует присылать в хорошем качестве для их дополнительного размещения на сайте журнала в макете статьи с доступом по ссылке. (Публикация материалов с использованием гипертекста, графики, аудио-, видео-, программных средств и др. возможна в электронном издании 
«Программные продукты, системы и алгоритмы», сайт www.swsys-web.ru.) Заголовок должен быть информативным; сокращения, а также терминологию узкой тематики желательно в нем не использовать. Количество авторов 
на одну статью – не более 4, количество статей одного автора в номере, включая соавторство, – не более 2. Список 
литературы, наличие которого обязательно, должен включать не менее 10 пунктов.

Необходимы также содержательная структурированная аннотация (не менее 250 слов), ключевые слова (7–10) 

и индекс УДК. Название статьи, аннотация и ключевые слова должны быть переведены на английский язык (машинный перевод недопустим), а фамилии авторов, названия и юридические адреса организаций (если нет официального перевода), пристатейные списки литературы – транслитерированы по стандарту BGN/PCGN. 

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

Порядок рецензирования

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

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

Рецензирование проводится конфиденциально. Автору статьи предоставляется возможность ознакомиться с 

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

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

проводятся раз в месяц в НИИ «Центрпрограммсистем» (г. Тверь), где принимается решение о целесообразности 
публикации статьи.

Статьи, одобренные редакционным советом, публикуются бесплатно в течение года с момента одобрения, а 

отправленные на доработку – с момента поступления после устранения замечаний.

Редакция международного журнала «Программные продукты и системы» в своей работе руководствуется 

сводом правил Кодекса этики научных публикаций, разработанным и утвержденным Комитетом по этике научных публикаций (Committee on Publication Ethics – COPE).

Программные продукты и системы / Software & Systems
3 (32) 2019

349

УДК 004.9
Дата подачи статьи: 30.01.19

DOI: 10.15827/0236-235X.127.349-357
2019. Т. 32. № 3. С. 349–357

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

в проектах по созданию информационных систем

Р.Д. Гутгарц 1, д.э.н., профессор, gutgarc@gmail.com
Е.И. Провилков 1, аспирант, provilkoff@gmail.com

1 Иркутский национальный исследовательский технический университет (ИРНИТУ), 
г. Иркутск, 664074, Россия

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

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

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

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

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

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

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

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

системам (ИС) весьма разнообразна: функциональные требования, требования к техническому обеспечению, инструментальным средствам программирования и ведения БД, к безопасности и др. Кроме того, в данную тематику 
входит рассмотрение вопросов, которые могут 
обобщать такое понятие, как «управление требованиями», то есть их взаимозависимость, согласование, утверждение, оценку, редактирование и др. И каждый аспект таит в себе множество 
проблем, 
требующих 
отдельного 

анализа. 

С течением времени острота такого рода 

проблем практически не уменьшается, а если и 
становится меньше, то совсем незначительно. 

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

Программные продукты и системы / Software & Systems
3 (32) 2019

350

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

проектируемой системе.

Проблемы при взаимодействии заказчика и 

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

упомянутой 
иллюстрации, 
известная 
под 

названием Бизнес-проект «Качели» [1]. Хотя 
по характеру рисунок является шуточным, он 
отражает принципиально важный аспект в процессе проектирования и разработки ИС: результат выполнения проекта может оказаться 
невостребованным, если в нем не реализована 
нужная заказчику функциональность.

Кроме того, говоря об ИС, часто понимают 

под ней микроИС, например, ИС заказа товаров. Бесспорно, ИС в таком виде имеет право 
на существование. Но, согласно классическому 
представлению системы, она всегда состоит из 
отдельных подсистем (модулей). Модульная 
структура является, например, одной из основополагающих характеристик ERP-систем (систем планирования ресурсов предприятия), 
очень распространенных и востребованных в 
настоящее время. Поэтому процесс рассмотрения требований к ИС, предназначенной для заказа товаров, будет, очевидно, отличаться от 
более крупной ИС, ориентированной, например, на управление каким-либо предприятием 
(организацией) или его отдельным подразделением.

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

Статистические данные за 2008 год, опуб
ликованные компанией Standish Group, свидетельствуют о том, что из 30 тысяч проанализи
рованных программных проектов только 1/3 
(32 %) завершились успешно, почти половина 
проектов (44 %) завершились с проблемами 
(главным образом, превысили бюджет и сроки) 
и почти четверть (24 %) полностью провалились [2]. 

В работе [3] отмечается, что при выявлении 

ошибок в требованиях на стадии начального 
формулирования стоимость их устранения будет в 5–10 раз меньше по сравнению с тем, когда эти требования трансформируются в программный код. Если же по каким-либо причинам ошибки на этих двух стадиях не были 
обнаружены и проявились только при сопровождении готовой к эксплуатации системы, 
стоимость их устранения превысит стоимость 
программирования уже в 20 раз. Авторы особо 
выделяют две категории ошибок, которые обнаруживаются на стадии проектирования:

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

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

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

Фактически формулирование функциональ
ных требований – второй этап в работе с требованиями. Первым этапом будет их выявление. 
Зависимость этапов при формулировании 
функциональных требований к ИС показана на 
рисунке 1.

Приведем несколько мнений о важности 

требований.

В [3] авторы выделяют следующие основ
ные факторы, обусловливающие проблемы в 
будущих проектах по созданию ИС:

–
недостаток исходной информации от 

клиента (13 % проектов);

–
неполные требования и спецификации 

(12 % проектов);

–
изменение требований и спецификаций 

(12 % проектов).

В [4] подчеркивается, что все современные 

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

Программные продукты и системы / Software & Systems
3 (32) 2019

351

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

В [5] утверждается, что от 40 до 60 % всех

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

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

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

В [7] авторы выделяют понятие «хорошие 

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

Подходы к формализации функциональных 

требований при проектировании 

и разработке ИС

Аспекты формализации требований в лите
ратурных источниках рассматриваются крайне 
редко и, как правило, в контексте UMLдиаграмм, например [8]. Но такие графические 
нотации понятны далеко не каждому эксперту 
от заказчика даже при современном уровне 
компьютерной грамотности. Чтобы правильно 
читать специализированные графические интерпретации процессов и технологических особенностей их выполнения в условиях автоматизированной 
реализации,
непосвященных 

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

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

По мнению авторов [9], наличие формали
зации при управлении большими проектами 
(включающими большой объем функциональности) является очень ценным качеством, так 
как позволяет обеспечить его прозрачность.

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

В [9] для упрощения процесса разработки 

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

требований

Нужно редактировать?

Формулирование функциональных 

требований

Обсуждение функциональных 

требований с заказчиком

Редактирование 

требований

Составление спецификаций 

(преобразование формулировок 
требований в формализованные 

конструкции, которые можно 

программировать)

Да

Нет

Рис. 1. Зависимость этапов 

при формулировании функциональных 

требований к ИС

Fig. 1. Dependence of stages when stating

functional requirements for IS

Программные продукты и системы / Software & Systems
3 (32) 2019

352

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

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

Интересный подход к формализации функ
циональных требований изложен в [10]. Автор 
подчеркивает, что представители бизнеса, 
участвующие в процессе формулирования требований, должны уметь изложить их в такой
стилистической и семантической форме, чтобы 
она была понятна как будущим пользователям, 
так и разработчикам. В качестве такого представления предлагаются две модели управления бизнес-требованиями на примере реализации финансового инструмента «Депозит на 
расчетном счете»: 1) для обработки бизнес-требования – B2 «Расчет процентов в зависимости 
от среднемесячной суммы остатка»; 2) 
для обработки требования пользователя – C5 «Отражение фактических выплат в отчете без учета разбора выписки».

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

Другой подход к формализации требований 

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

Эти же авторы приводят примеры схем для 

формулирования требований [6]:

–
Типичное требование, описывающее 

возможность (потребность), то есть <Тип 
пользователя> должен иметь возможность 
<описание возможности>;

–
Требование типа <ограничение>, то 

есть <Тип пользователя> не должен попадать 
под действие <соответствующее законодательство> и <Система> должна <выполняемая функция> не менее чем <количество> 
<объект> функционируя в <условия эксплуатации>;

–
Периодическое ограничение, то есть 

<Система> должна <выполняемая функция> 
<объект> каждые <показатель производительности> <единица измерения>.

Данную схему иллюстрирует рисунок 2.

<Система> должна <Выполняемая функция> 

<объект> каждые <производительность> <единица 

измерения>

Шаблон 34

Требование 347 + Шаблон 34

Требование 348 + Шаблон 34

<система> = кофемашина

<выполняемая функция> = производить

<объект> = горячий напиток

<производительность> = 10
<единица измеренеия> = секунд

<система> = кофемашина

<выполняемая функция> = производить

<объект> = холодный напиток

<производительность> = 5
<единица измеренеия> = секунд

Рис. 2. Глобальные шаблоны

Fig. 2. Global patterns

Программные продукты и системы / Software & Systems
3 (32) 2019

353

Требования к создаваемой ИС также 

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

−
внешние интерфейсы системы (кон
текстная диаграмма, диаграмма вариантов использования, диаграмма потоков данных, макеты отчетов и др.);

−
поток бизнес-процессов (диаграмма по
токов, диаграммы действий и др.);

−
определения данных и связи объектов 

данных
(диаграмма сущность–связь, диа
грамма классов и др.);

−
состояния системы и объектов (диа
граммы переходов состояния, таблицы состояния, таблица событий и реакций, функциональные требования);

−
сложная логика (дерево решений, таб
лица решений);

−
пользовательские интерфейсы
(карта 

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

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

−
нефункциональные требования (атри
буты качества, ограничения).

Для изложения спецификации требований 

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

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

Все перечисленные графические способы 

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

Очень часто специалисты, говоря о требо
ваниях к функциональному ПО, ссылаются 

на [11]. Но, несмотря на то, что в данном документе представлены содержание и характеристики, предоставляющие возможности для составления качественных спецификаций к ПО, 
эта методика не содержит в себе какой-либо 
конкретный метод, терминологическую базу 
или инструментарий для подготовки SRS 
(Software Requirements Specification) [11]. 
В этом же документе говорится об языках спецификаций требований, которые позволят нивелировать неоднозначности, характерные для 
естественного языка. При этом отмечаются 
длительность их изучения и остающаяся непонятность для неподготовленных пользователей.

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

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

2. Принципиальные идеи представления и 

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

3. Отдельно рассматриваются требования к 

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

4. Существуют несколько уровней работы 

с требованиями:

−
выявление требований (сбор первичной 

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

−
структурное преобразование первичной 

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

−
формирование функциональной состав
ляющей ИТ-проекта по созданию функционального ПО;

−
составление спецификаций (описание 

постановок задач), являющихся основой для 
программирования.

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