Стейкхолдеры, пользователи, акторы и граница системы
Перед описанием функций нужно понять, кто имеет отношение к системе. В реальных ИС один и тот же человек может быть заинтересованным лицом, пользователем и актором, но эти понятия всё равно лучше различать.
Стейкхолдер — это лицо или организация, которые влияют на систему или зависят от её результатов. Стейкхолдер не обязан пользоваться интерфейсом. Руководитель подразделения, служба безопасности, владелец процесса, техническая поддержка, внешний регулятор или бухгалтерия могут быть стейкхолдерами, даже если они не выполняют действий в системе каждый день.
Пользователь — тот, кто непосредственно работает с системой. Он вводит данные, получает результаты, подтверждает действия, смотрит отчёты, исправляет ошибки. Пользователь обычно имеет конкретные потребности и ограничения: время, навыки, доступ, ответственность.
Актор — роль относительно системы. Это термин, который особенно важен при описании вариантов использования. Один человек может выступать в нескольких ролях: преподаватель создаёт интервалы консультаций, но как обычный пользователь может просматривать своё расписание. Одна роль может исполняться многими людьми. Внешняя система тоже может быть актором, если она обменивается данными или инициирует взаимодействие.
Различие можно показать на примере системы записи на консультации:
| Понятие | Пример | Почему это не то же самое |
|---|---|---|
| Стейкхолдер | заведующий кафедрой | заинтересован в прозрачности консультаций, но может не работать в системе |
| Пользователь | студент | непосредственно создаёт и отменяет записи |
| Актор | записывающийся участник | роль в конкретном взаимодействии с системой |
| Внешняя система | сервис единого входа | участвует в авторизации, но не является частью проектируемой системы |
Граница системы показывает, что входит в проектируемую ИС, а что остаётся снаружи. Это не только техническая граница. Внутри может находиться автоматизированная проверка правила, а ручное утверждение решения останется вне системы. Внешняя система может быть показана как участник взаимодействия, но её внутреннее устройство при этом не моделируется.
Хороший способ проверить границу — задавать вопросы:
- кто создаёт данные, а кто только получает результат;
- какие действия выполняет проектируемая система;
- какие действия остаются ручными;
- какие внешние системы участвуют в обмене;
- какие документы или события приходят извне;
- что система должна хранить, а что только отображать;
- кто отвечает за ошибки на границе взаимодействия.
Если граница не определена, требования начинают расползаться. Система записи внезапно превращается в систему управления расписанием всего университета, систему кадрового учёта и почтовый сервис одновременно. Для учебного проекта это особенно опасно: слишком широкая граница делает модель поверхностной, а слишком узкая не позволяет показать полноценную ИС.
Граница системы также помогает договариваться о внешних системах. Если авторизация выполняется через университетский сервис, проектируемая система должна знать, как запросить подтверждение личности, но не должна моделировать внутреннее устройство сервиса авторизации. Это позволяет показать интеграцию без расширения проекта до чужой зоны ответственности.