Что такое управление требованиями?

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

Требование - это:

Условие или возможность, которым должна соответствовать система.

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

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

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

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

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

Что нужно для того, чтобы справиться с этими сложностями? По нашему опыту, важны следующие навыки:

• Анализ сложностей
• Понимание потребностей заинтересованных лиц
• Определение системы
• Управление содержанием проекта
• Уточнение определения системы
• Управление изменением требований

Анализ сложностей

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

См. также Операция: анализ сложностей.

Понимание потребностей заинтересованных лиц

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

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

См. также Операция: понимание потребностей заинтересованных лиц.

Определение системы

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

См. также Операция: определение системы.

Управление содержанием проекта

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

См. также Операция: управление содержанием системы.

Уточнение определения системы

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

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

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

См. также Операция: уточнение определения системы.

Управление изменением требований

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

См. также Операция: управление изменением требований.

Дополнительная информация

Дополнительные сведения по данному вопросу можно найти в следующих источниках:

Концепция: требования
Концепция: типы требований
Концепция: прослеживаемость
Информационный бюллетень: Управление требованиями на основе вариантов использования