Что такое нефункциональные требования? [С примерами]

Чтобы ваш продукт работал так, как вы хотите, или даже лучше, перед разработкой необходимо сформулировать требования к системе. Как мы рассказывали в одной из наших предыдущих статей, есть два типа требований: функциональные и нефункциональные. В этой статье сфокусируемся на последних и объясним, что это и почему они важны не меньше, чем функциональные.

Что такое нефункциональное требование?

Нефункциональное требование относится к системе целиком. Оно не описывает, как пользователь будет взаимодействовать с системой или интерфейсом. Нефункциональное требование определяет:

• ГДЕ и КАК система будет использоваться
• как лучше спланировать её с технической точки зрения

Нефункциональные требования также называют техническими пользовательскими историями (user stories) или требованиями качества.

Требования к тому, ГДЕ должна работать система

Есть системы, от которых мы ожидаем стабильной работы везде: на любом устройстве, на любой платформе и вообще откуда угодно. Это будет их техническим требованием. Пример таких систем — Facebook, YouTube. Но сначала они не были такими всемогущими и вездесущими. Meta и Google пришлось потратить много времени и сил, чтобы довести свои продукты до этого состояния. Первой версии продукта, MVP, для тестирования гипотез и получения первых пользователей такие широкие технические требования не нужны. Поэтому мы всегда спрашиваем, сколько активных пользователей система ожидает в первые месяцы и откуда с точки зрения месторасположения они будут использовать продукт. У такого планирования есть свои преимущества — с ним можно:

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

В целом, когда вы отвечаете навопрос “Где моя система должна работать?”, вы буквально определяете нефункциональные требования для локализации (страны первых пользователей) и масштабирования (сколько юзеров будут пользоваться системой одновременно).

Например: Владелец фабрики в Техасе хочет разработать систему видеонаблюдения под специальные нужды предприятия. Нефункциональными требованиями к системе будут:

• Локализация: США, язык — английский (американский)
• Масштабирование: 1 фабрика, 10 сотрудников охраны, до 100 одновременно включенных камер.

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

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

Технические пользовательские истории также определяют, какие браузеры и устройства должны поддерживать платформу. Вы наверняка видели такие сообщения: “Для лучшего опыта используйте последнюю версию Chrome”. Это буквально означает, что разработчик продукта протестировал ее, очевидно, на последней версии Chrome. Система может работать и в других версиях и браузерах, но создатель не уверен, как именно — он не проверил это. Обычно таким образом компании экономят на тестировании функциональностей, которыми юзеры пользуются мало или не пользуются вообще. Это довольно простое правило: продукт можно “растить” и добавлять к нему новые фичи, только если основные работают безупречно.

Требования к тому, КАК должна работать система

1. Эффективная производительность

Как разработать продукт, чтобы он работал хорошо? “Хорошо” — это вообще как?

Пример: Рассмотрим тот же пример с системой видеонаблюдения. В данном случае “хорошо” — это в хорошем качестве (Full HD, например). Но в то же время вы хотите оптимизировать затраты на сервер, чтобы не переплачивать. Тогда можно предположить, что такое высокое качество видео, как Full HD, не сильно-то нужно ночью, когда в объективе ничего не происходит. Нетехническим требованием в этом случае станет снижение качества до 480р, например, и его автоматическим улучшением, как только датчики движения фиксируют изменения.

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

2. Безопасность

Другая сторона “хорошо” — безопасно. Система может собирать или передавать персональные данные. Не учитывая это в нетехнических требованиях, рискуете нарваться на проблемы с законом. IBM в одном из своих исследований выяснили, что в 2022 средняя стоимость покрытия ущерба от утечки персональных данных составила $4,35 миллиона.

Примеры требований к безопасности:

• Пользователи платформы должны быть старше 18 лет;
• Платежи должны обрабатываться в соответствии с PCI DSS;
• Профили пользователей и хранение данных должны соответствовать GDPR.

3. Скорость

Нефункциональные требования также отвечают на вопрос “как быстро”, если скорость работы системы особенно важна (а это почти всегда).

Например:

• Результаты поиска должны загружаться за 3 секунды.

4. Интеграции

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

Например:

• Если в продукте производятся платежи, нефункциональные требования описывают платежные методы: Stripe, PayPal, покупки в приложении и т.д.
• Если пользователи должны получать сообщения на электронную почту, нефункциональные требования определяют систему рассылки: например, MailChimp, Sendinblue, Mailgun.
• Если на платформе можно смотреть видео, нефункциональные требования указывают плеер.
• Если совершают звонки, в нефункциональных требованиях прописывают, какую систему видеоконференций включить.
• Если нужно анализировать производительность, нефункциональные требования определяют необходимость интеграции Google Analytics.

И так далее.

Выводы

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

• Локализация и язык / Поддержка нескольких языков,
• Формат отображения даты и времени, часовой пояс, валюта оплаты и отображения цен,
• Текущие и потенциальные возможности масштабирования,
• Поддержка браузерами,
• Операционная система / Совместимость с устройствами,
• Ограничения по качеству / Размеру / Формату,
• Безопасность,
• Скорость / Производительность / Надежность / Отзывчивость,
• Сторонние интеграции.

Вот так может выглядеть стандартный список нефункциональных требований:

‍Заключение

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