Como você chama o cliente de um cliente em um documento de especificação, caso de uso ou cenário?

Minha equipe e eu desenvolvemos software que nossos clientes usarão para interagir com eles. Além disso, também comemos nossos próprios alimentos para cães e usamos o software para interagir com nossos clientes.

Portanto, às vezes pode ser difícil explicar casos e cenários de uso, pois nossos funcionários podem ser operadores, nossos clientes podem ser operadores e os clientes de nossos clientes podem ser visitantes.

No entanto, nossos clientes também podem ser visitantes interagindo com os funcionários de nossa operadora, os clientes de nossos clientes podem ser visitantes interagindo com nosso cliente ou funcionário.

Aqui está um modelo em que:

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

Como, às vezes, nossos clientes podem desempenhar funções diferentes, às vezes é necessário fazer referência à função específica, Operador ou Visitante, em vez de Funcionário e Cliente.

Também é um bocado dizer "cliente do cliente" o tempo todo.

Fiquei me perguntando como outras lojas de desenvolvimento lidam com esses detalhes semânticos ao escrever seus casos de uso e cenários.

• Existem termos genéricos de uma palavra que podem ser aplicados a qualquer produto que envolva um ator de terceiro nível?
• Além de usar as funções específicas Operador e Visitante, que palavras poderiam ser usadas para identificar um cliente de um cliente?

A palavra precisaria ser curta o suficiente para ser adotada dentro de uma organização. Se mais do que algumas sílabas, sua forma reduzida ainda deve diferenciá-la dos outros atores.

para explicar casos de uso e cenários

Essa é a chave: use a terminologia do domínio, ou seja, os nomes das funções. Quem pode desempenhar os papéis não é importante. Verifique se as funções estão bem definidas (para cada cenário).

É perfeitamente possível para mim visitar meu próprio site e comprar meus próprios produtos. É bobagem, mas é possível [mas eu fiz isso para testar o software de comércio eletrônico!]. O fato de eu ser o provedor, host, autor, webmaster, redator, programador, cliente, cliente, visitante, comprador, hóspede, proprietário e funcionário, tudo ao mesmo tempo , não altera a terminologia do caso de uso: "customer compra produto do proprietário via formulário da web "

Para deixar claro, chamar seu cliente como clientes , em seguida, os clientes do seu cliente como clientes . Isso tornará mais claro, não é?

Eu recomendo que você renomeie os termos e personalize seu pacote de software (um pouco) para cada cliente, dependendo da preferência deles. Alguns clientes podem querer ligar para clientes ou usuários.

Também a relação é um pouco engraçada. Como seu funcionário pode interagir com os clientes do cliente?

Portanto, a questão se torna mais simples quando pensamos em Funções como entidade relativa a desempenha um papel em relação à entidade b. Seu cliente se considera um usuário e o cliente é um cliente para ele. A única pessoa que se importa com seu cliente como cliente é você. Você tem duas funções no sistema como administrador e como usuário.

Vi a explicação de que você tem funcionários que interagem com os clientes finais por meio do seu software de bate-papo (vamos chamar essa função de agente). Para esclarecimentos, o Agente se representa como um funcionário do seu Usuário?

Eu argumentaria que o papel ainda é agente, usuário, cliente. Referir-se ao usuário como cliente apenas confunde as coisas. (Como você pode ver).

Já tive pior ... tive que trabalhar em três níveis de indireção. Havia uma entidade da empresa que, em alguns casos, era usuário direto do nosso aplicativo. Eles possuíam contas nas quais vendiam vários pacotes de nossas ofertas e rastreavam os clientes dessas contas.

Talvez um pouco de tangente, mas ...

Eu gosto muito do design de interação, e você nunca usa "papéis" ou "usuários" abstratos, mas algo chamado "personas". Basicamente, você cria um personagem com um nome, descrição e fotografia e depois o usa em seu processo de design.

"Bob é gerente de banco em seus primeiros anos, ele tem alguma experiência com computadores, mas não gosta muito deles".

Em seu projeto, você pode usar os nomes reais "Não, Bob não iria querer isso", "Se Bob fizer isso, Alice precisará ser avisada de alguma forma". Personas são especialmente úteis quando você está fazendo cenários.

Eu recomendo Os presos estão administrando asilo e Sobre o rosto

Me pediram para postar este comentário como resposta, então:

O projeto em que estou trabalhando no momento tem clientes de clientes do meu cliente. O jargão do projeto é que os clientes do meu cliente são chamados de "assinantes" e seus clientes são chamados de "consumidores". Usando a metáfora do mercado da Amazon, eles poderiam ser vendedores e compradores.

Operador e Visitante parecem bem definidos. Não tenho certeza se existe uma diferença quando um operador se torna um visitante ou um visitante se torna um visitante. Nesse ponto, todos são visitantes.

Dependendo do que o software deve usar, os personagens fictícios conhecidos, por exemplo, Dumbledore estão sempre deixando o conhecimento de Harry (ensinando coisas que ele não sabia antes e / ou respondendo suas perguntas). Use personagens que se encaixam na cultura de seus desenvolvedores. Então você pode se referir a eles nos casos de uso como tais: quando A está sentado na cadeira de Dumbledore ou quando B está interpretando Harry.

Se você acha que isso tornaria suas especificações informais e sem profissionalismo, leia este artigo de Joel e veja as especificações funcionais de exemplo dele .