В требованиях к 1С‑проектам постоянно мелькают аббревиатуры UR, FR, NFR. Для новичка это выглядит как «магия для галочки», хотя на деле это очень удобный способ навести порядок в хотелках, функциях и ограничениях системы.
Разберём по‑простому:
·        UR — чего хочет пользователь/бизнес.
·        FR — что конкретно должна делать система.
·        NFR — насколько хорошо всё это должно работать (скорость, надёжность и т.п.).

UR: User Requirements — пользовательские требования
Это желания и потребности пользователя, сформулированные его языком, без техподробностей.
Отвечают на вопрос: «Что пользователь хочет уметь делать/получать?»
Примеры:
·        «Закупщик должен видеть статус договора без звонков коллегам».
·        «Менеджер по продажам должен видеть просроченные счета в одном списке».
Для UR важно:
·        речь идёт о боли и потребности, а не о форме и кнопках;
·        нет слов типа «таблица 1С», «регистр», «HTTP‑запрос» — только бизнес‑язык;
·        обычно собираются через интервью, анкеты, воркшопы.
Проверяет UR бизнес:
«Это реально решает боль пользователя или просто красиво звучит?»

FR: Functional Requirements — функциональные требования
Это уже описание поведения системы: что конкретно будет делать 1С, какие функции выполнять.
Отвечают на вопрос: «Как система будет реализовывать это желание?»
Формат:
«Система должна…» + действие + условие.
Примеры для 1С:ERP:
·        «Система должна автоматически менять статус договора на “Согласован” при получении утверждения от директора и отправлять уведомление закупщику по email».
·        «Система должна формировать отчёт “Просроченные поставки” за выбранный период с фильтром по поставщикам и статусам».
Особенности FR:
·        описывают HOW — как именно будет реализовано пользовательское требование;
·        лежат в основе ТЗ, use cases, прототипов экранов;
·        по ним пишут задачи разработчикам и тестировщикам.
Проверяет FR разработчик:
«Функция работает так, как описано? Все условия учтены?»

NFR: Non‑Functional Requirements — нефункциональные требования
Это требования к качеству работы системы, а не к её логике.
Отвечают на вопрос: «Насколько быстро, надёжно, безопасно это должно работать?»
Примеры:
·        «Уведомление должно отправляться за ≤2 секунд при нагрузке до 50 одновременных пользователей».
·        «Отчёт “Просроченные поставки” формируется не дольше 5 секунд при объёме данных до 1 млн строк».
·        «Доступ к разделу “Закупки” только у ролей “Закупщик” и “Директор”, все действия логируются».
Особенности NFR:
·        описывают HOW WELL — насколько хорошо система выполняет функции;
·        часто относятся к производительности, безопасности, масштабируемости, удобству интерфейса;
·        базируются на техспеках, SLA, результатах нагрузочных тестов.
Проверяет NFR QA/архитектор:
«Укладываемся ли мы в нужные секунды/пользователей/ограничения?»

Сводная таблица: UR vs FR vs NFR на примере 1С:ERP


Как это связано с бизнес‑целями: небольшая иерархия
Пример:
Бизнес‑цель:
«Сократить время цикла закупки на 30%».
Дальше:
·        UR‑001: «Закупщик видит статус договора без звонков коллегам».
o   FR‑Закупки‑001: «Система автоматически меняет статус договора и отправляет email ответственному при согласовании».
o   NFR‑Perf‑001: «Уведомление отправляется за ≤2 секунд при 50 одновременных пользователях».
·        UR‑002: «Закупщик может быстро сравнивать цены разных поставщиков».
o   FR‑Закупки‑002: «Система строит таблицу сравнения цен по номенклатуре и поставщикам».
o   NFR‑Usability‑001: «Таблица корректно отображается на ноутбуке и планшете (responsive‑верстка)».
Так появляется цепочка:
·        бизнес‑цель → UR → FR → NFR → задачи в 1С.

Как использовать UR/FR/NFR в реестре требований
Реестр требований — это таблица, где каждый пункт имеет:
·        ID;
·        тип (UR / FR / NFR);
·        статус;
·        критерий приёмки.
Пример:

Зачем это аналитику:
·        видно, какая хотелка уже разобрана и во что она превратилась в системе;
·        можно отследить, нет ли FR/NFR, за которыми не стоит реальная пользовательская потребность (UR);
·        удобно строить traceability от идеи до кода и тестов.

Зачем вообще заморачиваться с UR/FR/NFR
Если всё писать «в одну кучу», возникают типичные проблемы:
·        бизнес не понимает ТЗ, потому что всё написано техническим языком;
·        разработчики получают размытые формулировки «должно работать быстро»;
·        QA не знает, как проверять: «быстро — это сколько?».
Разделение на UR / FR / NFR даёт:
·        бизнесу — язык потребностей;
·        разработчикам — язык функционала;
·        тестировщикам и архитекторам — язык качества и ограничений.
Для аналитика это удобный «скелет»:
·        сначала фиксируем UR (что болит и чего хотят люди);
·        потом делаем из них FR (что должна делать 1С);
·        и дополняем NFR (как хорошо это должно работать).
В итоге требования перестают быть «списком хотелок» и превращаются в управляемый набор: от бизнес‑идеи до кода и метрик.