Модуль 6. Проверка качества ТЗ: антипаттерны, чек‑листы, peer‑review, защита ТЗ и финального проекта
Цель модуля
Научить участников системно проверять и улучшать качество ТЗ: формализовывать критерии качества, организовывать peer‑review, устранять антипаттерны, обеспечивать трассируемость и тестопригодность требований, готовить ТЗ к защите перед бизнесом, ИТ и ИБ.
Результаты обучения
После модуля участник умеет:
- Применять качества хороших требований (однозначность, полнота, непротиворечивость, проверяемость, трассируемость, реализуемость).
- Проводить многоуровневую экспертизу ТЗ: self-check → peer-review → архитектурный/ИБ/юридический обзор → защита.
- Использовать чек‑листы и рубрики для оценки полноты и качества ТЗ.
- Выявлять и устранять антипаттерны в формулировках.
- Организовывать Fagan inspection / structured peer‑review с протоколом дефектов и критериями выхода.
- Готовить финальную версию ТЗ к защите: структура питча, рубрика защиты, артефакты приёмки.
Верификация vs Валидация (V&V)
- Верификация (Verification) — «правильно ли мы это написали?» (соответствие внутренним стандартам качества, шаблонам, чек‑листам, метрикам).
- Валидация (Validation) — «то ли мы написали, что нужно бизнесу?» (соответствие целям, ценности, ожиданиям стейкхолдеров, юридическим и ИБ‑ограничениям).
Простой тест: документ можно верифицировать без бизнеса (по чек‑листам и метрикам), но валидировать — только с участием стейкхолдеров.
Атрибуты качественного требования (и ТЗ в целом)
- Еднозначность (Unambiguous) — нет двусмысленностей, термины определены в глоссарии.
- Полнота (Complete) — нет TBD/TBC, нет «это опишем потом».
- Согласованность (Consistent) — требования не противоречат друг другу.
- Проверяемость/тестируемость (Verifiable/Testable) — есть критерии приёмки, SLI/SLO/SLA, RPO/RTO, формулы KPI, метрики DQ.
- Трассируемость (Traceable) — от цели → задачи → требований → тестов → результатов.
- Реализуемость (Feasible) — учтены ограничения архитектуры, ИБ, бюджета, сроков.
- Измеримость (Measurable) — количественные показатели, SLA/SLO/Latency, проценты, пороговые значения.
- Необходимость (Necessary) — исключены «хотелки», не привязанные к целям и KPI (Module 2).
- Актуальность (Up-to-date) — версия, дата, контроль изменений, протоколы согласования.
Процесс проверки качества ТЗ: уровни и роли
Уровни обзора
- Self-check автора — по чек‑листам и рубрикам (см. ниже).
- Peer-review команды — разработчики, архитекторы, аналитики (методика Fagan inspection).
- Архитектурный совет — проверка архитектуры, слоёв, NFR, интеграций.
- ИБ/Юридический обзор — доступы, PII, GDPR/152‑ФЗ, ретенции, логирование.
- Бизнес‑валидация — цели, KPI, витрины, формулы, SLA, понятность.
- Формальная защита — презентация и Q&A (см. 6.10).
Роли (в духе Fagan inspection)
- Author (Автор) — пишет ТЗ, фиксирует исправления.
- Moderator (Модератор) — ведёт встречу, следит за временем и регламентом.
- Reader (Читающий) — идёт по документу и проговаривает ключевые блоки.
- Reviewer(s) (Ревьюеры) — ищут дефекты по чек‑листу/матрице.
- Scribe (Секретарь) — протоколирует находки дефектов, решения, action items.
Входные/выходные критерии
Entry criteria:
- Документ пронумерован, версионирован, есть оглавление.
- Заполнены критические разделы (цели, scope, данные, архитектура, NFR, безопасность, SLA/SLO, приёмка).
- Автор выполнил self‑check и приложил чек‑лист с отметками.
Exit criteria:
- Нет открытых критичных дефектов (уровней A/B).
- Закрыты TBD/TBC.
- Матрица трассируемости полная.
- Все спорные решения задокументированы (решение + дата + владелец).
- Есть план и срок внесения правок (если есть некритичные замечания).
Метрики качества ТЗ (цифровать то, что улучшаем)
Примеры метрик:
- % требований с явными критериями приёмки / тестами (цель ≥ 95%).
- # TODO/TBD на 1 страницу (цель — 0 к финальной версии).
- # противоречий (conflicts) между разделами (цель — 0).
- Покрытие трассируемости: % целей, у которых есть связанные требования/витрины/тесты.
- # дефектов на 10 страниц (по итогам peer-review), доля критичных.
- Среднее время закрытия замечания.
- % НФТ, имеющих измеримые SLI/SLO/SLA (цель ≥ 90%).
- % секций с явной ответственностью и SLA на каждую функцию/интеграцию.
Большой чек‑лист качества ТЗ (для self-check и peer-review)
По разделам (короткая версия)
Раздел «Цели/задачи/метрики успеха»
- Цели привязаны к бизнес‑результату, есть метрики (как меряем эффект).
- Есть связь «цель → функция/витрина/показатель».
- Нет расплывчатых формулировок («улучшить», «ускорить» без числа).
Scope / Out of Scope
- Чётко описано, что делаем и что точно не делаем.
- Есть карта влияния смежных систем.
Требования к данным
- По каждому источнику заполнен шаблон (поля, объёмы, частоты, инкремент, SLA).
- Историчность/SCD/версии описаны, понятна политика.
- Указаны DQ‑правила, пороги, алерты, ответственные.
Архитектура
- Слои обозначены (Staging/ODS/DWH/DM или Bronze/Silver/Gold), технологии, форматы.
- Оркестрация, monitoring/alerting, CI/CD, DR (RPO/RTO) описаны.
- Диаграммы есть, читаемы, с легендой/нотацией.
НФТ
- Есть SLI/SLO/SLA, error budgets, политика эскалации.
- Производительность/масштабирование описаны с тестовыми сценариями.
- Доступность, DR‑план, бэкапы, ретенции — не забыты.
Безопасность и приватность
- RBAC/ABAC, RLS/CLS, SoD, шифрование (в покое/в движении).
- Ретеншн логов, аудит, журналирование.
- 152‑ФЗ/GDPR/DPIA/PIA учтены, поля PII классифицированы.
Интеграции
- Контракты, схемы, версии, совместимость (backward/forward).
- Retries/backoff, идемпотентность, DLQ, circuit‑breaker.
- SLO по интерфейсам, трассировка, correlation id.
Приёмка, тестирование, эксплуатация
- Критерии приёмки по каждому разделу/функции/витрине.
- Тест‑стратегия: unit/dbt/DQ/интеграционные/контрактные/нагрузочные/DR‑тесты.
- On-call, runbooks, postmortems, change management (RFC/CR), релизный календарь.
Глоссарий/Lineage/Трассируемость
- Все термины определены.
- Полная матрица трассируемости.
- Lineage виден и поддерживается.
Чек‑лист «резкими вопросами» (для red team)
- Где SLA на каждый пользовательский артефакт (витрина/отчёт/API)?
- Какие данные точно не должны попадать в аналитическое хранилище?
- Как вы доказательно покажете аудитору (через 18 месяцев), что конкретный человек не видел PII?
- Что будете делать, если CDC замолчит на 6 часов? Кто принимает решение, как восстанавливаемся?
- Какой у вас порог ошибки по DQ, при котором блокируете публикацию витрины?
- Как проверить, что все формулы KPI в BI соответствуют зафиксированным в ТЗ?
- Сколько времени займёт полный recovery DWH, если объектное хранилище S3 уничтожено?
- Сколько TODO/TBD осталось в документе на момент защиты? Почему?
- Где ваша error budget policy и какой порог для freeze-релизов?
Антипаттерны (и как их чинить)
Формулировки
- «Система должна быть быстрой/надёжной/безопасной» → дайте цифры (SLA/SLO/RPO/RTO, latency, P95).
- «Подключим BI к источнику напрямую» → нарушены архитектурные принципы, нет истории, деградация производительности.
- «Данные будут чистыми» → какие правила, где, пороги, алерты и кто владелец DQ?
- «Все смогут работать с данными» → RBAC/ABAC, RLS/CLS, SoD? Кто «все»?
- «Потом опишем» → запрет на TBD/TBC в финальной версии.
Структура документа
- Смешение слоёв (ODS и DM в одном месте, нет границ ответственности).
- Нет схемы оркестрации и мониторинга — «а кто это будет чинить, когда упадёт?».
- Нет DR‑процедур — «восстановимся из бэкапов» (каких? где? кто проверил?).
- Формулы KPI в BI, но не в ТЗ — расхождения в разных отчётах гарантированы.
- Слабая трассируемость — непонятно, как цель и KPI связаны с требованием и тестом.
Матрица трассируемости и протокол изменений
Матрица трассируемости (пример полей)
|
Goal |
Feature / Function |
Requirement ID |
Test Case |
Data Source / Mart |
KPI |
Status |
|---|
Правило: любая строка в требованиях должна иметь ID и быть найдена в обе стороны (из цели в требование и обратно).
Протокол замечаний и исправлений (issue log)
|
ID |
Тип дефекта |
Раздел |
Описание |
Критичность (A/B/C) |
Ответственный |
Срок |
Статус |
|---|
Автоматизация контроля качества ТЗ
- Шаблоны и линтеры: единые форматы, макросы проверки TODO/TBD, заполненности полей.
- Req/ALM‑системы: Polarion, Jama, Doors, Reqtify, Jira+Confluence с workflow и трейсингом.
- dbt tests / Great Expectations — линковка правил DQ из ТЗ к автоматическим тестам.
- OpenLineage / DataHub / Collibra / Atlan — автоматическое получение lineage и метаданных.
- CI/CD Quality Gates: проверка наличия тестов, миграций, SLO, секретов вне Git.
- Автоматические PDF/HTML отчёты: генерация «среза качества» ТЗ (метрики, TBD, дефекты).
Процедура Fagan inspection (пошагово)
- Planning — определить области документа, участников, чек‑листы, план времени.
- Overview — краткий бриф: цель ТЗ, архитектура, контекст.
- Preparation — ревьюеры читают индивидуально, отмечают дефекты.
- Inspection meeting — идём по документу, фиксируем дефекты (без обсуждений дизайна, только факты).
- Rework — автор исправляет, обновляет версию, закрывает дефекты.
- Follow-up — модератор проверяет, что критичные дефекты устранены, документ готов к следующему уровню.
Критерии дефектов (пример):
A — блокирует защиту/релиз; B — важно исправить до пилота; C — можно в бэклог улучшений.
Финальный аудит ТЗ перед защитой
Обязательные вопросы:
- Полнота и непротиворечивость: все разделы соблюдены? Есть ссылки на приложения, схемы.
- Измеримость и тестируемость: любые ключевые требования можно протестировать и подписать акт приёмки.
- Трассируемость: цели ↔ витрины ↔ KPI ↔ тесты ↔ SLA.
- Архитектурная реалистичность: выбранные технологии соответствуют объёмам, SLA и NFR.
- Безопасность/приватность/комплаенс: нет «чёрных дыр», пустых полей, устных договорённостей.
- План внедрения и сопровождения: есть on-call, мониторинг, DR, CI/CD, change management.
Защита ТЗ (финальный проект)
Что защищаем (deliverables)
- Полный текст ТЗ, версия/дата, список изменений.
- Приложения: архитектурные схемы, lineage, матрица трассируемости, список DQ‑правил, SLA/SLO/SLA, RPO/RTO.
- Протокол peer-review + закрытые замечания.
- Рубрика самооценки (self-assessment).
- План внедрения/пилота/продакшена.
Структура питча (15–20 минут)
- Контекст и цели (коротко, но с цифрами эффектов).
- Топ‑5 архитектурных решений и почему.
- Как закрыты ключевые риски и НФТ (SLA/SLO, RPO/RTO, безопасность, DR).
- Как обеспечены DQ и lineage, как это будет жить.
- CI/CD, эксплуатация, on-call, документация.
- Результаты peer-review и как учли замечания.
- Чёткий список критериев приёмки.
- Q&A + демонстрация трассируемости (быстрый переход от цели к витрине и тесту).
Рубрика оценки защиты (пример, макс. 30 баллов)
|
Критерий |
0 |
1 |
2 |
3 |
|---|---|---|---|---|
|
Чётко сформулированные цели и метрики |
Нет |
Частично |
Есть, но не все измеримы |
Полные, измеримые, привязаны к бизнесу |
|
Полнота ТЗ и отсутствие TBD |
Много пробелов |
Частично |
Мелкие TBD |
Полностью закрыто |
|
НФТ и SLA/SLO/RPO/RTO |
Нет |
Частично |
Есть, но без методов измерения |
Полные, измеримые, с мониторингом |
|
DQ/Lineage/Метаданные |
Нет |
Частично |
Есть правила/инструменты |
Полный цикл: правила, алерты, владельцы, инструменты |
|
Безопасность/Комплаенс |
Нет |
Частично |
Есть, но без процедур аудита |
Полный набор + аудит/ретенции |
|
CI/CD/Эксплуатация/DR |
Нет |
Частично |
Есть процессы |
Формализовано, протестировано, с runbooks |
|
Peer-review и работа с замечаниями |
Нет |
Проведено, но без протокола |
Есть протокол, не все закрыто |
Закрыто, метрики качества улучшены |
|
Питч: структура и Q&A |
Слабый |
Неструктурированный |
Структура есть, Q&A частично |
Чёткая структура, уверенные ответы |
Практическое задание
Часть 1. Self-check + peer-review
- Выполнить self-check своего ТЗ по большому чек‑листу (6.4).
-
Организовать peer-review (Fagan inspection) в мини-группах:
- распределить роли,
- заполнить протокол дефектов,
- классифицировать по критичности,
- устранить дефекты, показать дельту метрик качества.
Часть 2. Финальный аудит и защита
- Подготовить матрицу трассируемости (цели → требования → тесты → KPI → SLA).
- Подготовить пакет артефактов: схемы, DQ-правила, SLA/SLO/RPO/RTO, CI/CD, DR, безопасность.
- Защитить ТЗ за 15–20 минут перед экспертами и получить обратную связь.
- Приложить post‑review report: что было изменено после защиты.
Итоговые шаблоны и артефакты, которые участник получает
- Чек‑лист качества ТЗ (короткая и полная версия).
- Матрица трассируемости (готовый шаблон).
- Протокол peer-review / Fagan inspection.
- Рубрики оценки (для модуля, финального проекта и защиты).
- Шаблон метрик качества ТЗ (с формулами и целями).
- Образец «error budget policy» и процедуры эскалации.
- Образец release/change management (RFC/CR + календарь релизов).
- Шаблон отчёта postmortem (без обвинений, с action items).
Домашнее задание (вариант для «межмодульной» работы)
- Возьмите свою версию ТЗ (после Модулей 4–5).
- Примените чек‑лист 6.4 (короткий и полный).
- Проведите peer‑review по Fagan (приложите протокол, классификацию дефектов, метрики до/после).
- Заполните матрицу трассируемости (без пропусков).
- Подготовьте 10‑слайдовую презентацию для защиты (структура из 6.10.2).
- Сдайте: ТЗ vFinal, чек‑листы, протокол peer‑review, матрицу трассируемости, презентацию, отчёт об исправлениях.
внутри 5 листов:
- Traceability_Matrix — матрица трассируемости целей → функций → требований → тестов → SLA/SLO/SLI → витрин.
- TZ_Quality_Metrics — метрики качества ТЗ (формулы, цели, факты, владельцы, частота сбора).
- Peer_Review_Log — протокол peer‑review / Fagan inspection (дефекты, критичность, владелец, ETA, статус).
- Fagan_Session — роли, entry/exit criteria, подсчёт дефектов и next steps.
- README — краткая инструкция, как с этим работать.
Скрипт защиты ТЗ (пошаговый гайд по слайдам)
Формат: 15–20 минут на питч + 10–15 минут Q&A.
Цель: показать, что ТЗ полное, измеримое, реализуемое, безопасное, и вы готовы в прод.
Слайд 1. Заголовок и контекст
-
Что говорить:
«Мы защищаем финальную версию ТЗ по проекту X. Покажем цели, архитектуру, NFR, безопасность, SLA/SLO, DQ, lineage и как мы обеспечили качество документа.» - Покажите: Версию ТЗ, дату, список авторов/ревьюеров.
Слайд 2. Бизнес-цели и метрики успеха
-
Что говорить:
«Наша цель — снизить X на Y%/ускорить Z до N минут. Все цели привязаны к измеримым метрикам. Вот как мы будем их считать». - Покажите: Таблицу целей и KPI (фрагмент из матрицы трассируемости).
Слайд 3. Scope / Out of Scope (границы проекта)
-
Что говорить:
«Чётко зафиксировали, что делаем и что не делаем. Это позволит контролировать требования и Changе Requests.» - Покажите: Карту блока и короткую таблицу In/Out.
Слайд 4. Данные и источники (сильный слайд)
-
Что говорить:
«Для каждого источника описали формат, объёмы, SLA, инкремент/CDC, владельцев и риски. На экране — пример». - Покажите: Шаблон на 1 источник, акцент на объёмы, SLA и инкременты.
- Где показать трассируемость: связь источника с витринами/КPI.
Слайд 5. Архитектура и слои
-
Что говорить:
«Целевая архитектура — (DWH/Lakehouse). Слои: Staging/Bronze → ODS/Silver → DWH/Gold → DM/Semantic. Отдельно: оркестрация, мониторинг, CI/CD, DR.» - Покажите: Cхему (C4/DFD) + легенду.
- Где показать трассируемость: выделите, где считаются ключевые KPI.
Слайд 6. Историчность, DQ и lineage
-
Что говорить:
«SCD2 для X, time-travel в Delta/Iceberg для Y, DQ‑правила с порогами и алертами. Lineage автоматизирован через …» -
Покажите:
- пару ключевых DQ‑правил с SLO/алертами,
- кусочек lineage (источник → слой → витрина).
- Где показать трассируемость: укажите, как DQ-инциденты влияют на SLA витрин.
Слайд 7. Нефункциональные требования (SLA/SLO/SLI, RPO/RTO)
-
Что говорить:
«НФТ переведены в измеримые показатели. Вот наша матрица SLI/SLO/SLA и таблица RPO/RTO по компонентам.» - Покажите: Фрагмент из листа TZ_Quality_Metrics и RPO/RTO-таблицу.
Слайд 8. Безопасность, доступы, комплаенс
-
Что говорить:
«RBAC/ABAC, RLS/CLS, шифрование в движении и на хранении, IAM SLA. PII классифицированы, ретенции и аудит определены.» - Покажите: Таблицу ролей и прав, SLA по отзыву доступа, схему шифрования.
Слайд 9. Интеграции: контракты, версии, устойчивость
-
Что говорить:
«Определены контракты и версия схем, DLQ, retries, идемпотентность, at-least-once/at-most-once, трассировка correlation id. Breaking changes — через policy X.» - Покажите: Пример контракта/схемы, политику версионирования, DLQ-цепочку.
Слайд 10. Мониторинг, алерты, SRE, error budgets
-
Что говорить:
«Метрики, логи, трейсинг. Error budget на уровне оркестратора — 43 мин/мес. При 50% выработки — freeze.» - Покажите: Таблицу SLO + error budget policy, список критичных алертов и runbooks.
Слайд 11. Peer-review, исправления, зрелость ТЗ
-
Что говорить:
«Провели Fagan inspection: найдено N дефектов (A/B/C), все A/B закрыты. TBD=0. Метрики качества улучшены на X%.» - Покажите: Фрагмент Peer_Review_Log, график снижения дефектов (можем построить позднее).
Слайд 12. Приёмка, эксплуатация, next steps
-
Что говорить:
«Критерии приёмки формализованы. Есть on-call, DR, CI/CD, документация. Готовы к пилоту/продакшену. Следующие шаги — …» - Покажите: Чек-лист приёмки и план внедрения.
«Жёсткие» вопросы и как на них отвечать
|
Вопрос |
Как отвечать |
Где показывать |
|---|---|---|
|
Где SLA для каждой витрины/отчёта? |
«В матрице трассируемости и в разделе SLO/SLA. Для dm_sales_daily — до 08:00 МСК, P95 BI ≤ 7 сек.» |
Слайды 2/7 + Traceability_Matrix |
|
Что будете делать, если CDC встанет на 6 часов? |
«У нас есть DLQ, snapshot+merge процедура, RPO=15 минут, fallback — batch-выгрузка, runbook описан в разделе DR.» |
Слайд 7/10 + runbook в приложении |
|
Как вы докажете аудитору, что пользователь X не видел PII? |
«Все запросы к PII логируются, логи WORM, хранятся 2 года, отчёт формируется автоматом. RLS/CLS в BI задокументированы.» |
Слайд 8 |
|
Какой у вас error budget и что, если он кончился? |
«Для оркестратора SLO 99.9% → 43 мин/мес. При 50% — freeze, при 100% — релиз-блок до восстановления уровня.» |
Слайд 10 |
|
Что блокирует публикацию витрины при плохом DQ? |
«Порог по NULL/дублям/балансам зафиксирован. Нарушение → алерт + блок публикации. Правила/пороги в DQ-таблице.» |
Слайд 6 |
|
Кто владеет данными/правилами DQ/метриками KPI? |
«Owners определены: Data Steward Sales, Product Owner BI, IAM Admin. Есть RACI и SLA по IAM.» |
Слайд 8 + Traceability |
|
Где зафиксированы формулы KPI (а не в BI-скрипте одного разработчика)? |
«В ТЗ и semantic layer. BI-конфиг версионируется в Git. Проверка формул — в тестах.» |
Слайды 2/6 |
|
Как вы тестировали DR? |
«Сценарии DR-тестов задокументированы, проводили 2 прогона: полное восстановление DWH за 86 минут (RTO ≤ 2 часа).» |
Слайд 7 |
|
Сколько TBD осталось? |
«0. Все закрыты, см. Peer_Review_Log. Критичных дефектов нет.» |
Слайд 11 |
