Требования к программному обеспечению: от подготовки до управления изменениями (часть 1)

Подробности

Опубликовано: 31.03.2024 10:25

Автор: Демьянов Никита Алексеевич

Просмотров: 96

Аннотация: в работе ведется анализ обработки требований к программному продукту. Рассматривается жизненный цикл требований к приложениям, включающий этапы выявления и сбора требований, анализа и документирования, а также управления изменениями требований. Выполняется обзор видов требований, детально рассматривается этап выявления требований, включающий шаги подготовки и сбора требований, а также протоколирования результатов.
Скачать: PDF (статья), PDF (выпуск №25).
Ключевые слова: требования предъявляемые к по, требования к по, вигерс требования к программному обеспечению, требования к программному обеспечению системы, технические требования к программному обеспечению, какие требования к программному обеспечению, сбор и анализ требований к по, формирование и анализ требований к по, цели анализа требований к по, анализ требования к по, требования к разработке по, порядок разработки требований к по, этапы разработки требований к по, выявление и сбор требований. 

Первое упоминание компьютерной программе было сделано практически век назад и датировано еще далеким 1833 годом. С тем пор были изобретены множество языков программирования, начиная от машинных и до современных C++, Java, Python. Постепенно понимание и сложность компьютерных программ менялось: если ранее максимальное внимание уделялось алгоритму, то сейчас в комплексных программных приложениях, акцент смещается в сторону данных. Изобретены множество прикладных методов внедрения информационных систем, которые по существу являются производными от трех классических моделей имплементации. Однако, неоспоримым является тот факт, что любая программа в первую очередь должна покрывать исходные потребности пользователей. Данная истина зачастую теряется рутинных активностях разработки приложений и их внедрения.

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

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

• определение требований, их видов и категорий;
• обзор жизненного цикла программного продукта и требований к нему;
• анализ ключевых этапов работы над требованиями.

1. Требования и их виды

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

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

В [1] выделяют различные виды требований, описывающих поведение системы:

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

а также выделяют требования, относящиеся к свойствам программной системы:

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

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

2. Этапы обработки и управления требованиями

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

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

Далее мы рассмотрим каждый из этапов более подробно.

Рис. 1. Этапы работы над требованиями

3. Этап выявлений требований

Этап по выявлению требований позволяет идентифицировать бизнес-потребности организации и включает следующие группы задач:

• подготовка к выявлению требований;
• выявление требований;
• активности после выявления требований.

3.1. Подготовка к выявлению требований

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

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

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

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

Рис. 2. Карта процессов и определение состава стейкхолдеров

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

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

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

3.2. Выявление и сбор требований

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

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

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

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

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

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

3.3. Активности после выявления требований

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

Литература

1. Вигерс К., Битти Д. Разработка требований к программному обеспечению. – М.: Издательство Русская редакция, 2017. – 736 с.
2. Бубнов А.А., Бубнов С.А., Майков К.А. Разработка и анализ требований к программному обеспечению – М.: Курс, 2023. – 176 с.
3. Терентьев И.М. Стратегия анализа в проектах внедрения ERP-систем // Корпоративные информационные системы. – 2018. – №2 – с. 23-29. – URL: https://corpinfosys.ru/archive/issue-2/139-2018-2-analysisstrategy.

Выходные данные статьи

Демьянов Н.А. Требования к программному обеспечению: от подготовки до управления изменениями (часть 1) // Корпоративные информационные системы. – 2024. – №1 (25) – С. 16-22. – URL: https://corpinfosys.ru/archive/2024/issue-25/271-2024-25-requirements.

Об авторе

Демьянов Никита Алексеевич – выпускник кафедры корпоративных информационных систем института информационных технологий РТУ МИРЭА. Тема выпускной квалификационной работы магистра «Принципы и подходы внедрения новых компонентов в систему управления складом». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

Статьи выпуска №25

1. Жизненный цикл корпоративных информационных систем (часть 2);
2. ФСБУ и ПБУ как база модуля «Бухгалтерский учет» в КИС предприятия;
3. Требования к программному обеспечению (часть 1).