Позвольте мне использовать Business Actor и Business Use Case в качестве аналогии.
Бизнес-прецедент представляет собой процесс, представляющий ценность для Business Actor.
Таким образом, бизнес-сценарием для банка может быть «Обмен иностранной валюты».
Бизнес-субъект (Клиент) взаимодействует с Бизнесом (Банком), чтобы изменить £ s на $ s; -)
Разве не очевидно, что Клиент не является частью Банка? Сотрудник будет внутренним, но не клиентом.
Так что измените Business Actor на (System) Actor. И давайте предположим, что у нас есть банкомат (система), который может менять валюту. Если вы пишете сценарий использования системы, вы пишете «требования» для системы банкомата. НЕ клиент актер.
Это пользователь, а не система! Все, что вы можете сделать, это указать взаимодействие.
Теперь, что происходит с актером, это система? Как, скажем, xe.com, который дает обменные курсы?
Вопрос, который вы должны задать: «Могу ли я внести изменения в xe.com, который не является частью системы Банка? Или я просто использую API?».
В случае использования только API, xe.com является актером. Изменения на xe.com выходят за рамки ВАШЕГО проекта.
В случае изменения самого xe.com, тогда это НЕ актер, это часть вашего проекта / системы.
В этом красота актеров! Это поможет вам определить область вашей системы, которую вам разрешено изменять.
Надеюсь, это поможет.