Формальная инспекция — самый строгий метод статического тестирования: регламент, роли, протокол дефектов и обязательный follow-up. Для системного аналитика она закрывает вопрос «готов ли артефакт к передаче в разработку» — SRS, User Story, Use Case, OpenAPI, BPMN и связанные модели. Ниже — адаптация классического процесса Фейгана под эти объекты; обзор всех методов статической проверки и чек-листы качества — в 08.03 Тестирование требований (статическое тестирование). Тот же каркас процесса применим к коду и дизайну, но с другими чек-листами и составом группы — это уже STLC и смежные практики, не фокус данной статьи.

1. Суть темы

Методы проверки документов образуют шкалу формальности — от неформального peer review до регламентированной инспекции (inspection). Инспекция Фейгана находится на верхнем полюсе: цель — не обсуждение и не обучение, а поиск и документирование дефектов в рабочем продукте. Полная шкала (peer review, walkthrough, inspection, аудит) и risk-based выбор метода — в 08.03 Тестирование требований (статическое тестирование); здесь — контекст именно для инспекции.

Асинхронное рецензирование (комментарии в ALM, Confluence или PR без собрания) по дисциплине протокола стоит ниже walkthrough, но выше casual peer review: замечания фиксируются, есть follow-up, но нет модератора и группового согласования дефектов на встрече. Многие команды подменяют им meeting — это допустимо для низкорисковых срезов, но не заменяет формальную инспекцию при compliance или контрактном sign-off.

Место в жизненном цикле: инспекция артефакта анализа выполняется до baselining требований, передачи в разработку или merge PR в docs-as-code — после того, как автор считает документ готовым, но до contract gate или старта реализации (00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC)). В Agile это не каждый спринт, а risk-based точки: релизный срез SRS, критичные User Story после refinement, контрактные OpenAPI перед интеграцией. Sprint Review и UAT — validation результата, не инспекция текста требований.

Аудит (audit) — отдельная практика: независимая проверка соответствия процесса и выборки артефактов стандартам; итог — несоответствия процессу, а не цикл «дефект → rework → follow-up» одного документа. Не путайте инспекцию артефакта с аудитом зрелости процесса (08.01 Метрики и KPI процесса анализа).

Инспекция в первую очередь относится к верификации (verification): «правильно ли описан артефакт для команды» — однозначность, полнота атрибутов, непротиворечивость, тестируемость. Валидация (validation) — «то ли мы описываем для бизнеса» — чаще закрывается walkthrough с заказчиком и приёмочными сессиями, а не формальной инспекцией. Различие и комбинации методов — 02.04.01 Верификация и валидация (V&V).

Оригинальная работа Fagan (1976) описывала инспекции design и code; перенос на SRS, контракты и модели — через расширения Gilb/Graham и практику рецензирования требований (Wiegers, Robertson). Каркас этапов сохраняется, меняются чек-листы и состав группы.

Исправление дефекта на этапе требований обычно дешевле, чем после релиза, но конкретный множитель зависит от типа дефекта и процесса проекта; ориентир «в десятки раз» — индустриальный тезис, а не универсальная константа.

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

2.1. Полный процесс Фейгана и облегчённый вариант

Классический процесс Фейгана (1976) и расширения Gilb/Graham включают планирование, подготовку, собрание, доработку и follow-up. В схеме Gilb иногда добавляют Overview — короткое обзорное собрание до индивидуальной подготовки; для небольших артефактов и облегчённого варианта его пропускают.

Планирование — активность модератора до рассылки материалов, отдельная от entry criteria:

  • Срез документа — какие разделы, истории или контракты входят в сессию; объём не более 10–15 страниц или 5–7 User Stories.
  • Состав группы — рецензенты с нужными перспективами (разработка, тест, архитектура, безопасность для API/NFR); модератор не автор.
  • Календарь — дата собрания, срок индивидуальной подготовки (обычно 1–3 рабочих дня), дедлайн rework и follow-up.
  • Регламент — правила фиксации спорных пунктов, шкала severity (согласовать с 08.03 Тестирование требований (статическое тестирование)), шаблон протокола.
  • Критерии готовности к инспекции — checklist модератора перед рассылкой; совпадает с entry criteria (§3.1), но проверяется как решение «назначать собрание или вернуть автору».

Систематический анализ метрик (плотность дефектов, доля находок на подготовке vs на собрании) — элемент зрелого программного инспекционного процесса (Fagan 1986, Gilb), но не обязателен для каждой сессии. На проекте различайте:

ВариантКогдаОбязательные этапы
Полная инспекцияВысокий риск, SRS релизного среза, complianceПланирование → (Overview) → подготовка → собрание → rework → follow-up; метрики + sign-off
Облегчённая инспекцияBacklog refinement, 5–7 User Stories, PR в docs-as-codeПланирование (краткое) → подготовка → короткое собрание → rework → выборочный follow-up

Сопоставление с ISO/IEC 20246 (work product reviews): planning → Планирование; individual review → Подготовка; joint review → Собрание инспекции; исправления и проверка — Доработка и Follow-up. Overview в стандарте не выделен — это практика Gilb до individual review.

graph TD
    A[Планирование] --> O[Overview — опционально]
    A --> B[Подготовка]
    O --> B
    B --> C[Собрание инспекции]
    C --> D[Доработка]
    D --> E[Follow-up]
    E --> F{Критерии выхода выполнены?}
    F -- Да --> G[Sign-off / выход]
    F -- Нет --> D
    E -.-> H[Анализ метрик — опционально]

2.2. Роли

РольОбязанностиКто выполняет
Модератор (Moderator)Планирует и ведёт инспекцию, следит за регламентом, разрешает споры, контролирует follow-up. Не автор.Ведущий аналитик, QA, обученный фасилитатор
Автор (Author)Создал документ; на собрании поясняет контекстБизнес- или системный аналитик
Рецензент (Inspector)Изучает материал до встречи, находит дефекты по чек-листамАналитик, архитектор, разработчик, тестировщик
Секретарь (Scribe)Фиксирует согласованные дефекты в протоколеРецензент, не автор
Чтец (Reader)Зачитывает документ на собрании пошаговоЧасто отдельный участник; для кода — каноничная роль

Когда Reader не нужен: для User Story, OpenAPI, BPMN, диаграмм UML и коротких спецификаций рецензенты работают с материалом на экране — модератор ведёт по разделам, автор отвечает на вопросы. Reader сохраняют для плотного линейного текста (SRS, FRD) и обязательно для кода — там зачитывание снижает пропуск строк. Решение фиксируют в планировании.

Малая команда: роли совмещают осознанно — модератор не может быть автором; секретарь часто совмещается с рецензентом; один человек не должен одновременно модерировать и доминировать как единственный эксперт по содержанию. Конфликт «модератор = единственный рецензент» снижает качество: привлеките внешнего участника или разнесите сессии.

2.3. Правила собрания

  • Фокус на дефектах, не на решениях — исправления проектируют после собрания.
  • Критикуется продукт, не автор.
  • Дефект фиксируется при согласии группы; спорные пункты получают статус Needs clarification или Open с назначенным ответственным и сроком — не смешивайте их с закрытыми дефектами в метриках.
  • Тайминг — обычно до 2 часов; при переполнении — новая сессия по следующему срезу документа.

2.4. Классификация дефектов

Категории дефектов требований (Missing, Ambiguous, Incorrect, Extra, Inconsistent, Non-verifiable и др.) согласуют с командой по схеме из 08.03 Тестирование требований (статическое тестирование) — здесь не дублируем полную таксономию.

Шкала severity (Critical/High/Medium или blocker/major/minor) — единая для проекта; базовые определения и примеры — в 08.03 Тестирование требований (статическое тестирование). На инспекции можно уточнить mapping «категория дефекта × impact на релиз» в локальной матрице команды; без согласованной шкалы exit criteria остаются декларативными.

В протоколе указывают ID, локацию, категорию, серьёзность и автора находки.

Пример строк протокола:

IDЛокацияКатегорияОписаниеСерьёзностьОбнаружил
D-01SRS 3.2.1Ambiguity«Быстрый отклик» без метрикВысокаяАрхитектор
D-02SRS 4.1MissingНет сценария отмены заказа после оплатыКритическаяТестировщик
D-03US-42InconsistentAC противоречит диаграмме состоянийСредняяРазработчик

Дефект vs запрос на изменение: исправление опечатки, неоднозначности или пропуска в рамках согласованного scope — rework по протоколу. Если находка меняет границы решения или бизнес-обязательства — оформляйте change request (02.05.02 Управление изменениями (Change Control Board), 02.05.03 Управление объёмом (Scope Creep) и ожиданиями), а не «тихо» правьте SRS.

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

3.1. Входные и выходные критерии

Entry criteria (вход) — до назначения собрания модератор проверяет:

Вход зависит от типа артефакта: для OpenAPI — валидная схема, семантика контракта и описание ошибок (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), 10.01.04 Шаблон спецификации REST API); для BPMN — согласованность с текстовыми требованиями (03.04.01 BPMN 2.0 - введение и основы); для NFR — измеримость (08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 10.01.12 Шаблон нефункциональных требований (NFR)). Неготовый документ возвращают автору без инспекции.

Exit criteria (выход) — согласуйте до первой сессии и фиксируйте в протоколе:

  • все дефекты severity Critical и High закрыты или принят documented waiver (08.05 Управление рисками на этапе анализа);
  • Medium — закрыты или перенесены в backlog с согласия модератора и владельца продукта;
  • пункты Needs clarification — либо переклассифицированы, либо вынесены в отдельный трек;
  • follow-up подтвердил корректность rework (нет регрессий в смежных разделах);
  • для формального среза — sign-off модератора и, при необходимости, владельца требований или QA lead.

Минимум записи waiver: ID связанного дефекта; что именно принято «как есть»; владелец риска (имя/роль); обоснование; срок пересмотра или триггер (следующий релиз, изменение регуляторики). Без этих полей открытый Critical не считается закрытым для exit criteria.

Sign-off означает, что артефакт можно передавать дальше по цепочке (10.04 Чеклист аналитика перед стартом разработки). В Agile sign-off часто заменяет статус в ALM или merge PR после follow-up.

Re-inspection (повторная инспекция): если rework затронул >30–50% объёма или изменилась логика ключевых сценариев — назначайте новую подготовку и собрание по затронутым разделам. Если правки точечные — достаточно follow-up по diff (протокол «что проверено повторно»). Критерий выбирайте заранее в регламенте проекта.

3.2. Подготовка и чек-листы

Рецензенты до собрания изучают срез документа с чек-листами из 08.03 Тестирование требований (статическое тестирование) и атрибутами качества из 02.04.03 Управление качеством требований. Эффективность инспекции определяется качеством подготовки: цель — вынести максимум дефектов до общей встречи.

Perspective-Based Reading (PBR): каждый рецензент читает с перспективы роли (пользователь, разработчик, тестировщик, безопасник) — повышает охват типов дефектов. Для API и NFR перспектива безопасника опирается на чек-листы из 08.07 Основы кибербезопасности для системного аналитика. Это техника проведения инспекции, а не замена процесса.

Объём сессии: не более 10–15 страниц плотного текста или 5–7 User Stories за одно собрание. Большой SRS дробят на итерации (sampling): сначала контекст и сквозные NFR, затем функциональные блоки по приоритету риска.

Трассировка: полная сверка матрицы «цель → требование → тест/дизайн» (02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки) — на формальных инспекциях релизного SRS или перед контрактным sign-off. На облегчённых сессиях backlog — выборочно: новые связи, изменённые требования, элементы без upstream/downstream link.

3.3. Follow-up и инструменты

Модератор проверяет адресность исправлений по протоколу. Протокол и статусы дефектов ведут в согласованном инструменте — Confluence, Jama, Jira, PR в Git (07.05 Системы контроля версий (Git) для документации, 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence)). ID дефектов из протокола сохраняйте для последующего учёта escape rate.

3.4. Масштабирование в Agile

Формальная инспекция Фейгана не обязательна в каждом спринте; её элементы масштабируются по риску (08.05 Управление рисками на этапе анализа):

  • Backlog refinement с рецензированием — подготовка + короткое собрание «three amigos» (аналитик, разработчик, тестировщик): облегчённая инспекция User Story (05.02 Scrum и Kanban (аналитик в Agile)). Это в первую очередь verification формулировок; если в сессию включают product owner для согласования «строим ли это» — добавляется validation, и протокол должен разделять типы findings.
  • Pull Request в docs-as-code — асинхронное или синхронное рецензирование с обязательным approve и follow-up по замечаниям; метрики и exit criteria задаёт команда в Definition of Done.
  • Sprint Review — демонстрация инкремента; это validation результата, а не инспекция текста требований.

Чем выше цена ошибки, тем ближе процесс к полной инспекции с протоколом и sign-off.

3.5. Метрики эффективности

Ключевые метрики инспекций (08.01 Метрики и KPI процесса анализа):

  • Плотность дефектов — дефектов на страницу или на требование; помогает прогнозировать качество непроверенных разделов.
  • Скорость обнаружения — дефектов на человеко-час подготовки и собрания.
  • Доля дефектов, найденных на подготовке — индикатор качества индивидуальной проработки.
  • Escape rate — доля дефектов, не пойманных инспекцией, но обнаруженных позже.

Для escape rate нужен явный учёт: дефекты на последующих этапах (dev-тест, UAT, prod) связывают с локацией в артефакте и проверяют, покрывал ли этот фрагмент протокол инспекции (по ID среза или версии документа). Без трассировки «инспекция → поздний дефект» метрика остаётся декларацией. Этапы Fagan ↔ ISO/IEC 20246 (§2.1) используйте при аудите зрелости и сопоставлении с внешними assessor'ами (00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)).

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

  • Смешение инспекции с валидацией у заказчика — sign-off бизнеса не заменяет verification по чек-листам; и наоборот, инспекция без представителя домена не ловит «строим не то». Three amigos без PO — verification; с PO на согласование scope — смешанная сессия.
  • Собрание без подготовки — превращает инспекцию в walkthrough; дефекты всплывают позже, растёт escape rate.
  • Подмена инспекции асинхронными комментариями без follow-up — замечания не становятся согласованным протоколом дефектов.
  • Проектирование решений на собрании — съедает время и уводит от поиска дефектов; модератор возвращает фокус.
  • Обязательная полная трассировка на каждой лёгкой сессии — перегруз; привязывайте глубину проверки к риску и типу артефакта.
  • Нет exit criteria или waiver без владельца риска — команда не знает, когда артефакт «прошёл»; rework затягивается или передают с открытыми Critical.
  • Путаница дефекта и change request — scope меняется без CCB; потом невозможно объяснить отклонение от baseline.
  • Игнорирование re-inspection после крупного rework — follow-up по diff не заменяет повторную подготовку при переписанной логике.
  • Модератор без навыков фасилитации — эскалации и доминирование одного голоса; см. 09.02 Проведение эффективных встреч и воркшопов, 09.03 Управление конфликтами и переговоры.

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

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

Классические работы

  • Michael Fagan. «Design and Code Inspections to Reduce Errors in Program Development» (IBM Systems Journal, 1976) — исходная статья по инспекции design и code; основа процесса.
  • Michael Fagan. «Advances in Software Inspections» (IEEE Transactions on Software Engineering, 1986) — метрики и уточнения процесса.

Книги

  • Tom Gilb, Dorothy Graham. «Software Inspection» — полное руководство; этап Overview и программа метрик.
  • Karl Wiegers, Joy Beatty. «Software Requirements» (3rd Edition) — главы 16–17 о рецензировании требований.
  • Suzanne Robertson, James Robertson. «Mastering the Requirements Process» — раздел о рецензировании.

Стандарты

  • IEEE 1028-2008 «Standard for Software Reviews and Audits» — типы review и audit (стандарт снят с активного статуса в 2019; сохраняет справочную ценность). https://standards.ieee.org/standard/1028-2008.html
  • ISO/IEC 20246:2017 «Work product reviews» — planning, individual review, joint review; современная рамка для сопоставления с Fagan. https://www.iso.org/standard/67407.html

Статьи и ресурсы

Курсы (опционально, платные)

  • Pluralsight — «Software Inspections and Reviews».
  • ISTQB Advanced Level — Test Manager: модуль статических методов, включая инспекции. https://istqb.org/?page_id=2184