Non-functional requirements: что это и зачем они нужны
Почему без нефункциональных требований практически невозможно создать удобный и надежный продукт
Можно досконально прописать все пользовательские сценарии и выпустить продукт, который выполняет все нужные задачи. Но если он медленный, падает при нагрузке или выглядит слишком сложным, пользователи просто уйдут. И дело может быть в упущенных нефункциональных требованиях — тех, что определяют поведение системы в реальных условиях.
В этой статье разберем, что именно входит в нефункциональные требования, почему они критичны для любого цифрового продукта и как грамотно их формулировать, чтобы не переписывать половину системы после запуска.
Что такое нефункциональные требования
Термин «нефункциональные требования» (Non-functional requirements, НФТ) часто используют в связке с функциональными требованиями, поэтому проще объяснить через сравнение:
- Функциональные требования — описывают, что должна делать система: например, регистрация пользователя, оформление заказа или отправка уведомлений.
- Нефункциональные требования — это правила, ограничения и характеристики, которые описывают, как должна работать система.
Главное отличие в том, нефункциональные требования не изменяют суть функциональности системы. То есть, если создать систему без учета НФТ, она будет выполнять свою задачу. Вопрос в том, насколько качественно она будет это делать.
Рассмотрим различия на примере банковского приложения. Вот списки требований к нему:
Какой вывод можно сделать. Основные задачи приложения — дать пользователям возможность переводить деньги и получать доступ к своему счету и аккаунту. Смогут ли пользователи выполнять эти задачи, если в приложении не учли нефункциональные требования? Да. Даст ли приложение позитивный пользовательский опыт? Не факт.
Допустим, если перевод денег будет обрабатываться не 2 секунды, а 10 минут, то это слишком долго. Из-за этого пользователи могут перейти в другое приложение, которое быстрее сделает то же самое.
По этой причине нефункциональные требования важны. Если не уделить им внимание до разработки, итоговый продукт вряд ли будет востребованным.
Что входит в нефункциональные требования
Детально нефункциональные требования к системе описал программист Карл Вигерс в книге «Разработка требований к программному обеспечению». Ниже — схематичное представление того, как нужно работать с требованиями:
Все овалы справа относятся к нефункциональным требованиям. Исключение — бизнес-правила. Они могут лечь в основу НФТ, но их рассматривают как отдельную сущность. Получается, что НФТ можно разделить на 3 группы:
Атрибуты или параметры качества. Это характеристики, которые определяют, насколько удобно, эффективно и надежно работает система. Какие требования можно отнести к этой группе:
- Производительность — насколько быстро система выполняет операции.
- Надежность — гарантия того, что система будет работать без сбоев.
- Масштабируемость — возможность системы справляться с увеличением нагрузки (пользователей, данных и т. д.) без потери качества.
- Безопасность — защита данных от несанкционированного доступа. Например, авторизация, шифрование, аудит.
- Доступность — сколько времени система доступна для пользователей. Пример: 99.9% времени в месяц.
- Удобство сопровождения — насколько легко поддерживать, обновлять и изменять систему.
- Переносимость — насколько просто развернуть систему в другой среде: на другом сервере, в другой ОС и т. д.
- Удобство установки — насколько легко и быстро можно приступить к работе с системой.
- Локализация — это касается как языка системы, так и более узких моментов: например, формата отображения времени и валюты.
Внешние интерфейсы. Эти требования описывают взаимодействие системы с объектами, которые находятся вне ее «ядра»: другими программами, устройствами и людьми.
- Программные интерфейсы (API) — каким образом ваша система будет «разговаривать» с другими приложениями — какие методы доступны, какие форматы данных используются.
- Интерфейс с пользователем (UI/UX) — какие кнопки, формы, окна будут доступны пользователю. В каком виде будет отображаться информация.
- Аппаратные интерфейсы — с какими физическими устройствами работает система: принтеры, камеры, датчики, POS-терминалы и т. п.
Ограничения. Это жесткие условия или рамки, в рамках которых нужно реализовать проект. Они ограничивают свободу выбора при разработке и архитектуре системы.
- Технологические ограничения — например, использовать только Python или только PostgreSQL, потому что это уже используется в компании.
- Платформенные ограничения — система должна работать только на Windows, или только в браузере, или только на мобильных устройствах.
- Стандарты и регламенты — необходимо соответствовать стандартам безопасности (например, GDPR, ISO 27001) или отраслевым нормам (например, ГОСТ для России).
Финансовые или временные ограничения — разработка должна уложиться в определенный бюджет или быть завершена до определенной даты.
Иногда нефункциональные требования могут быть функциональными и наоборот
Список требований и их классификация зависят от конкретного проекта. Одно и то же поведение системы в разных контекстах может быть как функциональным, так и нефункциональным требованием.
Для сравнения возьмем одно и то же требование — наличие журнала действий. Посмотрим, как меняется его роль в зависимости от проекта.
Получается, что ключевой фактор — это контекст использования, который зависит от целей аудитории. Если пользователь напрямую взаимодействует с функцией в своей ежедневной работе — это функциональное требование. Если функция работает в фоне и нужна для стабильности или безопасности системы — это нефункциональное требование.
Пример нефункциональных требований и их влияние на итоговый продукт
Возьмем корпоративную CRM-систему для отдела продаж. Ее функциональные требования — хранить данные о клиентах, показывать воронку продаж, напоминать менеджерам о задачах и давать руководителю отчеты. Чтобы система реально приносила пользу, ее нужно окружить нефункциональными требованиями.
На примере нескольких НФТ посмотрим, что может произойти, если этого не сделать:
Скорость работы. Система должна открывать карточку клиента не дольше чем за секунду. Если менеджер кликает и ждет, он теряет фокус и мотивацию, начинает вести базу в Excel. Вся автоматизация рушится, отдел работает вразнобой.
Безопасность. В CRM хранятся контакты, сделки, коммерческие предложения. Если сотрудник уволился, его аккаунт должен блокироваться автоматически. А права доступа должны быть настроены так, чтобы обычный менеджер видел только свои сделки, а руководитель — весь отдел. Если эти не соблюсти эти требования, то легко нарушить конфиденциальность. В итоге возникает риск утечки, а руководство теряет доверие к системе
Отказоустойчивость. Это способность системы работать даже при сбоях. Требованием для этого критерия может быть доступность 99,95% в рабочие часы. Если его не учесть, то при сбоях отдел продаж может встать: CRM не открывается, сотрудники не могут напомнить клиентам о встречах, а сделки срываются.
Удобство. Если CRM не открывается с телефона или интерфейс перегружен, менеджеры начинают вести задачи в мессенджере или блокноте. Поэтому интерфейс должен быть адаптивным, а в карточке клиента не должно быть лишнего, чтобы нужные поля были на виду.
Поддерживаемость. Это про то, насколько легко вносить изменения в систему. Например, нужно подключить телефонию, но внезапно выясняется, что для этого придется переписать половину кода. Каждое улучшение превращается в проект на месяц, а команда боится трогать работающие модули.
Как составлять нефункциональные требования
Даже у крупных игроков и систем, которыми пользуются десятки тысяч пользователей, бывают проблемы с перегрузкой, ошибки на сайте, подвисания и подобные проблемы.
1. Составьте обширный список нефункциональных требований. Постарайтесь включить в него максимум условий, при которых система будет работать так, как требуется.
2. Подумайте, от чего можно отказаться. Некоторые нефункциональные требования можно отложить без ущерба для основной ценности продукта или полностью исключить из проекта. Это позволит ускорить работу, сократить нагрузку на команду и сосредоточиться на критичных аспектах.
Например, для сервиса доставки еды может быть не так критичная адаптация под планшеты. Если приложение планируют развивать в дальнейшем, то от адаптации можно пока отказаться.
3. Расставьте приоритеты. Один из способов — попарное сравнение. Смысл в том, что берут два атрибута и спрашивают: «Если бы пришлось выбрать только один из этих двух — какой важнее для нашей конкретной системы?» Такой подход особенно хорошо работает, если список характеристик небольшой.
Для наглядного сравнения атрибутов используют таблицу, где строки и столбцы — это те же характеристики. В каждой ячейке отмечают, какой из двух атрибутов важнее: < — приоритет у строки, ^ — у столбца. А в отдельном столбце указывают общее количество очков, которое получил атрибут. Чем больше очков, тем выше приоритет.
Итоговая таблица будет выглядеть примерно так:
4. Соберите конкретные ожидания пользователей. Здесь потребуется бизнес-аналитик, UX-исследователь или другой сотрудник, который общается с конечными пользователями.
5. Пропишите точные требования. Они не должны быть абстрактными и субъективными. Вместо «интерфейс должен быть удобным» лучше указать «пользователь должен находить нужный раздел не более чем за 3 клика» или «время отклика не должно превышать 1 секунды при нагрузке до 500 одновременных сессий». Чем конкретнее формулировка — тем проще ее реализовать и проверить.
Что такое нефункциональные требования: кратко
→ Нефункциональные требования описывают условия работы системы: скорость, надежность, безопасность, масштабируемость, удобство и др. То есть они дают понимание, как должна работать система. Это отличает их от функциональных требований, которые описывают, что система должна делать.
→ Основные группы НФТ:
- Параметры качества (производительность, отказоустойчивость, удобство сопровождения и др.).
- Внешние интерфейсы (API, UI/UX, аппаратные).
- Ограничения (технологические, платформенные, стандарты, бюджеты/сроки).
→ Если не учитывать нефункциональные требования, то система может формально выполнять задачи, но вызывать раздражение у пользователей и терять их. Помимо этого у пользователей может упасть доверие к системе из-за рисков по типу утери данных.
→ При подготовке нефункциональных требований нужно составить их полный список, отсечь второстепенные, расставить приоритеты, учесть ожидания пользователей. В конце После этого запишите требования в конкретной и измеримой формулировке.
