NFR в 1С: что это и как применять нефункциональные требования

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

Функциональное требование звучит как «система должна формировать отчёт по продажам за период». Нефункциональное уточняет: «отчёт должен формироваться не дольше 30 секунд при 200 одновременно работающих пользователях на базе объёмом 500 ГБ». Без второй части приёмка проекта превращается в спор: разработчик считает задачу выполненной, заказчик — нет.

Для 1С тема особенно актуальна, потому что платформа имеет свои особенности производительности: блокировки при проведении документов, регламентные задания, влияние СУБД (PostgreSQL, MS SQL), режим совместимости, толстый и тонкий клиент. NFR помогают зафиксировать ожидания до начала разработки и проверить их после.

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

Функциональные требования (FR) описывают поведение системы: какие документы создаются, какие проводки формируются, какие права у роли «Кассир». Их проверяют сценарным тестированием: выполнили операцию — получили ожидаемый результат.

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

Практический признак: если требование можно проверить только измерением (секундомером, счётчиком, нагрузочным тестом), а не простым «работает / не работает», — это NFR.

Основные виды NFR в проектах 1С

В проектах внедрения и доработки конфигураций 1С чаще всего выделяют следующие группы нефункциональных требований.

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

Самая конфликтная группа. Типичные формулировки: документ «Реализация товаров» проводится не дольше 3 секунд; открытие списка документов — не дольше 2 секунд; регламентное закрытие месяца укладывается в ночное окно с 22:00 до 6:00. Без конкретных цифр требование «система должна работать быстро» непроверяемо.

Надёжность и доступность

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

Безопасность

Требования к ролевой модели, ограничению доступа на уровне записей (RLS), протоколированию действий пользователей, защите персональных данных. Например: «менеджер видит только документы своей организации» — это NFR, реализуемое через RLS.

Сопровождаемость и переносимость

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

Как правильно формулировать NFR

Главное правило — измеримость. Каждое требование должно содержать метрику, целевое значение и условия измерения. Формула: при нагрузке X операция Y выполняется за время Z.

Хорошая формулировка выглядит так: «При 150 одновременно работающих пользователях и объёме таблицы регистра накопления "Продажи" до 50 млн записей проведение документа "Реализация" занимает не более 3 секунд в 95% случаев». Здесь есть нагрузка, объём данных, операция и критерий приёмки.

Условия измерения фиксируйте отдельно: конфигурация сервера 1С и СУБД, тип клиента (тонкий/веб), канал связи для филиалов. Иначе заказчик замерит на ноутбуке по Wi-Fi, а разработчик — на сервере, и результаты не сойдутся.

Как проверять выполнение NFR

Функциональные требования проверяются сценариями, а NFR — измерениями. Для 1С основной инструмент — нагрузочное тестирование: эмуляция работы десятков или сотен пользователей с типовыми операциями.

1. 1
   Сформируйте тестовую базу с объёмом данных, близким к боевому (копия рабочей базы или сгенерированные данные)
2. 2
   Составьте перечень ключевых операций: проведение документов, отчёты, обмены, регламентные задания
3. 3
   Определите целевые показатели из согласованных NFR
4. 4
   Выполните нагрузочный тест с эмуляцией целевого числа пользователей
5. 5
   Снимите замеры: время операций, блокировки, нагрузку на СУБД (можно через ЦУП или технологический журнал)
6. 6
   Сравните результаты с критериями и зафиксируйте протокол приёмки

Для диагностики узких мест используют технологический журнал платформы, замеры производительности в конфигураторе, анализ планов запросов на стороне СУБД. Частые причины нарушения NFR в 1С: запросы в цикле, отсутствие индексов по измерениям регистров, избыточные блокировки при проведении, неоптимальные запросы с соединениями виртуальных таблиц.

Контрольные точки

Как проверить результат

Время проведения документа

Норма

Укладывается в целевое значение при целевой нагрузке

Тревожный признак

Норма только на пустой базе или у одного пользователя

Параллельная работа

Норма

Нет взаимных блокировок и таймаутов при одновременном проведении

Тревожный признак

Ошибки «Конфликт блокировок» при росте числа пользователей

Регламентные задания

Норма

Завершаются в отведённое окно, не мешают пользователям

Тревожный признак

Закрытие месяца или обмен пересекаются с рабочим временем

Где фиксировать NFR и кто за них отвечает

NFR включают в техническое задание или отдельный документ «Нефункциональные требования», который подписывают обе стороны до старта разработки. В agile-проектах их добавляют в Definition of Done: задача не считается выполненной, пока не пройдены проверки производительности и соответствия стандартам.

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

Типичные ошибки и ограничения

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

Вторая — копировать требования из чужих проектов без привязки к своей инфраструктуре и объёмам. Требование «отчёт за 5 секунд» для базы в 10 ГБ и для базы в 2 ТБ — это разные задачи.

Третья — требовать невозможного от платформы. У 1С есть объективные ограничения: механизм блокировок, особенности работы с регистрами, накладные расходы клиент-серверной архитектуры. Нереалистичные NFR приводят либо к бесконечным доработкам, либо к формальной приёмке с нарушениями.

FAQ

Чем NFR отличается от SLA?

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

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

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

Можно ли проверить NFR без нагрузочного тестирования?

Частично. Требования к правам, RLS и обновляемости проверяются сценарно. Но производительность и масштабируемость без эмуляции целевой нагрузки достоверно не проверить — поведение одного пользователя не предсказывает работу сотни.

Что делать, если система не проходит по NFR после разработки?

Сначала локализуйте причину: технологический журнал, замеры, анализ запросов. Часто проблема решается оптимизацией запросов и индексов без переписывания логики. Если узкое место в инфраструктуре — пересматривайте либо оборудование, либо (по согласованию с заказчиком) сами требования.

Нужны ли NFR для небольшой базы на 10 пользователей?

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