Что представляет собой жизненный цикл требования, каковы его стадии и процессы, а также какие стейкхолдеры, помимо самого аналитика, принимают в них участие. Разбираемся, что должно быть в системе управления требованиями, чтобы ими можно было управлять.
Зачем нужна система управления требованиями: краткий ликбез по СУТ
Помимо разработки требований и их спецификации в виде ТЗ аналитик постоянно решает задачи управления этими пригодными для практического использования представлениями решения. Какие задачи относятся к области знаний «Управление жизненным циклом требований» в 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 и пр. Эти СУТ поддерживают все процессы жизненного цикла требований, включая их спецификацию благодаря встроенным инструментам моделирования бизнес-процессов и информационных систем или за счет интеграции с внешними редакторами. Кстати, с 1 марта 2023 года я стала партнером компании Devprom, которая разрабатывает и внедряет комплексную среду управления и реализации ИТ-проектов. Это значит, что теперь в курсах нашей Школы прикладного бизнес-анализа будет еще больше практических примеров использования современных инструментов для повышения эффективности аналитической работы.
Кроме графического и текстового описания требования, СУТ также хранят метаданные о нем, т.е. его характеристики или атрибуты. Наиболее важными атрибутами требования, которые описывают его, считаются следующие:
- дата создания;
- номер текущей версии;
- автор (создатель требования в СУТ);
- приоритет, который показывает его относительную важность для стейкхолдеров;
- статус, т.е. состояние жизненного цикла;
- происхождение или источник;
- логическое обоснование;
- контактное лицо, ответственное за принятие решений по одобрению и внесению изменений;
- номер выпуска или итерации, на которую назначена реализация;
- метод проверки или критерий приемки.
Идеальным состоянием любого требования в любой системе считается, когда оно согласованно между заказчиком и исполнителем, имеет согласованную стратегию проверки и удовлетворяется требованиями более низкого уровня или спецификацией системы. Чтобы разобраться с жизненным циклом (ЖЦ) требования, далее рассмотрим его возможные состояния и процессы, которые обеспечивают переходы между ними.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Жизненный цикл требования: состояния и процессы
Хотя в реальности каждая команда может определить свой набор состояний ЖЦ требования, я предлагаю вам набор статусов, которые чаще всего используются на практике. Они показаны в следующей таблице.
| Состояние | Определение |
| Предложено | Требование запрошено уполномоченным лицом |
| В разработке | Бизнес-аналитик работает над требованием |
| Подготовлено | Разработана начальная версия требования |
| Одобрено | Требование проанализировано, его влияние на проект просчитано, и оно размещено в базовой версии спецификации (SRS, ТЗ). Ключевые бизнес-стейкхолдеры согласны с этим требованием, а разработчики обязались реализовать его |
| В реализации | Разработчики работают над реализацией требования, т.е. пишут программный код |
| Реализовано | Код, реализующий требование, разработан и протестирован |
| Проверено | Требование удовлетворяет критериям приемки, что подтверждено соответствующими тест-кейсами. Требование считается завершенным |
| Отложено | Одобренное требование запланировано для реализации в более позднем выпуске. В СУТ следует указать причину переноса, например, отсутствие окончательного согласия по требованию или невозможность вписать требование с низким приоритетом в текущую итерацию из-за ограниченных ресурсов (времени, денег или емкости команды) |
| Отклонено | Требование предложено, но не запланировано для реализации ни в одном из релизов. В СУТ следует указать причины отклонения требования и ЛПР – стейкхолдера, кто принял такое решение |
Переходы между этими состояниями можно представить в виде UML-диаграммы состояний, которая представляет собой направленный граф от начальной точки к конечной через вершины. Каждая вершина представляет собой конкретное состояние ЖЦ требования из вышеприведенной таблицы.
Если требование удалено из какой-то версии ТЗ/SRS, причину этого удаления тоже следует указать в СУТ.
Состояния ЖЦ требований напрямую связаны с процессами работы с требованиями, начиная от их сбора из различных источников (люди, документы и информационные системы) до одобрения (утверждения) ключевыми стейкхолдерами. К процессам ЖЦ требования относятся следующие:
- Сбор (Выявление);
- Спецификация;
- Верификация;
- Валидация;
- Трассировка;
- Приоритизация;
- Поддержание;
- Запрос изменений;
- Оценка изменений;
- Одобрение (Утверждение).
Разграничить ответственность участников, вовлеченных во все эти процессы, поможет матрица ответственности, которую также часто называют RACI. О ней и других техниках работы со стейкхолдерами я писала в этой статье. Эта таблица показывает степень ответственности и вовлечения участников в процесс, используя следующие термины:
- Исполнитель (Responsible, R)— стейкхолдер, непосредственно выполняющий задачу, например, бизнес-аналитик, тестировщик;
- Ответственный (Accountable, A) — стейкхолдер, отвечающий за успешное выполнение задачи и принимающий решения. По сути, это владелец бизнес-процесса. В каждом процессе эту роль может выполнять занимать только 1 стейкхолдер, двоевластие не допускается.
- Консультирующий (Consulted, C)– стейкхолдер, обладающий специальными знаниями или опытом, которыми он может поделиться, например, эксперт предметной области;
- Информируемый (Informed, I) — стейкхолдер, которого следует держать в курсе о ходе выполнения процесса и/или его результатах. В отличие от консультирующего, коммуникация с информируемым стейкхолдерам направлена в одну сторону: от аналитика к заинтересованной стороне. Эту роль чаще всего выполняют регулятор и клиент (Заказчик).
Управление бизнес-анализом - курс для руководителей
Код курса
BAMP
Ближайшая дата курса
23 мая, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 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-матрица в каждой отдельно взятой команде будет выглядеть по-своему. Как разработать такую матрицу ответственности для процессов работы с требованиями и определиться с другими настройками СУТ, вы узнаете на курсах нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
