Функциональные и нефункциональные требования: различия и особенности

Рассказываем о двух основных категориях требований к продукту, приводим примеры, разбираемся в их отличиях и даём рекомендации по их составлению.

Функциональные требования описывают прикладные требования к системе, то есть то, что система должна делать. Они определяют все функции, которые программа или продукт должны выполнять в зависимости от того, какие действия совершает пользователь: например, пользователь должен иметь возможность авторизоваться на портале с помощью валидных логина и пароля или попасть на сценарий восстановления пароля, если он забыл свой пароль.
Если взять пример с интернет-магазином, пользователь должен иметь возможность добавлять товары в корзину, удалять или заменять их. Или, например, находясь в корзине, пользователь может нажать на соответствующую иконку и удалить товары — это будет более атомизированное, низкоуровневое требование.

Так как функциональные требования описывают непосредственно функционал продукта, при их описании можно использовать вопросы «что?» и «как?» в контексте операции с данными, взаимодействия с пользователями, бизнес-правил, интеграции с другими системами и т. д.

Функциональные требования может проверить не только тестировщик, но и сам пользователь в процессе использования системы, приложения, сайта и т. д. Научиться тестировать веб- и мобильные приложения на профессиональном уровне поможет курс «Инженер по тестированию: от новичка до автоматизатора». Наставники из Яндекса, EPAM и других крупных компаний объяснят теорию, помогут справиться с практическими задачами и собрать впечатляющее портфолио. Попробовать учиться можно бесплатно.

Нефункциональные требования описывают то, как система должна работать, то есть качество системы или продукта в целом: надёжность, безопасность, масштабируемость и т. д. Такие требования более абстрактны. Как правило, нефункциональные требования с точки зрения пользователя невозможно проверить или воспроизвести простыми действиями. Кроме того, они более объёмные: чтобы их проверить, нужно собирать статистику, смотреть определённые цифры, графики и метрики, часто уже ретроспективные.

Примеры функциональных требований: система должна поддерживать не менее 1000 пользователей на портале одновременно и откликаться на действия пользователя не более чем за две секунды. Это требование обычный пользователь не сможет проверить, просто зайдя на портал. Тут требуется работа специалистов — нагрузочное тестирование, графики, метрики, проверка времени отклика и т. д.

Рассмотрим пример, когда команда выкатывает новый дизайн страницы авторизации или новый флоу процесса регистрации пользователя. На сайт или в приложение вносятся изменения, и функциональные требования как раз будут описывать, как теперь этот флоу работает. Более конкретно: какие шаги нужно выполнить пользователю, чтобы авторизоваться или зарегистрироваться?

Например, раньше вход на сайт осуществлялся по логину, а теперь придётся входить по номеру телефона, вводя код из СМС. Выполнение функциональных требований можно проверить буквально на ходу: есть новый флоу по регистрации и авторизации, тестировщик взял требования, авторизовался или зарегистрировался — всё работает, проверено.

Что могло быть нефункциональным требованием в данном случае: например, уровень оценки удобства пользователями новой системы авторизации. Условно говоря, пользователи должны оценивать её на 4,5 балла из 5. Проверить мгновенно выполнение этого требования не получится, измерить удовлетворённость пользователя от использования новой системы можно только ретроспективно. Сначала команда выпускает эту функцию в продакшн, пользователи некоторое время ею пользуются и со своей стороны выставляют оценки. Только по истечении времени команда сможет собрать и проанализировать обратную связь, оценить результат и сравнить, лучше стало или хуже.

Для другого примера возьмём приложение банка. Функциональными требованиями могут быть: возможность пользователя проверять баланс счёта, переводить средства между счетами, оплачивать счета и заказывать выписки по операциям.

А нефункциональные требования могут включать возможность обрабатывать запросы 10 000 параллельных пользователей, загрузку приложения не более чем за три секунды, требования по защите данных, такие как шифрование передаваемой информации и выполнение аутентификации на нескольких уровнях.

Составлять требования нужно сразу после того, как у команды появилась идея или ТЗ некоей задачи или функции, которую планируется реализовать. В этот момент уже можно и нужно начинать продумывать функциональные и нефункциональные требования. Как правило, этим занимаются аналитики, бизнес- или системные, каждый на своём уровне.

Функциональные требования должны быть согласованы со всеми заинтересованными сторонами:

● с бизнесом и заказчиком — они делятся пожеланиями и выдвигают требования;
● с пользователями — здесь команда может только предполагать, как будут восприняты изменения;
● с внешними командами — например, как наше приложение будет интегрировано с внешним сервисом (какими данными будет обмениваться, по какой логике и т. д.).

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

Крайне желательно при постановке требований составлять их по шаблону, например в формате юзер-стори, или пользовательского сценария. Например, «я как пользователь хочу иметь возможность авторизоваться с валидными учётными данными в интернет-магазине».

Тогда работа по составлению требований выглядит так: команда прописывает список необходимых юзер-стори и, отталкиваясь от него, разрабатывает функциональные требования. В процессе требования дробятся на более низкоуровневые. Например, из «авторизоваться c валидными учётными данными» получаем «авторизоваться с почтой с доменом .ru».

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

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

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

В зависимости от существующих процессов команда может использовать такие инструменты постановки задач для описания нефункциональных требований: Яндекс Трекер, Trello, Jira и т. д. Как правило, заводится новая задача и в карточке прописываются функциональные и нефункциональные требования. Также нефункциональные требования могут быть описаны просто в виде тезисов и списков в Google-документе и т. д.