При помощи функциональности обеспечивается отображение бизнес-требований в проекте по разработке продукта. Таким образом, в проекте доступно описание бизнес-требований, с указанием степени их готовности. Проектируя архитектуру и описывая функциональные требования, архитектор и аналитики сохраняют трассировку функциональных и нефункциональных требований на модели бизнес-процессов или исходные бизнес-требования.
Разработка архитектуры продукта, включая его функциональную декомпозицию (функциональные требования), и выявление нефункциональных требований.Создание плана выпуска версий продукта и формирование состава каждого из релизов.Реализация и тестирование функциональных и нефункциональных требований и т.д.Учет, обработку и реализацию новых функциональных требований или изменений в уже существующих требованиях.
В отличие от проекта по управлению бизнес-требованиями, для управления процессом разработки каждого программного продукта создается отдельный проект. Основными участниками проекта являются: владелец продукта, архитектор, системные аналитики, разработчики и тестировщики. Основные задачи участников каждого из проектов:
4. Разработка архитектуры и требований к продукту
Внутри проектной команды вы можете выполнять ревью списка требований при помощи встроенной функциональности для рецензирования. Для этого необходимо отметить требования для ревью и в действиях выбрать операцию "Рецензирование". За обсуждением разделов требований могут следить все участники проекта при помощи журнала обсуждений. За изменениями в требованиях можно следить при помощи журнала изменений.
Эффективным инструментом для совместной работы над требованиями является ревью. Вы можете выбрать наиболее подходящий для вашей команды вариант ревью. Например, вы можете выгружать подготовленные требования в MSWord или PDF и отправлять внешним ревьюерам, например, представителю заказчика. Правки, внесенные внешними ревьюерами вы можете внести в систему вручную.
3. Совместная работа и рецензирование
Графика подготовки требованийГрафика для контроля за согласованием требованийГрафика реализации заявок к функциональности
Контроль за процессами обработки заявок и управления требований, выявление узких мест и повышение эффективности процессов достигается за счет анализа:
Когда цикл согласования завершен и полученные артефакты можно передать в разработку, аналитик переводит исходную заявку в состояние "Передано в разработку", указывая при этом затраченное время.
Аналитик переводит исходную заявку в состояние "В работе" и приступает к анализу и разработке необходимых артефактов. Для создаваемых артефактов аналитик создает связь с исходным пожеланием.
"В работе" - аналитик приступил к анализу запроса и разработке необходимых артефактов."Передано в разработку" - завершены все согласования, можно приступать к реализации требования.
Для учета запросов к функциональности жизненный цикл пожеланий был настроен таким образом, чтобы отражать факт работы над бизнес-требованиями и реализации их в продукте:
2. Учет и обработка запросов
Учет поступающих запросов к функциональности в форме пожеланий, писем, концепций и других источников требований к будущему решению.Описание предметной области, например, путем описания автоматизируемых бизнес-процессов, функций и ролей.Формирование бизнес-требований на основе описания предметной области и поступивших запросов к функциональности, учет затраченного времени.Согласование требований, их приоритезация, планирование реализации и контроль за ходом их разработки.Контроль за реализацией исходных запросов пользователей разрабатываемого решения.
Участниками проекта являются бизнес-аналитики, эксперты в предметной области, продавцы и другие сотрудники, непосредственно взаимодействующие с клиентами. Основные выполняемые ими активности:
Заказчики и покупатели будущего решения являются источниками отрывочных требований и разнообразных "хотелок", которые через руководство компании-разработчика, а также отделы маркетинга, продаж и внедрения попадают в проект по управлению бизнес-требованиями для анализа. Цель проекта: аккумулировать исходные пожелания и требования, преобразовать их в бизнес-требования и описание предметной области, для последующей передачи разработчикам продуктов.
1. Анализ бизнес-требований
Управление требованиями и изменениями для линейки продуктов Рассмотрим типовую задачу: есть заказчик или рынок, которым необходимо автоматизировать части своего бизнеса, например, взаимодействие с клиентами. Принимается решение о разработке нескольких программных продуктов, которые будут автоматизировать процессы взаимодействия с клиентами. Необходимо собрать и зафиксировать бизнес-требования, описать предметную область, разработать архитектуру приложений и реализовать их, а также в процессе разработки реагировать на пожелания заказчиков, изменения в законодательстве или тенденции на рынке.
Управление требованиями и изменениями для линейки продуктов | DEVPROM
Комментариев нет:
Отправить комментарий