Рассказали, зачем бизнес аналитику описывать функционирование продукта с помощью нотаций ARIS eEPC и BPMN 2.0 и как это делать.

Здравствуйте! Меня зовут Сергей Гусев, я ведущий системный аналитик IT_One. В данной статье я бы хотел затронуть важные нюансы деятельности системного аналитика и команд разработки ПО.

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

Эти инструменты позволяют описать то, как будет работать продукт и как пользователи будут с ним взаимодействовать. Чаще всего получается довольно объемный документ или набор документов, где описаны функциональные и нефункциональные требования, варианты взаимодействия (use case diagrams) и чек-листы для тестирования. Что же из этого лучше с точки зрения разработчика? В идеале – это готовый прототип программного продукта, демонстрирующий, как пользователь взаимодействует с ним, что именно требуется разработать, как и в какой последовательности должны появляться окна для заполнения информации. Остается только открыть текстовый документ, чтобы в нем свериться со свойствами атрибутов. Увы, чаще всего из-за нехватки времени и желания сэкономить многие команды пренебрегают созданием такой модели.

Второй, не менее популярный, метод — это описание функционирования продукта с помощью нотаций ARIS eEPC и BPMN 2.0. Чем же они удобны?

Преимущества ARIS eEPC – простыми словами

Нотацию ARIS eEPC разработал основатель IDS Scheer Август Вильгельм Шеер со своими коллегами. Взяв за основу методологию IDEF3, он дополнил ее до модели EPC – расширенной цепочки процесса, управляемого событиями, которую позже стали называть «процессно-событийная модель» (дословно Event-driven Process Chain). Используемая для моделирования бизнес-процессов в инструментарии ARIS, она представляет собой последовательность событий и функций, отражающих логику выполнения взаимосвязанных действий, направленных на достижение определенного результата. По сути, если созданная модель описывает функциональность разрабатываемого ПО, то она является инструкцией для разработчика.

Посмотрим на основные компоненты данной нотации:

...

Полный текст на сайте Tproger