Что такое нефункциональные требования — с примерами

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

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

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

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

Нефункциональные требования также называют техническими пользовательскими историями (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, это красной нитью проходит через весь жизненный цикл проекта.