Управление качеством требований (Requirements Quality Management) — совокупность процессов, методов и практик, которые обеспечивают пригодность спецификации для проектирования, разработки и приёмки. Дефекты на фазе требований обходятся значительно дороже на последующих стадиях (ориентир «1-10-100» — эвристика из литературы по экономике дефектов; коэффициенты в источниках различаются, см. 08.05 Управление рисками на этапе анализа). Эта статья отвечает на вопрос: как организовать систему качества, какие атрибуты делают требование «хорошим», как измерить качество набора и когда набор готов к baseline.

1. Суть темы

Управление качеством требований включает три компонента:

  1. Планирование качества (Quality Planning) — критерии, стандарты, метрики, пороговые значения, роли и частота проверок.
  2. Обеспечение качества (Quality Assurance, QA) — превентивные меры: шаблоны, чек-листы, обучение, структурированный язык формулировок (EARS, INCOSE).
  3. Контроль качества (Quality Control, QC) — выявление дефектов в готовых артефактах: рецензирование, инспекции, статическое тестирование.

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

Управление качеством не сводится к верификации. Верификация проверяет форму и атрибуты текста; валидация — соответствие бизнес-потребности. QC в основном закрывает верификацию; QA и validation-активности (обзоры с заказчиком, sign-off) — часть общей системы качества. Различие V&V, техники и границы с V&V продукта — в 02.04.01 Верификация и валидация (V&V); исполнимые критерии приёмки — в 02.04.02 Критерии приёмки (Acceptance Criteria).

План качества: минимальное содержание

План качества требований — не отдельный толстый документ, а зафиксированные договорённости проекта. Минимальный набор:

ЭлементЧто фиксируемПример
Артефакты и шаблоныФормат спецификации по контекстуUser Story + AC в Agile; SRS/BRD для контракта — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)
Атрибуты и gateКакие свойства ISO/BABOK обязательны; порогиUpstream-трассировка 100% на baseline; плотность дефектов < 0,5 на 10 требований
Частота и тип проверокКогда peer review, когда инспекцияКаждая US — peer review; baseline SRS — формальная инспекция (08.04 Рецензирование и инспекции (техники Фейгана))
РолиКто готовит, рецензирует, принимает gateСм. таблицу ниже
МетрикиПродуктовые KPI набора; процессные — в 08.01 Метрики и KPI процесса анализаПлотность дефектов, конфликты набора; утечка и эффективность ревью — см. 08.01
Выбор gate по типу проектаAgile vs контракт/SRSDoR на уровне спринта vs формальный baseline с sign-off

Частота ревью зависит от зрелости артефакта: черновик — walkthrough после elicitation; перед передачей в разработку — формальный QC; после каждого CR — мини-цикл проверки (02.05.02 Управление изменениями (Change Control Board)). В Agile gate «мягче»: DoR на историю, а не единый baseline всего backlog (05.02 Scrum и Kanban (аналитик в Agile)); в контрактных и регуляторных проектах — жёсткий baseline с протоколом инспекции.

Quality gate: когда набор «достаточно хорош»

Baseline требований фиксируется не «когда закончили писать», а при выполнении критериев выхода (quality gate) — согласованных командой порогов. Ниже — иллюстративный набор; конкретные числа проект адаптирует под объём, риск и класс дефектов.

  • Атрибуты документа: критические классы дефектов (неоднозначность, противоречие, отсутствие верифицируемости) — 0 открытых; для некритических допустима выборочная инспекция или waiver с обоснованием. Плотность дефектов после инспекции ниже порога (например, < 0,5 дефекта на 10 требований).
  • Трассировка: upstream-связи (к целям/источникам) — 100% для baseline; downstream (к тестам, дизайну) — по договорённости проекта (для регуляторики часто > 95%).
  • Процедура: формальная инспекция по 08.04 Рецензирование и инспекции (техники Фейгана) или эквивалент; журнал дефектов закрыт или принят с обоснованием.
  • Validation: sign-off ключевых стейкхолдеров; подтверждение покрытия scope без gold plating (02.01.04 Определение границ решения (Scope Modelling)).
  • Готовность к разработке: для Agile — соответствие Definition of Ready (DoR) команды; агрегированный чеклист — 10.04 Чеклист аналитика перед стартом разработки.

Gate — решение go/no-go. Метрики без порогов и без владельца решения не работают.

Владелец gate зависит от контекста:

КонтекстКто принимает go/no-goРоль аналитика
Agile / продуктовая командаProduct Owner или делегат с мандатомОрганизует QC, готовит метрики; PO решает по DoR
Проект с BA leadBA lead / lead аналитикВедёт gate, эскалирует к PM/архитектору при рисках
Контракт / регуляторикаУполномоченный представитель заказчика + QA (независимая проверка)Готовит baseline, протокол инспекции, трассировку
Изменение после baselineCCB или эквивалент (02.05.02 Управление изменениями (Change Control Board))Инициирует CR, проводит мини-QC изменённого фрагмента

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

Качество единичного требования vs качество набора

ISO/IEC/IEEE 29148 разделяет критерии для индивидуального требования (§5.2.5) и набора требований (§5.2.6). Единичное может быть атомарным и верифицируемым, но набор при этом неполон или противоречив scope. Обе плоскости нужны при оценке — gate проверяет и строку, и коллекцию.

Модель ISO/IEC/IEEE 29148: единичное требование (§5.2.5)

Стандарт (заменивший IEEE 830) задаёт свойства качественной формулировки — см. также 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148):

  • Корректность (Correctness) — точное отражение потребности.
  • Недвусмысленность (Unambiguity) — одна интерпретация; помогают глоссарий (10.01.14 Шаблон глоссария и словаря данных), 02.03.03 Спецификация требований (SRS, Use Case, User Story) и шаблоны EARS/INCOSE.
  • Полнота (Completeness) — нет пробелов на уровне одного требования.
  • Непротиворечивость (Consistency) — формулировка не конфликтует с другими в том же контексте.
  • Ранжирование (Ranked) — приоритет и стабильность зафиксированы; в BABOK эквивалент — Prioritized (одна идея, разная терминология сводов).
  • Верифицируемость (Verifiability) — есть практически реализуемый способ проверки.
  • Модифицируемость (Modifiability) — структура допускает изменения без разрушения целостности.
  • Трассируемость (Traceability) — идентификатор и связи вверх/вниз; концепция — 02.03.04 Трассировка требований (концепция), артефакт — 10.01.15 Шаблон матрицы трассировки.

Модель ISO/IEC/IEEE 29148: набор требований (§5.2.6)

Критерии набора — отдельная плоскость gate. Типовые проверки:

Атрибут набораЧто проверяемСвязь с gate
Полнота scopeВсе элементы согласованного scope покрыты требованиями; нет «дыр» по процессам, ролям, 02.03.01 Классификация требований (БТ, ФТ, НФТ)Сверка с границами решения (02.01.04 Определение границ решения (Scope Modelling))
Покрытие потребностей стейкхолдеровКаждая зафиксированная потребность имеет трассируемое требованиеUpstream-трассировка 100% на baseline
Согласованность набораНет логических конфликтов между требованиями; единая терминологияМетрика «конфликты» = 0 критических
Отсутствие дубликатовОдна потребность — одно (или явно согласованное) требованиеРевью + RM-инструмент (02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence))
Отсутствие gold platingНет требований вне scope без явного CRValidation sign-off + scope model
Полнота NFRНефункциональные требования не «забыты» в наборе08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 10.01.12 Шаблон нефункциональных требований (NFR)

SMART для единичного требования

SMART как мнемоника для формулировки одного требования — не путать с SMART целей проекта (02.01.02 Цели, KPI и критерии успеха (SMART, GQM)): цель отвечает «зачем проект», требование — «что система должна делать».

  • Specific — один аспект поведения или свойства.
  • Measurable — объективная проверка выполнения.
  • Attainable/Appropriate — реализуемо в ограничениях проекта.
  • Relevant — связано с бизнес-потребностью.
  • Testable — близко к верифицируемости ISO.

Атрибуты BABOK и IREB

BABOK Guide v3 (гл. 7, Verify Requirements) выделяет девять характеристик. Feasible и Achievable не дублируют друг друга: feasible — технически реализуемо при текущих технологиях; achievable — достижимо в рамках ограничений проекта (бюджет, сроки, компетенции команды).

Остальные: Atomic, Complete, Unambiguous, Necessary, Prioritized, Verifiable, Implementation-free (описывает что, не как).

IREB добавляет к документированию: ясную структуру, модифицируемость, расширяемость.

Метрики качества: продукт vs процесс

Метрики продукта описывают свойства документа и входят в gate. Метрики процесса показывают, насколько эффективно команда выявляет и удерживает качество — определения, целевые значения и root-cause — в 08.01 Метрики и KPI процесса анализа.

МетрикаТипОписаниеФормула / операционализация
Плотность дефектовПродуктДефекты на единицу объёма(Число дефектов) / (Количество требований) × N, где N — масштаб (например, 10)
Доля неоднозначных требованийПродуктСубъективные формулировки («быстро», «удобно»)(Неоднозначные) / (Все) × 100%
Upstream-трассируемостьПродуктСвязи к источникам и бизнес-целям(Требования со связями вверх) / (Все) × 100%
Downstream-покрытие трассировкиПродуктСвязи к дизайну и тестам(Требования со связями вниз) / (Все) × 100%
Количество конфликтов набораПродуктПары противоречащих требований (§5.2.6)Подсчёт при ревью или инструментально; разделение критических / некритических
Полнота покрытия сценариевПродуктОписанные vs согласованный реестр сценариевЗнаменатель = реестр сценариев, зафиксированный на валидации: use cases, результаты воркшопа, test ideas из 02.04.01 Верификация и валидация (V&V) — не «все возможные», а явно выявленные и принятые
Эффективность рецензированияПроцесс→ см. 08.01 Метрики и KPI процесса анализа
Утечка дефектов REПроцесс→ см. 08.01 Метрики и KPI процесса анализаГраница фазы RE = момент baseline / sign-off (контракт) или передача в In Progress / sprint start (Agile) — фиксируется в плане качества
Изменчивость требованийПроцесс→ см. 08.01 Метрики и KPI процесса анализа
Время разрешения измененийПроцесс→ см. 08.01 Метрики и KPI процесса анализа

Upstream и downstream трассируемость измеряются отдельно — не смешивайте в одном KPI. Высокая изменчивость после baseline в Agile может быть нормой; сигнал слабого elicitation — если меняются формулировки без изменения scope и без traceable CR (02.05.02 Управление приоритетами в условиях изменчивости, 02.05.03 Управление объёмом (Scope Creep) и ожиданиями).

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

Сквозной процесс

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

  1. Планирование качества — план по шаблону из §1: шаблоны, gate, роли, метрики, частота ревью.
  2. Стандарты и QA — шаблоны BRD/SRS/US (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD), 10.01.01 Шаблон User Story), правила идентификации, EARS/INCOSE, обучение команды.
  3. Проверки при написании — чек-листы; линтеры в RM-инструменте (02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence)) или текстовые проверки в CI (07.06 CICD и конвейеры — влияние на требования); ранние обзоры со стейкхолдерами.
  4. Формальное рецензирование (QC) — статическое тестирование (08.03 Тестирование требований (статическое тестирование)), при необходимости инспекции по Фейгану (08.04 Рецензирование и инспекции (техники Фейгана)): роли, IEEE 1028, журнал дефектов, решение о baseline.
  5. Измерение и коррекция — сбор продуктовых метрик для gate; процессные — в 08.01 Метрики и KPI процесса анализа; root-cause, доработка шаблонов.
  6. Управление изменениями — каждый CR проходит мини-цикл QC (02.05.02 Управление изменениями (Change Control Board)).

Техники QC по атрибутам

Вместо освоения каждой техники «в общем» — привязка к атрибуту ISO. Детали техник — в соседних статьях.

Атрибут ISOТехникаГде подробнее
НедвусмысленностьEARS, INCOSE-шаблоны, глоссарийINCOSE Guide; 02.03.03 Спецификация требований (SRS, Use Case, User Story)
ВерифицируемостьBDD-сценарии, Specification by Example02.04.02 Критерии приёмки (Acceptance Criteria); Gojko Adzic, «Specification by Example»
Полнота / согласованность набораЧек-листы, perspective-based reading (чтение с позиции роли: test/dev/ops)08.03 Тестирование требований (статическое тестирование)
Конфликты, трассируемостьМатрица трассировки, RM-инструмент02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки
Критические дефекты перед baselineФормальная инспекция08.04 Рецензирование и инспекции (техники Фейгана)

Роль аналитика

Аналитик владеет планом качества и стандартами, организует ревью, собирает продуктовые метрики для gate и проводит root-cause при системных дефектах (например, после слабой фасилитации — 02.02.02 Воркшопы, фасилитация и совместные сессии; при неверных приоритетах — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)). При обнаружении дефекта исправляет не только текст, но и процесс, который его породил.

Чек-листы по формату артефакта

Атрибуты качества одинаковы независимо от формата; меняется только шаблон проверки. Для SRS/BRD/регуляторного набора — структура из 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD) плюс gate §5.2.6 (полнота scope, NFR, конфликты). Ниже — фрагмент для User Story (04.02 Пользовательские истории (User Stories) и Job Stories); полный перечень полей SRS не дублируется.

  1. Структура

    • Формат «Как <роль>, я хочу <действие>, чтобы <ценность>»
    • Ценность обоснована
    • Размер согласован с командой (эвристика DoR, не атрибут ISO — обычно «не крупнее N SP» по договорённости в 05.02 Scrum и Kanban (аналитик в Agile))

  2. Критерии приёмки — см. 02.04.02 Критерии приёмки (Acceptance Criteria)

    • Happy path, ключевые негативные и граничные сценарии
    • Без технических деталей реализации
    • Каждый критерий бинарно тестируем

  3. Атрибуты качества

  4. Трассируемость

ИИ как вспомогательный инструмент

Генеративный ИИ может ускорить проверку синтаксических атрибутов (ясность, структура по INCOSE/EARS) и подсказать пропуски в трассировке, но контекстную валидацию и решения go/no-go остаются за аналитиком. Пилоты и vendor-материалы не заменяют инспекции — см. 11.07 Практические кейсы применения LLM в анализе, 11.03 Промпт-инжиниринг для аналитика; не подменяйте ими классический QA/QC процесс.

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

  • Объявить planning, но не зафиксировать план — метрики и gate «в голове»; нет ролей, частоты ревью и границы фазы RE.
  • Сужать качество до верификации — игнорировать validation со стейкхолдерами; «документ без дефектов», но не тот продукт.
  • Проверять только единичные требования — игнорировать §5.2.6: набор полный по форме, но с дырами в scope или дубликатами.
  • Метрики без gate и владельца — собирать трассируемость и плотность дефектов, но не фиксировать пороги и кто принимает go/no-go.
  • Жёсткий «0% неоднозначных» на большой SRS — без классификации дефектов, waiver и выборочной инспекции gate становится формальностью или блокером.
  • Смешивать SMART целей и SMART требований — измеримая цель проекта не заменяет верифицируемую формулировку требования.
  • Один KPI на всю трассируемость — upstream и downstream нужно разводить.
  • Путать Feasible и Achievable — техническая возможность ≠ достижимость в рамках проекта.
  • SP и DoR как «качество ISO» — это командные договорённости Agile, не нормативные атрибуты спецификации.
  • Чек-лист только для User Story — для SRS нужны те же атрибуты на уровне набора через шаблон 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).
  • Передача качества ИИ — автоматическая оценка слаба на контексте и конфликтах интересов стейкхолдеров (01.07 Когнитивные искажения и критическое мышление).

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

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

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

  1. ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering (§5.2.5, §5.2.6). IEEE Xplore (может требовать институциональный доступ).
  2. BABOK Guide v3, IIBA — гл. 7, Verify Requirements. IIBA: BABOK.
  3. IREB CPRE Foundation Level Syllabus — раздел «Качество требований». IREB Downloads.
  4. IEEE Std 1028-2008 — Standard for Software Reviews and Audits. IEEE Xplore.
  5. INCOSE Guide for Writing Requirements — критерии качества формулировок. INCOSE Requirements Working Group.
  6. Karl E. Wiegers, Joy Beatty, «Software Requirements», 3rd ed. — Microsoft Press, 2013.
  7. Suzanne Robertson, James Robertson, «Mastering the Requirements Process», 3rd ed. — Addison-Wesley, 2012.
  8. Capers Jones, Olivier Bonsignour, «The Economics of Software Quality» — Addison-Wesley, 2011 (экономика дефектов, в т.ч. эвристика 1-10-100).
  9. Gojko Adzic, «Specification by Example» — Manning, 2011 (связка примеров, BDD и валидации требований).

Статьи

  1. P. Mavin et al., «Easy Approach to Requirements Syntax (EARS)» — IEEE 2009 / INCOSE working material; краткий обзор синтаксиса EARS.
  2. Adam J. Fleischer, «Requirements Management KPIs: Measuring Requirements Quality» — Altium, 2025. resources.altium.com.
  3. DOU, «Критерии качества требований и как им следовать» (Иванова и др.), 2021. dou.ua/forums/topic/35139.

ИИ в RE (ориентиры, не норматив)

  1. Oz Levy et al., «AI-Assisted Requirements Engineering: An Empirical Evaluation Relative to Expert Judgment» — arXiv, 2026; предварительные данные, не заменяют экспертный QC.
  2. B. Bluemelhuber, S. Junker, «Engineering Better Requirements: Understanding the Impact of GenAI…» — HICSS-59, 2026. scholarspace.manoa.hawaii.edu.

Смежно: ГОСТ Р 54536 / ISO 25010 описывает качество продукта, не спецификации требований — подробнее в 08.02 Нефункциональные требования (НФТ) — классификация и стандарты.