Получите все материалы с наших тренингов — бесплатно
Что Такое Нефункциональные Требования, Примеры, Что в Них Должно Быть
Что Такое Нефункциональные Требования, Примеры, Что в Них Должно Быть
Что Такое Нефункциональные Требования, Примеры, Что в Них Должно Быть
⚡ Ответим в течение 30 минут — contact@leadstartup.ru
+7 495 150 42 63 — с 8:00 до 21:00 МСК
Катерина Сухих

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

18 отзывов, в среднем 5 из 5
Что такое нефункциональные требования, примеры, что в них должно быть

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

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

Получите нашу единую MIRO–доску с 100+ инструментами и доступ к Google–диску
Материалы тренингов LeadStartup

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

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

Какими должны быть нефункциональные требования?

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

Нефункциональные требования

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

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

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

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

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

Какие бывают нефункциональные требования

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

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

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

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

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

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

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

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

  • Обучаемость. Насколько быстро пользователи могут выполнить целевые действия, как только увидят интерфейс?
  • Эффективность. Как быстро пользователи могут достичь своих целей в продукте?
  • Запоминаемость. Могут ли пользователи вернуться к интерфейсу через некоторое время и сразу же начать работать с ним?
  • Ошибки. Как часто пользователи допускают ошибки при использовании продукта?
  • Удовлетворенность. Приятен ли дизайн в использовании?

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

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

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

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

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

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

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

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

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

нефункциональные требования Интерфейс Яндекс.Вебмастер

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

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

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

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

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

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

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

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

Получите единый доступ ко всем нашим 21 курсам, 8 тренингам, 4 профессиям и 126 воркшопам — с сертификацией