Все требования к программным продуктом можно разделить на две группы. Это функциональные и нефункциональные требования (НФТ). Первые описывают «что» нужно сделать, вторые — «как» должна работать система. Это условия, при которых продукт должен работать, и качества, которыми он должен обладать (например, производительность, надежность, масштабируемость). Они имеют большое значение, хотя напрямую и не описывают основные функции системы. От них зависит пользовательский опыт. Сегодня расскажем о трех интересных задачах из нашей практики, в которых НФТ играли решающую роль. Будем рады обсудить ваши задачи в комментариях. Увидимся под катом!
Что такое нефункциональные требования
Нефункциональные требования — это ограничения системы, они определяют ее атрибуты качества и помогают гарантировать, что система соответствует потребностям пользователя.
Нефункциональные требования можно разделить на две категории:
Атрибуты качества: Это характеристики системы, определяющие ее качество. Примеры атрибутов качества включают безопасность, производительность и удобство использования.
Ограничения: Примеры ограничений включают время, ресурсы и среду.
Задача по гарантии быстрой доставки
НФТ в этой задаче — вывести контент на странице за короткое, приемлемое для пользователя время. Для этого контент собирают из кусочков, — одна часть контента отрисовывается сразу, другая подгружается потом.
Такая задача возникает обычно там, где есть сгенерированный пользователем контент: соцсети, блоги, новостные ленты. Когда на странице есть основной набор данных, а есть данные, которые не нужны в первоначальной выдаче. Например, когда пользователь заходит смотреть товар, он хочет в первую очередь видеть сам товар. А далее, в пользу продвижения и маркетинга, сайт начинает «досыпать» данные: разделы «рекомендованное» и «вы недавно смотрели». Ту информацию, которую пользователь напрямую не запрашивал. То же самое бывает в соцсетях, новостных лентах. Пользователь запрашивал один контент, вместе с ним ему отдают возможности осуществлять навигацию к другому контенту.
Чем дольше пользователь ходит по сайту или магазину, тем больше он всего видит, — например, рекламы — и тем выше шанс, что он что-то купит.
Суть в том, что собираемая для пользователя информация может храниться в разных форматах, базах. Некоторые базы могут быть очень тяжеловесными, вычисления других может занимать время. Из-за этого, если отдавать пользователю все данные скопом, может увеличиться время ожидания сервера. Время, когда пользователь увидит информацию и сможет начать ей пользоваться. Грубо говоря, если пользователь открывает страницу в соцсетях или магазине, а она грузится пять секунд, скорее всего, пользователь закроет ее через две секунды с мыслью: «Наверное, не работает». Надо загрузиться максимум за две секунды. Для этого содержимое и разделяют.
Выглядит это следующим образом: в случае магазина нужно быть готовыми на фронте вывести страницу, которая будет наполнена только информацией о товаре. Там будет заголовок, футер — в общем, все то, что есть на каждой странице. Однако отобразится только основная информация и придет она очень быстро. Так как нужно всего лишь отобрать товар по ID, открыть его и показать. Такая страница отрисуется за полсекунды, пользователь уже может с ней работать. Попутно с первоначальной отрисовкой отправляются запросы на получение дополнительной информации. Отдельно уходят запросы либо на все дополнительное разом, либо по частям. Один запрос пошел — загрузились аватарка, информация об имени и предпочтениях. Другой запрос проанализировал активность и скидки пользователя и принес цену. Третий запрос отобразил рекомендуемые товары и так далее.
Здесь бэк и фронт работают вместе. Бэк может независимо обслуживать запросы, фронт знает, что когда получил страницу, должен запросить определенную информацию и потом собрать все воедино.
Тогда на фронте самая интересная задача состоит в том, чтобы все выглядело красиво. Красиво падало, если какой-то из запросов не дошел. Чтобы вся страница не умирала, а рисовалась заглушка или пропадала секция.
Также быстрого доступа к главному контенту можно добиться, правильно выбрав архитектуру фронта. В частности — статическую генерацию страниц — подход, при котором страницы создаются не в момент запроса, а в момент публикации или по графику. Это позволяет отдавать их пользователю мгновенно. Внутри также могут быть встроены подгружаемые части.
Вот примеры таких генераторов:
Задача поддержки доступности
НФТ в этой задаче — сделать веб-приложение доступным для людей с ограниченными возможностями. Задача сложная, потому что накладывает множество ограничений на фронтенд.
Что если у человека проблемы с цветовосприятием? Тогда все на страничке должно быть очень контрастным. Есть определенные схемы, в которых показано что, с чем и как контрастирует. Придется менять дизайн под эту контрастность.
Для слабовидящих людей нужен крупный текст. И это не значит, что нужно везде сделать семидесятый кегль, сайт должен нормально масштабироваться. Если пользователь захочет увеличить масштаб сайта, он покрутит колесико мыши с зажатым Ctrl, и сайт должен увеличиться корректно. Ведь нет нужды делать версию сайта для слабовидящих доступной для всех — большинство пользователей видят нормально. Слабовидящим же нужно дать возможность пользоваться сайтом. Это наложит свои ограничения на верстку и стили.
Слепые люди для навигации по интернету пользуются читалками. Читалки озвучивают тексты, которые написаны на сайте. При разработке сайта для слепых нужно дополнительно настроить что читать, а что — нет. Среди проблем, возникающих в разработке: текст, который логически читается первым, в верстке может оказаться дальше другого текста, что нужно читать за ним. В таких сайтах должна хорошо работать навигация по Tab’у и стрелочкам.
Полезные бесплатные инструменты для выявления и исправления проблем с доступностью:
подробнее про Web Content Accessibility Guidelines (WCAG) можно почитать тут: https://www.w3.org/WAI/standards-guidelines/wcag/
Визуализация данных
НФТ в этой задаче — вывести данные полезным для пользователя образом за приемлемое для него время. Сложность заключается в том, что данных много. Их сложно забрать, прочитать, хранить, передавать и выводить.
Проблемы в дизайне могут быть, например, такими: есть несколько миллиардов записей, как их вывести? Если вывести каждую запись отдельно, сможет ли пользователь сделать какой-либо вывод? Нужно понимать, как использовать данные, нужна аналитика — что от этих данных хочется получить, как они могут быть полезны.
После аналитики составляют дизайн — как это будет выглядеть. Дальше этот дизайн применяют с двух сторон: на вебе и на бэке. И хорошо бы не упереться ни в какие ограничения по производительности.
Придется итеративно лавировать между проблемами. С одной стороны есть требования к дизайну и аналитике: какие данные должно быть видно, чтобы это имело ценность. С другой стороны есть реальные ограничения в системе — может быть, для целей аналитики и нужно вывести три миллиона точек, но отрисовываться это будет долго. Браузер может «прикряхтеть». Три миллиона точек — это сотни мегабайт данных, которые будут пересылаться с бэкенда на фронтенд, и не факт, что пользователь готов ждать минуту или две, пока эти данные загрузятся.
Чтобы решить эту проблему, нужна агрегация данных. Сначала придумывают, как агрегировать данные, чтобы они не лишились смысла. Потом строят агрегированные графики, рисуют агрегаты на картах. Может быть, выводят выборки, если это таблица. В общем, не пытаются вывести все значения, а выводят, например, самых ярких представителей категории или среднее значение.
Другой способ решить проблему визуализации — если нужно показать много данных, можно разбить их на кусочки и показывать кусочками.
Полезные библиотеки для визуализации графиков:
https://echarts.apache.org/en/index.html — поддерживает множество разных графиков, высоко настраиваема, в том числе визуал и интерактив;
https://www.highcharts.com/ — тоже неплохая, но гораздо менее гибкая чем первая.