Перед началом разработки к ПО составляются требования - это формализованные утверждения, выражающие потребность, которую должно удовлетворять программное обеспечение, а также связанные с этой потребностью условия и ограничения
Даже если требования понятны и интерпретируются заказчиками и разработчиками одинаково, могут возникнуть другие проблемы, например, насколько требования реализуемы
Для проверки требований существуют два процесса:
Требования задают общий контракт понимания между заказчиками и разработчиками
Требования разделяют:
По функции (то есть функциональные) - что система должна делать
Функциональные требования описывают то, как функция должна работать, то есть какой наблюдаемый результат должен быть при определенных условиях после действия системы. Например:
Зарегистрированный пользователь должен иметь возможность войти с использованием верных электронной почты и пароля
Здесь присутствуют:
Требования должны описывать не только хорошие сценарии (так называемый happy path, “счастливый путь”), но и плохие, например, “Зарегистрированный пользователь не должен иметь возможность войти с использованием неверного пароля”
И по характеристикам (то есть нефункциональные) - какими характеристиками обладает функция или система в целом
Нефункциональные требования описывают характеристики системы. Например, время ответа на запрос:
При штатной нагрузке не менее 95% запросов авторизации должны обрабатываться не более 1 секунды
Для нефункционального требования важно обозначить измеримое качество. Для этого нужно определить:
В нефункциональных требованиях нельзя использовать слова “быстро”, “понятно” и другие, так как такие слова по-разному толкуют качественную меру функции
У требования есть 5 основных качеств, которые задают то, насколько оно правильно сформулировано:
Однозначность
Требование считается однозначным, если оно может быть растолковано одинаково для всех
Например, требование “После нескольких неуспешных попыток вход временно блокируется” плохое, потому что не указано:
Чаще всего, если в требовании есть такие слова, то оно неоднозначно: “удобно”, “быстро”, “просто”, “современно”, “оптимальный”, “подходящий”, “достаточно”, “и так далее”, “при необходимости”, “надёжно”, “по возможности”, “обычно”
Неоднозначность может быть скрытой, например:
Если пользователь отменил заказ после оплаты, система возвращает деньги и уведомляет его после проверки
В этом требовании не указано, что такое проверка, что именно проверяется, кто проверяет, когда и при каких условиях
Полнота
Хорошее требование должно описывать всю нужную информацию, необходимую для его понимания
Требование
После трех неверных паролей учетная запись блокируется
является плохим, так как не описано: срок блокировки, способ разблокировки, поведение при правильном пароле и так далее
При этом требование не должно быть избыточным или перегруженным лишними деталями, например деталями реализации
Непротиворечивость
В хорошем наборе требований они не должны противоречить друг другу
Требования “пароль должен состоять из больше 20 символов” и “пароль должен состоять из менее 15 символов” плохие
Обычно противоречивость возникает из-за множества источников принятия решений
Корректность
Хорошее требование должно удовлетворять потребность бизнеса
Требование “Пароль должен состоять из 30 или более символов” плохое, потому что пользователю не представляется удобным запоминать 30 символов, а бизнес страдает от недовольных пользователей
Требование “После одного неверного пароля учётная запись блокируется на 30 дней” тоже плохое. Несмотря на то, что оно однозначно, измеримо и легко проверяется, такое требование вряд ли соответствует бизнес-целям и пользовательским сценариям
Тестируемость
Хорошее требование должно быть тестируемым
Требование “Интерфейс должен быть интуитивно понятным” плохое, потому что не описывает, что считается “интуитивно понятным” и как это тестировать
Вместо этого “понятность” интерфейса можно оценить с помощью целевой группы пользователей, которые будут проверять этот интерфейс. Тогда требование станет таким:
Не менее 90% участников целевой группы должны самостоятельно оформить заказ по заданному сценарию без помощи модератора
Из этих качеств выделяется общая структура требования:
Чаще всего плохое требование декомпозируется в набор хороших, например:
Пользователь должен быстро и безопасно войти в интернет-магазин
Такое требование плохое, но его можно разделить в набор хороших:
1) Зарегистрированный пользователь может войти с использованием электронной почты и пароля 2) После пяти последовательных неверных паролей вход блокируется на 15 минут 3) Для 95% запросов авторизации время ответа не превышает 1 секунды при заданной штатной нагрузке (500 пользователей)
Помимо этих основных 5 качеств также можно выделить:
Для проверки требования также составляются критерии приемки. Для составления критериев приемки можно использовать схему Given-When-Then (Дано-Когда-Тогда):
Для требования также полезно проводить трассировку - процесс создания и отслеживания связей между требованиями проекта и другими его артефактами на всех этапах жизненного цикла. Трассировка проводится для анализа влияния (насколько другие части системы изменятся, если изменить или добавить требование), контроля покрытия (того, что каждое требование реализовано и проверено тестами) и прозрачности
Зачастую набор требований в текстовом виде плохо анализировать на непротиворечивость, поэтому используют другие модели: таблицы решений, диаграммы состояний или прототип функционала
Для проверки требований осуществляют ревью. Как правило, есть три типа ревью требований (от мере возрастания формальности):
Требования проверяют разные роли в компании: заказчик может проверить, действительно нужно ли это требование, аналитик проверяет на полноту, разработчик на реализуемость, тестировщик на тестируемость и так далее
Подытожим, требование должно:
Процесс создания требований превращается в цикл: