Первое упоминание компьютерной программе было сделано практически век назад и датировано еще далеким 1833 годом. С тем пор были изобретены множество языков программирования, начиная от машинных и до современных C++, Java, Python. Постепенно понимание и сложность компьютерных программ менялось: если ранее максимальное внимание уделялось алгоритму, то сейчас в комплексных программных приложениях, акцент смещается в сторону данных. Изобретены множество прикладных методов внедрения информационных систем, которые по существу являются производными от трех классических моделей имплементации. Однако, неоспоримым является тот факт, что любая программа в первую очередь должна покрывать исходные потребности пользователей. Данная истина зачастую теряется рутинных активностях разработки приложений и их внедрения.
Множество литературных источников описывают подходы и методы анализа бизнес-требований [1-3], забывая то, что они не могут «жить» независимо. Требования являются важным элементом жизненного цикла программного обеспечения, именно с их формулирования начинается проработка концепции будущего программного продукта. Механизмы теории дизайн-мышления помогают сформулировать требования, если изначально пользователи не могут их озвучить. Получается, что требования – отправная точка разработки любого софтверного продукта, чем качественнее ведется их обработка, тем более управляемым становится проект реализации приложения.
Цель данной работы состоит в анализе жизненного цикла требований к программным продуктам для обеспечения эффективного внедрения коробочных ERP-решений в приемлемые сроки, с заданным уровнем качества и фиксированными затратами. Достижение указанной цели потребует реализации следующих задач:
определение требований, их видов и категорий;
обзор жизненного цикла программного продукта и требований к нему;
анализ ключевых этапов работы над требованиями.
Требования и их виды
Для начала введем ключевое определение, которым мы будем пользоваться на протяжении всей статьи.
Определение 1. Требование – это спецификация того, что должно быть реализовано. Требования описывают поведение, свойства и атрибуты программной системы, служат ограничениями в ходе разработки приложения.
В [1] выделяют различные виды требований, описывающих поведение системы:
бизнес-требования, задающие высокоуровневые бизнес-цели организации и/или заказчика системы;
пользовательские требования, характеризуют задачи, которые определенные классы пользователей должны иметь возможность выполнять в программе;
системные требования, относящиеся к верхнеуровневым техническим требованиям к продукту;
и, наконец, функциональные требования, задающие необходимое поведение системы в определенных условиях;
а также выделяют требования, относящиеся к свойствам программной системы:
нефункциональные, в рамках которых ведется описание особенностей, которыми должно обладать приложение, характеристик сервиса и/или производительности продукта.
Стоит отметить, что ранее термин нефункционального требования относился исключительно к программному продукту, теперь же он носит более общий характер: нефункциональные требования могут предъявляться к проекту, персоналу, программной платформе и др.
Этапы обработки и управления требованиями
Работа над требованиями состоит из набора этапов, коррелирующих с жизненным циклом программного обеспечения (рис. 1):
выявление требований, где определяются классы пользователей, формируются фокус-группы, проводится работа с пользователями для определения задач, которые должны быть автоматизированы разрабатываемым приложением, ведутся совместные семинары ��о выявлению требований;
анализ требований, здесь осуществляется очистка требований, устраняются их ошибки и недостатки, проверяется реализуемость требований, выполняется их приоритизация;
документирование требований, что подразумевает запись требований в документ спецификации требований к ПО, присвоение уникальных идентификаторов требованиям, а также формирование матрицы отслеживания требований;
утверждение, рецензирование и согласование требований;
управление требованиями, где задается порядок управления изменениями требований и версиями требований.
Далее мы рассмотрим каждый из этапов более подробно.
Этап выявлений требований
Этап по выявлению требований позволяет идентифицировать бизнес-потребности организации и включает следующие группы задач:
подготовка к выявлению требований;
выявление требований;
активности после выявления требований.
Подготовка к выявлению требований
Подготовка начинается с определения пользователей продукта, являющихся подмножеством стейкхолдеров или заинтересованных лиц проекта. Пользователей продукта можно сгруппировать по различным признакам, например, по:
привилегиям доступа;
используемым функциям системы;
географии;
частоте применения продукта;
орг��низационной структуре компании и др.
На практике определение классов пользователей преимущественно осуществляется на основе организационной структуру предприятия. Чтобы снизить нагрузку на всех бизнес-пользователей, из каждого класса выбираются не все, а только ключевые пользователи. Ключевые пользователи являются единой точкой контакта с остальными сотрудниками компании.
Уточнение состава ключевых пользователей в дальнейшем ведется с использованием карты бизнес-процессов. Термин карты процессов присущ каскадным методологиям внедрения программных продуктов, в то время как в итерационных и спиралевидных моделях применяется понятие вариантов использования. Используя типовую карту процессов или же руководствуясь картой процессов заказчика, определяется владелец процесса обычно из числа ключевых пользователей, а также прочие вовлеченные сотрудники (рис. 2).
Важность карты процессов состоит в том, что именно она применяется для планирования сессий обсуждения и выявления требований с ключевыми пользователями в разрезе каждого бизнес-процесса 3-го или 4-го уровней детализации. План-график семинаров так же должен включать встречи по обсуждению интеграционных топиков, а также открытых вопросов.
Ситуация сжатых сроков проекта диктует свои условия: вынужденной мерой является необходимость вести часть встреч параллельно, хотя в идеальных условия лучше их проводить последовательно, так как часть ключевых пользователей должны присутствовать на всех рабочих встречах. Подготовленный план согласуется с руководителем проекта со стороны заказчика.
Заключительным шагом подготовки к проведению сессий выявления требований служит установочная встреча с ключевыми пользователями, на которой им будет рассказан подход к сбору требований, а также показан предварительный план работ.
Выявление и сбор требований
Сбор требований ведется согласно сформированному плану-графику семинаров. Предварительно проектная команда готовит карту процессов и список вопросов. Хорошо зарекомендовавшими подходами, упрощающими сбор требований служат:
использование прототипа и/или показ демо-базы программной системы. Прототип демонстрирует ключевые возможности системы пользователям, что позволяет им высказать предложения и указать на недостатки, которые впоследствии оформляются в виде уточненных требований к программному продукту. Основная цель прототипирования заключается в устранении неопределенностей путем проверки различных гипотез и итеративного уточнения требований. В зависимости от типа прототипа, который может быть эволюционным (предназначенным для дальнейшего развития до готового продукта) или одноразовым (используемым для проверки гипотез и последующего удаления), определяется необходимость его дальнейшего использования или уничтожения. Если прототип программной системы обычно подразумевает доработку приложения, то показ демо-базы, напротив, ведется исключительно с целью отражения работы стандартного коробочного решения.
демонстрация копий экранов существующей программы, подразумевающая показ исключительно иллюстраций и рисунков работы приложения. Применяется как альтернатива прототипам и демо-базам в условиях ограниченных технический возможностей;
активности которых ведутся в ходе семинаров для типовых и/или наиболее критичных бизнес-потребностей ...
Литературный источник, полный текст статьи
Демьянов Н.А. Требования к программному обеспечению: от подготовки до управления изменениями (часть 1) // Корпоративные информационные системы. – 2024. – №1 (25) – С. 16-22. – URL: https://corpinfosys.ru/archive/2024/issue-25/271-2024-25-requirements.
