Представьте: в модели есть сущность «Заявка», но требования не показывают, кто и на каком шаге её создаёт, изменяет или удаляет. Какой аналитический приём поможет выявить пробелы?
Используйте CRUD-матрицу: сопоставьте бизнес-процессы или варианты использования с сущностями и отметьте операции Create, Read, Update, Delete. Если для сущности отсутствует ожидаемая операция либо операция есть, но не указаны процесс и ответственный, это сигнал о неполноте требований.
Матрица не доказывает корректность процесса сама по себе. Она служит контрольным представлением, которое помогает обнаружить пропущенные шаги жизненного цикла данных, неясные зоны ответственности и потенциальные конфликты доступа.
CRUD-матрица возникла как практический способ связать обработку данных с функциями системы. Одного описания процессов недостаточно: в нём можно пропустить создание записи, изменение её статуса или правила удаления.
Табличное представление заставляет проверить систему с двух сторон: какие данные использует каждый процесс и какие процессы обеспечивают жизненный цикл каждой сущности. Поэтому приём применяют на ранних этапах анализа требований и проектирования границ ответственности.
Если для «Заявки» не определено, кто её создаёт, требования могут описывать только просмотр уже существующих данных. Если не указан владелец изменения, разные роли начнут трактовать правила по-разному. Если не определено удаление или архивирование, накопятся неактуальные записи либо появятся несогласованные ручные операции.
Неполная картина приводит к дефектам интерфейсов, интеграций, прав доступа и тестов. Особенно опасны сущности, которые участвуют в нескольких процессах: изменение в одном процессе может нарушить предположения другого.
Сначала выделите устойчивые сущности данных, например «Заявка», «Клиент» и «Решение». Затем перечислите процессы, варианты использования или роли, которые работают с этими сущностями. В пересечении укажите операции C, R, U и D; при необходимости добавьте исполнителя или ссылку на конкретное требование.
Аналитик проверяет несколько признаков:
Пустая ячейка не всегда означает дефект. Например, сущность может создаваться внешней системой, удаление может быть запрещено политикой хранения, а процесс может только читать справочник. Поэтому каждая необычная комбинация должна иметь объяснение, зафиксированное в требовании или ограничении.
CRUD-матрица также не показывает порядок операций, условия переходов и альтернативные ветви. Для этого нужны BPMN, диаграммы состояний, сценарии или правила. Кроме того, буква U слишком груба для сложных случаев: изменение адреса и изменение финансового лимита могут иметь разные права, согласования и критерии приёмки.
Практический результат лучше оформлять не как самостоятельную спецификацию, а как средство трассируемости. В ячейке можно хранить ссылку на процесс, user story или требование, а выявленные пробелы превращать в вопросы к предметному эксперту.
В системе обработки заявок команда описала приём заявки, её проверку и вынесение решения. При построении CRUD-матрицы выяснилось, что «Заявка» создаётся оператором, изменяется проверяющим, но для отказа не существовало операции обновления: статус менялся только в устном описании процесса.
Рассматривались три варианта. Можно было оставить описание в BPMN, но связь с данными осталась бы неявной. Можно было добавить отдельную техническую задачу «обновить статус», однако она не объясняла бизнес-условие и права. Выбранным решением стало уточнение пользовательской истории: фиксировались допустимые статусы, роль, выполняющая переход, причина отказа и критерии приёмки.
После этого в матрице появилась операция обновления, а в модели процесса — явный переход к состоянию «Отказана». Это позволило согласовать права доступа и подготовить проверяемые сценарии, не превращая CRUD-матрицу в замену процессной модели.
1. Означает ли пустая ячейка CRUD-матрицы, что требование пропущено?
Нет. Пустая ячейка означает только отсутствие зафиксированной связи между процессом и операцией над сущностью. Это может быть корректным решением: процесс не должен изменять данные, сущность создаётся внешней системой или удаление запрещено.
Аналитик должен проверить основание такой пустоты. Если объяснение невозможно получить из требований, модели или согласованного ограничения, ячейку следует превратить в вопрос на уточнение, а не автоматически добавлять функциональность.
2. Можно ли по букве U понять, какие именно атрибуты изменяются?
Нет. Update обозначает факт изменения сущности, но не состав изменяемых данных, условия, инициатора и последствий. Для финансового лимита могут требоваться согласование и аудит, тогда как изменение контактного телефона может быть доступно пользователю напрямую.
Поэтому для существенных изменений нужно дополнить матрицу ссылкой на сценарий, список атрибутов, бизнес-правило или переход состояния. Иначе матрица создаёт ложное ощущение полноты.
3. Чем CRUD-матрица отличается от матрицы ответственности ролей?
CRUD-матрица показывает операции процессов над данными. Матрица ответственности, например с ролями и видами ответственности, отвечает на другой вопрос: кто выполняет, согласует или контролирует действие.
Их можно связать, добавив роль в ячейку или создав отдельное представление, но смешивать назначения без явного обозначения опасно. Иначе наличие операции «обновить» ошибочно примут за право конкретной роли выполнять любое изменение сущности.