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

Подробности

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

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

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

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

4. Анализ требований

Ссылка на 1-ю часть статьи. Запротоколированные требования служат источником проведения дальнейшего анализа. Для чего над ними проделываются следующие операции:

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

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

• трехуровневая шкала приоритетов;
• MoSCoW;
• на основе ценности, стоимости и рисков.

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

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

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

5. Документирование требований

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

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

Определение 2. Спецификация требований (Software Requirement Specification, SRS) содержит детальное описание потребностей, понятное как бизнес-пользователям, так и техническим специалистам.

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

Определение 3. Матрица отслеживания требований (Requirement Traceability Matrix, RTL) представляет собой список верхнеуровневых требований, обогащенный информацией по:

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

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

Рис. 3. Пример матрицы отслеживания требований

6. Утверждение требований

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

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

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

7. Управление требованиями 

Утвержденные требования подлежат дальнейшей реализации в программном продукте. Реализация требований может потребовать донастройку и/или доработку программной системы, в редких случаях бизнес-потребности уже покрываются стандартным функционалом системы. Более детально о процедуре Fit/Gap-анализа требований для выявления областей покрытия и функциональных разрывов, а также работы по RICEF-классификации разработок даны в работах [3-4]. Вне зависимости от того, каким способом реализуется требование в софтверном продукте, шаги работы над ним включат стандартные этапы классической каскадной методологии внедрения:

• проектирование;
• настройка и разработка.
• тестирование;
• подготовка и гиперподдержка продуктивной эксплуатации,

а также, следуя пост-проекту имплементации,

• поддержка продуктивной эксплуатации.

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

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

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

Определение 4. Новое требование – это требование, порождающее обработку нового объекта данных, необходимость в котором отсутствовала в описании исходной потребности.

Подобные требования так же называют запросами на изменение (ЗНИ, Change Request, CR). Примером нового пользовательского требования служит автоматическое создание документа поступления из заказа на закупку, если о необходимости формирования поступления до этого не заявлялось. Обработка новых потребностей ведется по согласованной процедуре управления изменениями, для чего формируется документ запроса на изменение, который проходит дополнительное подтверждение, выделение бюджета и мобилизацию команды ответственных исполнителей (рис. 4). Реализация ЗНИ ведется в рамках отдельного подпроекта, сопоставимого по задачам с проектом внедрения программного продукта: новые требования описываются в спецификации требований, после предварительной регистрации в матрице отслеживания.

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

Рис. 4. Структура запроса на изменение

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

Рис. 5. Элементы управления требованиями

Заключение

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

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

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

Литература

1. Вигерс К., Битти Д. Разработка требований к программному обеспечению. – М.: Издательство Русская редакция, 2017. – 736 с.
2. Бубнов А.А., Бубнов С.А., Майков К.А. Разработка и анализ требований к программному обеспечению – М.: Курс, 2023. – 176 с.
3. Терентьев И.М. Стратегия анализа в проектах внедрения ERP-систем // Корпоративные информационные системы. – 2018. – №2 – с. 23-29. – URL: https://corpinfosys.ru/archive/issue-2/139-2018-2-analysisstrategy.
4. Катасонова Н.С. RICEFS-классификация разработок и настроек для оценки трудозатрат // Корпоративные информационные системы. – 2023. – №4 (24) – c. 26-37. – URL: https://corpinfosys.ru/archive/2023/issue-24/230-2023-24-ricefclassification.
5. Степанов Д.Ю. Жизненный цикл корпоративных информационных систем: от бизнес-кейса до прекращения промышленной эксплуатации (часть 1) // Корпоративные информационные системы. – 2023. – №4 (24) – c. 16-25. – URL: https://corpinfosys.ru/archive/2023/issue-24/229-2023-24-erplifecycle.

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

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

Об авторе

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

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

1. ФСБУ 28/2023 и 4/2023 в 2025 году: нововведения и адаптация КИС предприятия;
2. Требования к программному обеспечению (часть 2).