День 1936. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 9. Качество требований каждый определяет по-своему. Окончание
Начало

Контрольный список для оценки качества требований
Ставя цель создать качественные требования, бизнес-аналитики должны стремиться к достижению следующих характеристик:

1. Полнота
Отсутствие упущений в требованиях. Каждое требование содержит всю информацию, необходимую читателю для выполнения его работы. Любые упущения отмечаются как подлежащие уточнению. Никто не сможет гарантировать, что выявил все требования. Но если вы намеренно пишете неполные требования, ожидая, что читатели запросят дополнительную информацию, когда она им понадобится, то убедитесь, что они знают об этом.

2. Непротиворечивость
Решение, удовлетворяющее любому отдельно взятому требованию, должно быть совместимо с любыми другими требованиями. Уловить противоречия сложно. Порой очень трудно выявить несоответствия между требованиями разных типов, например нарушение бизнес-правил со стороны функциональных требований или конфликт с требованиями пользователя.

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

4. Достижимость
Разработчики смогут реализовать решение для удовлетворения данного требования в рамках известных технических, временных и ресурсных ограничений.

5. Необходимость
Каждое требование описывает возможность, в которой действительно нуждаются те или иные заинтересованные стороны.

6. Приоритетность
Требования классифицируются по их относительной важности и своевременности включения в продукт.

7. Отслеживаемость
Каждому требованию присваивается уникальный идентификатор, чтобы его можно было связать с источником и далее с проектами, кодом, тестами и любыми другими элементами, созданными для удовлетворения этого требования. Знание источника дает дополнительный контекст и показывает, к кому можно обратиться за разъяснениями.

8. Однозначность
Все читатели интерпретируют каждое требование совершенно одинаково. Если требование неоднозначно, то невозможно будет определить, является оно полным, правильным, выполнимым, необходимым или достоверным, поскольку вы не сможете точно сказать, что оно означает. Нельзя полностью избавиться от двусмысленности естественного языка; тем не менее старайтесь избегать следующих слов и выражений: лучший, и так далее, быстрый, гибкий, например, то есть, улучшенный, включая, максимизировать, необязательно, несколько, достаточно, поддержка и обычно.

9. Достоверность
Существует некий объективный, однозначный и эффективный способ определить, удовлетворяет ли решение требованиям. Наиболее распространённый способ проверить достоверность — тестирование, поэтому некоторые называют эту характеристику тестируемостью.

Невозможно создать идеальный набор требований. Но в этом и нет необходимости, если процесс разработки проекта подразумевает использование механизмов для быстрого выявления и исправления ошибок в требованиях до того, как команда их реализует. Получение отзывов от многочисленных читателей требований поможет избежать чрезмерных затрат на доработку.

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.