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

Цель урока

Научиться оценивать и улучшать качество требований. Изучить стандарты качества (ISO/IEC 25010, IEEE 830), метрики качества требований и методы валидации требований: reviews, walkthroughs, inspections. Освоить методологию Fagan Inspection на молекулярном уровне. Понять, что такое технический долг требований и как с ним бороться.

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

Quality of Requirements — характеристика требований: точность, полнота, однозначность, проверяемость
ISO/IEC 25010 — стандарт качества ПО и данных (заменил ISO 9126)
Requirements Review — формальный или неформальный анализ требований группой экспертов
Walkthrough — неформальная презентация требований автором для получения обратной связи
Inspection (Инспекция) — формальный процесс проверки требований по чек-листу; метод Майкла Фэгана (IBM, 1976)
Fagan Inspection — наиболее эффективный метод выявления дефектов в требованиях (60–90% обнаружения)
Технический долг требований — накопленные несоответствия, которые замедляют разработку
Метрики (Metrics) — измеримые показатели качества требований
Правило инспекции: «Не обсуждаем решения, только фиксируем проблемы» — фундаментальный принцип, нарушение которого разрушает эффективность инспекции

1. Что такое «качество требований»?

1.1. Хорошее vs Плохое требование

Хорошее требование	Плохое требование
«Система должна проверять email на формат username@domain.tld»	«Система должна быть удобной»
«Время ответа API не должно превышать 200 мс для 95% запросов»	«Система должна работать быстро»
«При вводе пароля короче 8 символов — ошибка "Пароль должен быть минимум 8 символов"»	«Пароль должен быть надёжным»
«Количество одновременных пользователей — не менее 1000»	«Система должна выдерживать нагрузку»
«При удалении задачи с комментариями — комментарии также удаляются»	«Пользователь может управлять своими данными»

1.2. Критерии качества требований (по IEEE 830)

Критерий	Описание	Пример нарушения
Correct (Корректность)	Требование отражает реальную потребность	«Отправлять email» — а заказчик хотел SMS
Unambiguous (Однозначность)	Только одна интерпретация	«Большой файл» — 1 MB или 1 GB?
Complete (Полнота)	Все условия, сценарии, ошибки описаны	Не сказано, что делать при ошибке
Consistent (Согласованность)	Нет противоречий с другими требованиями	FR-01: «Только админ удаляет задачи», FR-02: «Пользователь может удалить свою задачу»
Verifiable (Проверяемость)	Можно написать тест	«Быстрый отклик» — как измерить?
Modifiable (Изменяемость)	Легко вносить изменения	Всё в одном абзаце — нельзя изменить одно без риска сломать другое
Traceable (Трассируемость)	Можно отследить источник	«Сделать круто» — откуда это? Из какого интервью?

2. Стандарты качества

2.1. ISO/IEC 25010 (Quality Model)

Определяет 8 характеристик качества ПО:

Характеристика	Подхарактеристики	Пример для Task Manager
Functional Suitability	Functional completeness, correctness, appropriateness	Все ли функции из Use Case реализованы?
Performance Efficiency	Time behavior, resource utilization	Страница задач грузится < 1 сек
Compatibility	Co-existence, interoperability	Интеграция со Slack через API
Usability	Appropriateness, learnability, accessibility	Новая форма создания задачи интуитивна
Reliability	Maturity, availability, fault tolerance	Система доступна 99.9%, при ошибке — retry
Security	Confidentiality, integrity, non-repudiation	Только автор задачи может её удалить
Maintainability	Modularity, reusability, testability	Код легко менять, требования легко тестировать
Portability	Adaptability, installability	Система работает в Docker и на bare-metal

Для аналитика: Используйте ISO 25010 как чек-лист для нефункциональных требований. Проходя по каждой характеристике, вы не пропустите важный аспект.

2.2. IEEE 830 (SRS — Software Requirements Specification)

Стандарт структуры документа требований (подробно в модуле 03). Определяет разделы: Introduction, Overall Description, Specific Requirements, Appendices.

3. Метрики качества требований

3.1. Количественные метрики

Метрика	Формула	Цель	Целевое значение
Плотность дефектов в требованиях	Число дефектов / Количество требований	Оценить качество	< 0.1 (1 дефект на 10 требований)
Покрытие требований тестами	Число требований с тест-кейсами / Всего требований	Оценить готовность к тестированию	> 90%
Стабильность требований	Число неизменных требований / Всего требований	Понять, насколько требования «заморожены»	> 80% к середине проекта
Среднее время review	Суммарное время / Число требований	Норма для планирования	~ 30–60 мин на требование
Число требований	—	Размер проекта	50–200 для среднего проекта
Эффективность review	Дефекты при review / (Дефекты при review + Дефекты при разработке) × 100%	Оценить качество процесса	> 70%

3.2. Качественные метрики (оценка экспертом)

По шкале 1–5 (1 — плохо, 5 — отлично):

Критерий	Оценка (1–5)	Комментарий
Полнота	4	Все сценарии описаны, но нет Error Path
Однозначность	3	«Данные должны быть актуальны» — неоднозначно
Проверяемость	5	К каждому требованию можно написать тест
Согласованность	2	FR-03 противоречит FR-07

3.3. Как интерпретировать метрики

Метрика	Значение	Интерпретация
Плотность дефектов	0.05	Отлично. Меньше 1 дефекта на 20 требований.
Плотность дефектов	0.2	Плохо. 2 дефекта на 10 требований. Требования сырые, нужен рерайт.
Покрытие тестами	95%	Отлично. Почти всё покрыто.
Покрытие тестами	60%	Плохо. 40% требований не проверяются — риск пропущенных багов.
Стабильность (месяц 1)	30%	Нормально. В начале проекта требования часто меняются.
Стабильность (месяц 6)	95%	Отлично. Требования заморожены.
Стабильность (месяц 6)	50%	Плохо. Требования всё ещё нестабильны — риск срыва сроков.
Эффективность review	85%	Отлично. Большинство дефектов найдено до разработки.
Эффективность review	40%	Плохо. Много дефектов «протекает» в разработку — нужно усилить review.

4. Методы валидации требований

4.1. Сравнение методов

Метод	Формальность	Участники	Время	Находит
Walkthrough	Низкая	Автор + заинтересованные	1 час	Очевидные ошибки
Peer Review	Средняя	Автор + 1–2 коллеги	30 мин	Пропуски, неоднозначности
Inspection	Высокая	Автор + модератор + инспекторы	2–4 часа	Все типы дефектов (самый эффективный)
Checklist-based	Средняя	Автор + любой	15 мин	Стандартные ошибки

4.2. Walkthrough (Обзор)

Процесс:

Автор рассылает требования за 1 день до встречи
На встрече автор «проводит» слушателей по тексту
Участники задают вопросы, предлагают исправления
Все замечания фиксируются

Когда проводить: На ранних стадиях, когда требования неформальные. Для быстрой обратной связи.

Недостаток: Низкая эффективность (находит ~30% дефектов). Автор может «вести» слушателей по тексту так, что они пропустят проблемы.

4.3. Fagan Inspection (Инспекция) — полный разбор

Разработана Майклом Фэганом в IBM (1976). Это формальный, структурированный процесс, который находит 60–90% дефектов требований.

4.3.1. Шесть шагов инспекции

Шаг 1: Planning (Планирование)
  │
  ▼
Шаг 2: Overview (Обзор)
  │
  ▼
Шаг 3: Preparation (Подготовка)
  │
  ▼
Шаг 4: Inspection Meeting (Инспекционная встреча)
  │
  ▼
Шаг 5: Rework (Доработка)
  │
  ▼
Шаг 6: Follow-up (Контроль)

Шаг 1: Planning (Планирование)

Модератор выбирает:

Материал для инспекции — какой фрагмент требований проверяется (не более 10–20 страниц за одну инспекцию)
Участников — автор, модератор, инспекторы (3–5 человек)
Время — встреча 1.5–3 часа, подготовка 1–2 часа на каждого инспектора
Роли — распределяет заранее

Шаг 2: Overview (Обзор)

Автор кратко описывает контекст (15–20 минут):

Что это за функция?
Какие бизнес-процессы она поддерживает?
Какие предположения сделаны?
Какие части документа самые сложные?

Цель: Дать инспекторам контекст, чтобы они могли понять требования, а не просто читать текст.

Шаг 3: Preparation (Подготовка)

Самый важный шаг для качества. Каждый инспектор самостоятельно изучает требования, используя чек-лист (см. раздел 5).

Что делает инспектор:

Читает каждое требование
Применяет критерии IEEE 830
Выписывает потенциальные дефекты
Отмечает неоднозначности, пропуски, противоречия

Время: 1–2 часа на 10–20 страниц. Если инспектор не успел подготовиться — встреча переносится.

Шаг 4: Inspection Meeting (Инспекционная встреча)

Самый важный шаг для процесса. Именно здесь действует фундаментальное правило.

4.3.2. Фундаментальное правило инспекции: «Только фиксация, без решений»

Правило: На инспекционной встрече запрещено обсуждать, как исправить найденную проблему. Разрешена только фиксация:

«Вот проблема»
«Вот где она находится»
«Какой критерий IEEE 830 нарушен»

Почему это критически важно:

Если обсуждать решения	Если только фиксировать
Встреча длится 4+ часов вместо 1.5	Встреча укладывается в тайминг
Участники спорят о решениях, забывая о проблемах	Все внимание — на поиск проблем
Инспекторы «выгорают» к 3-му часу и перестают находить дефекты	Инспекторы работают эффективно всю встречу
Автор чувствует себя «под атакой» и начинает защищаться	Автор спокоен — решения будут обсуждаться позже
Обсуждается 1 проблема 20 минут, а 5 проблем остаются незамеченными	За 20 минут фиксируется 5–10 проблем

Аналогия: Представьте, что врач на приёме вместо того, чтобы поставить диагноз, начинает обсуждать с вами схему лечения. «У вас кашель. Давайте подумаем: может, антибиотики? Или ингаляции? А может, народные средства?» — пока они обсуждают, пациент с инфарктом умрёт в коридоре. Сначала диагностика (фиксация проблем), потом лечение (решение проблем) — на разных встречах.

Как это выглядит на практике:

❌ НЕПРАВИЛЬНО:
Модератор: «Какие замечания?»
Инспектор 1: «В пункте 3.2 не указано, что делать при ошибке. 
   Я предлагаю добавить retry 3 раза с интервалом 30 секунд...»
Модератор: «Хорошее предложение. А если retry не поможет? 
   Может, circuit breaker?»
Инспектор 2: «Нет, circuit breaker слишком сложно для этого случая. 
   Давайте просто логировать...»
— 15 минут потрачено на обсуждение решения одной проблемы.
— 5 других проблем не найдены.

✅ ПРАВИЛЬНО:
Модератор: «Какие замечания?»
Инспектор 1: «В пункте 3.2 не указано, что делать при ошибке. 
   Это нарушение полноты (Complete).»
Модератор: «Записал: пункт 3.2, отсутствует Error Path, 
   нарушение Complete. Следующее замечание?»
Инспектор 2: «В пункте 4.1 термин "большой файл" не определён — 
   нарушение однозначности (Unambiguous).»
Модератор: «Записал. Дальше?»
— 2 минуты на проблему. 10 проблем зафиксированы за 20 минут.

Роль модератора: Следить за соблюдением правила. Если кто-то начинает предлагать решение — мягко прерывать:

«Отличная идея! Давайте запишем проблему и вернёмся к решениям на этапе Rework. Какое следующее замечание?»

Шаг 5: Rework (Доработка)

Автор самостоятельно исправляет требования на основе зафиксированных проблем:

Переписывает неоднозначные формулировки
Добавляет пропущенные сценарии
Устраняет противоречия

Время: 1–3 дня (зависит от количества проблем). Автор не должен согласовывать исправления — он автор, он решает, как исправить.

Шаг 6: Follow-up (Контроль)

Модератор проверяет, что все проблемы исправлены:

Каждая проблема имеет статус: Fixed / Not Fixed / Won't Fix
Если проблема не исправлена — автор объясняет почему
Если проблема критическая — назначается повторная инспекция

4.3.3. Роли в инспекции

Роль	Кто	Что делает	Чего НЕ делает
Author (Автор)	Аналитик, написавший требования	Предоставляет материал, отвечает на вопросы контекста	Не ведёт встречу, не защищает требования
Moderator (Модератор)	Старший аналитик / архитектор	Планирует, ведёт встречу, следит за правилами, фиксирует	Не предлагает решения, не является автором
Inspector (Инспектор)	Разработчик, тестировщик, другой аналитик	Ищет дефекты, применяет чек-лист	Не исправляет дефекты (это работа автора)
Scribe (Секретарь)	Может совпадать с модератором	Записывает замечания	—

4.3.4. Что проверяется на инспекции

Категория	Что ищем
Пропуски	Отсутствуют сценарии, не описаны ошибки, нет альтернативных потоков
Неоднозначности	Термины без определений, субъективные оценки («быстро», «удобно»)
Противоречия	Два требования говорят разное об одном и том же
Непроверяемость	Нельзя написать тест (нет критериев приёмки)
Нереалистичность	Технически невозможно (например, «всегда 100% uptime»)
Избыточность	Требование не нужно, дублирует другое, или не соответствует бизнес-целям

4.3.5. Эффективность Fagan Inspection

Метрика	Walkthrough	Peer Review	Fagan Inspection
Дефектов найдено до разработки	25–40%	30–55%	60–90%
Стоимость исправления после разработки	×10	×10	×1 (исправление на стадии требований — самое дешёвое)
Время на 10 страниц требований	1 час	1.5 часа	3–4 часа (с подготовкой)
Требуется обучение?	Нет	Минимальное	Да (особенно модератору)

Экономический эффект (по данным IBM): Исправление дефекта на этапе требований стоит $100. На этапе разработки — $1000. На этапе эксплуатации — $10 000. Inspection возвращает $10 на каждый $1, вложенный в процесс.

4.3.6. Когда проводить инспекцию

Ситуация	Inspection?	Почему
Крупный проект (>50 требований)	✅	Высокий риск
Критическая функция (платёж, безопасность)	✅	Ошибка = деньги/безопасность
Новый предметная область	✅	Аналитик может не знать всех нюансов
После обнаружения дефектов на прошлой итерации	✅	Проблема системная, нужен формальный подход
Небольшое изменение (1–2 User Story)	❌	Достаточно Peer Review
Прототип/MVP	❌	Inspection замедлит, а требования всё равно будут меняться

5. Чек-лист для review требований

5.1. Функциональные требования

№	Вопрос
1	Каждый ли Use Case / User Story имеет Acceptance Criteria?
2	Описаны ли все альтернативные потоки?
3	Описаны ли исключительные потоки (ошибки)?
4	Указаны ли роли (кто выполняет)?
5	Есть ли примеры данных (не абстрактно)?
6	Можно ли по требованию написать тест-кейс?
7	Нет ли слов-паразитов («быстро», «удобно», «большой», «разные»)?

5.2. Нефункциональные требования

№	Вопрос
1	Указаны ли требования к производительности? (время ответа, throughput)
2	Указаны ли требования к безопасности? (аутентификация, роли)
3	Указаны ли требования к доступности? (SLA 99.9%)
4	Указаны ли совместимость и интеграции?
5	Указаны ли требования к usability?

5.3. Проектные мета-требования

№	Вопрос
1	Каждое требование имеет уникальный ID?
2	Есть ли трассировка к источнику (интервью, документ)?
3	Нет ли противоречий между требованиями?
4	Требования атомарны? (нельзя разбить на несколько)
5	Требования можно приоритизировать (MoSCoW)?

6. Технический долг требований

6.1. Что это такое

Технический долг требований (Requirements Debt) — накопленные несоответствия, пропуски и неоднозначности в требованиях, которые со временем замедляют разработку. Аналогия — технический долг в коде, но ещё опаснее: код можно отрефакторить, а требования, записанные «в общих словах», приходится пересобирать заново.

6.2. Виды технического долга требований

Тип долга	Пример	Последствия
Missing (Пропуски)	Не описан Error Path для сценария	Разработчик сам придумывает поведение (обычно неверное)
Vague (Размытость)	«Система должна быть быстрой»	Невозможно проверить, каждый трактует по-своему
Contradictory (Противоречия)	FR-01: «Только админ удаляет», FR-02: «Пользователь удаляет свою задачу»	Разработчик выбирает одно, тестировщик проверяет другое
Untraceable (Нет источника)	«Сделать круто» — откуда это требование?	Нельзя проверить, действительно ли это нужно бизнесу
Unprioritized (Нет приоритетов)	Все требования одинаково важны	Разработчик не знает, что делать в первую очередь
Gold-plating (Избыточность)	«Добавить экспорт в 10 форматов» (хотя нужен только CSV)	Потрачено время на ненужную функциональность

6.3. Как накапливается долг требований

Спринт 1: 
  Требование: «Пользователь может удалить задачу» 
  (не сказано про комментарии — долг №1)

Спринт 2:
  Разработчик реализовал удаление задачи, но комментарии остались 
  в БД (висячие данные — баг в эксплуатации)
  → Исправление: «При удалении задачи комментарии тоже удаляются»

Спринт 3:
  Появилось требование: «Комментарии можно восстановить»
  → Переделка: теперь не удаляем, а помечаем is_deleted=true
  (Потрачено в 5 раз больше времени, чем если бы учли изначально)

6.4. Как бороться с техническим долгом требований

Долг	Решение	Профилактика
«Размытые» формулировки	Переписать с использованием техник (урок 03.02)	Self-review по чек-листу
Отсутствие Error Path	Дополнить Acceptance Criteria	В чек-лист review добавить пункт «Error Path описан?»
Противоречия	Провести inspection	Матрица трассировки (RTM)
Нет трассировки	Создать RTM (урок 03.03)	Требовать ссылку на источник при создании каждого требования
Нет приоритетов	Применить MoSCoW	Политика проекта: «Каждое требование имеет приоритет»
Gold-plating	Задать вопрос: «Это действительно нужно для MVP?»	Техника «5 почему»

6.5. Чек-лист: есть ли у вас долг в требованиях?

Признак	Если «да» — у вас долг
Разработчики постоянно приходят уточнять требования?	⚠️ Долг есть
Тестировщики находят баги, которые на самом деле — неописанные сценарии?	⚠️ Долг есть
Одно и то же требование переписывают 3+ раза?	⚠️ Долг есть
Заказчик говорит «я же просил по-другому» после демо?	⚠️ Долг есть
Вы не можете найти, откуда взялось требование?	⚠️ Долг есть

7. Процесс управления качеством требований

Сбор требований
      │
      ▼
Документирование (User Story / SRS)
      │
      ▼
Self-review (автор проверяет по чек-листу)
      │
      ▼
Peer Review / Walkthrough (с коллегами)
      │
      ▼
Исправление замечаний
      │
      ▼
Согласование с заказчиком (Sign-off)
      │
      ▼
Требование в разработку

Когда проводить Fagan Inspection

                   ┌─────────────────────────────┐
                   │ Новый модуль > 50 требований?│
                   │ Да ──→ Fagan Inspection      │
                   │ Нет ─→ ┌─────────────────┐   │
                   │        │ Критическая      │   │
                   │        │ функция? (платёж,│   │
                   │        │ безопасность)    │   │
                   │        │ Да ──→ Inspection│   │
                   │        │ Нет ──→ Peer Rev.│   │
                   │        └─────────────────┘   │
                   └─────────────────────────────┘

8. Сравнение всех методов валидации требований

Характеристика	Self-Review	Walkthrough	Peer Review	Fagan Inspection
Участников	1	3–5	3	4–6
Время подготовки	15 мин	—	30 мин	1–2 часа
Время встречи	—	1 час	30 мин	2–3 часа
Эффективность	20%	25–40%	30–55%	60–90%
Формальность	Низкая	Низкая	Средняя	Высокая
Роли	Нет	Нет	Нет	Автор, Модератор, Инспекторы
Чек-лист	Опционально	Опционально	Обязательно	Обязательно
Обсуждение решений	Да	Да	Да	❌ ЗАПРЕЩЕНО
Когда применять	Всегда	Ранние стадии	Стандарт	Крупные/критические модули

Вопросы для самопроверки

Какие 7 критериев качества требований по IEEE 830 вы знаете?
Что такое ISO 25010? Какие характеристики качества она определяет?
Чем Walkthrough отличается от Inspection?
Какие 6 шагов в методологии Fagan Inspection?
Почему на инспекционной встрече запрещено обсуждать решения? К каким последствиям приводит нарушение этого правила?
Какие роли участвуют в инспекции требований? Что делает каждая?
Какую метрику можно использовать для оценки стабильности требований?
Что такое «технический долг требований»? Приведите 3 примера.
Почему важно проверять требования ДО начала разработки?
Какая эффективность у Fagan Inspection? А у Walkthrough?
Что такое «золотой напыление» (gold-plating) в требованиях?
Какие 4 метрики качества требований вы знаете? Какие у них целевые значения?

Практическое задание

Задание 1. Оцените качество требований

Даны 5 требований. Для каждого:

Оцените по шкале 1–5 (1 — плохо, 5 — отлично) по критериям IEEE 830 (однозначность, полнота, проверяемость)
Если оценка < 4 — перепишите требование в корректном виде

Требования:

«Система должна быть быстрой и не тормозить.»
«При создании задачи система проверяет, что заголовок не пустой. Если заголовок пустой — отображается ошибка "Заголовок не может быть пустым".»
«Пользователь может управлять своими данными.»
«Пароль пользователя должен быть безопасным.»
«Система отправляет уведомление при изменении статуса задачи: email — исполнителю, если статус изменился на Done; Slack — автору, если приоритет Critical; уведомление не отправляется, если пользователь отключил уведомления в настройках.»

Задание 2. Проведите review требований

Вы получили на review User Story:

US-042: Как пользователь, я могу удалить свою задачу, чтобы убрать её из списка.

Acceptance Criteria:

Пользователь нажимает «Удалить» на задаче
Система запрашивает подтверждение
После подтверждения задача удаляется
Задача не отображается в списке

Найдите 5 проблем (проверьте по чек-листу из урока).

Формат:

№	Проблема	Тип (из IEEE 830)	Как исправить
1
2

Задание 3. Инспекция Fagan

Вы — модератор инспекции. Ваша команда проверяет требование FR-10.

Инспектируемый фрагмент:

FR-10: Удаление задачи
Пользователь может удалить задачу. Задача удаляется безвозвратно.

Задания:

Распределите роли (кто Author, Moderator, Inspectors, Scribe)
Найдите минимум 5 проблем, используя чек-лист
Во время инспекционной встречи один из инспекторов начинает предлагать решение: «Давайте при удалении задачи архивировать её, а не удалять безвозвратно». Как модератор должен отреагировать? Напишите фразу.
После встречи — напишите исправленную версию FR-10 с Acceptance Criteria

Задание 4. Метрики

Дан проект с 50 требованиями. После review найдено 12 дефектов в требованиях.

Посчитайте плотность дефектов в требованиях.
Хороший ли это показатель?
Через месяц добавили 10 требований и изменили 3 из 50 исходных. Какая стабильность требований?

Дополнительные данные для анализа:

Из 12 дефектов 2 нашли при разработке (пропустил review)
Требований, покрытых тест-кейсами — 40
Слов-паразитов в SRS — 7 («быстро», «удобно», «достаточно»)

Дополнительные вопросы:

Посчитайте эффективность review
Посчитайте покрытие тестами
Какая метрика самая критичная? Почему?
Что бы вы рекомендовали улучшить в первую очередь?

Дополнительные материалы

Стандарт: ISO/IEC 25010:2011 — Systems and software Quality Requirements and Evaluation (SQuaRE)
Стандарт: IEEE 830-1998 — Recommended Practice for Software Requirements Specifications
Книга: Сьюзан Робертсон — «Mastering the Requirements Process» — о качестве требований
Книга: Карл Вигерс — «Разработка требований к ПО» — главы о рецензировании требований
Статья: Michael Fagan — «Design and Code Inspections to Reduce Errors in Program Development» (IBM Systems Journal, 1976) — оригинальная статья
Статья: «Fagan Inspection: The Most Effective Way to Find Defects in Requirements» — современный обзор
Шпаргалка: «Requirements Review Checklist» — одностраничный чек-лист
Практика: Взять любое реальное требование из своего проекта и провести self-review по чек-листу
Книга: Tom Gilb — «Competitive Engineering» — количественные методы в требованиях