| 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.
Обязательные действия
- Прочитай файл/папку. Если передана папка — итерируй по
*.md, исключая README/INDEX-файлы.
- Для каждого артефакта: пройдись по восьми критериям, одна оценка на критерий. Используй символы
✓ (прошёл), ⚠ (предупреждение, нужно посмотреть), ✗ (не прошёл — блокер).
- Сформируй отчёт в формате ниже.
- Предложи тривиальные правки (например, добавить отсутствующий тег приоритета). Сложные — только описание, без авто-исправления.
- Если артефакт прошёл все 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: ✗✓✓✓⚠✓✓
Чеклист самопроверки ревьюера
Частые ошибки
❌ Сводить ревью к стилю — ошибки оформления не делают требование некачественным; критерии Вигерса о смысле, а не о форме.
❌ «Слишком общее» без указания, чем слово заменить — комментарий без рекомендации не помогает.
❌ Привязка к одному критерию там, где нарушены несколько — показывай каждый.
❌ Авто-применять не-тривиальные правки — добавить тег приоритета можно автоматически, переписать use case — нет.
