The Process of Justifying and Developing the Requirements for a Software System that Will Support the Organisation’s Activities

Full Text

ВВЕДЕНИЕ

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

Имеется три иерархических уровня: бизнес-требования; пользовательские требования; функциональные и нефункциональные требования [2].

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

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

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

АКТУАЛЬНОСТЬ И МЕТОДЫ ИССЛЕДОВАНИЯ

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

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

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

Бизнес-цели:

• увеличение прибыли за счет сокращения времени обслуживания одного клиента на заправочной станции на 45% в течение трех месяцев после первого выпуска системы;
• сокращение расходов автозаправочной станции на 20% в течение шести месяцев после первого выпуска системы;
• достижение лидерства автозаправочной станции в течении двух лет после первого выпуска системы.

Критерии успеха:

• увеличение количества обслуженных клиентов за день на 30% в течение трех месяцев и на 45% в течение шести месяцев после первого выпуска системы;
• повышение доходности автозаправочной станции до 40%.

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

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

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

 

Таблица 1. Состав первого и последующих выходов программной системы [Composition of the first and subsequent outputs of the software system]

Действия [Actions]	Выпуск 1 [Issue 1]	Выпуск 2 [Issue 2]	Выпуск 3 [Issue 3]
Реализация основных функций [Implementation of basic functions]	Реализация основных функций [Implementation of basic functions]	Устранены недочеты в реализации основных функций. Реализованы дополнительные функции [Shortcomings in the implementation of basic functions have been eliminated. Additional functions implemented]	Расширение функционала, устранение ошибок [Expansion of functionality, troubleshooting]
Реализация интерфейсов [Implementing interfaces]	Реализация интерфейсов для веб-приложения [Implementing interfaces for a web application]	Реализация интерфейсов для мобильного приложения [Implementation of interfaces for a mobile application]	Развитие интерфейсов под добавляемый функционал [Development of interfaces for added functionality]
Реализация программы лояльности [Implementation of the loyalty program]	Реализация сбора метрик программы лояльности и ее запуск [Implementation of collecting loyalty program metrics and launching it]	Анализ эффективности и корректировка программы лояльности [Analysis of effectiveness and adjustment of the loyalty program]	Анализ эффективности и корректировка программы лояльности [Analysis of effectiveness and adjustment of the loyalty program]

 

ОСОБЕННОСТИ РАЗВЕРТЫВАНИЯ

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

Подробно разберем бизнес-процессы автозаправочной деятельности на структурно-функциональной модели. Многие исследователи подчеркивают преимущества структурно-функционального подхода к моделированию бизнес-процессов компании [7; 8]. Для этого лучше всего использовать диаграммы в нотации IDEF0, поскольку считается наиболее удобной для их подробного изучения и анализа в контексте системного подхода (рис. 1, 2). Цель моделирования – проведение анализа бизнес-процесса «как есть», выявление недостатков и уязвимостей в функционировании системы, выработка контрмер для устранения недостатков и построение модели «как должно быть» с учетом контрмер.

 

Рис. 1. Контекстная диаграмма автозаправочной деятельности в состоянии «as is»

Fig. 1. Contextual diagram of gas station activity in the “as is” state

 

В контекстной диаграмме описывается бизнес- процесс в общем [9–11].

На входе:

• заказ клиента;
• информация о топливе;
• само топливо в резервуаре;
• незаправленный автомобиль.

На выходе:

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

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

В управлении:

• нормативно-правовые документы;
• ГОСТ 58404;
• регламент работы АЗС.

Контекстная диаграмма была декомпозирована на три подпроцесса (см. рис. 2):

• «Определение нужной колонки с топливом»;
• «Оплата выбранного топлива»;
• «Заправка автомобиля».

Основные недостатки существующих бизнес-процессов и предлагаемые контрмеры отражены в табл. 2.

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

 

Рис. 2. Диаграмма декомпозиции автозаправочной деятельности в состоянии «as is»

Fig. 2. Decomposition diagram of gas station activities in the “as is” state

 

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

Для устранения выявленных недостатков и уязвимостей с учетом проектируемого приложения, нам необходимо внести изменения в подпроцессы и отразить эти изменения в диаграмме «to be» (рис. 3, 4). Измененные подпроцессы отражены на декомпозированной диаграмме (рис. 4).

Из рис. 4 видно, что в управлении появилась инструкция по работе с программной системой, а в механизмах сама программная система. Роли кассира и диспетчера выпали из механизмов. Все подпроцессы автоматизированы, кроме механического исполнения. Добавился подпроцесс «Удаленное резервирование топлива», также определение колонки и оплата происходят с помощью программной системы.

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

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

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

Далее опишем некоторые функциональные требования к программной системе.

 

Рис. 3. Процесс «Автозаправочная деятельность» в состоянии «to bi»

Fig. 3. The process of “Refueling activity” in the “to bi” state

 

Рис. 4. Подпроцессы процесса «Автозаправочная деятельность» в состоянии «to bi»

Fig. 4. Subprocesses of the “gas station activity” process in the “to bi” state

 

Таблица 2. Выявленные недостатки в существующих бизнес-процессах и предлагаемые контрмеры [Identified shortcomings in existing business processes and proposed countermeasures]

Недостатки существующих бизнес-процессов [Disadvantages of existing business processes]	Предлагаемые контрмеры [Suggested Countermeasures]
Продолжительный по времени период (увеличенное время) обслуживания одного автомобиля [Long period (extended time) of servicing one car]	Предварительное бронирование нужного количества имеющегося в наличии вида топлива, предварительное бронирование определенной колонки с нужным видом топлива, приглашение заправщика к колонке к определенному времени, онлайн оплата через приложение [Pre-booking the required amount of available type of fuel, pre-booking a specific pump with the required type of fuel, inviting a tanker to the pump at a certain time, online payment through the application]
Образование очередей и утечка клиентов из-за длинных очередей [Formation of queues and loss of customers due to long queues]	Определение количества машин в очереди к определенной колонке [Determining the number of cars in queue for a specific column]
Отсутствие возможности предварительного резервирования топлива на случай его продажи и исчерпания запасов к моменту подачи машины к колонке [No possibility of pre-reserving fuel in case it is sold and reserves are exhausted by the time the vehicle is delivered to the pump]	Предварительное резервирование топлива через приложение [Pre-booking fuel via the app]
Отсутствие возможности учета постоянных покупателей и скидок для клиентов [Lack of ability to take into account regular customers and discounts for customers]	Создание программы лояльности и купонов для клиентов через приложение [Creating a loyalty program and coupons for customers through the application]
Отсутствие возможности узнать о качестве топлива [Inability to find out about fuel quality]	Обеспечение возможности написания отзывов о топливе и просмотра чужих отзывов [Providing the ability to write reviews about fuel and view other people’s reviews]
Большие расходы руководства АЗС на оплату зарплаты кассирам [Large expenses of gas station management to pay salaries to cashiers]	Сокращение кассиров за счет онлайн оплаты [Reduction of cashiers due to online payment]

 

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

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

• Безопасность. Не допускается утечка конфиденциальных данных сотрудников и пользователей (клиентов). Системе необходимо обладать защитой от различных видов взлома и других атак. Система должна предупреждать пользователя о попытках взлома или кражи данных третьей стороной.
• Доступность. Система должны быть доступна и успешно поддерживаться 90% существующими на данный момент мобильными устройствами.
• Надежность. Допускается незначительная потеря пакетов при отправке или получении данных от сервера. Потерянные пакеты не должна превышать 0,8% от общего числа отправленных/полученных пакетов.
• Устойчивость. Система должна быть устойчива к множественным запросам со стороны клиента. При возникновении сбоя какая-либо потеря данных не допускается.
• Эффективность. Система должна потреблять не более 15% ресурсов процессора, доступных для мобильного приложения. Система обязана предупреждать пользователя в случае, если нагрузка на устройство достигнет 80% максимальной плановой загрузки.
• Простота использования. Интерфейс приложения должен быть удобен для пользователя. Использование приложения не должно быть сложным, пользователю необходимо предоставить возможность быстро сориентироваться в интерфейсе приложения

Описание ограничений к программной системе:

• при проектировании приложения рекомендуется использовать паттерн mvvm;
• программная система во время эксплуатации не должна нарушать какие-либо нормативно-правовые акты, предусмотренные законодательством;
• приложение должно быть реализовано на достаточном теоретическом уровне.

ЗАКЛЮЧЕНИЕ

Итогом исследования стали определенные спецификации требований к программной системе (мобильному и веб-приложению) для формирования технического задания. Постоянное взаимодействие с заказчиком и конечными пользователями позволило избежать проблем, связанных с разработкой требований. На всех этапах разработки требований для однозначного понимания пользовательских требований активно использовались модели анализа и проектирования. Это позволило выявить некорректные, избыточные и недостающие требования. Собранные требования успешно утверждены, соглашение о требованиях достигнуто. Менеджер проекта со стороны заказчика подтвердил, что все требования починены бизнес-цели. Разработанные требования позволят создать систему, которая способна сократить время заправки одного транспортного средства на 40%, увеличить количество обслуженных клиентов за день на 45% в течение шести месяцев после первого выпуска системы, увеличить прибыль за счет этого на 45% в течение трех месяцев после первого выпуска системы, сократить расходы автозаправочной станции на 20% в течение 6 месяцев после первого выпуска системы, достигнуть лидерство автозаправочной станции в течении 2 лет после первого выпуска системы.

¹ 7 приложений, которые помогут заправиться, не выходя из машины // Тинькофф журнал. 2021. № 8. URL: https://journal.tinkoff.ru/short/azs-online.

About the authors

Yuliya A. Lezhnina

MIREA – Russian Technological University

Author for correspondence.
Email: Lejninau@mail.ru
ORCID iD: 0000-0002-7801-0327
Scopus Author ID: 55905550600
ResearcherId: B-9409-2014

Cand. Sci. (Eng.); associate professor, Department of Industrial Programming, Institute of Advanced Technologies and Industrial Programming

Russian Federation, Moscow

Khamida G. Akhmedova

MIREA – Russian Technological University

Email: h.ahmedova@mail.ru
ORCID iD: 0000-0003-2442-9955

Cand. Sci. (Eng.); associate professor, Department of Industrial Programming, Institute of Information Technologies

Russian Federation, Moscow

References

Supplementary files