requirements-review

name	requirements-review
description	Проверка качества требований по критериям качества Вигерса. Используй когда пользователь просит: - проверить качество требования / use case / SRS-документа - провести инспекцию требований - найти двусмысленности и пробелы в требованиях - оценить готовность требований к разработке

Навык: Ревизия требований по Вигерсу

Цель

Прочитай переданный артефакт требований (SRS, vision, use case, ADR, feature description) и сформируй структурированный отчёт, в котором каждое замечание привязано к одному из восьми критериев качества Вигерса.

Восемь критериев качества (обязательные)

Критерий	Вопрос проверки
Clear (Понятное)	Однозначно ли формулировка? Поймёт ли её разработчик/тестировщик так же, как заказчик?
Complete (Полное)	Не пропущены ли альтернативные потоки, граничные условия, ошибки, нефункциональные ограничения?
Consistent (Согласованное)	Не противоречит ли другим требованиям, бизнес-правилам, более ранним решениям?
Feasible (Реализуемое)	Достижимо ли в рамках бюджета/сроков/команды? Не блокировано ли внешним фактором?
Necessary (Необходимое)	Есть ли у этого требования источник (BO-N, стейкхолдер, регулятор)? Что сломается, если его убрать?
Prioritized (Приоритизированное)	Указан ли явный приоритет (P0–P3, MoSCoW, и т.п.)?
Testable (Тестируемое)	Сформулировано ли так, что можно построить пройденный/непройденный тест?
Unambiguous (Однозначное)	Нет ли «обтекаемых» слов: «быстрый», «удобный», «гибкий», «эффективный», «обычно»?

Каждое замечание в отчёте обязано быть отнесено хотя бы к одному из этих критериев. Это то, что отличает Wiegers-review от обычного code-review.

Обязательные действия

1. Прочитай файл/папку. Если передана папка — итерируй по *.md, исключая README/INDEX-файлы.
2. Для каждого артефакта: пройдись по восьми критериям, одна оценка на критерий. Используй символы ✓ (прошёл), ⚠ (предупреждение, нужно посмотреть), ✗ (не прошёл — блокер).
3. Сформируй отчёт в формате ниже.
4. Предложи тривиальные правки (например, добавить отсутствующий тег приоритета). Сложные — только описание, без авто-исправления.
5. Если артефакт прошёл все 8 критериев — предложи поднять статус документа до analyzed / approved.

Формат отчёта (один файл)

FILE: requirements/use-cases/UC-003_run-dcf.md
├ ✓ clear
├ ⚠ complete       — отсутствует обработка случая «модель не сходится»
├ ✓ consistent
├ ✓ feasible
├ ✓ necessary
├ ✗ prioritized   — нет тега приоритета во frontmatter
├ ⚠ testable      — критерий «модель работает быстро» неоднозначен; предложи p95 < 5s
├ ✗ unambiguous  — слова «эффективно», «удобно» в шаге 4 основного потока

Suggested edits:
  1. Добавь во frontmatter: `priority: P2`
  2. Замени «модель работает быстро» на «p95 латентности < 5s на тестовом датасете D»
  3. Опиши альтернативный поток A1: модель не сходится после 100 итераций → возврат ошибки `MODEL_DIVERGED`
  4. Слова «эффективно», «удобно» в § 5: переформулируй или вынеси в нефункциональные ограничения

Финальная сводка (если проверялась папка)

Reviewed: 7 files
├ Pass:    4
├ Warning: 2
├ Fail:    1

Top blockers:
  - UC-003: 2 ✗ (prioritized, unambiguous)
  - FR-014: 1 ✗ (testable)

Quality criteria heatmap:
  clear:        ✓✓✓✓✓⚠✓
  complete:     ✓⚠✓✓⚠✓✓
  consistent:   ✓✓✓✓✓✓✓
  feasible:     ✓✓✓✓✓✓✓
  necessary:    ✓✓⚠✓✓✓✓
  prioritized:  ✗✓✓✓✓✓✓
  testable:     ⚠✓✓✗✓✓✓
  unambiguous:  ✗✓✓✓⚠✓✓

Чеклист самопроверки ревьюера

• Каждое замечание привязано хотя бы к одному критерию
• Не путать «critical» и «failed unambiguous» — ✗ ставится за объективное нарушение, не за личную предпочтительность
• Ни одного «non-actionable» комментария (если ✗ — есть конкретная замена)
• Не перечитывать собственные замечания на тот же артефакт повторно — это не правка, это аудит

Частые ошибки

❌ Сводить ревью к стилю — ошибки оформления не делают требование некачественным; критерии Вигерса о смысле, а не о форме. ❌ «Слишком общее» без указания, чем слово заменить — комментарий без рекомендации не помогает. ❌ Привязка к одному критерию там, где нарушены несколько — показывай каждый. ❌ Авто-применять не-тривиальные правки — добавить тег приоритета можно автоматически, переписать use case — нет.