Владелец процесса утверждает: «Оператор всегда проверяет данные перед отправкой». Как аналитик должен классифицировать это утверждение до включения в требования?
Это следует зафиксировать как предположение о текущем процессе, а не сразу как подтверждённое требование. Аналитик должен проверить его по наблюдениям, регламентам и фактическим данным, после чего определить: это обязательное бизнес-правило, функциональное требование к системе или неподтверждённое допущение.
В ранних проектах требования часто строились почти исключительно на интервью с заказчиком. Такой подход не учитывал, что участники описывают желаемое, формально установленное или привычное поведение, смешивая эти понятия.
Управление предположениями появилось как способ отделить проверенные факты от гипотез, от которых зависит решение. Это снижает риск построить систему на неверном представлении о процессе.
Фраза «оператор всегда проверяет данные» не сообщает, почему проверка выполняется и обязательна ли она. Это может быть утверждённое правило, рекомендация, описание обычной практики или ожидание владельца процесса.
Если принять утверждение без проверки, система может не содержать нужной валидации, разрешить пропуск обязательного шага или, наоборот, навязать ограничение, которого нет в реальной работе. Особенно опасны слова «всегда», «обычно», «никогда» и другие неквантифицированные обобщения.
Сначала аналитик заносит утверждение в реестр предположений с указанием источника, затронутого процесса, способа проверки и риска ошибочной трактовки. Формулировка должна сохранять неопределённость: «Предполагается, что оператор проверяет данные перед отправкой».
Затем нужно выяснить основание утверждения:
Проверка должна опираться не на один источник. Полезно сопоставить интервью с регламентом, наблюдением за работой и данными об уже выполненных операциях. При расхождении источников аналитик фиксирует конфликт и выносит его на решение владельца процесса, а не выбирает трактовку самостоятельно.
После подтверждения утверждение нужно переформулировать в проверяемый вид: определить объект проверки, момент выполнения, ответственного, допустимый результат и последствия ошибки. Важно не переносить в требование сам способ работы оператора, если бизнес-цель может быть достигнута иначе.
Владелец процесса сообщил, что оператор всегда проверяет реквизиты перед отправкой платежа. Были рассмотрены варианты: принять слова владельца без проверки — быстро, но с высоким риском; провести только дополнительное интервью — дешевле наблюдения, но возможна социально желательная версия процесса; изучить регламент, понаблюдать за операциями и сопоставить данные об отклонённых платежах — дольше, зато позволяет проверить и правило, и фактическое исполнение.
Выбран третий вариант. Выяснилось, что проверка обязательна по регламенту, но часть реквизитов уже проверяется автоматически, а оператор вручную контролирует только исключения. Поэтому в требования включили не ручной шаг «проверить все данные», а правило блокировки отправки при непроверенных обязательных реквизитах и отдельное требование к обработке исключений.
Так удалось избежать как дублирования ручной работы, так и опасного предположения, что фактическая практика полностью соответствует регламенту.
1. Можно ли считать предположение требованием, если его высказал владелец процесса?
Нет. Авторитет источника повышает приоритет проверки, но не превращает утверждение в подтверждённое требование. Владелец может описывать цель, желаемое поведение или устаревший регламент, поэтому происхождение утверждения и его статус нужно фиксировать отдельно.
2. Чем предположение отличается от ограничения?
Предположение — это ещё не подтверждённое утверждение, на котором временно основывается анализ. Ограничение — подтверждённое условие, сужающее допустимые варианты решения: например, обязательное законодательное правило или заданная организационная политика.
Если предположение подтверждено, оно может стать ограничением или источником требований. Пока проверка не выполнена, его нужно учитывать как риск, а не использовать как безусловную границу системы.
3. Что делать, если предположение нельзя проверить до выпуска системы?
Нужно явно принять решение о риске: указать владельца, вероятность, последствия и срок пересмотра. В требования можно включить наблюдаемость, журналирование или управляемый резервный сценарий, чтобы после запуска проверить предположение и безопасно изменить поведение.
Такой подход не доказывает истинность предположения, но ограничивает ущерб от ошибки. Если риск неприемлем, выпуск следует отложить либо получить формальное решение уполномоченного лица о принятии риска.