Какие предпочитаешь нотации?

Предпочитаемые нотации для бизнес-анализа

В своей практике я использую различные нотации и диаграммы в зависимости от контекста задачи, аудитории и типа системы. Каждая нотация имеет свои strengths и применяется для разных целей.

1. UML (Unified Modeling Language)

Use Case Diagram

• Основная нотация для описания взаимодействия пользователей с системой
• Показывает actors (пользователи/системы), use cases и их связи
• Отличная для документирования функциональности на высоком уровне
• Легко понимается всеми стейкхолдерами

Плюсы:

• Стандарт, знаком всем в IT
• Визуализирует граница системы
• Показывает основные сценарии использования

Когда использую: В начале проекта для определения scope и основных фич

Activity Diagram

• Показывает последовательность действий в процессе
• Может содержать условные переходы и параллельные потоки
• Хорош для описания сложных бизнес-процессов

Плюсы:

• Отражает логику процесса и ветвления
• Показывает параллельные действия (swimlanes)
• Выявляет decision points

Когда использую: При описании workflow-ов и процессов со сложной логикой

Class Diagram (ERD — Entity-Relationship Diagram)

• Для описания структуры данных и сущностей системы
• Показывает атрибуты, методы, связи между классами
• Более детальный уровень для разработчиков

Плюсы:

• Очень полезна для обсуждения архитектуры данных
• Выявляет сложные связи между сущностями
• Служит основой для проектирования БД

Когда использую: На детальном этапе анализа для обсуждения с разработчиками

2. DFD (Data Flow Diagram)

Структура:

• Processes (процессы, обозначаются кружками)
• Data Flows (потоки данных, стрелки)
• Data Stores (хранилища данных, параллельные линии)
• External Entities (внешние системы/пользователи, прямоугольники)

Плюсы:

• Фокусируется на потоках данных через систему
• Показывает, как информация трансформируется
• Хорош для выявления интеграций
• Простая нотация, легко воспринимается

Минусы:

• Не показывает временные зависимости
• Может стать громоздкой для сложных систем

Когда использую: Для описания взаимодействия систем и потоков данных между компонентами

3. BPMN (Business Process Model and Notation)

Элементы:

• Start/End events (начало, конец процесса)
• Tasks (конкретные работы)
• Gateways (условия, развилки)
• Pools & Lanes (ответственность по ролям)

Плюсы:

• Стандарт для моделирования бизнес-процессов
• Может быть исполняемой (BPMN 2.0)
• Показывает ответственность по ролям (lanes)
• Поддерживается множеством инструментов

Минусы:

• Может быть сложна для начинающих
• Много нюансов в интерпретации

Когда использую: Для детального описания business processes, особенно с несколькими ролями

4. Swimlane Diagram (Диаграмма ответственности)

Структура:

• Горизонтальные или вертикальные полосы (lanes) по ролям
• Действия размещаются в соответствующей lane
• Стрелки показывают переходы между действиями

Плюсы:

• Наглядно показывает, кто за что отвечает
• Выявляет узкие места и задержки
• Помогает оптимизировать процессы
• Легко понимается бизнесом

Когда использую: При анализе текущих процессов и оптимизации workflow-ов

5. State Diagram (Диаграмма состояний)

Элементы:

• States (состояния системы)
• Transitions (переходы между состояниями)
• Events/Conditions (события, вызывающие переходы)

Плюсы:

• Показывает все возможные состояния объекта
• Выявляет невалидные переходы
• Хорош для описания сложных life cycles

Когда использую: Для сущностей с жёсткими состояниями (заказ, подписка, документ)

6. Sequence Diagram (Диаграмма последовательности)

Элементы:

• Actors/Objects (объекты системы, вертикальные линии)
• Messages (сообщения между объектами, стрелки)
• Sequence (порядок взаимодействия)

Плюсы:

• Показывает temporal ordering (порядок во времени)
• Выявляет сложные взаимодействия
• Хорош для описания use cases в деталях

Когда использую: При документировании сложных сценариев взаимодействия между системами

7. Матрицы и таблицы

RACI Matrix:

• R — Responsible (исполнитель)
• A — Accountable (ответственный)
• C — Consulted (согласующий)
• I — Informed (информируемый)

Когда использую: Для определения ролей и ответственности в проекте

Traceability Matrix:

• Связывает требования с тест-кейсами, фичами и багами
• Обеспечивает полноту покрытия

Когда использую: При контроле качества требований и их реализации

8. Более современные подходы

Event Storming (Штурм событий)

• Участники совместно выявляют события в системе
• Выстраивают timeline событий
• Определяют команды и их ответственность

Плюсы:

• Совместный процесс (whole team understanding)
• Выявляет скрытые требования
• Создаёт shared mental model

Когда использую: В начале проекта при работе со сложными доменами

User Journey Map

• Показывает путь пользователя через систему
• Включает touchpoints, emotions, боли и gains
• Помогает понять пользовательский опыт

Когда использую: При работе над улучшением UX и customer experience

Мой предпочитаемый подход

На практике я комбинирую нотации в зависимости от аудитории и этапа проекта:

На разговорах с бизнесом:

• Use Case Diagram (простой, визуальный)
• Swimlane Diagram (показывает ответственность)
• User Journey Map (фокус на пользователе)

На встречах с разработчиками:

• BPMN (детально и точно)
• Class/Entity Diagram (структура данных)
• Sequence Diagram (интеграции и взаимодействия)

В документации:

• DFD (потоки данных)
• State Diagram (жизненные циклы)
• Матрицы (трассируемость)

Инструменты

Для создания диаграмм я использую:

• Miro — collaborative, быстро, идейно (Event Storming)
• Lucidchart — профессиональные диаграммы
• Draw.io — бесплатный, встраивается в Confluence
• ArchiMate — для архитектурных диаграмм (в крупных проектах)
• ARIS/Enterprise Architect — для больших документирований

Главный принцип

Забываю красоту диаграмм в пользу ясности. Нотация должна быть понятна аудитории. Лучше простая правильно нарисованная диаграмма, чем сложная идеально оформленная, которую никто не поймёт.

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