Обучение

Новости
О центре
Центр карьеры
Сообщение об ошибке

Обучение

Ближайшие старты

IT Bootcamp

Новости

О центре

Центр карьеры

Корпоративное обучение

Отзывы

Истории успеха

Сообщение об ошибке
Введите поисковый запрос

Пишем качественные требования с помощью DMN: таблиц Decision Table

10 июня 2022

Артем Кагукин 14+ лет работает аналитиком в ИТ и 2,5 года ведет курс «Бизнес-анализ с области разработки ПО». За это время он успел поработать с разными клиентами и пробовать различные способы спецификации требований: моделирование с использованием нотации BPMN и UML, естественный язык, таблицы событий и реакций системы, прототипирование и прочее.

В данной статье Артем делится своим опытом создания таблиц Decision Table из нотации DMN (далее используется понятие Таблицы решений) и показывает, как и для каких целей их можно использовать.

Если ты знаком с нотацией UML, BPMN, а также техниками Анализ бизнес-правил и Варианты использования (Use Case), эта статья как раз для тебя.

Еще не научился превращать сложный документ в диаграммы, понятные другим членам проекта? В IT-Academy есть продвинутый курс по использованию нотации UML для практического анализа и визуального моделирования.

DMN — общая нотация, понятная всем бизнес-пользователям:

  • бизнес-аналитикам, которым необходимо создать первоначальные требования к принятию решений, а затем более подробные модели принятия решений;

  • техническим разработчикам, ответственным за автоматизацию решений в процессах;

  • деловым людям, которые будут управлять и следить за этими решениями. 

DMN создает стандартизированный мост для преодоления разрыва между разработкой бизнес-решений и реализация решений. С её помощью можно представить требования в графическом и табличном виде. Также вы можете применять принципы DMN в системах low-code для настроек ИТ-решений согласно потребностям заказчика. 

Кто не хочет формулировать качественные требования с использованием готового шаблона, чтобы сделать их краткими, понятными и полными?

Что такое Таблицы решений в нотации DMN

Вы можете пропустить эту часть статьи, если знакомы с понятием Таблиц решений в нотации DMN. Я не буду давать подробное описание принципов и правил построения таких таблиц. Все это вы можете найти в спецификации к нотации DMN. Ссылка будет в конце статьи. Я бы хотел дать основные понятия для понимания приведенных мною примеров из практики ниже.

DMN — это нотация, основная цель которой — описать логику принятия решений. Моделирование решений показывает, как принимаются повторяемые бизнес-решения. Однако данная нотация применима и для определения решения при проектировании систем: продуктов, списка контрольных вопросов, логики отображения полей на UI и др. DMN структурирована и имеет три уровня соответствия, позволяющие использовать данную нотацию в автоматизированных решениях no-code и использовать в системах, работающих на BPMN «движке». Можно выделить следующие цели данной нотации:

  • Для моделирования процесса принятия решений человеком

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

  • Для внедрения автоматизированного процесса принятия решений

Требования могут быть представлены в виде графов Decision Requirements Graph (DRG), диаграмм Decision Requirements Diagrams (DRDs) и табличном виде Decision Table.

Таблицы Decision Table могут быть вертикально или горизонтально ориентированными, иметь набор входных и выходных параметров, а также ряд других дополнительных атрибутов, определяющих правила работы с ними.



Мой опыт

Мое знакомство с DMN началось в 2019 году. На ИТ-мероприятии моя бывшая коллега, Рыбалко Юлия, рассказала мне об использовании в ее компании Таблиц решений из нотации для тестирования. Я не знал, что это такое, но данный подход меня заинтересовал своей возможностью применения в тестировании и спецификации требований. Позже я ознакомился со стандартом DMN, прочитал несколько статей, посмотрел ряд докладов. Ссылки на источники вы найдете в конце статьи. Сейчас же я хотел бы отметить, что данный подход показался мне полезным в части использования Таблиц решений при формулировании требований, нежели графических элементов (Decision Requirements Diagrams). Я понимал, как могу применять их в спецификации требований отдельно и в комбинации с BPMN диаграммами, UML диаграммами, Вариантами использования (Use Case). Именно этим опытом я бы и хотел поделиться далее.

Анализ бизнес-правил

  • Бизнес для принятия решений часто использует большое количество разнообразных бизнес-правил. Скоринговая оценка клиента, определения рейтинга клиента — все это лишь несколько примеров, сложных и объемных бизнес-правил. Табличное представление дает возможность сортировать, группировать, фильтровать данные. Именно поэтому их использование позволяет удобно и эффективно анализировать, и синтезировать данные, а также выявлять противоречия при анализе бизнес-правил.

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


Определение границ системы с помощью описания бизнес-процессов AS IS и TO BE

Моделирование бизнес-процессов AS IS и TO BE помогает в определении границ будущей системы, а также для выявления различий между текущим и будущим состоянием рабочих процессов. Нотация BPMN является одним из основных инструментов, помогающих решать данные задачи. При моделировании бизнес-процессов часто требуется описывать логику принятия бизнес-решений с использованием множества ветвлений потоков и шлюзов. Это перегружает диаграмму различными элементами и уменьшает ее восприятие. 


Для решения данных проблем в BPMN есть отдельный тип задач «Выполнение бизнес-правил». Он позволяет объединить все возможные бизнес-правила, на основании которых принимается решение. Сами же бизнес-правила при этом описаны в отдельной таблице в отдельном артефакте.

  • Основываясь на примере выше, процесс может быть представлен в виде примечания для задачи или как гиперссылка на страницу с Таблицей решений. Ниже приведен пример процесса обработки кредитной заявки в нотации BPMN из моей практики.


Спецификация требования заинтересованных лиц

  • После определения границ системы и формулирования целей и бизнес-требований к системе необходимо определить требования заинтересованных. Существуют различные подходы к спецификации пользовательских требования: «Пользовательские истории» (User Story), «Вариант использования» (Use Case), работа с Персонами и сценариями для них. В своей практике я часто использовал «Вариант использования» (Use Case) для формулирования требований заинтересованных лиц. Общеизвестно, что количество шагов в «Варианте использования» (Use Case) должно быть не более 12-15. Это делает их более понятными для восприятия и анализа противоречий. Однако сделать это не всегда легко. Можно конечно выполнить декомпозицию «Варианта использования» (Use Case) на несколько связанных, но это не всегда удобно и применимо. Таблицы решений могут быть альтернативным вариантом, который может вам помочь в группировке несколько шагов проверок системы в один шаг.

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


Формулирование требований к решению

  • Самыми точными и детализированным являются функциональные требования к решению. Такие требования можно формулировать в классическом текстовом виде, в формате «Варианта использования» (Use Case) и других формах. При использовании «Варианта использования» (Use Case) и построении Диаграммы действий в нотации UML можно добавить Таблицы решений для описания логических правил по выбору системой дальнейшей стратегии действия. Это позволит сделать ваши требования полными и понятными.

  • Пример из практики, представлен ниже. В данном «Варианта использования» (Use Case) и Диаграммы действий описаны функциональные требования к системе по выбору индивидуальных договоров, в которое необходимо внести правки на основании типа, статуса и даты договора. Система должна иметь возможность отбирать индивидуальные договора для внесения изменений в них, когда по основному договору было заключено дополнительное соглашения. Выборка индивидуальных договоров делается на основании трех параметров: тип, статус и дата договора и дата дополнительного соглашения. Далее во всех отобранных индивидуальных договорах вносятся соответствующие изменения системой без участия человека.



Конфигурация решения путем выполнения настроек

Отдельно хочу упомянуть про возможности использования Таблиц решений не только для спецификации требований, но и для выполнения настроек реального работающего решения. Существуют low-code системы (например, OpenL /WebStudio, с которой я работал 2 года) предоставляющие специалисту в режиме реального времени выполнять настройки продукта, бизнес-правил, задавать логику поведения элементов системы на UI и определять алгоритмы калькуляции различных параметров. Таблицы в данном случае могут содержать множество строк и столбиков, но принципы построения Таблиц решений остаются неизменными. 

Несколько скринов с примерами из практики



В заключение

Знание принципов построения Таблиц решений из DMN поможет вам улучшить качество формулируемых вами требований и повысит уровень компетенций в работе с low-code системами для конфигурации готовых решений.

Помните, что таблицы «используются, когда бизнес-аналитик моделирует требование или набор требований, имеющих сложную, но однородную структуру, которая может быть разбита на элементы, применимые к каждому значению в таблице» (цитата из «Руководство к своду знаний по бизнес-анализу», ВАВОК). Разумное сочетание табличного представления требований вместе с другими формами представления требований может быть удобным инструментом в руках бизнес-аналитика и системного аналитика. Мои примеры, надеюсь, смогли убедить вас в этом. 

P.S. Благодарю Павла Кондратьева за помощь в подготовке статьи. 

Список полезных ресурсов

  1. Спецификация Decision Model and Notation от OMG

  2. Статьи и видео для общего понимания:

  3. OpenL Tablet. No-code система использующая Decision Model and Notation

  4. Книга Real-World Decision Modeling with DMN by James Taylor

Читай еще 

BABOK от IIBA или REF от IREB: что и когда читать бизнес-аналитику?

«Каждый находит в бизнес-анализе что-то свое»

Внутри бизнес-анализа. PT. 1

Внутри бизнес-анализа. PT. 2


Полная, частичная перепечатка или любое иное использование материалов с сайта IT-Academy разрешается только с указанием активной гиперссылки, ведущей на первоисточник (точный адрес страницы на www.it-academy.by).