Урок 4 из 8 · 20 мин · обновлено
Требования: зачем они нужны и какими бывают
Что такое требование и почему без требований проект 1С превращается в спор «мы не это заказывали», какие бывают требования — бизнес-требования, пользовательские, функциональные, нефункциональные и бизнес-правила — и как отличать их на примерах.
Зачем нужны требования
Заказчик говорит: «Сделайте контроль скидок». Разработчик сделал: при скидке больше 10% появляется предупреждение. Через месяц заказчик недоволен: «Я хотел, чтобы такой заказ нельзя было провести без моего согласия!» Кто прав? Никто — договорённости не было.
Требование — точное описание того, что должна делать система или каким условиям отвечать. По требованиям:
- оценивают сроки и стоимость работ;
- делают — разработчик знает, что именно нужно;
- проверяют — тестировщик сверяет результат с требованием;
- принимают — заказчик подписывает, что получил то, о чём договорились.
В проектах 1С требования особенно важны: доработки типовых конфигураций влияют на учёт, отчётность и обновления. Ошибка может обойтись в неправильные налоги или сорванное закрытие месяца.
Виды требований
| Вид | Что описывает | Пример для «ДомТорга» |
|---|---|---|
| Бизнес-требования | цель компании | сократить потери от необоснованных скидок |
| Пользовательские | что хочет сделать человек | руководитель продаж хочет видеть все заказы, ждущие его согласия, в одном списке |
| Функциональные | что делает система | система не даёт провести заказ со скидкой больше 10% без согласования |
| Нефункциональные | насколько хорошо | список заказов на согласование открывается не дольше 3 секунд; согласовывать может только руководитель продаж |
| Бизнес-правила | правила компании | скидку больше 10% согласует руководитель продаж, больше 20% — директор |
Виды связаны цепочкой: цель бизнеса → что для этого нужно людям → что для этого делает система. Если функциональное требование не связано ни с одной целью, стоит спросить, зачем оно вообще нужно.
Пользовательские истории
Пользовательские требования часто записывают в виде пользовательской истории:
Как руководитель продаж, я хочу видеть все заказы, ждущие согласования, в одном списке, чтобы быстро отвечать менеджерам.
Формула «как — хочу — чтобы» помогает не забыть, кому это нужно и зачем. Без «чтобы» легко сделать то, что просили, но не то, что нужно.
Нефункциональные требования
Про них часто забывают, а потом удивляются. Что обычно уточняют в проектах 1С:
- скорость — как быстро открываются списки и формируются отчёты;
- права доступа — кто видит, кто меняет, кто согласует;
- надёжность — что будет, если обмен с сайтом прервался;
- удобство — сколько действий нужно для частой операции;
- совместимость — работает ли доработка с обновлениями типовой конфигурации.
Попробуйте сами. Определите вид каждого требования: бизнес-требование, пользовательское, функциональное, нефункциональное или бизнес-правило.
- Снизить долю просроченной задолженности клиентов до 5%.
- Бухгалтер хочет каждое утро видеть список клиентов с просрочкой оплаты.
- Клиентам с просрочкой больше 30 дней отгрузку не делаем.
- Система запрещает проводить отгрузку клиенту с просрочкой больше 30 дней.
- Отчёт по просрочке формируется не дольше 10 секунд.
- Снять запрет на отгрузку для отдельного клиента может только финансовый директор.
Решение
- Бизнес-требование — цель компании.
- Пользовательское — что хочет сделать конкретный человек.
- Бизнес-правило — правило компании, оно действует и без системы.
- Функциональное — что делает система по этому правилу.
- Нефункциональное — скорость.
- Нефункциональное: права доступа. Само правило «исключения разрешает только финансовый директор» — ещё и бизнес-правило.
Последний пункт показывает, что границы между видами не всегда жёсткие. Важно не угадать название, а убедиться, что вы ничего не упустили: цель, кто и что делает, что делает система, насколько хорошо и по каким правилам.
Мини-тест: проверьте себя
Закрепите урок: несколько вопросов, разбор ответов — в конце.
-
«Сократить время согласования заказов со скидкой до одного часа». Какой это вид требования?
Это цель компании — чего бизнес хочет добиться. Как именно система поможет, опишут другие требования.
-
«Система не даёт провести заказ со скидкой больше 10% без согласования». Какой это вид?
Функциональное требование описывает, что делает система. Порог 10% при этом — бизнес-правило.
-
«Список заказов на согласование открывается не дольше 3 секунд». Какой это вид?
Требование описывает не что делает система, а насколько хорошо: скорость работы.