Какие знаешь критерии качественного требования?

Критерии качественного требования

В процессе работы с требованиями business analyst должен руководствоваться чётким набором критериев, которые гарантируют качество и понятность для всех заинтересованных сторон.

Основные критерии качества

SMART-принцип

Любое требование должно быть:

• Specific (конкретное) — не размытое, с чёткой формулировкой
• Measurable (измеримое) — содержит метрики или критерии приёмки
• Achievable (достижимое) — реально осуществимо в рамках проекта
• Relevant (релевантное) — соответствует бизнес-целям
• Time-bound (с временными рамками) — указаны сроки реализации

Структурные характеристики

Полнота информации

• Требование содержит контекст и предпосылки
• Описана как happy path, так и граничные случаи
• Указаны исключения и условия применимости

Атомарность

• Одно требование = одна функциональность
• Избегаем составных требований типа "И при этом..."
• Легко ставить в спринт или разбивать на подзадачи

Независимость

• Требования минимально зависимы друг от друга
• Можно разрабатывать параллельно
• Нет циклических зависимостей

Прецедентные сценарии

Качественное требование содержит примеры использования:

Примеры сценариев:
- Пользователь с ролью admin может отредактировать все поля
- Пользователь с ролью editor может менять только текст контента
- Система должна предотвратить удаление активных задач

Критерии приёмки

Должны быть явно определены условия, при которых требование считается выполненным:

• Функциональные проверки
• Граничные случаи
• Требования по производительности
• Требования по безопасности

Отсутствие двусмысленности

Плохое требование: "Система должна быть быстрой" Хорошее требование: "Время загрузки страницы не должно превышать 2 секунд на подключении 3G при первой загрузке"

Используем точные термины вместо субъективных оценок.

Согласованность и консистентность

• Требование не противоречит другим
• Использует единую терминологию по всему документу
• Согласовано с бизнес-процессами и техническими ограничениями

Проверяемость

Тестировщик должен иметь возможность четко определить, выполнено требование или нет:

• Не должно быть субъективной интерпретации
• Можно автоматизировать проверку (где применимо)
• Требование реально протестировать в рамках проекта

Трассируемость

• Требование связано с источником (стейкхолдер, документ)
• Можно отследить его через весь цикл жизни
• Документированы все изменения и согласования

Эти критерии помогают избежать недопониманий, переделок и конфликтов на этапах разработки и тестирования.