Управление требованиями и изменениями для линейки продуктов

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

1. Анализ бизнес-требований

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

Участниками проекта являются бизнес-аналитики, эксперты в предметной области, продавцы и другие сотрудники, непосредственно взаимодействующие с клиентами. Основные выполняемые ими активности:

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

2. Учет и обработка запросов

Для учета запросов к функциональности жизненный цикл пожеланий был настроен таким образом, чтобы отражать факт работы над бизнес-требованиями и реализации их в продукте:

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

Аналитик переводит исходную заявку в состояние "В работе" и приступает к анализу и разработке необходимых артефактов. Для создаваемых артефактов аналитик создает связь с исходным пожеланием.

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

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

• Графика подготовки требований
• Графика для контроля за согласованием требований
• Графика реализации заявок к функциональности

3. Совместная работа и рецензирование

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

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

4. Разработка архитектуры и требований к продукту

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

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

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

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

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

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

5. Управление изменениями

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

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

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

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

6. Контроль за реализацией требований

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