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

17.02.2010 11:51

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

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

Анализ бизнес потребностей

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

При анализе проблемы или бизнес-процесса клиента вы создаете раздел требований, в котором необходимо привести следующую информацию:

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

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

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

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

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

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

Валидация описания проблем

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

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

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

img3

Функциональный анализ и подготовка требований

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

img4

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

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

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

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

Попробуйте сейчас!