6 апреля я провёл бесплатный вебинар Разработка требований в Confluence с использованием плагина Requirements Yogi. В этой статье я привожу краткий обзор того, о чём рассказывалось на вебинаре. Это поможет вам решить, стоит ли потратить примерно полтора часа своего времени на просмотр записи.
Atlassian Confluence – широко распространённая wiki-система, используемая в компаниях для ведения корпоративных баз знаний и разработки документации. Во многих компаниях Confluence также используют для документирования требований к ПО. Система «из коробки» не предоставляет каких-либо специальных возможностей для разработки и управления требованиями. Но открытая архитектура позволяет добавлять такие возможности с помощью устанавливаемых расширений (плагинов).
Одним из таких расширений является плагин Requirements Yogi.
Возможности плагина
Плагин предоставляет следующие возможности:
-
Разбиение страниц Confluence на отдельные требования. Любой фрагмент страницы (удовлетворяющий определённым условиям, о которых ниже) может быть объявлен отдельным атомарным требованием, с присвоением ему уникального идентификатора. На каждое атомарное требование можно ссылаться с помощью гиперссылки с уникальным url.
-
Назначение атомарным требованиям произвольных атрибутов, в том числе связывающих требования между собой.
-
Построение отчётов о требованиях, отбираемых по разным критериям (в том числе по значениям атрибутов).
-
Создание срезов (baselines, базовых линий требований), фиксирующих версии включенных в срез требований на определённый момент времени. Срезы можно создавать как по всему набору требований, так и по набору требований, отобранных по определённым критериям.
-
Построение таблиц покрытия и матриц трассировки требований.
Атомарным требованием может быть:
-
Абзац текста;
-
Пункт
списка-перечисления ; -
Строка таблицы.
Полностью все возможности плагина раскрываются только при использовании таблиц. Атомарные требования в виде простого текста могут использоваться только для ссылок.
Чего нет в плагине
Плагин не предлагает
Поэтому использование плагина нужно адаптировать под существующие в компании или команде процессы. Это скорее достоинство плагина, чем недостаток. Но для того, чтобы его можно было успешно использовать, до внедрения плагина нужно ответить, как минимум, на два важных вопроса:
-
что считать атомарным требованием (до какого уровня декомпозировать требования);
-
какие типы требований нужно выделить и как их связывать между собой.
Если эти решения не принять до начала использования плагина, то модель требований становится громоздкой и трудноуправляемой.
Таким образом, нужно сначала определить схему разработки требований, а под неё адаптировать шаблоны требований и способы использования плагина.
Схемы разработки требований
Я предлагаю определять схему разработки требований по двум параметрам, которые считаю важнейшими для настройки процессов управления требованиями: 1) частота поставок и 2) формат разработки требований.
По этим двум параметрам предлагается матрица 3×3, каждая ячейка которой представляет собой обобщённую схему разработки требований.
Для частоты поставок выбраны три значения. Принцип деления прост: берём два крайних случая, а всё, что к ним не относится, остаётся посередине.
- Разработка короткими итерациями (спринтами) представляет одну крайность. Предполагается длительность итерации примерно от 1 недели до 1 месяца. Отличительная особенность этого подхода в том, что мы не думаем о следующем спринте, пока не закончили текущий.
- Периодический выпуск версий. Итерации в этом случае обычно длятся от одного до нескольких месяцев. Требования к версиям при этом могут разрабатываться параллельно: разработка требований к следующей версии идёт параллельно с реализацией текущей. Для выпуска каждой версии нужен зафиксированный набор требований.
- Разработка требований в виде документации (aka «водопад») представляет собой другую крайность. Все разработанные требования фиксируются до начала разработки.
Форматы требований тоже сведены к трём основным видам. Названия форматов довольно условны: они соответствуют наиболее распространённым методикам описания требований, но не ограничивают выбор схемы только этими методиками.
- User Stories — очень распространённый в настощее время формат. Каждая User Story включает требования разных уровней: требуемую функцию, цель пользователя, поясняющие комментарии и приёмочные тесты. При этом User Story представляет собой атомарное требование, которое должно быть реализовано целиком в пределах итерации.
- Use Cases — распространённый формат описания требований на пользовательском уровне. Несмотря на название, к этой категории можно отнести любые форматы описания пользовательских требований. Основное отличие этого вида требований от предыдущего в том, что требования в этом формате могут декомпозироваться на более мелкие атомарные требования, реализуемые в разных итерациях или версиях.
- Текстовые описания требований, обычно в виде «система должна». Из таких требований состоят традиционные технические задания и спецификации требований.
В вебинаре рассматриваются получившиеся девять схем. При этом некоторые сочетания оказываются несовместимыми.
Слайд с итоговой таблицей приведен ниже.
Для каждой работающей схемы были показаны возможности плагина Requirements Yogi в специально созданных пространствах на тестовом сервере Confluence. На вебинаре демонстрировались операции и настройки входящих в состав плагина макросов. Их всего три:
- Макрос для создания атомарного требования с присвоением ему идентификатора;
- Макрос для описания атрибутов требований в таблице;
- Макрос для создания отчётов по требованиям. Этот макрос использует простой язык поисковых запросов, с помощью которых можно отбирать требования по разным критериям, включая тип требования и значения произвольных атрибутов.
Для присвоения статусов требованиям использовался другой плагин Confluence — Handy Status (входящий в пакет Handy Macros). Этот простой плагин позволяет настраивать произвольные наборы статусов и изменять их одним кликом, без необходимости перехода в режим редактирования страницы. В реальных проектах статусы, скорее всего, должны формироваться во внешних системах управления задачами — например, Jira.
Теперь у вас должно быть достаточно информации, чтобы решить, нужно ли просматривать запись вебинара.
Requirements Yogi from Grigoriy Pechenkin on Vimeo.
Автор статьи

Григорий Печёнкин
Курсы Вебурситета
Введение в профессию аналитика 2 900 руб. | |
Введение в профессию аналитика (демо) Бесплатно | |
Вебинары Сообщества Аналитиков Бесплатно | |
SQL для непрограммистов (СЕРТИФИКАТ) 750 руб. | |
![]() | SQL для непрограммистов Бесплатно |