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

Вернемся к задаче «Спроектируй мессенджер». Ладно, звучит вроде понятно, примеров у тебя много, так что ты смело приступаешь к работе.

Спустя месяц ты приходишь и показываешь минимально жизнеспособный продукт (в англ литературе MVP), но заказчик недоволен. Он хотел, чтобы в мессенджере была возможность интеграции в корпоративную сеть и самый надежный механизм шифрования. А тут всё не то — месяц работы насмарку!

Функциональные требования описывают, ЧТО система будет делать.

• Пример — отправка сообщений или заказ товара через мобильное приложение.
• Их важно определить на самом старте, потому что от них зависит общий функционал системы.

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

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

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

Нефункциональные требования или НФР (в разных источниках ты можешь встретить разные названия) описывают, КАК система будет это делать.

• Пример — MAU, RPS, распределенность
• Определяются строго после сбора функциональных требований.

Почему это все важно: вот ты проектируешь мессенджер.

• Если у тебя нет четких функциональных требований «делать повторную рассылку о новых фичах продукта только один раз, а если человек отписался от нее — не присылать ничего вообще», ты неверно проработаешь систему.
• Другой вариант — ты не проработал нефункциональные требования, и на твою систему обрушивается гораздо бОльшее число запросов. Как результат, смежные сервисы, в которые ты обращаешься, полностью не готовы к такой нагрузке. Ты начинаешь бегать по смежным командам и спрашивать, как же поднять лимиты.

В итоге у тебя система, которая работает нестабильно и плохо выполняет требования бизнеса. Ты постоянно тушишь пожары, и бизнес всем этим недоволен. (Дальше ты начинаешь выгорать, теряешь интерес к работе и увольняешься).

И всё это из-за плохой проработки требований.

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

Например, какое будет количество пользователей, в каких регионах какая нагрузка на БД или на смежные интеграции. А если мы упадем, сколько времени системе окей быть в downtime — в день/неделю/месяц/год.

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

Давай разберем пример.

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

Так мы получим наиболее сбалансированный вариант: он решает бизнес-задачу, пользовательский опыт (дальше мы будем говорить UX — user experience)  не страдает, и технически всё это возможно реализовать — система выдержит текущие нефункциональные требования:

• Мы уменьшаем RPS на сервис рекомендаций.
• Увеличиваем общую пропускную способность системы, так как не нужно ждать, пока система посчитает рекомендацию при каждой покупке.
• Повышаем надежность, так как убираем лишний запрос в аналитический сервис.

Другой пример: бизнес говорит, что ваш интернет-магазин выходит на новый рынок.

Функциональные требования при этом такие:

• возможность выбирать товар по строке поиска;
• возможность оплачивать товары полностью или в рассрочку;
• личный кабинет, где отображаются предыдущие покупки;
• рекомендации по потенциально интересным товарам.

И на этом рынке будет 1 млн пользователей ежедневно. То есть нефункциональные требования здесь — количество пользователей.

Дальше вы обсуждаете с бизнесом, как часто пользователи будут взаимодействовать с системой и какие действия будут совершаться (так называемые user story). От этого уже можно посчитать нагрузку, объем хранения данных и все остальное.

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

1. Нужно провести груминг проекта с заказчиком (менеджером, тимлидом или другими представителями вне команды).
2. Определить один или несколько milestone — поэтапное донесение пользы пользователю.
3. Обсудить сроки и последовательность раскатки.
4. Понять, какая будет нагрузка.

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

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

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