Чтобы ваш продукт работал так, как вы хотите, или даже лучше, перед разработкой необходимо сформулировать требования к системе. Как мы рассказывали в одной из наших предыдущих статей, есть два типа требований: функциональные и нефункциональные. В этой статье сфокусируемся на последних и объясним, что это и почему они важны не меньше, чем функциональные.
Что такое нефункциональное требование?
Нефункциональное требование относится к системе целиком. Оно не описывает, как пользователь будет взаимодействовать с системой или интерфейсом. Нефункциональное требование определяет:
- ГДЕ и КАК система будет использоваться
- как лучше спланировать её с технической точки зрения
Нефункциональные требования также называют техническими пользовательскими историями (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, это красной нитью проходит через весь жизненный цикл проекта.
Комментарии