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

Жизненный цикл требования (Requirement Life Cycle Management, RLCM) — упорядоченная модель состояний и переходов для одного элемента спецификации от фиксации идеи до архивирования. На проекте без явной state-машины требования «теряются» в бэклоге, baseline смешивается с черновиком, а изменения не попадают в аудит. Эта статья даёт каноническую модель состояний, правила переходов и роли BA и PM — без дублирования инструментов и процессов соседних заметок раздела 02.05.

1. Суть темы

Жизненный цикл требования — формальная модель, определяющая:

• Состояния (статусы) элемента спецификации;
• Правила перехода между состояниями, включая entry/exit criteria;
• Атрибуты, обновляемые на каждом этапе;
• События, инициирующие переход (решение PO, baseline, merge в main, результат теста).

Цели RLCM:

• Прослеживаемость — кто предложил, когда, в каком релизе реализовано и принято; в 10.01.15 Шаблон матрицы трассировки фиксируют текущий статус REQ, а при аудите — историю переходов (02.03.04 Трассировка требований (концепция));
• Дисциплина изменений — правка текста сопровождается сменой статуса и записью в истории (02.05.02 Управление изменениями (Change Control Board));
• Метрики потока — lead time по статусам, «застрявшие» требования (08.01 Метрики и KPI процесса анализа).

В отличие от 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC), RLCM описывает «микрожизнь» одного REQ/Story, а не фазы проекта. Один спринт может одновременно содержать требования в In Elaboration, In Development и Verified.

Два уровня согласования

Главный источник путаницы — смешение первичного одобрения и baseline. В канонической модели это разные gate:

Gate	Состояние	Смысл	Типичный владелец перехода
Gate 1 — включение в работу	Approved	Потребность валидна, соответствует целям, элемент включён в бэклог; полная спецификация ещё не обязательна	PO / бизнес-спонсор
Gate 2 — заморозка спецификации	Baselined	Текст спецификации согласован, присвоена версия (например v1.0); дальнейшие правки — только через change control	BA + стейкхолдеры; в жёстких процессах — CCB

После baseline требование может быть In Development с версией 2.0 — это новая версия текста после change request, а не «отсутствие baseline». Версия фиксируется при переходе в Baselined или при переутверждении из Changed; история хранится в VCS или audit trail (07.05 Системы контроля версий (Git) для документации).

RLCM и SDLC: что видит PM

Project baseline (объём релиза, сроки) и REQ baseline (версия текста) — разные артефакты. PM читает статусы REQ как сигнал готовности к планированию и поставке:

Статус REQ	Ожидание PM	Связь с фазой SDLC
Proposed, Deferred	Не в commit релиза	Инициация, discovery
Approved	В бэклоге, нужна оценка	Планирование
In Elaboration, Baselined	Готовность к спринту / контракт baseline	Анализ, проектирование
In Development, Implemented	Работа в потоке, риск срыва спринта	Разработка, сборка
Verified, Accepted	Готовность к демо / UAT	Тестирование (STLC)
Closed, Deprecated	Поставлено в prod или выведено	Эксплуатация

Детали фаз SDLC — в 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC); здесь важна стыковка «статус одного REQ ↔ решение PM о включении в релиз».

2. Ключевые понятия

Гранулярность: Epic, Story, Task

Lifecycle не один на все уровни. Правило для Jira и аналогов:

Уровень	Workflow	Что отслеживается
Epic / Feature	Упрощённый: Proposed → Approved → In Progress → Done	Бизнес-ценность, release, декомпозиция; детальный RLCM — на дочерних stories
Story / REQ / Use Case	Полная state-машина ниже	Спецификация, AC, baseline, трассировка до тестов
Task / Sub-task	Наследует от родителя: To Do → In Progress → Done	Исполнение; смена Verified/Accepted — только на уровне story

Definition of Ready (DoR) и Definition of Done (DoD) из 05.02 Scrum и Kanban (аналитик в Agile) накладываются поверх статусов: story не переходит в In Development, пока DoR не выполнен, даже если PO формально нажал «Approved». Формат элемента (User Story, Use Case) не меняет машину состояний — см. 04.03 Use Case vs User Story — выбор подхода.

Когда вводить полную машину: контрактный baseline, регуляторика, мультикоманда — каноническая модель или её явный маппинг (05.01 Waterfall и V-model). В чистом Scrum на Story достаточно минимума статусов с маппингом на DoR/DoD; полный RLCM — когда без audit trail и версий текста нельзя восстановить «что было согласовано на момент релиза».

Каноническая state-машина

Модель обобщает BABOK RLCM и CMMI RDM; Baselined выделен явно, чтобы не смешивать backlog approval и заморозку спецификации. Диаграмму состояний можно использовать как артефакт спецификации — см. 03.02.04 Диаграмма состояний (State Machine Diagram).

stateDiagram-v2
    [*] --> Proposed
    Proposed --> Approved : gate 1: в бэклог
    Proposed --> Rejected : отклонение
    Proposed --> Duplicated : дубликат
    Proposed --> Deferred : отложено
    Deferred --> Proposed : возврат
    Approved --> In_Elaboration : детализация
    In_Elaboration --> Baselined : gate 2: baseline vX.Y
    Baselined --> In_Development : в итерацию
    Approved --> In_Development : hotfix / минор без re-baseline*
    In_Development --> Implemented : dev завершён
    Implemented --> Verified : тесты пройдены
    Verified --> Accepted : приёмка PO/заказчика
    Accepted --> Closed : в проде
    Closed --> Deprecated : вывод функции
    Deprecated --> [*] : архив
    Closed --> [*] : архив без deprecated
    Approved --> Changed
    In_Elaboration --> Changed
    Baselined --> Changed
    In_Development --> Changed
    Implemented --> Changed
    Verified --> Changed
    Accepted --> Changed
    Changed --> Approved : переутверждение
    Approved --> In_Elaboration : change: нужна re-elaboration
    Approved --> Baselined : change: re-baseline без re-elaboration
    Approved --> In_Development : change: минор, dev не завершён
    note right of Changed : Критерии выбора пути — см. §3
    note right of Baselined : Версия текста фиксируется здесь;\nchange → новая версия

*Переход Approved → In Development без Baselined допустим только по явной политике (мелкий дефект, spike) с записью risk acceptance в change log — тот же термин, что и «documented exception» в exit criteria ниже.

Словарь состояний

• Proposed (New) — идея зафиксирована; источник и черновик описания есть. ИИ-черновики тоже начинают здесь, с меткой «сгенерировано AI» до проверки аналитиком.
• Approved — gate 1: включено в бэклог, приоритет согласован (02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)); полная спецификация не обязательна.
• In Elaboration — детальная проработка: AC, зависимости, модели (02.03.03 Спецификация требований (SRS, Use Case, User Story)).
• Baselined — gate 2: спецификация согласована, версия зафиксирована; изменения — через 02.05.02 Управление изменениями (Change Control Board).
• In Development — реализация в работе.
• Implemented — артефакт поставлен в целевую среду сборки (PR merged, образ собран); это не обязательно prod. Автопереход из CI/CD допустим сюда, не в Closed (07.06 CICD и конвейеры — влияние на требования).
• Verified — верификация: формальная проверка «сделано ли так, как написано» (исполнение тестов по трассировке REQ→test case) — см. 02.04.01 Верификация и валидация (V&V) и фазу STLC в 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC).
• Accepted — валидация: PO/заказчик подтверждает «то ли сделали» по 02.04.02 Критерии приёмки (Acceptance Criteria).
• Closed — развёрнуто в production (или иная согласованная operational-среда); новые правки только через change.
• Deprecated — функциональность выведена или заменена; история сохраняется для аудита.
• Deferred — не в текущем релизе; reprioritization — 02.05.02 Управление приоритетами в условиях изменчивости.
• Rejected — терминально отклонено; причина обязательна.
• Duplicated — терминально объединено с каноническим REQ; поле «заменено на ID» указывает на master-запись.
• Changed — транзитный статус change request; детали impact analysis и решения CCB — в 02.05.02 Управление изменениями (Change Control Board).

NFR проходят тот же workflow, но gate 2 для них часто включает отдельные review (performance, security sign-off); критерии — в 08.02 Нефункциональные требования (НФТ) — классификация и стандарты. Performance-REQ baselined, когда согласованы измеримые пороги и способ проверки, а не «когда написали абзац в Confluence».

Verified vs Accepted

	Verified	Accepted
Вопрос	Реализация соответствует спецификации?	Решает ли это нужную бизнес-проблему?
Кто	QA / автотесты	PO, заказчик
Связь с V&V	Verify	Validate

При failed-тесте: Verified не достигается; дефект трассируется к REQ (02.03.04 Трассировка требований (концепция)). При reopen после Accepted — только через Changed с обязательным CR. Статус Reopened в Jira и аналогах не входит в каноническую модель: настройте его как alias перехода в Changed или локальный подстатус с тем же impact analysis.

Сквозной пример

REQ-AUTH-023 (вход по SSO): Proposed (интервью) → Approved (refinement) → In Elaboration → Baselined v1.0 → In Development → Implemented (PR в main) → Verified → Accepted → Closed (prod, Release 2.3). После baseline заказчик меняет AC по таймауту сессии → Changed → Approved → Baselined v2.0 (затронут контракт API) → In Development. Без смены статуса правка v1.0 «молча» потеряла бы audit trail.

Атрибуты lifecycle

Атрибут	Назначение	Пример
ID	Неизменяемый ключ	REQ-AUTH-023
Тип	Классификация	02.03.01 Классификация требований (БТ, ФТ, НФТ)
Приоритет	Для планирования PM	Must have
Текущее состояние	Статус машины	Baselined
Версия текста	Snapshot спецификации	v1.0 при baseline, v2.0 после change
Связанные требования	Зависимости	02.05.01 Управление зависимостями между требованиями
Целевой релиз / спринт	План PM	Release 2.3
Lead Time Target	SLA по статусам (метрика потока)	5 дней In Elaboration — см. 08.01 Метрики и KPI процесса анализа

Принцип для любого инструмента (02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence)): смена статуса = событие с автором, временем и обоснованием.

3. Как применяется в работе аналитика

Роли BA и PM

Зона	PM / PO	BA
Backlog gate	Proposed → Approved, Deferred, приоритет, release	Консультация, проверка на дубликаты и scope (02.05.03 Управление объёмом (Scope Creep) и ожиданиями)
Спецификация	Участие в review	Владелец Approved → In Elaboration → Baselined, качество текста (02.04.03 Управление качеством требований)
Change	Решение о scope/cost	Impact analysis, обновление спецификации из Changed
Приёмка	Verified → Accepted	Поддержка демо, актуальность AC
Планирование	Lead time, capacity по статусам	Оценка аналитической части (02.05.04 Совместная оценка трудоёмкости требований)

PM использует статусы для прогноза поставки; BA — для зрелости спецификации и трассировки.

Entry и exit criteria (ядро переходов)

Переход	Exit criteria (минимум)
→ Approved	Связь с бизнес-целью; нет дубликата; предварительный приоритет
→ In Elaboration	Gate 1 пройден (Approved); PO включил в работу
→ Baselined	AC записаны; зависимости проверены; рецензия пройдена; версия присвоена (10.04 Чеклист аналитика перед стартом разработки)
→ In Development	DoR выполнен; Baselined или documented exception (= risk acceptance в change log для hotfix/spike); блокирующие зависимости ≥ Baselined (02.05.01 Управление зависимостями между требованиями)
→ Implemented	PR merged / артефакт в целевой среде сборки (не prod)
→ Verified	Исполнение тестов по трассировке REQ→test case (02.04.01 Верификация и валидация (V&V), STLC в 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC))
→ Accepted	Демо PO; AC подтверждены
→ Closed	Релиз в prod; документация актуальна
→ Changed	Зарегистрирован CR; impact analysis выполнен — процедура в 02.05.02 Управление изменениями (Change Control Board)

Путь после Changed → Approved

После переутверждения аналитик выбирает один следующий рабочий статус по impact:

Следующий статус	Когда достаточно
In Elaboration	Меняются AC, модели, границы scope; нужна повторная проработка
Baselined	Текст уточнён, но AC/контракт API/NFR изменены — нужна новая версия vX.Y и gate 2
In Development	Минорная правка без изменения AC и внешних контрактов; dev ещё не завершён или hotfix на уже baselined v1.0

Если gate 1 затронут (отмена ценности, смена приоритета «в ноль») — не обходите Approved: CCB/PO принимает решение до возврата в рабочий поток.

Переходы с учётом зависимостей

Перед In Development проверьте граф 02.05.01 Управление зависимостями между требованиями: prerequisite-REQ должны быть минимум Baselined. Допуск In Development/Implemented у prerequisite — политика проекта: ускоряет старт, но переносит риск интеграции на PM (зависимость может измениться до Verified). Инструмент может блокировать переход автоматически; в Confluence-only процессах — чеклист в DoR.

Ролевая модель переходов

Роль	Разрешённые переходы
Аналитик	Approved → In Elaboration; In Elaboration → Baselined (после review); → Rejected/Duplicated; инициация → Changed; после Changed → Approved — выбор In Elaboration / Baselined / In Development
PO / бизнес	Proposed → Approved; Verified → Accepted; → Deferred
Разработчик	In Development → Implemented
QA	Implemented → Verified; reopen через дефект → Changed
CCB / Change Manager	Changed → Approved

Внутренний черновик BA без gate 1 остаётся в Proposed до решения PO — переход Proposed → In Elaboration не каноничен. Автопереходы из CI/CD — только в Implemented (merge/build), не в Closed; prod — отдельный release gate.

ИИ и lifecycle

ИИ влияет на RLCM там, где меняется контроль перехода: черновики попадают в Proposed с меткой происхождения; переход в Approved — только после human-in-the-loop. Семантический поиск дубликатов поддерживает переход Proposed → Duplicated (с обязательной проверкой аналитиком). Генерация тест-кейсов и извлечение из протоколов — в 11.07 Практические кейсы применения LLM в анализе и 11.03 Промпт-инжиниринг для аналитика.

4. Типовые ошибки и ограничения

Ошибка	Последствие	Как избежать
Один статус «Approved» на backlog и baseline	Неконтролируемые правки в dev	Разделить gate 1 и Baselined
Lifecycle один на Epic и Task	Шум в Jira, фальшивая отчётность	Разные workflow по уровням
Правка текста без Changed	Потеря audit trail, scope creep	Любая post-baseline правка — через CR
Verified = «заказчик доволен»	Путаница на аудите V&V	Развести Verified и Accepted явно
Implemented = «уже в prod»	Ложная отчётность при CI/CD	Implemented = сборка; Closed = prod
Игнор зависимостей при переводе в Dev	Заблокированные stories в спринте	DoR + проверка prerequisite
Duplicated без ссылки на master	Потеря истории решений	Обязательное поле «заменено на REQ-XXX»
Автопереходы CI/CD без политики	Ложный Implemented / пропуск QA	Согласовать с QA и BA

Упрощённый Agile-workflow (To Do → In Progress → Done) допустим на уровне Task, но на Story минимум фиксируйте: ready for dev (≈Baselined), in test (≈Implemented), done (≈Accepted) — иначе метрики и трассировка к релизу не восстановить. Полную state-машину вводите при контрактном baseline и аудите (05.01 Waterfall и V-model); в потоковом Scrum — маппинг на DoR/DoD (05.02 Scrum и Kanban (аналитик в Agile)).

Связи с другими разделами базы

• 02.05.01 Управление зависимостями между требованиями — блокеры и риск prerequisite при переходах.
• 02.05.02 Управление приоритетами в условиях изменчивости — Deferred и reprioritization.
• 02.05.03 Управление объёмом (Scope Creep) и ожиданиями — контроль scope при Approved и Changed.
• 02.05.04 Совместная оценка трудоёмкости требований — планирование BA/PM по статусам.
• 02.05.02 Управление изменениями (Change Control Board) — процесс Changed, impact analysis, переутверждение.
• 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence) — workflow и audit trail в RM-инструментах.
• 02.03.04 Трассировка требований (концепция) — текущий статус и история в RTM.
• 02.04.01 Верификация и валидация (V&V) — Verified vs Accepted.
• 02.04.02 Критерии приёмки (Acceptance Criteria) — gate для Accepted.
• 02.04.03 Управление качеством требований — качество перед Baselined.
• 04.03 Use Case vs User Story — выбор подхода — один lifecycle для разных форматов спецификации.
• 08.02 Нефункциональные требования (НФТ) — классификация и стандарты — gate 2 для NFR.
• 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC) — RLCM внутри SDLC/STLC.
• 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148) — нормативная база RLCM.
• 05.01 Waterfall и V-model — когда нужна полная state-машина.
• 05.02 Scrum и Kanban (аналитик в Agile) — DoR/DoD и упрощённый маппинг.
• 03.02.04 Диаграмма состояний (State Machine Diagram) — моделирование lifecycle в спецификации.
• 07.05 Системы контроля версий (Git) для документации — версии текста требования.
• 07.06 CICD и конвейеры — влияние на требования — автопереходы до Implemented.
• 08.01 Метрики и KPI процесса анализа — lead time и метрики по статусам.
• 10.01.15 Шаблон матрицы трассировки — колонка статуса REQ.
• 10.04 Чеклист аналитика перед стартом разработки — DoR и gate перед In Development.
• 11.07 Практические кейсы применения LLM в анализе — ИИ и human-in-the-loop.

Источники и дополнительные материалы

Книги и стандарты

• BABOK Guide v3, IIBA — Knowledge Area «Requirements Life Cycle Management». Обзор: IIBA: BABOK (полный гид — по членству IIBA). См. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).
• ISO/IEC/IEEE 29148:2018 — Life cycle processes — Requirements engineering (актуальная редакция 2018, статус подтверждён в 2024). ISO 29148, IEEE 29148-2018.
• CMMI V2.0 — Process Area Requirements Development and Management (RDM). CMMI Institute.
• Karl E. Wiegers, Joy Beatty — Software Requirements, 3rd ed. (2013), гл. о жизненном цикле требований.
• Suzanne Robertson, James Robertson, Adrian Reed — Mastering the Requirements Process, 4th ed. (Addison-Wesley, 2024). Pearson — 4th ed.
• IREB CPRE Advanced Level — Requirements Management (2021). IREB CPRE.

Практика и инструменты

• IBM DOORS Next — Managing workflow for requirements: DOORS Next 9.7 — workflow.
• Atlassian — Requirements in Agile (контекст backlog и refinement, не формальная state machine): Atlassian Agile — requirements.

Дополнительно

• Joy Beatty — Visual Models for Requirements (2021) — модели состояний в спецификации.