• Условие или возможность, необходимая пользователю для решения проблемы или достижения цели.
• Условие или возможность, необходимая для обеспечения системой или компонентом системы соответствия контракту, стандарту, спецификации или другому формализованному документу.
• Документ, описывающий возможности системы и/или спецификация функций системы.
Ключевыми моментами в данных определениях является, то, что требования содержат спецификацию необходимых возможностей, но не привязаны к реализации и основным источником требований являются пользователи системы.
Однако практическая польза от данного определения невелика, так как из него недостаточно ясно как же получать, обрабатывать и применять требования в процессе создания ПО. Попробуем очертить круг наиболее часто задаваемых вопросов относительно управления требованиями и затем ответить на них.
Роль и место требований в методологии разработки ПО. Виды требований.
Независимо от выбранной методологии разработки, можно выделить следующие этапы жизненного цикла ПО:.
1.
Анализ рынка, технико-экономическое обоснование проекта.
2.
Сбор и анализ бизнес требований к ПО.
3.
Проектирование архитектуры системы.
4.
Кодирование.
5.
Тестирование.
6.
Развертывание.
7.
Эксплуатация и обслуживание.
Наиболее активно интенсивно управление требованиями осуществляется на этапах 2 и 3, менее активно на этапах 4-5.
Общая классификация требований приведена на рис. 1.
Требования можно разделить на две большие категории: функциональные и нефункциональные.
Функциональные требования описывают, что именно должно делать разрабатываемое ПО. Нефункциональные требования содержат описание таких характеристик, как качество, соответствие стандартам и корпоративным правилам.
В свою очередь функциональные требования делятся на три основных группы:.
• Бизнес требования.
• Пользовательские требования.
• Функциональные требования
Бизнес требования описывают пожелания пользователей с точки зрения задач бизнеса. Примеры бизнес требований:.
• Ускорение обработки заказов на 30 %.
• Снижение издержек ведения бухгалтерии на 200 тыс. рублей в год.
Источником бизнес требований, как правило, является отдел маркетинга и высшее руководство. Бизнес требования описывают критерии успешности проекта с точки зрения спонсоров проекта. Бизнес требования являются требованиями высшего уровня, остальные требования подчинены им.
Пользовательские требования отражают пожелания непосредственных пользователей системы. Хорошей практикой является оформление пользовательских требований в виде вариантов использования (use cases). Работе с пользовательскими требованиями следует уделять пристальное внимание, так как мнение о системе, сложившееся у непосредственных пользователей является ключевым фактором успешности внедрения и эксплуатации системы.
Самый нижний уровень требований - это функциональные требования. Данный вид требований детально описывает функции, которые должно выполнять ПО для удовлетворения пользовательских требований. Функциональные требования фактически являются заданиями для архитекторов и программистов.
К нефункциональным требованиям, относят:.
1.
Бизнес правила. Набор принятых приемов организации бизнес процессов, которые должны быть учтены при разработке ПО.
2.
Quality Attributes - атрибуты качества. Чаще всего это характеристики надежности отказоустойчивости системы.
3.
Внешние интерфейсы. Набор программных интерфейсов, которые необходимо реализовать для интеграции в существующую в организации среду программных средств.
4.
Ограничения. Законодательные и другие ограничения накладываемые на создаваемое ПО.
Каким образом формируются требования?.
В данном разделе мы подробно рассмотрим основные этапы создания требований. Основные этапы создания требований включают:.
• Первичный сбор требований.
• Разработка и анализ требований.
• Управление изменениями требований