в облаке
Попробовать

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

06.04.2010 11:41

Если в вашей команде участвует больше двух человек, то однозначное и детальное описание требуемой функциональности просто необходимо, чтобы синхронизировать действия всех участников. Форма описания функциональности (или постановка) может отличаться в зависимости от квалификации и потребностей команды, возможности подробного описания требований заказчиком и других условий. Я хочу описать три основных варианта процессов работы с требованиями и показать как это можно использовать в DEVPROM.

 

Водопадная модель

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

 

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

 

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

 

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

 

Итерационная модель

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

 

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

 

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

 

Отсутствие формализованных требований

Данный вариант пришел из Agile практик и предлагает отказаться от формализации требований, то есть их составления, а вместо этого описывать желаемое поведение приложения путем создания так называемых историй пользователя (user story). Такой подход удобен для легковесного итерационного процесса, где не требуется явно выделять роли аналитика и тестировщика.

 

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

 

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

Еще интересные статьи на эту тему: