1. Проблемы и способы их решения
1.1. Сложно "продать"
1.1.1. Через руководство ДУП
1.1.2. Постоянный внутренний пиар
1.1.3. Элемент соревновательности
1.2. Качество ревью
1.2.1. Правильные ревьюеры
1.2.2. Правильное время
1.2.3. Чеклист
1.2.4. Аудит ревью
1.2.5. Метрики ревью в аудит проекта
1.3. Сложно контролировать
1.3.1. JIRA, протоколы, отчеты
1.4. Ложные ожидания
1.4.1. Ошибки будут
1.4.2. Главный за ТЗ автор, а не ревьюер
2. Проблематика - зачем?
3. На что смотрим?
3.1. Бизнес-цели
3.1.1. Все ли стейкхолдеры включены
3.1.2. Решены ли бизнес-цели проекта
3.1.3. Совпадают ли цели проекта с бизнес-целями? Если нет, зачем тогда проект?
3.2. Здравый смысл
3.2.1. Понятен ли скоп проекта, имеет ли он смысл
3.2.2. Понятно ли, что входит в скоп проекта, а что нет
3.2.3. Есть ли описания as is и to be?
3.2.4. Есть ли верхнеуровневая схема функционала
3.2.5. Бизнес-требования описаны в терминах бизнеса?
3.2.6. Все требования изложены на корреткных уровнях
3.3. Изложение требований
3.3.1. Ясность
3.3.1.1. Соответсвуют решению бизнес-проблемы?
3.3.1.2. Многословно? Два требования в одном предложении
3.3.1.3. Использование жаргона
3.3.1.4. Использование терминов не упомянутых в глоссарии?
3.3.1.5. Двойное толкование?
3.3.2. Тестируемость
3.3.2.1. Требования можно протестировать, продемонстрировать
3.3.2.2. Критерий выполнения, метрика
3.3.2.3. Слова-паразиты: Несколько, удобный, быстрый, достаточный и т.п.
3.3.3. Открытые вопросы
3.3.3.1. Реестр открытых вопросов
3.3.4. Регуляторные требования
3.3.5. Стиль
3.3.5.1. "должен" shall
3.3.5.2. Четкое деление на уровни: бизнес-требования, функциональные-требования, системные требования
3.3.6. непротиворечивость
3.3.7. относятся к скопу проекта
3.4. Оформление документа
3.4.1. Все схемы и таблицы пронумерованы
3.4.2. Использован актуальный шаблон
3.4.3. Использованы единые стили
3.4.4. Исправлены орфографические ошибки