Что такое NFR в 1С и как работать с нефункциональными требованиями

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

На практике NFR чаще всего вспоминают, когда что-то пошло не так: база «тормозит», обмен данными отваливается по ночам, пользователи жалуются на зависания, а подрядчик отвечает, что «в ТЗ этого не было». Именно поэтому грамотно сформулированные нефункциональные требования — обязательная часть технического задания на внедрение, доработку или оптимизацию 1С.

Термин пришёл из классической инженерии ПО и стандартов качества (например, семейства ISO/IEC 25010), но в контексте 1С имеет свою специфику: здесь важны производительность механизмов платформы, объёмы регистров, нагрузка на СУБД, особенности клиент-серверной архитектуры и регламентные операции.

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

Функциональные требования (FR) описывают поведение системы: какие документы создаются, какие проводки формируются, какие кнопки есть в интерфейсе, какие отчёты доступны. Это ответ на вопрос «что делает система». Нефункциональные требования описывают качества и ограничения: скорость, отказоустойчивость, защищённость, удобство, требования к окружению.

Простой пример из практики 1С. Функциональное требование: «При проведении документа "Реализация товаров" должны списываться остатки по регистру партий по методу FIFO». Нефункциональное требование к той же операции: «Проведение документа с 500 строками не должно занимать более 5 секунд при штатной нагрузке». Первая формулировка проверяется тестом «работает / не работает», вторая — замером на конкретном стенде.

Ключевое отличие в способе проверки. Функциональность тестируется сценариями, а NFR — измерениями, нагрузочными испытаниями, аудитом кода и конфигурации. Если требование нельзя измерить, это плохое NFR: формулировка «система должна работать быстро» бесполезна, потому что у заказчика и исполнителя будут разные представления о «быстро».

Основные категории NFR для систем на платформе 1С

Набор категорий зависит от проекта, но для типовых внедрений 1С:ERP, 1С:УТ, 1С:ЗУП или 1С:Бухгалтерии обычно выделяют несколько групп требований.

• Производительность — время выполнения операций, формирования отчётов, проведения документов, скорость обменов. Самая частая и самая «болезненная» категория.
• Масштабируемость — способность системы сохранять показатели при росте числа пользователей, объёма данных, количества филиалов.
• Надёжность и доступность — допустимое время простоя, требования к резервному копированию, поведение при сбоях, восстановление после отказа.
• Безопасность — разграничение прав (RLS), защита данных, аудит действий, требования к парольной политике и шифрованию соединений.
• Удобство использования — количество действий для типовых операций, требования к интерфейсу, обучаемость пользователей.
• Сопровождаемость — возможность обновления конфигурации, требования к стандартам разработки, документированию доработок.
• Совместимость — версии платформы, СУБД, операционных систем, браузеров для веб-клиента, интеграционных протоколов.

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

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

Главное правило: каждое NFR должно быть измеримым и проверяемым. Хорошая формулировка содержит объект измерения, целевое значение и условия, при которых требование проверяется.

Полезно формулировать NFR вместе с методом проверки: «замер выполняется на тестовом стенде, аналогичном продуктивному, с помощью типовой обработки оценки производительности или штатных средств СУБД». Это снимает споры на этапе приёмки: обе стороны заранее знают, как и где будет доказываться выполнение требования.

Ещё одно практическое правило — фиксировать граничные условия. Требование «отчёт формируется за 30 секунд» без указания объёма данных и числа пользователей бессмысленно: на пустой базе оно выполнится всегда, а на реальной — неизвестно.

Где фиксировать NFR в проекте внедрения 1С

Нефункциональные требования собираются на этапе обследования, вместе с функциональными. Источники — интервью с пользователями и ИТ-службой, анализ текущей инфраструктуры, данные о планируемом росте компании. Типичные вопросы на этом этапе: сколько пользователей будет работать одновременно, какой объём документов вводится в день, какие обмены и как часто выполняются, какое время простоя допустимо.

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

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

1. 1
   Соберите исходные данные: число пользователей, объёмы документов, перечень обменов, допустимое время простоя
2. 2
   Сформулируйте требования измеримо: объект, целевое значение, условия проверки
3. 3
   Согласуйте с подрядчиком метод проверки каждого требования и зафиксируйте в ТЗ
4. 4
   Перед приёмкой подготовьте тестовый стенд с объёмом данных, близким к продуктивному
5. 5
   Проведите замеры и зафиксируйте результаты в протоколе испытаний

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

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

Нагрузочное тестирование — отдельная задача. Для имитации работы десятков и сотен пользователей применяют специализированные средства нагрузочного тестирования, сценарии которых воспроизводят типовые операции: ввод документов, проведение, формирование отчётов. По результатам строят картину: как растёт время отклика с ростом числа сессий и где находится «узкое место» — сервер 1С, СУБД, сеть или дисковая подсистема.

Требования к надёжности проверяются иначе: тестовым отключением сервисов, восстановлением из резервной копии с замером времени, проверкой поведения обменов при обрыве связи. Требования к безопасности — аудитом настроек прав, проверкой RLS на тестовых пользователях, анализом журнала регистрации.

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

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

Время формирования ключевых отчётов

Норма

В пределах значения из ТЗ на реальном объёме данных

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

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

Работа под нагрузкой

Норма

Время отклика стабильно при росте числа сессий до целевого

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

Резкая деградация, блокировки, ошибки при половине целевой нагрузки

Резервное копирование и восстановление

Норма

Копия создаётся по расписанию, восстановление проверено и укладывается в допустимое время

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

Копии есть, но восстановление никогда не проверялось

Разграничение прав

Норма

Тестовый пользователь видит только разрешённые данные

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

RLS настроен формально, доступны лишние документы или отчёты

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

Самая распространённая ошибка — полное отсутствие NFR в ТЗ. Заказчик получает работающую функционально систему, которая не справляется с реальной нагрузкой, а предъявить претензии не может: требований к скорости и ёмкости не было зафиксировано. Вторая ошибка — неизмеримые формулировки вроде «быстро», «удобно», «стабильно», которые каждая сторона трактует по-своему.

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

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

Инструменты и документы, которые помогают управлять NFR

Для сбора и фиксации требований достаточно структурированного документа: таблица с категорией, формулировкой, целевым значением, методом проверки и приоритетом. На крупных проектах требования ведут в системах управления требованиями или хотя бы в задачах трекера, чтобы каждое NFR имело статус: согласовано, реализовано, проверено.

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

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

Частые вопросы о NFR в 1С

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

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

Сколько NFR должно быть в типовом ТЗ?

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

Можно ли предъявить претензии по производительности, если NFR не было в договоре?

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

Нужно ли нагрузочное тестирование для небольшой базы на 10–15 пользователей?

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

Что делать, если система не соответствует согласованным NFR после внедрения?

Зафиксируйте отклонения протоколом замеров, выполненных согласованным методом. Дальше типовой путь — анализ причин (код, индексы, настройки СУБД, инфраструктура), план оптимизации и повторная проверка. Если причина в доработках подрядчика, устранение обычно входит в его обязательства по договору.

Относятся ли требования к версии платформы и СУБД к NFR?

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