Нефункциональные требования:
как не провалить цифровизацию,
следуя ГОСТу и здравому смыслу

Когда клиент формулирует задачу на автоматизацию, фокус почти всегда направлен на функциональность: система должна вести учет, формировать отчеты, отправлять уведомления. Это логично и понятно. Но именно здесь кроется главная ловушка. Реализовав все 100% заявленных «хотелок» по функционалу, можно получить продукт, который невозможно развернуть на инфраструктуре заказчика, который падает под нагрузкой первых же 50 пользователей или не проходит проверку службы информационной безопасности.

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

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

Самый дорогостоящий пример из практики — раздел, который разработчики и заказчики не любят больше всего: требования к защите информации (п. 3.8 по ГОСТ 34.602). В погоне за кнопками и отчетами вопросы ИБ часто откладываются на потом. Но когда система готова, выясняется, что ее архитектура не соответствует требованиям ФСТЭК, отсутствуют необходимые программно-аппаратные средства защиты, а сертификация комплекса займет полгода.

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

Другой классический провал — показатели назначения (п. 3.2). Представьте: в компании работает 10 000 сотрудников. Систему делают с запасом на 12 000 пользователей. Но в ТЗ забыли уточнить количество активных (одновременно работающих) пользователей. Здравый смысл подсказывает, что все 12 тысяч не зайдут в систему одновременно. Но здравый смысл не является техническим заданием. В результате проект получает архитектуру, не рассчитанную на конкурентную нагрузку, или серверные мощности, которые «падают» в первый же час пиковой нагрузки. Дозаказ оборудования — это месяцы закупочных процедур, сдвиг сроков сдачи и штрафы.

ГОСТ 34.602 «Техническое задание на создание автоматизированной системы» — это не набор абстрактных требований к оформлению, а готовый чек-лист, который не дает упустить ничего важного.

Стандарт предписывает обязательные разделы. Функциональным требованиям там посвящен лишь один подраздел. Все остальное — структура системы, виды обеспечения (программное, техническое, лингвистическое), общие технические требования — это и есть те самые НФТ, которые защитят вас на приемке.

Важное примечание в ГОСТе гласит: если требования по разделу отсутствуют, раздел сохраняется с записью «Требования не предъявляются». Это не пустая формальность, а юридически значимое действие. Оно фиксирует, что вы осознанно прошли этот пункт, и у клиента не возникнет соблазна придумать новые вводные на этапе приемки.

Работа с нефункциональными требованиями строится по тем же правилам, что и с функциональными: выявление, анализ, документирование, утверждение, управление изменениями. Но здесь есть нюанс: функциональный заказчик (представитель бизнеса) часто не знает, как ответить на вопросы о нагрузке, архитектуре решения или требованиях ИБ.

Ключевое правило: не пытайтесь получить все ответы от одного человека. Нужно подключать руководителей смежных подразделений — службы эксплуатации, ИБ, архитектурного комитета. Ответы должны давать ответственные лица, а не просто заинтересованные сотрудники. Если вы получили ТЗ, которое вызывает больше вопросов, чем дает ответов, у вас есть два пути:

1. Уточнять. Используя структуру ГОСТа как анкету, провести интервью с профильными специалистами клиента. Каждое уточнение фиксировать в протоколах или отдельном документе.
2. Закладывать риски. Если возможности уточнить нет, оценка проекта должна содержать четкие допущения и оговорки. Например: «Оценка произведена исходя из предположения, что архитектура предполагает x86-процессоры. При выявлении требований к архитектуре процессора стоимость и сроки будут пересмотрены».

Чтобы избежать споров в день сдачи, принцип должен быть один: чем больше покрытие требований, тем меньше пространства для споров. Универсального списка нет — каждый проект индивидуален. Но если использовать логику ГОСТ 34.602, то структура качественного ТЗ для любого корпоративного проекта будет включать обязательную проработку следующих блоков:

1. Защита информации (ИБ). Есть ли требования к средствам криптозащиты, учету ФСТЭК, разграничению доступа на уровне аппаратного обеспечения?
2. Нагрузка и производительность. Количество активных пользователей, время отклика критических операций (особенно «тяжелых» отчетов), объем обрабатываемых данных (например, количество банковских выписок в час).
3. Интеграция и совместимость. Требования к интероперабельности со смежными системами, архитектура (монолит/микросервисы), операционная система на стороне заказчика (Windows, Linux, macOs) и тип процессоров (x86, ARM).
4. Надежность и отказоустойчивость. Время восстановления после сбоя, требования к резервному копированию, сохранность данных при авариях.
5. Эргономика и эстетика. Формально это мягкие требования, но если их не прописать, приемка превратится в обсуждение того, какого оттенка должен быть серый цвет кнопки.

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

• Избежать лишних споров и возврата на завершенные этапы разработки;
• Не срывать сроки из-за внезапных закупочных процедур для «железа», которое забыли учесть;
• Удержать бюджет без штрафов и необходимости «заливать проект железом» в попытке исправить архитектурные просчеты;
• Сохранить профессиональную репутацию и нервы команды.

ГОСТ 34.602 — это не обязательное требование (если только оно не прописано в контракте), но это консолидированный опыт поколений профессионалов. Если мы привыкли доверять продуктам со знаком соответствия стандарту, почему бы не ставить такой же «знак качества» на техническое задание? Внедрение системы — это всегда изменение. Но контролируемое изменение начинается с качественного ТЗ, где прописано всё: и что мы делаем, и как это будет работать.