Лица, связанные с системой, и её границы

Стейкхолдеры, пользователи и акторы

Перед моделированием функциональной архитектуры (и созданием диаграммы использования) нужно аккуратно разделить три похожих, но разных понятия.

Стейкхолдер — любое лицо или организация, заинтересованные в системе или затронутые её результатами. Стейкхолдер может вообще не работать с системой напрямую: например, руководитель, владелец процесса, служба безопасности, регулятор.

Пользователь — человек, который непосредственно работает с системой. Пользователь может выполнять несколько ролей.

Актор — роль относительно системы на диаграмме использования. Актором может быть не только человек, но и внешняя система, устройство или организация, если они взаимодействуют с системой как внешняя сущность.

Разница между этими понятиями особенно заметна на простом примере. В системе записи к врачу пациент является пользователем, если сам работает с приложением, и актором, если инициирует запись, отмену или просмотр результатов. Главный врач может быть стейкхолдером, потому что ему важна загрузка кабинетов и соблюдение регламентов, но он может не быть пользователем конкретной системы. Медицинская информационная система клиники может быть актором, если проектируемая система передаёт ей данные о записи или получает из неё расписание врачей.

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

Из этого следуют практические правила:

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

Акторов лучше называть по роли, а не по должности или имени конкретного человека. Роль “Менеджер” обычно слишком широкая, если непонятно, что именно он делает в системе. Роль “Оператор склада” или “Модератор заявки” точнее, потому что сразу показывает область ответственности.

Граница системы как аналитическое решение

Граница системы показывает, что входит в проектируемую ИС, а что остаётся внешним. Это не просто рамка на диаграмме использования, а проектное решение.

При определении границы нужно явно указать:

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

Если граница не определена, диаграмма использования начинает смешивать действия пользователя, внутренние функции, процессы другой системы и организационные регламенты.

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

Типичная ошибка — помещать внутрь границы всё, что упоминается в предметной области. Но граница системы не равна границе предметной области. Предметная область может включать людей, документы, регламенты, внешние организации и старые системы, а проектируемая ИС автоматизирует только часть этой реальности.

Хорошая проверка границы формулируется так: если элемент внутри границы, мы проектируем его поведение и несём ответственность за его функции. Если элемент снаружи, мы описываем только взаимодействие с ним и ожидания к этому взаимодействию.