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

Про то, как болит голова

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

• Машина ехала 2 часа вместо 30 минут (плохая производительность).
• В машине было грязно и воняло (плохой UX/UI).
• Такси сломалось по дороге (ненадежность).
• Водитель требовал наличные, хотя вы заказывали с оплатой по карте (несоответствие требованиям).

Вы останетесь недовольны. Хотя функция “довезти” была выполнена.

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

Нефункциональные требования – это требования к качеству системы, к тому, КАК она выполняет свои функции.

Что такое нефункциональные требования (НФТ/NFR)

Функциональные требования отвечают на вопрос “ЧТО система делает?”. Нефункциональные – на вопросы “КАК?”, “НАСКОЛЬКО ХОРОШО?”, “С КАКИМ КАЧЕСТВОМ?”.

Если проводить аналогию с автомобилем:

• Функциональные требования: машина едет, поворачивает, тормозит, открывает двери.
• Нефункциональные требования: разгон до 100 км/ч за 10 секунд, расход топлива 8 литров на 100 км, уровень шума в салоне, количество звезд в краш-тесте, гарантия 5 лет.

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

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

Есть старая поговорка в IT: “Функциональные требования продают продукт, а нефункциональные – возвращают пользователей”.

Что это значит?

• Если у вас нет нужной функции, пользователь вообще не придет (функциональные требования).
• Если функция есть, но работает ужасно, пользователь придет один раз и больше не вернется (нефункциональные требования).

Пример: Представьте два интернет-магазина. В обоих можно купить телефон (функция одинаковая). Но в первом сайт грузится 10 секунд, во втором – 1 секунду. Куда вы пойдете в следующий раз?

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

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

Существует много классификаций, но мы разберем основные категории, которые встречаются в любом проекте.

Производительность (Performance)

Требования к скорости работы системы, времени отклика, пропускной способности.

О чем думаем:

• Как быстро загружается страница?
• Сколько времени выполняется операция?
• Сколько пользователей могут работать одновременно?

Примеры:

• “Время загрузки главной страницы не должно превышать 2 секунд при ширине канала 10 Мбит/с”.
• “Поиск по каталогу должен выдавать результаты не дольше чем за 1 секунду”.
• “Система должна обрабатывать не менее 100 запросов в секунду”.
• “Отчет по продажам за месяц должен формироваться не дольше 30 секунд”.
• “API-метод должен отвечать не дольше 500 миллисекунд (ms)”.

Надежность и доступность (Reliability & Availability)

Требования к тому, как часто система падает, как быстро восстанавливается, не теряет ли данные.

О чем думаем:

• Сколько времени система может быть недоступна?
• Как часто случаются сбои?
• Что происходит при сбое? Теряются данные?

Примеры:

• “Система должна быть доступна 24/7. Допустимое время простоя – не более 1 часа в месяц (это называется SLA 99,86%)”.
• “Время восстановления после сбоя не должно превышать 15 минут”.
• “Система должна автоматически создавать резервные копии базы данных каждые 24 часа”.
• “При сбое электропитания все несохраненные данные должны быть восстановлены после включения”.
• “Система должна сохранять работоспособность при отказе одного из серверов”.

Часто используется термин “SLA” (Service Level Agreement) – соглашение об уровне обслуживания. Например, SLA 99,9% означает, что система может быть недоступна не более 8 часов в год.

Безопасность (Security)

Требования к защите данных, разграничению доступа, аудиту.

О чем думаем:

• Кто имеет доступ к данным?
• Как данные защищены от взлома?
• Как мы узнаем, что произошло что-то подозрительное?

Примеры:

• “Пароли пользователей должны храниться в базе в захэшированном виде с солью”.
• “Все соединения с системой должны быть зашифрованы по протоколу HTTPS (TLS 1.2 и выше)”.
• “Доступ к API должен быть защищен токенами авторизации”.
• “Должно быть разграничение прав доступа: администратор видит всё, менеджер видит только свои заказы”.
• “Все действия пользователей с персональными данными должны логироваться”.
• “После 5 неудачных попыток входа аккаунт должен блокироваться на 15 минут”.

Масштабируемость (Scalability)

Требования к тому, как система будет расти.

О чем думаем:

• Что будет, когда пользователей станет в 10 раз больше?
• Как легко добавить новые мощности?

Примеры:

• “Архитектура системы должна позволять горизонтальное масштабирование (добавление новых серверов) без остановки работы”.
• “При увеличении количества пользователей в 5 раз производительность не должна падать более чем на 20%”.
• “Система должна поддерживать хранение данных объемом до 10 ТБ”.

Удобство использования (Usability)

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

О чем думаем:

• Понятно ли пользователю, как работать?
• Может ли пользователь с ограничениями пользоваться системой?
• Насколько быстро новый сотрудник научится работать?

Примеры:

• “Время обучения нового сотрудника работе с системой не должно превышать 2 часов”.
• “Интерфейс должен быть интуитивно понятным: все основные функции доступны в 2 клика”.
• “Система должна поддерживать горячие клавиши для основных операций”.
• “Критические действия (например, удаление) должны сопровождаться подтверждением”.
• “Интерфейс должен соответствовать стандартам доступности для людей с ограниченными возможностями (WCAG 2.1)”.

Совместимость и переносимость (Compatibility & Portability)

С кем и чем система должна дружить, на каких платформах работать.

О чем думаем:

• С какими браузерами система работает?
• На каких устройствах открывается?
• Интегрируется ли с другими системами?

Примеры:

• “Система должна корректно отображаться в последних версиях Chrome, Firefox, Safari и Edge”.
• “Интерфейс должен быть адаптирован под мобильные устройства (разрешение от 320px)”.
• “Система должна интегрироваться с 1С через REST API”.
• “Должна быть возможность развернуть систему в среде Linux и Windows”.

Сопровождаемость (Maintainability)

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

О чем думаем:

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

Примеры:

• “Код должен быть документирован на русском или английском языке”.
• “Система должна вести логи всех ошибок с указанием времени, пользователя и стека вызова”.
• “Должна быть предусмотрена возможность мониторинга состояния системы через отдельный дашборд”.
• “Обновление конфигурации должно производиться без остановки работы системы”.

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

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

Спрашивать заказчика

Да, даже если он не говорит, спросите сами:

• “Сколько пользователей будут работать одновременно?”
• “Как быстро должна загружаться страница?”
• “Что для вас критичнее – скорость или надежность?”
• “Какие браузеры используют ваши клиенты?”
• “Какие требования по безопасности есть в вашей компании?”

Анализировать предметную область

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

Изучать законодательство

Если система работает с персональными данными, есть закон (152-ФЗ), который диктует требования к безопасности и хранению.

Смотреть аналоги

Как работают конкуренты? Какие требования к производительности у популярных сервисов в вашей нише?

Спрашивать команду

Архитектор, DevOps, разработчики – они часто лучше знают, какие нефункциональные требования нужны для стабильной работы.

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

Давайте посмотрим на примере, как одно и то же функциональное требование обрастает разными нефункциональными в зависимости от контекста.

Функциональное требование (общее для всех)

“Система должна отображать список товаров с фильтрацией по категориям”.

Вариант А: Маленький интернет-магазин для 10 сотрудников

• Производительность: страница грузится до 3 секунд, одновременно работают до 20 человек.
• Надежность: допустим простой до 4 часов в месяц (рабочее время).
• Безопасность: базовая авторизация по паролю.
• Масштабируемость: не требуется, роста не ожидается.

Решение: Можно сделать простой сайт на одном сервере, без кэширования, с простой архитектурой.

Вариант Б: Маркетплейс на миллион пользователей

• Производительность: страница грузится до 1 секунды, одновременно 100 000 пользователей.
• Надежность: доступность 99,99% (не более 1 часа простоя в год).
• Безопасность: шифрование данных, защита от DDoS, PCI DSS для платежей.
• Масштабируемость: должна легко расти при увеличении нагрузки.

Решение: Нужна сложная распределенная архитектура, кластер серверов, кэширование (Redis), CDN для контента, балансировщики нагрузки, репликация базы данных.

Функциональное требование одно и то же, а системы будут построены совершенно по-разному. Вот почему нефункциональные требования так важны.

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

Четко и измеримо

Самое главное правило: нефункциональное требование должно быть измеримым. Иначе как вы проверите, что оно выполнено?

Плохо: “Система должна быть быстрой”. Хорошо: “Время загрузки страницы каталога при стандартных настройках и ширине канала 10 Мбит/с не должно превышать 2 секунд”.

Плохо: “Система должна быть надежной”. Хорошо: “Доступность системы должна составлять не менее 99,5% времени в месяц (не более 3,5 часов простоя)”.

Группировать по категориям

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

• Требования к производительности
• Требования к безопасности
• Требования к надежности
• Требования к интерфейсу и удобству
• Требования к совместимости
• Требования к эксплуатации и сопровождению

Связывать с функциональностью

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

• Ко всей системе: доступность 99,9%, работа в Chrome, логирование ошибок.
• К конкретной функции: формирование отчета не дольше 30 секунд.

Типичные ошибки

Ошибка 1: Забывать про нефункциональные требования вообще

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

Ошибка 2: Формулировать размыто

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

Ошибка 3: Не проверять реалистичность

Написать “время загрузки 0,5 секунды при 10 000 пользователей одновременно” для стартапа с бюджетом 100 тысяч рублей – нереалистично. Требования должны соответствовать возможностям.

Ошибка 4: Путать функциональные и нефункциональные

“Система должна шифровать пароли” – это функциональное или нефункциональное? Строго говоря, это функциональное (конкретное действие системы). Но часто такие требования, связанные с качеством, относят к нефункциональным. Главное – не в категориях запутаться, а не забыть их описать вообще.

Ошибка 5: Не согласовывать с командой

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

Резюме для системного аналитика

1. Нефункциональные требования - про качество. Они отвечают на вопрос “КАК?” и “НАСКОЛЬКО ХОРОШО?” работает система.

2. Их легко забыть, но без них система провалится. Функции есть, но пользователи недовольны - скорее всего, забыли про нефункциональные требования.

3. Главное правило – измеримость. Любое нефункциональное требование должно быть проверяемо. Иначе это не требование, а пожелание.

4. Категории: производительность, надежность, безопасность, масштабируемость, удобство, совместимость, сопровождаемость – проверяйте себя по этим пунктам.

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