Какие метрики вы используете для оценки качества требований?

Метрики оценки качества требований

Зачем нужны метрики требований

Качество требований напрямую влияет на:

• Скорость разработки (плохие требования → переделки)
• Стоимость проекта (изменения → переработка)
• Удовлетворённость пользователей (неправильные требования → неправильный продукт)
• Мораль команды (неясные требования → фрустрация)

Метрики помогают объективно оценить качество и улучшить процесс.

Основные метрики требований

1. Полнота требований (Requirements Completeness)

Определение: Процент требований, которые полностью определены и не требуют уточнений.

Формула:

Полнота = (Требования с полным описанием / Всего требований) × 100%

Что считается "полным":

• Есть чёткое описание
• Есть приёмочные критерии
• Есть примеры
• Нет неоднозначностей

Примеры:

❌ Неполное (30%):
"Реализовать фильтр поиска"
(что фильтровать? какие параметры? как сохранить?)

✅ Полное (100%):
"Как покупатель, я хочу фильтровать товары по цене (мин-макс), 
бренду и рейтингу, чтобы быстро найти нужный товар.

Критерии приёмки:
- Слайдер для цены (от 0 до 10000)
- Чекбоксы для брендов (выбрать несколько)
- Слайдер для рейтинга (от 1 до 5 звёзд)
- Фильтры работают в комбинации
- Результат обновляется в реальном времени
- Фильтры сохраняются в URL (для sharing)"

Целевое значение: 85-95% (100% редко достижимо)

2. Ясность и однозначность (Clarity)

Определение: Процент требований, которые понимаются одинаково всеми заинтересованными сторонами.

Метрика: Количество вопросов / уточнений на требование

Ясность = 100% - (Количество вопросов от team / Всего требований × 20)

Как измерить:

• Напиши требование
• Покажи 3-5 разработчикам
• Спроси: "Сколько вопросов?"
• Если вопросов > 2 → требование неясно

Примеры неясности:

❌ "Система должна быть быстрой"
Вопросы: Как быстро? < 1сек? < 100ms? Какую операцию измеряем?

✅ "API endpoint должен вернуть результат за < 200ms в 95% случаев"
Четко и измеримо

Целевое значение: > 90%

3. Трёхэзабилити / Отслеживаемость (Traceability)

Определение: Способность отследить требование от источника до реализации и тестов.

Метрика:

Трёхэзабилити = (Требования с ссылками на tests / Всего требований) × 100%

Что отслеживаем:

• Требование → User Story
• User Story → Code
• Code → Unit Tests
• Unit Tests → QA Test Cases
• QA Test Cases → Результаты тестирования

Матрица отслеживаемости (Traceability Matrix):

| Требование | User Story | Code Review | Tests | Deploy |
|------------|-----------|-------------|-------|--------|
| REQ-001 | US-123 | ✓ | ✓ | ✓ |
| REQ-002 | US-124 | ✓ | ~ | - |
| REQ-003 | - | - | - | - |

Инструменты: Excel, JIRA, Confluence, специализированные RPM tools

Целевое значение: 95-100%

4. Консистентность требований (Consistency)

Определение: Отсутствие противоречий между требованиями.

Метрика:

Консистентность = (Требования без конфликтов / Всего требований) × 100%

Примеры конфликтов:

❌ Противоречие:
REQ-001: "Система должна быть доступна 99.99% (недоступность <44мин/год)"
REQ-002: "На обслуживание отводится 2 часа в месяц (240мин/год)"
(конфликт: обслуживание займёт больше, чем позволяет SLA)

✅ Консистентное:
REQ-001: "Система должна быть доступна 99.5% (недоступность <3,6 часа/год)"
REQ-002: "На обслуживание отводится 2 часа в месяц, распределённые
так, чтобы не превышать 3,6 часа в год"  

Как проверять:

• Читай требования в поисках противоречий
• Используй автоматизацию: инструменты могут найти конфликты
• Проводи сессии анализа требований с team

Целевое значение: 98-100%

5. Достижимость / Осуществимость (Feasibility)

Определение: Процент требований, которые технически и экономически осуществимы.

Метрика:

Осуществимость = (Требования, оценённые как feasible / Всего требований) × 100%

Как оценивать:

• Разработчик: "Это возможно сделать с текущим tech stack?"
• Архитектор: "Соответствует ли это архитектуре?"
• Product: "Стоит ли это затрат на реализацию?"

Примеры:

❌ Неосуществимо:
"Система должна работать без интернета И синхронизироваться с облаком в реальном времени"
(невозможно синхронизировать без интернета)

✅ Осуществимо:
"Система кэширует данные локально (offline work) И синхронизирует при наличии интернета"

Целевое значение: 90-100%

6. Приоритизация (Prioritization)

Определение: Все требования имеют чёткий приоритет (MoSCoW, Value vs Effort).

Метрика:

Приоритизация = (Требования с приоритетом / Всего требований) × 100%

Методология MoSCoW:

- MUST (обязательно): без этого продукт не работает
- SHOULD (желательно): улучшает продукт, но не критично
- COULD (можно): nice-to-have
- WON'T (не будет): отложено на будущее

Value vs Effort матрица:

        High Value
             ↑
       ┌─────┴─────┐
       │   Quick   │  Do First
       │   Wins    │
       ├─────┬─────┤
       │ Invest   │ Low Priority
       │  Later   │
       └─────┴─────┴→ High Effort
       Low Value

Целевое значение: 100% (все требования приоритизированы)

7. Обоснованность (Justification)

Определение: Каждое требование имеет обоснование (почему оно нужно).

Метрика:

Обоснованность = (Требования с обоснованием / Всего требований) × 100%

Примеры обоснований:

❌ Без обоснования:
"Реализовать двухфакторную аутентификацию"

✅ С обоснованием:
"Реализовать двухфакторную аутентификацию
- ПРИЧИНА: 23% пользователей просили эту функцию
- МЕТРИКА УСПЕХА: 40% активных пользователей включат 2FA
- СРОК: Требует реализации до конца квартала (конкурент уже имеет)
- СТОИМОСТЬ ОШИБКИ: Средняя (security incident повредит репутацию)"

Целевое значение: 80-90%

8. Testability (Тестируемость)

Определение: Требование можно объективно протестировать.

Метрика:

Тестируемость = (Требования с clear test cases / Всего требований) × 100%

Примеры:

❌ Нетестируемо:
"Система должна быть удобной"
("удобная" — субъективно)

✅ Тестируемо:
"Пользователь должен создать аккаунт за < 2 минуты
- Test: Засечь время от открытия формы до успешной регистрации
- Pass criteria: < 120 секунд
- Тестировать с 10 пользователями"

Целевое значение: 90-100%

9. Стабильность требований (Requirements Stability)

Определение: Требования не меняются (или меняются минимально) после утверждения.

Метрика:

Стабильность = 100% - (Количество changes / Требования × 100)
или
Индекс стабильности = (Требования, не поменявшиеся с утверждения / Всего требований) × 100%

Примеры:

Текущий спринт: 30 требований
Из них:
- 26 требований реализованы без изменений
- 3 требования слегка изменены
- 1 требование полностью переделано

Стабильность = 26/30 = 86%
Это нормально (85-90%)

Целевое значение: 85-95% (100% невозможно в реальности)

10. Метрики по требованиям в процессе

Требования, которые нужны уточнения

Метрика = Количество требований, к которым были уточняющие вопросы / Всего требований
Цель: < 15% (более 15% = плохое качество требований)

Требования, отклоненные QA

Метрика = Количество stories, вернутых QA до завершения / Всего stories
Цель: < 5% (более 5% = требования не полные)

Время на уточнение требований

Метрика = Часы на уточнение / Часы разработки
Цель: < 5% (более 5% = требования неясны)

Комплексная оценка качества требований

Requirements Quality Index (RQI):

RQI = (Полнота × 0.20) + 
      (Ясность × 0.20) + 
      (Консистентность × 0.20) +
      (Тестируемость × 0.15) +
      (Осуществимость × 0.15) +
      (Стабильность × 0.10)

Веса можно менять в зависимости от проекта

Пример расчёта:

Полнота: 85% × 0.20 = 17%
Ясность: 90% × 0.20 = 18%
Консистентность: 95% × 0.20 = 19%
Тестируемость: 88% × 0.15 = 13.2%
Осуществимость: 92% × 0.15 = 13.8%
Стабильность: 88% × 0.10 = 8.8%
──────────────────────────────
RQI = 89.8%

Интерпретация RQI:

90-100% → Отличное качество (go to development)
80-89% → Хорошее качество (нужны небольшие улучшения)
70-79% → Приемлемое (нужны улучшения перед разработкой)
< 70% → Плохое (переделать требования)

Dashboard метрик

Пример dashboar для отслеживания:

┌─────────────────────────────────────────┐
│ REQUIREMENTS QUALITY METRICS            │
├─────────────────────────────────────────┤
│ Полнота:           85% (↑ +3% vs месяц) │
│ Ясность:           88% (↑ +2% vs месяц) │
│ Консистентность:   94% (↓ -1% vs месяц) │
│ Тестируемость:     86% (→ +0% vs месяц) │
│ Осуществимость:    90% (↑ +4% vs месяц) │
│ Стабильность:      87% (↓ -2% vs месяц) │
├─────────────────────────────────────────┤
│ REQUIREMENTS QUALITY INDEX: 89%         │
│ TREND: ↑ Улучшение                      │
├─────────────────────────────────────────┤
│ ISSUES:                                 │
│ • Стабильность снизилась на 2%          │
│ • Нужно улучшить процесс refinement      │
└─────────────────────────────────────────┘

Практические советы

1. Измеряй регулярно

• Раз в месяц пересчитывай метрики
• Отслеживай тренды (растут или падают)

2. Используй автоматизацию

• JIRA плагины для анализа требований
• Tools для отслеживания изменений

3. Обсуждай метрики с team

• На retro: какие метрики падают и почему
• Улучшай процесс на основе данных

4. Действуй на основе данных

• Если ясность < 80% → тренируй team по написанию требований
• Если стабильность < 80% → улучшай процесс refinement

Заключение

Метрики требований помогают:

• Объективно оценивать качество
• Выявлять проблемные области
• Улучшать процесс со временем
• Экономить время на переделки

Главное — не зацикливаться на метриках ради метрик. Используй их для улучшения качества и скорости разработки.