Продолжаем изучение по работе с требованиями по Карлу Вигерсу. В этой статье рассмотрим разработку и управление требованиями.
Согласно Вигерсу более полезным будет разделение области разработки технических условий на разработку требований и управление требованиями. Также, необходимо учесть, что независимо от методологии проекта - водопадная, поэтапная, итеративная, гибкая или смешанная - есть вещи, которые надо выполнить в отношении всех требований. Однако, в зависимости от методологии эти операции могут выполняться в разное время жизненного цикла проекта и с разным уровнем глубины и детализации.
Составные части предмета разработки технических условий
Разработка требований
Разработка технических условий по Вигерсу подразделяется на:
выявления
анализ
документирование
утверждение
Выявление и сбор требований
Выявление и сбор требований охватывает все действия, связанные с выявлением требований, например:
интервью,
совещания,
анализ документов,
создание прототипов
и другие
Ключевые действия по выявлению требований:
определение классов ожидаемых пользователей продукта и других заинтересованных лиц
понимание задач и целей, а также бизнес-целей которым соответствуют эти задачи
изучение среды, в которой будет использоваться новый продукт
работа с отдельными людьми, которые представляют каждый класс пользователей, чтобы понять их потребности и ожидания в отношении качества
Возникает вопрос: "На что ориентироваться: на использование или на продут?"
Вигерс дает следующий ответ
При сборе требований обычно используется подход, ориентированный на использование, или подход, ориентированный на продукт, хотя возможны и другие стратегии. В ориентированном на использование подходе упор делается на понимание и исследование задач пользователей, и на основе этой информации выводится необходимая функциональность системы. Ориентированный на продукт подход сфокусирован на определение функций, которые, как ожидается, приведут к успеху на рынке или успеху бизнеса компании. В стратегиях, ориентированных на продукт, есть риск реализовать функции, которые не будут активно использоваться, несмотря на то, что во время сбора требований они казались очень нужными. Мы рекомендуем сначала изучить бизнес-цели и цели пользователей, а затем на основе этой информации определить нужные функции и характеристики продукта.
Анализ
Анализ требований подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде.
Также, Вигерс приводит основные действия по анализу требований:
анализ информации, полученной от пользователей, с целью отделения из задач от функциональных и нефункциональных требований, бизнес-правил, предлагаемых решений и другой информации;
разложение высокоуровневых требований до нужного уровня детализации;
выведение функциональных требований из информации других требований;
понимание относительной важности атрибутов качества;
распределение требований по компонентам ПО, определенным в системной архитектуре;
согласование приоритетов реализации;
выявление пробелов в требованиях или излишних требований, не соответствующих заданным рамкам.
Документирование
Под документированием требований подразумевается хранение и отображение полученной информации по требованиям в структурированном виде.
Действия по документированию:
отражение в письменном виде и в виде диаграмм полученных требований, на уровне достаточном для понимания заинтересованным сторонам.
Утверждение требований
На этапе утверждение требований необходимо подтвердить правильность набора собранных требований для дальнейшей их передачи в разработку для создания продукта, удовлетворяющего бизнес-целям.
Действия по утверждению требований:
выверка задокументированных требований для устранения всех недостатков до принятия требований группой разработки,
подготовка приемочных тестов и критериев приемки.
Также, при планировании необходимо предусмотреть не один цикл проверки требований для поступательного уточнения деталей высокоуровневых требований для поступательного уточнения деталей высокоуровневых требований и подтверждения правильности пользователями.
Управление требованиями
Действия по управлению требованиями:
определение основной версии требования. В рамках данного действия фиксируются и утверждаются требования с основными заинтересованными лицами для выпуска конкретного продукта или итерации разработки (спринта)
оценка влияния предлагаемых требований и внедрение одобренных изменений в проект управляемым образом. В рамках данного действия анализируются изменения (источник запроса, тип изменения, приоритет), осуществляется оценка влияния изменений (сложность, сроки и бюджет, риски, зависимости), принимается решение о внедрении (принять, отложить, отклонить),
обновление плана проекта в соответствии с планируемыми изменениями,
обсуждение новых обязательств, возникших при оценке влияния требований,
определение отношений и зависимостей между требованиями (если они есть),
отслеживание отдельных требований до их проектирования, исходного кода и тестов. В рамках данного действия выстраивается система по трассировке требований,
отслеживание состояния требований и действий по изменению на протяжении всего проекта.
Целью управления требованиями является не в предотвращении изменений или усложнении их внедрения, а в предугадывании и приспосабливали к ожидаемым реальным изменениям, чтобы снизить их разрушительное влияние на проект.
Итого
В рамках данной статьи мы рассмотрели разработку и управление требованиями по Карлу Вигерсу. Подчеркну, что возможно его взгляды для какого-то устарели, но они активно применяются в крупных проектах и по сей день.