Продолжаем изучение по работе с требованиями по Карлу Вигерсу. В этой статье рассмотрим разработку и управление требованиями.

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

Составные части предмета разработки технических условий

Разработка требований

Разработка технических условий по Вигерсу подразделяется на:

1. выявления

2. анализ

3. документирование

4. утверждение

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

Выявление и сбор требований охватывает все действия, связанные с выявлением требований, например:

1. интервью,

2. совещания,

3. анализ документов,

4. создание прототипов

5. и другие

Ключевые действия по выявлению требований:

1. определение классов ожидаемых пользователей продукта и других заинтересованных лиц

2. понимание задач и целей, а также бизнес-целей которым соответствуют эти задачи

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

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

Возникает вопрос: "На что ориентироваться: на использование или на продут?"

Вигерс дает следующий ответ

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

Анализ

Анализ требований подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде.

Также, Вигерс приводит основные действия по анализу требований:

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

• разложение высокоуровневых требований до нужного уровня детализации;

• выведение функциональных требований из информации других требований;

• понимание относительной важности атрибутов качества;

• распределение требований по компонентам ПО, определенным в системной архитектуре;

• согласование приоритетов реализации;

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

Документирование

Под документированием требований подразумевается хранение и отображение полученной информации по требованиям в структурированном виде.

Действия по документированию:

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

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

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

Действия по утверждению требований:

• выверка задокументированных требований для устранения всех недостатков до принятия требований группой разработки,

• подготовка приемочных тестов и критериев приемки.

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

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

Действия по управлению требованиями:

• определение основной версии требования. В рамках данного действия фиксируются и утверждаются требования с основными заинтересованными лицами для выпуска конкретного продукта или итерации разработки (спринта)

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

• обновление плана проекта в соответствии с планируемыми изменениями,

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

• определение отношений и зависимостей между требованиями (если они есть),

• отслеживание отдельных требований до их проектирования, исходного кода и тестов. В рамках данного действия выстраивается система по трассировке требований,

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

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

Итого

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