О ключевой роли управления требованиями в процессе создания нового продукта

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

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

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

идентификация требований;

выявление требований;

документация требований;

анализ требований;

отслеживание требований;

приоритезация требований;

достижение соглашения по требованиям;

управление изменениями;

уведомление соответствующих заинтересованных лиц.

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

На каждом этапе процесса разработки проекта существуют ключевые методы и задачи, связанные с управлением требованиями. Чтобы было более или менее понятно,  как это всё работает, рассмотрим стандартный процесс реализации проекта, с пятью фазами: исследованием, анализом осуществимости, дизайном, разработкой и тестированием и выпуском.

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

На стадии анализа осуществимости определяется стоимость требований. Задаются такие вопросы, как: «Сколько нам сейчас стоят ошибки ввода данных?», «Какова стоимость потери данных из-за ошибки оператора связанной с используемым интерфейсом?». Подобные вопросы очень важны. Группа должна определить, будет ли новый автоматизированный инструмент иметь достаточную эффективность, чтобы доверить системе операции, проводимые человеком. Результатом стадии анализа осуществимости является бюджет и график проекта.

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

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

Управление требованиями не заканчивается выпуском продукта. С этого момента полученные данные о приемлемости приложения собираются и используются во время фазы исследования для следующего поколения системы или выпуска. Таким образом, процесс начинается снова.

Ошибки в управлении требованиями являются основной причиной неудач очень многих проектов. Несмотря на это, в России эти технологии практически не используются. И напрасно. Живой пример – широко распиаренный самолёт Sukhoi Superjet 100 (SSJ 100), после испытаний которого стало ясно, что заявленные характеристики машины далеки от полученных в итоге результатов – «чтобы достигнуть рекламных «98 пассажиров на 4420 км», надо массу конструкции самолета 97003 сократить на 3600кг, а максимальную взлетную массу при этом увеличить на 5 тонн. Это, как говорится, из области фантастики». (Подробнее здесь: http://www.aex.ru/docs/3/2009/8/25/791/). Кроме того, что проект не оправдал ожиданий в техническом плане, он также не внушает доверия с экономической стороны. По мнению независимых экспертов, прямые государственные вложения в SSJ 100 на данный момент составили около 3,5 миллиардов долларов США. И это – по минимуму. Плюс возможная ремоторизация и доработки, испытания (минимум миллиард долларов), а также тот факт, что заказчиком SSJ 100 пока что выступает только «Армавиа»… Очевидно, что, если бы некорректные требования к проекту были определены и исправлены в начале работы, возможно было бы избежать технических и прочих проблем, для решения которых сейчас требуются большие затраты и дополнительное время.

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