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

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

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

Они должны быть измеримы. Их можно проверить и протестировать.

Представьте, что вы покупаете мотоцикл. Какие характеристики вам важны? Чтобы он мог ехать со скоростью 150 км в час и не развалиться на части? Или для вас важно, можно ли прикрепить к нему мотоколяску или прицеп? Наконец, он должен быть безопасным? Все эти требования не описывают напрямую основную функцию мотоцикла — доставку человека из пункта А в пункт Б. Это нефункциональные требования, но для водителей они тоже имеют значение.

К сайтам, ПО, приложениям люди тоже предъявляют нефункциональные требования. Это качества, которые удовлетворяют пользователей.

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

Если совсем просто, то к нефункциональным относят те требования, которые не описывают функциональность продукта.

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

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

Комплаенс требования. Процессы и стандарты, принятые в компании или стране. Продукт должен им следовать и разрабатываться в соответствии с ними.

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

Надежность, доступность, ремонтопригодность. Как часто в системе происходят критические сбои. Как быстро их можно устранить. Пример требований к доступности: сайт должен быть доступна для пользователей из США 98% времени каждый месяц в рабочие часы.

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

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

Удобство использования. Удобно ли людям пользоваться продуктом. Nielsen Norman Group предлагают оценивать юзабилити (usability, удобство использования) по пяти параметрам:

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

2. Эффективность. Как быстро пользователи могут достичь своих целей в продукте?

3. Запоминаемость. Могут ли пользователи вернуться к интерфейсу через некоторое время и сразу же начать работать с ним?

4. Ошибки. Как часто пользователи допускают ошибки при использовании продукта?

5. Удовлетворенность. Приятен ли дизайн в использовании?

Как скорость загрузки влияет на отказы пользователей. Чем дольше загружается, тем чаще люди закрывают продукт

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

Есть три метрики для времени отклика, они основаны на том, как работает человеческое внимание:

0,1 секунды — предел, после которого реакция системы не кажется мгновенной;

1 секунда — пользователь заметит задержку, но для него это не критично;

10 секунд — внимание пользователя полностью потеряно.

За скоростью следят и поисковики. Страницы с быстрой загрузкой и качественным контентом будут отображаться на первой странице поисковой выдачи. Если же контент хорош, но сайт долго грузится, то первых строчек ему не видать. Например, исследования Гугл показали, что 50 пользователей из 100 закроют сайт, если он загружается дольше трех секунд.

У Яндекса и Google есть бесплатные сервисы, которые измеряют скорость загрузки сайтов: Яндекс. Вебмастер и Google PageSpeed Insights. Сервисы дают рекомендации, на чем теряется время загрузки и что исправить, чтобы повысить скорость.

Интерфейс Яндекс.Вебмастер

Сделайте их измеримыми и тестируемыми. Нефункциональные требования следует формировать так, чтобы их можно было измерить и проверить. Например, Wow–эффект у приложения: это требование нельзя измерить и проверить, но если сформировать его как «на юзабилити тесте более 70% респондентов отметили высокое качество интерфейса в опроснике», то отследить приближение такой цели и протестировать ее достижение становится легко.

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

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

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

Учитывайте технические ограничения. Если сторонний API возвращает данные медленнее, чем вам нужно, вы или ваша команда мало что можете с этим поделать. Остается только принять этот факт.

Учитывайте архитектурные ограничения. Устаревшие системы могут накладывать ограничения на качество. Иногда нет другого выхода как полностью переделать текущую архитектуру.

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