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

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

Ниже — группы требований, готовые формулировки, которые можно вставить в ТЗ, что разрешено не писать для небольшого сайта, как всё это проверить при приёмке и чек-лист из 15 пунктов. Как описывать сами функции через сценарии, мы разбирали в статье про user story, а структуру ТЗ целиком — в материале как составить ТЗ на сайт.

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

Функциональное требование отвечает на вопрос «что система делает»: клиент оформляет заказ, менеджер видит заявку. Нефункциональное — «насколько хорошо и в каких условиях»: заказ оформляется за три экрана, страница открывается за 2,5 секунды, данные не теряются при сбое сервера.

Разницу легко увидеть на одной функции. «Пользователь ищет товар по названию» — функциональное. «Поиск по каталогу из 5 000 позиций отвечает быстрее секунды и находит товар при опечатке в одной букве» — уже набор качеств той же функции. Без них разработчик выполнит требование формально: поиск будет, но медленный и капризный.

Международная модель качества ISO/IEC 25010:2023 описывает качество программного продукта через девять характеристик, каждая из которых делится на подхарактеристики. Заказчику не нужно знать стандарт наизусть: достаточно пройтись по группам ниже и решить, какие из них важны для вашего проекта.

Какие группы нефункциональных требований бывают?

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

Числа в примерах — ориентиры для типового проекта, а не норматив. Для лендинга с десятком заявок в день и для кабинета на тысячу сотрудников они разные. Подставьте свои значения, но сохраните форму: показатель, порог, условие измерения.

Группа	Проверяемая формулировка	Как проверить на приёмке
Скорость	LCP ключевых страниц на мобильном — не более 2,5 с по лабораторному замеру	Отчёт PageSpeed Insights по списку страниц
Время ответа	Поиск по каталогу из 5 000 товаров отвечает быстрее 1 с	Замер в инструментах разработчика браузера, 10 запросов
Нагрузка	Сервис выдерживает 100 одновременных пользователей без ошибок	Нагрузочный прогон с отчётом: число запросов, ошибки, время
Доступность	Не менее 99,5 % времени в месяц, плановые работы ночью с предупреждением	Отчёт внешнего мониторинга за первый месяц
Резервные копии	База — ежедневно, хранение 14 дней, копия на другом сервере	Список копий и одно пробное восстановление
Восстановление	После сбоя сервис поднимается из копии не дольше 4 часов	Пробное восстановление на тестовом сервере с замером
Безопасность	Только HTTPS, пароли хранятся в виде хеша, 5 неверных входов — блокировка на 15 минут	Ручная проверка и просмотр кода
Данные	Персональные данные граждан РФ записываются и хранятся в базе на сервере в России	Адрес и договор хостинга, схема данных
Совместимость	Последние две версии Chrome, Safari, Яндекс Браузера, Firefox; ширина экрана от 360 px	Прохождение ключевых сценариев на списке устройств
Сопровождаемость	Код в репозитории заказчика, инструкция по развёртыванию, журнал ошибок	Развёртывание по инструкции на чистом сервере

Как написать требование, которое можно проверить?

Формула простая: что измеряем, какое значение допустимо и при каких условиях. «Сайт должен быть быстрым» проверить нельзя. «Главная и карточка товара на мобильном показывают основное содержимое не дольше чем за 2,5 секунды» — можно, и спорить не о чем.

Примеры переписанных формулировок:

• Было: «сайт должен выдерживать большую нагрузку». Стало: «каталог отвечает без ошибок при 200 одновременных посетителях; время ответа сервера при этом не больше 1 секунды».
• Было: «данные должны быть защищены». Стало: «все страницы работают только по HTTPS; пароли хранятся в виде хеша; доступ к админке — только у ролей «администратор» и «менеджер».
• Было: «сайт должен работать везде». Стало: «ключевые сценарии проходят в двух последних версиях Chrome, Safari, Яндекс Браузера и Firefox, на экранах от 360 px».
• Было: «нужны бэкапы». Стало: «копия базы и загруженных файлов — ежедневно, хранится 14 дней на другом сервере; восстановление проверяется раз в квартал».
• Было: «сайт должен работать стабильно». Стало: «доступность не ниже 99,5 % в месяц по данным внешнего мониторинга, плановые работы — с 01:00 до 05:00 по Москве с предупреждением за сутки».

Что прописать про скорость и нагрузку?

Для скорости берите показатели Core Web Vitals: LCP не больше 2,5 с, INP меньше 200 мс, CLS меньше 0,1. Для нагрузки — число одновременных пользователей и допустимое время ответа при нём. Замер — на рабочем сервере с реальным контентом и списком конкретных страниц.

Пороги «хорошо» для трёх показателей опубликованы в документации Google о Core Web Vitals: LCP — как быстро показалось главное, INP — как быстро страница реагирует на нажатие, CLS — не «прыгает» ли вёрстка при загрузке. Как замерять и что обычно тормозит, подробно разобрано в статье о скорости загрузки сайта.

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

Отдельно укажите тяжёлые операции: выгрузку отчёта за год, импорт прайса на 20 000 строк, генерацию PDF. Для них разумное требование — не «мгновенно», а «выполняется в фоне не дольше 5 минут, пользователь получает уведомление».

Как описать доступность, резервные копии и восстановление?

Тремя числами: допустимый простой в месяц, частота и срок хранения копий, время восстановления после сбоя. И одним условием приёмки — пробным восстановлением из копии. Копия, из которой ни разу не восстанавливались, остаётся предположением.

Доступность удобнее переводить в часы. 99,5 % за 30 дней — это около 3,6 часа простоя в месяц, 99,9 % — около 43 минут. Второе значение требует уже не одного сервера, а дублирования и дежурства, и стоит соответственно. Для корпоративного сайта обычно хватает первого, для сервиса, через который идут оплаты, стоит обсуждать второе.

В требованиях к резервным копиям стоит указать:

• что копируется: база данных, загруженные файлы, настройки — не только код;
• как часто: для магазина с заказами — минимум ежедневно, для сайта-визитки достаточно копии после изменений;
• сколько хранить: 7–30 дней, чтобы успеть заметить тихую порчу данных;
• где: на другом сервере или в другом хранилище, а не рядом с рабочей базой;
• сколько данных допустимо потерять: «не больше суток заказов» — это и есть требование к частоте копий;
• за какое время сервис должен подняться после сбоя.

Следить за тем, что сайт жив и копии создаются, помогает мониторинг; что именно отслеживать, описано в статье про мониторинг сайта после запуска.

Что написать про безопасность и персональные данные?

Минимум для любого проекта: только HTTPS, пароли в виде хеша, разграничение ролей, защита входа от перебора, журнал действий администраторов в сервисах с данными клиентов. Отдельной строкой — где хранятся персональные данные граждан РФ: по закону запись и хранение должны идти в базах на территории России.

Это требование ч. 5 ст. 18 закона 152-ФЗ: при сборе персональных данных, в том числе через интернет, операции с ними с использованием баз за пределами России не допускаются, кроме узкого перечня исключений. Для ТЗ это значит конкретную строку: «база с данными из форм и кабинета размещается на сервере в России». Подробности о формах, уведомлении Роскомнадзора и политике — в статье где хранить данные сайта по 152-ФЗ.

Что ещё стоит записать для сервиса с кабинетами:

• какие роли есть и что каждая видит — особенно если сотрудник не должен видеть чужих клиентов;
• что происходит после N неверных паролей и как восстанавливается доступ;
• кто и как получает доступы к серверу, базе и репозиторию, и как они отзываются при смене подрядчика;
• какие действия пишутся в журнал: вход, изменение цен, удаление записей, выгрузка базы;
• куда уходят данные во внешние сервисы: рассылки, аналитика, чаты, платёжные системы.

Юридическую часть — тексты согласий, политику, уведомление регулятора — разработчик не пишет. Он отвечает за то, чтобы техническая сторона соответствовала тому, что согласует ваш юрист.

Как задать браузеры, устройства и удобство?

Перечнем: какие браузеры и версии, минимальная ширина экрана, обязательные устройства для проверки, требования к доступности для людей с ограничениями зрения, если они есть. Чем короче и конкретнее список, тем дешевле и честнее приёмка.

Удобная формулировка — «две последние стабильные версии» браузеров: она не устаревает с выходом обновлений. Если ваши сотрудники работают на старых рабочих компьютерах или на конкретной модели терминала, укажите это явно: такие устройства разработчик сам не угадает. Для внутренних сервисов полезно назвать реальные устройства — «ноутбуки бухгалтерии, планшет кладовщика».

Удобство тоже можно сделать проверяемым: «заявка отправляется не больше чем за три шага», «все поля формы подписаны, ошибка показывается рядом с полем», «кнопки на мобильном не меньше 44 px по высоте». Если сайт должен быть доступен людям с нарушениями зрения, сошлитесь на конкретный уровень рекомендаций WCAG — о нём подробно в статье про доступность сайта.

Что можно не писать для небольшого сайта?

Для лендинга или визитки достаточно пяти требований: скорость на мобильном, адаптив, HTTPS, адресат заявок и хранение данных форм в России. Нагрузка, время восстановления и журнал действий здесь избыточны и только раздувают ТЗ.

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

Проект	Что прописать обязательно	Что можно не писать
Лендинг, сайт-визитка	Скорость на мобильном, адаптив, HTTPS, куда уходят заявки, где хранятся данные формы	Нагрузку, время восстановления, сложные требования к паролям
Корпоративный сайт	То же плюс резервные копии и список браузеров	Нагрузочное тестирование, если нет рекламных всплесков трафика
Интернет-магазин	Скорость каталога и корзины, доступность, копии базы заказов, поведение при отказе оплаты	Требования к сотням тысяч одновременных пользователей «на вырост»
Веб-сервис, личный кабинет	Роли и права, нагрузка, копии и время восстановления, журнал действий, хранение данных в РФ	Ничего из ключевого: здесь нефункциональные требования определяют архитектуру

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

Для каждого требования заранее согласуйте способ проверки и того, кто её делает. Часть можно проверить самому за час: скорость, HTTPS, браузеры, адаптив. Нагрузку, копии и восстановление проверяет исполнитель и показывает отчёт или делает проверку при вас.

Порядок, который работает:

1. В ТЗ рядом с каждым требованием пишется способ проверки — как в первой таблице.
2. До сдачи исполнитель присылает протокол: замеры скорости по списку страниц, отчёт нагрузочного прогона, список резервных копий, результат пробного восстановления.
3. Вы сами проходите ключевые сценарии на своих устройствах и в своих браузерах.
4. Несоответствия оформляются как замечания к приёмке с указанием требования из ТЗ.

Часть требований подтверждается только временем: доступность 99,5 % за месяц на приёмке не измерить. Для таких пунктов договоритесь, что проверка идёт по данным мониторинга за первый месяц, а отклонения разбираются в рамках гарантии или поддержки. Какие ещё проверки делает разработчик до сдачи, описано в статье о видах тестирования сайта.

Чек-лист: 15 нефункциональных требований

Пройдитесь по списку перед отправкой ТЗ. Для каждого пункта — либо число и способ проверки, либо осознанное решение «для нашего проекта не нужно».

1. LCP ключевых страниц на мобильном и список этих страниц.
2. Время ответа для тяжёлых операций: поиск, фильтры, отчёты, импорт.
3. Пиковое число одновременных пользователей и поведение при превышении.
4. Допустимый простой в месяц и окно плановых работ.
5. Что копируется, как часто и сколько хранится.
6. Где хранятся копии — не на том же сервере.
7. Сколько данных допустимо потерять и за какое время система восстанавливается.
8. HTTPS на всех страницах и автопродление сертификата.
9. Хранение паролей и защита входа от перебора.
10. Роли и права: кто что видит и меняет.
11. Журнал действий администраторов и сотрудников.
12. Размещение персональных данных граждан РФ на сервере в России и список внешних сервисов, куда уходят данные.
13. Браузеры, версии, минимальная ширина экрана, обязательные устройства.
14. Требования к доступности для людей с нарушениями зрения, если они нужны.
15. Репозиторий, инструкция по развёртыванию и журналы ошибок для будущей поддержки.

Какие ошибки делают чаще всего и когда это вам не нужно?

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

• Прилагательные вместо порогов. «Быстрый», «надёжный», «защищённый» не проверяются — их невозможно принять или оспорить.
• Запас без расчёта. Требования уровня крупного маркетплейса для небольшого сервиса меняют архитектуру и бюджет, а реальной пользы не дают.
• Копии без проверки восстановления. Самый частый неприятный сюрприз: копии есть, но восстановиться из них нельзя или долго.
• Замер на пустом сайте. Скорость проверяют с реальными фото, каталогом и подключёнными счётчиками, иначе цифры ничего не значат.
• Требования, добавленные после старта. Нагрузка или доступность, появившиеся в середине работ, могут потребовать другой сервер и пересчёт сметы.

Если вы не готовы назвать числа, это нормально: опишите ситуацию словами — «рассылка на 10 000 адресов раз в неделю», «в сезон заказов втрое больше», «без кабинета склад стоит». Разработчик переведёт это в пороги, а вы их согласуете.

Где это фиксируется и сколько стоит?

Нефункциональные требования входят в ТЗ и спецификацию к договору, а их проверка — в приёмку: у заказчика на неё 5 рабочих дней. Цена зависит от того, что за требованиями стоит: дополнительный сервер, дублирование, нагрузочный прогон. Её считаем после брифа и фиксируем в договоре до старта.

Базовые качества уже заложены в тарифы: адаптив, HTTPS, подключение аналитики, публикация на домене. Ориентиры — лендинг от 24 000 ₽, корпоративный сайт от 56 000 ₽, интернет-магазин от 104 000 ₽, веб-приложение от 160 000 ₽. Требования к нагрузке, доступности и восстановлению выше типовых оцениваются отдельно. Ошибки по вине исполнителя исправляются в течение гарантии — 30 календарных дней с даты акта, а наблюдать за доступностью и копиями дальше можно в рамках поддержки от 7 900 ₽ в месяц.

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

Короткие ответы на частые вопросы

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

Это требования к тому, какой должна быть система, а не что она делает: как быстро открывается, сколько людей выдерживает, как защищена, как часто делаются копии и на каких устройствах работает.

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

Функциональное описывает действие: «клиент оформляет заказ». Нефункциональное описывает качество этого действия: «оформление занимает не больше трёх экранов и работает на телефоне с шириной экрана 360 px».

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

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

Как проверить скорость сайта при приёмке?

Прогнать ключевые страницы через PageSpeed Insights в мобильном режиме и сравнить показатель LCP с числом из ТЗ. Замер делают на рабочем сервере с реальным контентом, а не на пустых страницах.

Можно ли добавить нефункциональные требования после начала работ?

Можно, но это изменение объёма: требование к нагрузке или времени восстановления может поменять сервер и архитектуру. Такие изменения оформляют отдельным документом с новой ценой и сроком.

Услуги и кейсы по теме: бриф проекта онлайн · заказная разработка · типовые договоры · цены и сроки