Моя команда и я разрабатываем программное обеспечение, которое наши клиенты будут использовать для взаимодействия со своими клиентами. Кроме того, мы также едим нашу собачью еду и сами используем программное обеспечение для взаимодействия с нашими клиентами.
Поэтому иногда бывает сложно объяснить варианты использования и сценарии, поскольку наши сотрудники могут быть операторами, наши клиенты могут быть операторами, а клиенты наших клиентов могут быть посетителями.
Однако наши клиенты также могут быть посетителями, взаимодействующими с сотрудниками нашего оператора, клиенты наших клиентов могут быть посетителями, взаимодействующими с нашим клиентом или нашим сотрудником.
Вот модель, где:
A is an employee
B is a customer
C is our customers' customer
X interacts with Y
Operator --> Visitor
A --> B
A --> C
B --> C
Поскольку иногда наши клиенты могут играть разные роли, иногда необходимо сослаться на конкретную роль, оператора или посетителя, а не на сотрудника и клиента.
Также все время говорить «клиент клиента».
Мне было интересно, как другие магазины разработки обрабатывают эти семантические детали при написании своих сценариев использования и сценариев.
- Существуют ли какие-либо общие слова, которые могут применяться к любому продукту, в котором участвует актер третьего уровня?
- Какие слова можно использовать, кроме использования определенных ролей, Оператор и Посетитель, для идентификации клиента клиента?
Слово должно быть достаточно коротким, чтобы быть принятым в организации. Если он длиннее пары слогов, его сокращенная форма все равно должна отличать его от других актеров.
источник
Ответы:
Это ключ: используйте терминологию домена, то есть имена ролей. Кто может играть роли, не важно. Убедитесь, что роли четко определены (для каждого сценария).
Для меня вполне возможно посетить мой собственный веб-сайт и купить мои собственные продукты. Это глупо, но это возможно [но я сделал это, чтобы протестировать программное обеспечение электронной коммерции!]. Тот факт, что я являюсь провайдером, хостом, автором, веб-мастером, копирайтером, программистом, клиентом, клиентом, посетителем, покупателем, гостем, владельцем и сотрудником одновременно , не меняет терминологию варианта использования: «клиент покупает товар у владельца через веб-форму
источник
Чтобы было понятно, называйте своих клиентов как клиентов , а затем клиентов своих клиентов как клиентов . Это сделает это яснее, не так ли?
Я рекомендую вам переименовать условия и настроить свой программный пакет (немного) для каждого из ваших клиентов в зависимости от их предпочтений. Некоторые клиенты могут хотеть называть своих клиентов клиентами или пользователями.
Также отношение немного смешно. Как ваш сотрудник может взаимодействовать с клиентами клиента?
источник
Таким образом, вопрос становится проще, если думать о ролях как об относительной сущности а, выполняющей роль по отношению к сущности б. Ваш Клиент считает себя Пользователем, а его Клиент - Клиентом для них. Единственный человек, который заботится о вашем Клиенте как о Клиенте, это вы. У вас есть две роли в системе как администратор и как пользователь.
Я видел объяснение, что у вас есть Сотрудники, которые взаимодействуют с Конечными клиентами через ваше программное обеспечение для чата (назовем эту роль Агентом). Для пояснения, Агент выступает в качестве сотрудника вашего Пользователя?
Я бы сказал, что роль по-прежнему агент, пользователь, клиент. Обращение к вашему Пользователю как к клиенту просто сбивает с толку. (Как вы видете).
У меня было хуже ... Мне пришлось работать на трех уровнях косвенности. Существовала компания, которая в некоторых случаях была непосредственным пользователем нашего приложения. У них были Аккаунты, которым они продавали различные пакеты из наших предложений, и они отслеживали Клиентов для этих Аккаунтов.
источник
Может быть, немного касательно, но ...
Я сам увлекаюсь интерактивным дизайном, и там вы никогда не используете абстрактные «роли» или «пользователи», а то, что называется «персонами». По сути, вы создаете персонажа с именем, описанием и фотографией, а затем используете его в процессе проектирования.
«Боб - менеджер банка в среднем возрасте, у него есть некоторый опыт работы с компьютером, но он его не особенно любит».
Тогда в вашем проекте вы можете использовать их настоящие имена: «Нет, Боб этого не хочет», «Если Боб сделает это, Алису нужно как-то уведомить». Персонажи особенно полезны, когда вы делаете сценарии.
Я очень рекомендую, чтобы заключенные управляли убежищем и о лице
источник
Меня попросили опубликовать этот комментарий в качестве ответа, поэтому:
В проекте, над которым я сейчас работаю, есть клиенты клиентов моего клиента. Жаргон проекта заключается в том, что клиенты моего клиента называются «подписчиками», а их клиенты - «потребителями». Используя метафору рынка Amazon, они могли бы стать владельцами и покупателями.
источник
Оператор и Посетитель кажутся довольно четко определенными. Не уверен, что есть разница, когда оператор становится Посетителем или Посетитель становится Посетителем. В этот момент каждый посетитель.
источник
В зависимости от того, для чего предназначено программное обеспечение, используются известные вымышленные персонажи, например, Дамблдор всегда бросает знания о Гарри (обучая его вещам, которых он не знал раньше, и / или отвечая на его вопросы). Используйте персонажей, которые соответствуют культуре ваших разработчиков. Тогда вы можете ссылаться на них в случаях использования как таковых: когда А сидит на стуле Дамблдора или когда Б играет Гарри.
Если вы думаете, что это приведет к тому, что ваши спецификации станут неформальными и вам не хватит профессионализма, вам следует прочитать эту статью Джоэла и взглянуть на пример его функциональных спецификаций.
источник