Управление требованиями: процессы и стадии жизненного цикла требования к ПО

управление требованиями примеры курсы обучение, разработка и спецификация требований к ПО примеры курсы обучение, атрибуты и жизненный цикл требования, СУТ системы управления требованиями примеры курсы, обучение бизнес-анализу, курсы системного анализа, управление требованиями для аналитика, Школа Прикладного Бизнес-анализа Учебный Центр Коммерсант

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

Зачем нужна система управления требованиями: краткий ликбез по СУТ

Помимо разработки требований и их спецификации в виде ТЗ аналитик постоянно решает задачи управления этими пригодными для практического использования представлениями решения. Какие задачи относятся к области знаний «Управление жизненным циклом требований» в BABOK®Guide, я рассказывала здесь.

Система управления требованиями (СУТ) нужна, чтобы хранить следующую информацию:

  • все виды требований (бизнес-требования, требования стейкхолдеров, а также требования к решению функциональные и нефункциональные) во всех формах их представления (Use Case, User Story, Каноническая форма);
  • трассировки требований разного уровня между собой, а также их связи с бизнес-правилами, тест-кейсами, компонентами системы и задачами на реализацию в таск-трекере;
  • метаданные требований, т.е. их атрибуты, включая версии и состояния жизненного цикла.

Обеспечивая управление версиями и изменениями требований, СУТ также выполняет роль общего проектного пространства, поддерживая функции навигации и поиска по набору требований (сортировки и фильтры), разные уровни доступа к данным для командной работы и связи со всеми стейкхолдерами. В настоящее время большинство компаний в качестве СУТ используют комбинацию продуктов корпорации Atlassian: Jira как таск-трекер, где отслеживается прогресса выполнения работы, т.е задачи по реализации требований, и wiki-подобная система Confluence как средство хранения требований. Однако, Confluence сам по себе не является системой управления требованиями. Поэтому, чтобы он выполнял функции СУТ, например, построение матрицы трассировок и отслеживание атрибутов, нужны специализированные плагины. К таким плагинам относятся Requirements Yogi, Mocky, Moqups.

В качестве более легковесной (и более дешевой) альтернативы Confluence можно использовать Notion — веб-сервис для создания заметок и текстовых документов, списков задач и структурирования знаний. Благодаря модульной структуре Notion, его можно настроить для хранения требований и другой информации по ИТ-проекту, включая календарный план и задачи для участников. Этот вполне рабочий вариант отлично подходит для небольших и средних проектов. Однако, при использовании бесплатного аккаунта Notion есть ограничения на размер проектного пространства: не более 5 пользователей, а также лимитированы объемы загружаемых в сервис файлов. Кроме того, как и в любом облачном решении, есть риск утечки конфиденциальной информации. Поэтому для хранения чувствительных данных, особенно за пределами локального контура предприятия, следует очень тщательно проработать вопросы информационной безопасности, чтобы снизить риски утечки и несанкционированного доступа.

Помимо общих wiki-подобных решений также существуют специализированные системы управления требованиями, изначально разработанные именно для этого. Например, 3SL Cradle, IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner, Borland Caliber RM, Devprom ALM и пр. Эти СУТ поддерживают все процессы жизненного цикла требований, включая их спецификацию благодаря встроенным инструментам моделирования бизнес-процессов и информационных систем или за счет интеграции с внешними редакторами. Кроме графического и текстового описания требования, СУТ также хранят метаданные о нем, т.е. его характеристики или атрибуты. Наиболее важными атрибутами требования, которые описывают его, считаются следующие:

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

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

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса
14 ноября, 2022
Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.

Жизненный цикл требования: состояния и процессы

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

Состояние Определение
Предложено Требование запрошено уполномоченным лицом
В разработке Бизнес-аналитик работает над требованием
Подготовлено Разработана начальная версия требования
Одобрено Требование проанализировано, его влияние на проект просчитано, и оно размещено в базовой версии спецификации (SRS, ТЗ). Ключевые бизнес-стейкхолдеры согласны с этим требованием, а разработчики обязались реализовать его
В реализации Разработчики работают над реализацией требования, т.е. пишут программный код
Реализовано Код, реализующий требование, разработан и протестирован
Проверено Требование удовлетворяет критериям приемки, что подтверждено соответствующими тест-кейсами. Требование считается завершенным
Отложено Одобренное требование запланировано для реализации в более позднем выпуске. В СУТ следует указать причину переноса, например, отсутствие окончательного согласия по требованию или невозможность вписать требование с низким приоритетом в текущую итерацию из-за ограниченных ресурсов (времени, денег или емкости команды)
Отклонено Требование предложено, но не запланировано для реализации ни в одном из релизов. В СУТ следует указать причины отклонения требования и ЛПР – стейкхолдера, кто принял такое решение

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

управление требованиями, анализ и разработка требований, Жизненный цикл требования к ПО, СУТ, обучение системному и бизнес-анализу
Жизненный цикл требования к ПО

Если требование удалено из какой-то версии ТЗ/SRS, причину этого удаления тоже следует указать в СУТ.

Состояния ЖЦ требований напрямую связаны с процессами работы с требованиями, начиная от их сбора из различных источников (люди, документы и информационные системы) до одобрения (утверждения) ключевыми стейкхолдерами. К процессам ЖЦ требования относятся следующие:

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

  • Исполнитель (Responsible, R)— стейкхолдер, непосредственно выполняющий задачу, например, бизнес-аналитик, тестировщик;
  • Ответственный (Accountable, A) — стейкхолдер, отвечающий за успешное выполнение задачи и принимающий решения. По сути, это владелец бизнес-процесса. В каждом процессе эту роль может выполнять занимать только 1 стейкхолдер, двоевластие не допускается.
  • Консультирующий (Consulted, C)– стейкхолдер, обладающий специальными знаниями или опытом, которыми он может поделиться, например, эксперт предметной области;
  • Информируемый (Informed, I) — стейкхолдер, которого следует держать в курсе о ходе выполнения процесса и/или его результатах. В отличие от консультирующего, коммуникация с информируемым стейкхолдерам направлена в одну сторону: от аналитика к заинтересованной стороне. Эту роль чаще всего выполняют регулятор и клиент (Заказчик).

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

Код курса
BAMP
Ближайшая дата курса
15 декабря, 2022
Длительность обучения
8 ак.часов
Стоимость обучения
15 000 руб.

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

Процесс Аналитик Заказчик Эксперт

домена

РП Конечный пользователь ИТ-архитектор Разработчик Тестировщик Регулятор
Сбор R I C A C C C C C
Спецификация A I С I C C C C C
Верификация A I С I C C C C C
Валидация R A С I C C C C C
Трассировка R I С I C C C C C
Приоритизация R A С I C C C C C
Поддержание A, R С I C C C C C
Запрос изменений A R R I R C C C C
Оценка изменений A, R C C I C C C C C
Одобрение (Утверждение) R A C I C C C C C

На практике подобная RACI-матрица в каждой отдельно взятой команде будет выглядеть по-своему. Как разработать такую матрицу ответственности для процессов работы с требованиями и определиться с другими настройками СУТ, вы узнаете на курсах нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Добавить комментарий

Поиск по сайту

Напишите нам, мы онлайн!