Содержание:
Что такое функциональные и нефункциональные требования?
Ключевые отличия типов требований
Иерархия функциональных требований
Иерархия нефункциональных требований
Когда и как составлять требования?
Что такое функциональные и нефункциональные требования
Требования к программному обеспечению — это формализованное описание того, каким должен быть продукт: что он умеет, как себя ведет и при каких условиях работает корректно. Весь этот массив принято делить на два принципиально разных класса.
Функциональные требования к программному обеспечению описывают конкретное поведение системы: что она делает в ответ на действие пользователя или внешнего события. «Пользователь нажимает кнопку — система отправляет письмо», «при вводе некорректного пароля система блокирует аккаунт после трех попыток» — это все функциональность. Они отвечают на вопрос «что?».
Нефункциональные требования к программному обеспечению — это ограничения и качественные характеристики, которые определяют, насколько хорошо система выполняет свои функции. Они отвечают на вопрос «как?»: как быстро, как надежно, как безопасно, насколько легко поддерживать. Если функциональные требования описывают поведение, то нефункциональные — качество этого поведения.
Классический пример: интернет-магазин. Функциональное требование — «покупатель может добавить товар в корзину и оформить заказ». Нефункциональное — «страница каталога загружается не более чем за 2 секунды при нагрузке в 10 000 одновременных пользователей».
Оба класса одинаково важны. Система, которая делает все что нужно, но делает это медленно, нестабильно или небезопасно — плохая система. И наоборот: невероятно быстрое приложение, которое не решает задачи пользователя, тоже никому не нужно.
Функциональные требования: характеристики и критерии
Функциональные требования к системе описывают конкретные действия, которые система должна выполнять. Их ключевая особенность — измеримость: каждое требование либо выполнено, либо нет. Нет градаций, нет «почти». Это делает их относительно удобными для тестирования: написал тест-кейс, прогнал, получил однозначный результат.
Критерии функциональных требований, которым они должны соответствовать, чтобы быть рабочими:
- Конкретность
Требование должно описывать одно действие, а не целый процесс. «Система управляет пользователями» — это направление, не требование. «Администратор может заблокировать учетную запись через панель управления, после чего пользователь теряет доступ ко всем функциям сервиса» — уже рабочий вариант.
- Верифицируемость
Если требование нельзя проверить — оно бесполезно. «Система должна быть удобной» не пройдет ни одно приемочное тестирование. «Форма регистрации содержит не более 5 полей и заполняется менее чем за 3 минуты по результатам юзабилити-теста» — проходит.
- Отсутствие двусмысленности
Слова «быстро», «иногда», «соответствующий» — источники проблем. Каждый читает их по-своему. Числа и конкретные условия эту проблему снимают.
- Трассируемость
Каждое требование должно быть связано с бизнес-целью. Если никто в команде не может объяснить, зачем это нужно пользователю или бизнесу — требование под вопросом.
Виды функциональных требований к ПО принято делить по нескольким основаниям. По источнику: бизнес-требования (что нужно организации), пользовательские требования (что нужно конечному пользователю), системные требования (что должна делать система для выполнения двух предыдущих). По типу поведения: требования к функциям, к данным, к интерфейсам, к интеграциям, к безопасности и управлению доступом.
Примеры функциональных требований
Абстрактные определения хорошо работают в учебниках, но на практике важно понимать, как функциональные требования к разработке ПО выглядят в документации. Ниже — функциональные требования к ПО примеры из разных предметных областей с правильной степенью детализации.
Авторизация и управление доступом:
- Система должна поддерживать авторизацию через email и пароль, а также через OAuth 2.0 (Google, GitHub).
- При трех последовательных неудачных попытках входа учетная запись блокируется на 15 минут; пользователь получает уведомление на email.
- Администратор может назначать роли (viewer, editor, admin) и отзывать их в реальном времени без перезапуска сессий.
Обработка данных и транзакции:
- При оформлении заказа система резервирует товар на складе и удерживает резервацию в течение 30 минут до подтверждения оплаты.
- Если оплата не поступила в течение 30 минут, резервация снимается автоматически, товар возвращается в доступный остаток.
- Все транзакции должны быть атомарными: либо заказ создается полностью, либо не создается совсем.
Уведомления и коммуникации:
- Система отправляет push-уведомление в мобильное приложение в течение 60 секунд после смены статуса заказа.
- Пользователь может настроить типы уведомлений (email, push, SMS) и отключить любой из каналов в разделе настроек профиля.
Интеграции:
- Система должна принимать данные о новых заказах из CRM через REST API в формате JSON; ответ на запрос — не позднее 500 мс.
- При недоступности внешнего сервиса система переходит в режим очереди и повторяет попытку каждые 5 минут до восстановления соединения.
Заметна общая закономерность: функциональные требования программы всегда описывают конкретного актора — кто что делает и что система делает в ответ. Это помогает не упустить граничные случаи и лучше понять поток взаимодействий.
Нефункциональные требования: качественные аспекты ПО
Можно думать о них так: функциональные требования — это контракт на доставку, нефункциональные требования к ПО — условия, при которых доставка считается выполненной. Привезли, но через три недели — контракт формально закрыт, по факту нет. Они не описывают конкретные действия, но определяют, при каких условиях эти действия остаются приемлемыми. Пренебрежение ими на старте — одна из самых дорогостоящих ошибок: архитектурные решения, которые не учитывают требования к производительности или безопасности, потом переделываются с огромными затратами.
Основные категории нефункциональных требований:
- Производительность
Время отклика, пропускная способность, утилизация ресурсов. Пример: «95-й перцентиль времени ответа API при нагрузке 500 RPS — не более 200 мс».
- Надежность и доступность
SLA, допустимый процент ошибок, время восстановления после сбоя (RTO) и допустимые потери данных (RPO). Пример: «Доступность сервиса — 99,9% в месяц; плановые технические работы — не более 4 часов в квартал в период минимальной активности».
- Безопасность
Шифрование данных в покое и в транзите, требования к аутентификации, аудит-логирование, соответствие регуляторным стандартам (GDPR, PCI DSS). Это не «прикрутить SSL», а системная модель угроз и защита от конкретных векторов атак.
- Масштабируемость
Как система ведет себя при росте нагрузки. Горизонтальное или вертикальное масштабирование. Пример: «Система должна выдерживать 10-кратный рост нагрузки в течение 15 минут без деградации производительности».
- Сопровождаемость
Покрытие кода тестами, стандарты документирования, требования к логированию. Это напрямую влияет на стоимость владения системой.
- Портируемость и совместимость
Поддерживаемые операционные системы, браузеры, версии мобильных платформ, требования к интеграционным стандартам.
- Usability
Требования к интерфейсу, доступности (WCAG), локализации. «Интерфейс должен поддерживать русский и английский языки; переключение доступно из любого экрана без перезагрузки» — рабочий пример.
Важно понимать: нефункциональные требования нередко вступают в противоречие друг с другом. Максимальная безопасность может ухудшать производительность. Высокая доступность требует затрат на инфраструктуру. Задача системного аналитика — зафиксировать эти компромиссы явно, а не оставлять их на усмотрение разработчиков в процессе реализации.
Ключевые отличия типов требований в системном анализе
Функционально технические требования и нефункциональные — разные инструменты для разных вопросов. Понимание различий помогает правильно их распределять, документировать и использовать в работе команды.
Принципиальное различие — в последней строке. Добавить новую кнопку в интерфейс или новое поле в форму — это изменение функционального требования, которое обычно не затрагивает всю систему. Но если на этапе MVP забыли зафиксировать требование к шифрованию данных или к горизонтальному масштабированию, ретрофитинг этого в рабочую систему может стоить как второй проект.
Еще одно практическое отличие — в том, кто является «владельцем» требования. Функциональные требования, как правило, формулирует бизнес совместно с аналитиком и валидирует с пользователями. Нефункциональные зачастую приходят со стороны технической команды или из регуляторных требований отрасли — их нельзя просто «придумать», не понимая архитектуры и контекста эксплуатации.
Иерархия функциональных требований
Функциональные и технические требования к ПО выстраиваются в несколько уровней, каждый из которых отвечает на свой вопрос и адресован своей аудитории.
Уровень 1: Бизнес-требования
Самый верхний уровень. Отвечают на вопрос «зачем?» — какую бизнес-проблему решает система или какую возможность открывает. Формулируются на языке бизнеса, без технических деталей. Пример: «Сократить время обработки заявки клиента с 48 до 4 часов за счет автоматизации первичной проверки».
Уровень 2: Пользовательские требования
Описывают, что конкретные группы пользователей должны уметь делать с системой. Часто оформляются как пользовательские истории или сценарии использования. Пример: «Менеджер по продажам может создать новую заявку, заполнив форму из 7 полей, и отследить ее статус в личном кабинете».
Уровень 3: Системные функциональные требования
Технический уровень: что именно должна делать система для выполнения пользовательских требований. Здесь появляются конкретные условия, исключения, граничные случаи. Пример: «Система проверяет ИНН контрагента через API ФНС в течение 10 секунд после создания заявки; при недоступности API — ставит заявку в очередь ручной проверки».
Уровень 4: Требования к компонентам
Самый детальный уровень: что должен делать конкретный модуль, микросервис или компонент. Используется командой разработки непосредственно перед реализацией.
Такая структура помогает поддерживать трассируемость: любое системное требование должно быть связано с пользовательским, а любое пользовательское — с бизнес-целью. Если цепочка рвется, это повод задать вопрос: зачем вообще это делать?
Иерархия нефункциональных требований
Нефункциональные требования тоже не плоские. У них есть своя структура, которая помогает не превращать документ требований в хаотичный список пожеланий.
Уровень 1: Качественные характеристики
Верхний уровень — общие характеристики качества системы, принятые в отрасли. Стандарт ISO/IEC 25010 выделяет восемь основных: функциональная пригодность, производительность, совместимость, удобство использования, надежность, безопасность, сопровождаемость, портируемость. Это не требования сами по себе, а категории, внутри которых требования формулируются.
Уровень 2: Архитектурно значимые требования
Подмножество нефункциональных требований, которые непосредственно влияют на архитектурные решения. Масштабируемость до 1 млн пользователей, требование к шардированию базы данных, запрет на хранение персональных данных за пределами РФ — все это архитектурные ограничения, которые нельзя игнорировать на стадии проектирования.
Уровень 3: Операционные требования
Требования к среде эксплуатации: конкретные параметры производительности, SLA, требования к мониторингу и алертингу, резервному копированию. Здесь уже числа и конкретные метрики, а не общие слова.
Уровень 4: Ограничения
Технически это тоже нефункциональные требования, но они не описывают желаемое качество — они задают жесткие рамки. «Система должна работать на существующей инфраструктуре AWS», «разработка только на Python», «бюджет на лицензии ПО — не более X в год». Constraints не обсуждаются командой — они принимаются как данность.
Правильная иерархия нефункциональных требований позволяет архитектору читать документ целенаправленно: сначала понять общие качественные цели, затем выделить архитектурно значимые ограничения и только потом детализировать операционные параметры. Архитектор не должен охотиться за ограничениями по всему документу — они должны лежать на виду. Иначе критичное требование по безопасности обнаруживается на код-ревью за день до релиза.
Когда и как составлять функциональные и нефункциональные требования
Функциональные требования к ПО и нефункциональные появляются в проекте не одновременно и не в одном и том же формате — это зависит от методологии, масштаба проекта и стадии его жизненного цикла.
Бизнес-требования фиксируются до старта проектирования — без понимания «зачем» невозможно правильно ответить на «что» и «как». Нефункциональные требования к производительности, безопасности и масштабируемости должны быть зафиксированы до выбора архитектуры: это ограничения, которые влияют на фундаментальные технические решения.
Пользовательские и системные функциональные требования уточняются итерационно — особенно в agile-проектах, где бэклог живет и меняется. Но даже при гибком подходе важно иметь «скелет» требований к началу каждого спринта или итерации.
Для функциональных требований наиболее распространены три формата:
- User Story
Короткая запись от лица пользователя: «Как [роль], я хочу [действие], чтобы [ценность]». Работает хорошо для agile-команд и удобна для приоритизации в бэклоге. Критерии приемки к каждой истории превращают ее из пожелания в проверяемое требование.
- Use Case
Сценарий взаимодействия актора с системой: основной поток, альтернативные потоки, исключения. Подходит для сложных бизнес-процессов с множеством ветвлений.
- Спецификация требований
Формальный документ по отраслевым стандартам. Используется в проектах с жесткими регуляторными требованиями или длинным циклом согласования.
Для нефункциональных требований критично добавлять измеримые параметры к каждому пункту. Не «система должна быть быстрой», а «время ответа на 95% запросов — не более 300 мс при нагрузке 1000 RPS». Именно так функциональные и нефункциональные требования к ПО становятся рабочим инструментом, а не декларацией о намерениях.
Частые ошибки, которые допускают при составлении требований:
- Смешение уровней
Бизнес-требование не должно содержать технических деталей реализации. Системное требование не должно говорить «потому что бизнес так хочет» без объяснения логики.
- Требования без владельца
Каждое требование должно иметь стейкхолдера, который его подтверждает и несет ответственность за приоритет.
- Нефункциональные требования «на потом»
«Мы разберемся с производительностью, когда система заработает» — этот подход регулярно приводит к дорогостоящим переработкам архитектуры или неприемлемому техническому долгу.
- Игнорирование противоречий
Если требование к безопасности конфликтует с требованием к производительности — это не повод убрать одно из них. Это повод задокументировать компромисс и принять осознанное решение.
Заключение
Хорошо написанные требования — скучный документ, который экономит месяцы. Плохо написанные — повод для ретроспективы с вопросом «а мы точно об этом договаривались?».
Хорошо составленные функциональные требования к системе отвечают на вопрос «что именно делает система» — без воды, без двусмысленностей, с конкретными условиями и граничными случаями. Нефункциональные задают рамку качества: при каких параметрах производительности, надежности и безопасности эта функциональность считается реализованной приемлемо.
Оба типа нужно фиксировать до начала проектирования, а не по ходу разработки. Чем позже выявляется пропущенное требование, тем дороже его исправление.
Стоимость исправления требования на этапе анализа — часы. На этапе разработки — дни. После релиза — недели и репутация.