Найденное правило и требование — не одно и то же

Аналитик открывает найденное правило и видит: назначение платежа обязательно для одной из операций. Пользователь же говорит, что недавно отправил заявку без назначения. Кто прав? Возможно, правило найдено не полностью; возможно, выбран возврат средств; возможно, поле было заполнено на экране, но не сохранено; наконец, система действительно ведёт себя не так, как задумано. Чтобы ответить, нужно различать три вещи: найденное правило, требование к процессу и фактическое поведение в конкретном сценарии.

Рассмотрим учебную модель «Заявка на выплату»: назначение обязательно для «Оплаты услуг», а для согласования нужны один человек до 100000 рублей и два — от этой суммы. Это условный пример, не описание реальной конфигурации.

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

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

Найденное правило описывает условие, но не заменяет весь путь пользователя. Момент проверки, сохранение значения при переключении и действия после отправки стоит уточнить отдельно. А решение о том, соответствует ли правило процессу, принимает владелец процесса. О том, как пересказать найденную логику человеческим языком, рассказывает статья «Как объяснить работу функции».

Требование выражает ожидаемый процесс

Требование отвечает не на вопрос «что уже обнаружено?», а на вопрос «как должно работать для пользователя?». Ответ на него утверждает владелец процесса. Например: «При оплате услуг назначение обязательно до отправки. При возврате поле можно оставить пустым. Если пользователь временно меняет операцию и возвращается к оплате, система сохраняет ранее введённое назначение».

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

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

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

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

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

Для такой проверки нужна тестовая база 1С; автоматизируйте её через Vanessa Automation MCP, если инструмент отдельно настроен для этой среды.

Сведите три слоя рядом

Для разговора с командой запишите короткую таблицу или три строки:

Слой	Пример формулировки
Найденное правило	Доступные статические сведения связывают обязательность назначения с оплатой услуг.
Требование	При оплате услуг назначение заполнено до отправки; возврат допускает пустое поле.
Наблюдение	Например, если проверка покажет, что после переключения и повторного открытия поле пусто, это будет результатом именно этого сценария.

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

Выберите следующий шаг по расхождению

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

После этого сформулируйте проверяемые случаи. Для назначения: обе операции с заполненным и пустым значением; переход туда и обратно; сохранение и повторное открытие. Для согласования: 99999, 100000 и 100001 рубль. Сквозной маршрут аналитика собран в статье «Как аналитику работать с LEM».

Так найденное правило становится основанием для разговора, требование — согласованным ожиданием, а тест — свидетельством о конкретном поведении. Разделяя эти слои, аналитик может честно объяснить, что уже известно, что решено и что ещё предстоит проверить.