Какие бывают требования в 1С‑проектах
и зачем их различать
Внедрение 1С всегда начинается с одного и того же вопроса: «А что именно нам нужно от системы?»
Ответ скрыт в требованиях.
Если не разделять типы требований, получается каша:
· «хотелки» пользователей превращаются в бесконечные доработки;
· разработчики не понимают, что критично, а что второстепенно;
· система в итоге «как‑то работает», но не решает бизнес‑задачи.
Поэтому важно различать три базовых типа:
· пользовательские требования;
· функциональные требования;
· нефункциональные требования.
Пользовательские требования: язык бизнеса
Что это такое
Пользовательские требования описывают, что хочет видеть и делать человек в системе, без техподробностей.
Это взгляд глазами роли: закупщика, кладовщика, менеджера, бухгалтера.
Как их узнать:
· интервью с пользователями;
· анкеты;
-совместные сессии/мозговые штурмы.
Как они звучат
· пишутся на языке предметной области (продажи, склад, закупки);
· отвечают на вопрос: «Что пользователь должен уметь сделать/получить?»;
· не содержат «как это реализовано в 1С».
Примеры для 1С:УТ 11:
· «Закупщик должен видеть статус согласования договора без звонков коллегам».
· «Кладовщик должен распечатать накладную по штрих‑коду за 10 секунд».
· «Менеджер должен контролировать оборачиваемость товара по каждому складу».
Для аналитика:
это сырьё. Из него дальше рождаются функциональные и нефункциональные требования.
Функциональные требования: как именно работает 1С
Что это такое
Функциональные требования описывают поведение системы:
· какие действия выполняет 1С;
· что делает с данными;
· какие экраны, обработки, отчёты должны быть.
Обычно формулируются в формате:
«Система должна…» + конкретное действие и условие.
Что в них важно
· вход и выход (что подаём на вход, что получаем на выходе);
· условия (когда срабатывает, когда нет);
· связь с бизнес‑процессом (закупки, склад, ценообразование и т.п.);
· возможность проверить по сценарию (use case).
Примеры для 1С:ERP:
· «Система должна автоматически рассчитывать скидку по номенклатуре при сумме заказа больше 50 000 руб., с сохранением истории расчёта».
· «При проведении накладной система должна проверять остатки и блокировать документ, если они уходят в минус, выводя сообщение “Недостаточно на складе X”».
· «Отчёт “Оборачиваемость” должен формироваться за выбранный период, иметь фильтр по видам номенклатуры и возможность выгрузки в Excel».
Для аналитика и разработчика:
это основа ТЗ, сценариев тестирования и задач в Jira/Redmine/1С:EDT.
Нефункциональные требования: скорость, надёжность, удобство
Что это такое
Нефункциональные требования описывают качество работы системы, а не бизнес‑логику:
· скорость;
· надёжность;
· безопасность;
· удобство интерфейса;
· масштабируемость.
Формат:
«Система должна работать…» + нужное качество.
Основные категории:
· производительность;
· безопасность и права доступа;
· масштабируемость (сколько пользователей, объём данных);
· удобство работы (usability), особенно если есть мобильные сценарии.
Примеры для 1С:
· Производительность: «Отчёт по 1 млн строк должен формироваться не дольше 3 минут на сервере с 16 ГБ ОЗУ».
· Безопасность: «Доступ к разделу “Закупки” — только у ролей “Закупщик” и “Директор”, с записью всех действий в журнал регистрации».
· Usability: «Форма списания товаров должна корректно открываться на планшете и поддерживать сканер штрих‑кодов».
· Масштабируемость: «Система выдерживает до 50 одновременных пользователей без увеличения времени отклика более 2 секунд».
Для архитектора, админа и тестировщика:
это база для настройки инфраструктуры и нагрузочного тестирования.
Сводная картинка: кто что читает и использует
Как работать с требованиями в 1С‑проекте: практический подход
1. Сначала собрать «чего хочется» на языке пользователей
· анкеты, интервью, совместные обсуждения;
· фиксируем пользовательские требования:
o «Пользователь должен…»
o в предметных терминах (отдел, процесс, роль).
2. Потом переводить их в язык системы
Из каждого пользовательского требования делаем:
· 1–несколько функциональных требований:
o «Система должна [действие] при [условии]»;
· и при необходимости — нефункциональные:
o «Система должна обеспечивать [KPI по скорости/надёжности/удобству]».
Пример:
· Пользовательское: «Кладовщик должен быстро печатать накладную по штрих‑коду».
· Функциональное: «Система должна находить документ по штрих‑коду и открывать форму печати по кнопке F6».
· Нефункциональное: «Время от сканирования штрих‑кода до вывода формы печати — не более 3 секунд».
3. Настроить трассируемость (связь цепочки)
Полезно держать матрицу:
· Пользовательское требование →
· Функциональное требование →
· Конкретная задача/реализация в 1С (карточка в Jira, задача разработчику).
Так проще:
· видеть, какие хотелки ещё не покрыты;
· выбрасывать функциональные требования, за которыми не стоит реальная бизнес‑потребность.
4. Проверять формулировки и показывать прототипы
· ревью требований с бизнесом, разработкой и тестированием;
· ранние прототипы в 1С (формы, отчёты, обработки) — даже «на черновик».
Это экономит недели на переделках: лучше немного поругаться на прототипе, чем после полноценной доработки.
Типичные ошибки в 1С‑проектах и как их не допустить
1. Смешение видов требований
Пример:
«Система должна работать быстро».
Проблема:
· непонятно, что такое «быстро»;
· непонятно, к чему это относится: к отчётам? к формам? ко всему?
Как исправить:
· разделить на функциональное и нефункциональное;
· для нефункционального задать цифры:
«Отчёт X должен строиться до 5 секунд при базе до N записей».
2. Игнор нефункциональных требований
Классика:
· внедрили 1С:ERP на слабом сервере;
· отработали все бизнес‑процессы;
· но система так тормозит, что пользователи её ненавидят.
Как избежать:
· сразу проговаривать ограничения по инфраструктуре;
· включать в ТЗ и план тестов пункты по производительности и количеству пользователей.
3. Нет приоритизации
Когда всё «важно», команда захлёбывается в задачах, а сроки плывут.
Решение:
· расставлять приоритеты по MoSCoW для каждого вида требований:
o Must have — без этого система не сработает;
o Should have — желательно в первый релиз;
o Could have — можно потом;
o Won’t have — точно не делаем сейчас.
Что взять в работу аналитикам
· Всегда разделять: кто что хочет (пользователь) и что должна делать система (функционал + качества).
· Формулировать в явном виде три уровня:
o «Пользователь должен…»
o «Система должна [что] при [каких условиях]»
o «Система должна обеспечивать [какие цифры по скорости, надёжности и удобству]».
· Следить за связью: нет пользовательского требования — задумайтесь, зачем вообще нужна доработка.
Так требования перестают быть «списком хотелок» и превращаются в управляемый инструмент: что делаем, зачем и как поймём, что получилось.
Ответ скрыт в требованиях.
Если не разделять типы требований, получается каша:
· «хотелки» пользователей превращаются в бесконечные доработки;
· разработчики не понимают, что критично, а что второстепенно;
· система в итоге «как‑то работает», но не решает бизнес‑задачи.
Поэтому важно различать три базовых типа:
· пользовательские требования;
· функциональные требования;
· нефункциональные требования.
Пользовательские требования: язык бизнеса
Что это такое
Пользовательские требования описывают, что хочет видеть и делать человек в системе, без техподробностей.
Это взгляд глазами роли: закупщика, кладовщика, менеджера, бухгалтера.
Как их узнать:
· интервью с пользователями;
· анкеты;
-совместные сессии/мозговые штурмы.
Как они звучат
· пишутся на языке предметной области (продажи, склад, закупки);
· отвечают на вопрос: «Что пользователь должен уметь сделать/получить?»;
· не содержат «как это реализовано в 1С».
Примеры для 1С:УТ 11:
· «Закупщик должен видеть статус согласования договора без звонков коллегам».
· «Кладовщик должен распечатать накладную по штрих‑коду за 10 секунд».
· «Менеджер должен контролировать оборачиваемость товара по каждому складу».
Для аналитика:
это сырьё. Из него дальше рождаются функциональные и нефункциональные требования.
Функциональные требования: как именно работает 1С
Что это такое
Функциональные требования описывают поведение системы:
· какие действия выполняет 1С;
· что делает с данными;
· какие экраны, обработки, отчёты должны быть.
Обычно формулируются в формате:
«Система должна…» + конкретное действие и условие.
Что в них важно
· вход и выход (что подаём на вход, что получаем на выходе);
· условия (когда срабатывает, когда нет);
· связь с бизнес‑процессом (закупки, склад, ценообразование и т.п.);
· возможность проверить по сценарию (use case).
Примеры для 1С:ERP:
· «Система должна автоматически рассчитывать скидку по номенклатуре при сумме заказа больше 50 000 руб., с сохранением истории расчёта».
· «При проведении накладной система должна проверять остатки и блокировать документ, если они уходят в минус, выводя сообщение “Недостаточно на складе X”».
· «Отчёт “Оборачиваемость” должен формироваться за выбранный период, иметь фильтр по видам номенклатуры и возможность выгрузки в Excel».
Для аналитика и разработчика:
это основа ТЗ, сценариев тестирования и задач в Jira/Redmine/1С:EDT.
Нефункциональные требования: скорость, надёжность, удобство
Что это такое
Нефункциональные требования описывают качество работы системы, а не бизнес‑логику:
· скорость;
· надёжность;
· безопасность;
· удобство интерфейса;
· масштабируемость.
Формат:
«Система должна работать…» + нужное качество.
Основные категории:
· производительность;
· безопасность и права доступа;
· масштабируемость (сколько пользователей, объём данных);
· удобство работы (usability), особенно если есть мобильные сценарии.
Примеры для 1С:
· Производительность: «Отчёт по 1 млн строк должен формироваться не дольше 3 минут на сервере с 16 ГБ ОЗУ».
· Безопасность: «Доступ к разделу “Закупки” — только у ролей “Закупщик” и “Директор”, с записью всех действий в журнал регистрации».
· Usability: «Форма списания товаров должна корректно открываться на планшете и поддерживать сканер штрих‑кодов».
· Масштабируемость: «Система выдерживает до 50 одновременных пользователей без увеличения времени отклика более 2 секунд».
Для архитектора, админа и тестировщика:
это база для настройки инфраструктуры и нагрузочного тестирования.
Сводная картинка: кто что читает и использует
Вид требований | Чем описывается | Пример в 1С:УТ | Источник | Кто использует |
Пользовательские | Бизнес‑язык | «Контроль просрочек поставок» | Интервью, анкеты | Бизнес, заказчик, аналитик |
Функциональные | Поведение системы | «Автоуведомление по email при просрочке >3 дн» | Use cases, схемы | Аналитик, разработчик |
Нефункциональные | Качества системы (скорость, надёжность) | «Уведомление уходит <1 сек при 100 пользователях» | Спецификации | Архитектор, тестировщик |
Как работать с требованиями в 1С‑проекте: практический подход
1. Сначала собрать «чего хочется» на языке пользователей
· анкеты, интервью, совместные обсуждения;
· фиксируем пользовательские требования:
o «Пользователь должен…»
o в предметных терминах (отдел, процесс, роль).
2. Потом переводить их в язык системы
Из каждого пользовательского требования делаем:
· 1–несколько функциональных требований:
o «Система должна [действие] при [условии]»;
· и при необходимости — нефункциональные:
o «Система должна обеспечивать [KPI по скорости/надёжности/удобству]».
Пример:
· Пользовательское: «Кладовщик должен быстро печатать накладную по штрих‑коду».
· Функциональное: «Система должна находить документ по штрих‑коду и открывать форму печати по кнопке F6».
· Нефункциональное: «Время от сканирования штрих‑кода до вывода формы печати — не более 3 секунд».
3. Настроить трассируемость (связь цепочки)
Полезно держать матрицу:
· Пользовательское требование →
· Функциональное требование →
· Конкретная задача/реализация в 1С (карточка в Jira, задача разработчику).
Так проще:
· видеть, какие хотелки ещё не покрыты;
· выбрасывать функциональные требования, за которыми не стоит реальная бизнес‑потребность.
4. Проверять формулировки и показывать прототипы
· ревью требований с бизнесом, разработкой и тестированием;
· ранние прототипы в 1С (формы, отчёты, обработки) — даже «на черновик».
Это экономит недели на переделках: лучше немного поругаться на прототипе, чем после полноценной доработки.
Типичные ошибки в 1С‑проектах и как их не допустить
1. Смешение видов требований
Пример:
«Система должна работать быстро».
Проблема:
· непонятно, что такое «быстро»;
· непонятно, к чему это относится: к отчётам? к формам? ко всему?
Как исправить:
· разделить на функциональное и нефункциональное;
· для нефункционального задать цифры:
«Отчёт X должен строиться до 5 секунд при базе до N записей».
2. Игнор нефункциональных требований
Классика:
· внедрили 1С:ERP на слабом сервере;
· отработали все бизнес‑процессы;
· но система так тормозит, что пользователи её ненавидят.
Как избежать:
· сразу проговаривать ограничения по инфраструктуре;
· включать в ТЗ и план тестов пункты по производительности и количеству пользователей.
3. Нет приоритизации
Когда всё «важно», команда захлёбывается в задачах, а сроки плывут.
Решение:
· расставлять приоритеты по MoSCoW для каждого вида требований:
o Must have — без этого система не сработает;
o Should have — желательно в первый релиз;
o Could have — можно потом;
o Won’t have — точно не делаем сейчас.
Что взять в работу аналитикам
· Всегда разделять: кто что хочет (пользователь) и что должна делать система (функционал + качества).
· Формулировать в явном виде три уровня:
o «Пользователь должен…»
o «Система должна [что] при [каких условиях]»
o «Система должна обеспечивать [какие цифры по скорости, надёжности и удобству]».
· Следить за связью: нет пользовательского требования — задумайтесь, зачем вообще нужна доработка.
Так требования перестают быть «списком хотелок» и превращаются в управляемый инструмент: что делаем, зачем и как поймём, что получилось.
Полезные статьи для аналитиков
