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