Comment appelez-vous le client d'un client dans un document de spécification, un cas d'utilisation ou un scénario?

Mon équipe et moi développons un logiciel que nos clients utiliseront pour interagir avec leurs clients. De plus, nous mangeons également nos propres aliments pour chiens et utilisons nous-mêmes le logiciel pour interagir avec nos clients.

Par conséquent, il peut parfois être difficile d'expliquer des cas d'utilisation et des scénarios, car nos employés peuvent être des opérateurs, nos clients peuvent être des opérateurs et les clients de nos clients peuvent être des visiteurs.

Cependant, nos clients peuvent également être des visiteurs en interaction avec nos employés opérateurs, les clients de nos clients peuvent être des visiteurs en interaction avec notre client ou notre employé.

Voici un modèle où:

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

Parce que parfois nos clients peuvent jouer des rôles différents, il est parfois nécessaire de se référer au rôle spécifique, opérateur ou visiteur, au lieu d'employé et de client.

C'est aussi une bouchée de dire "client du client" tout le temps.

Je me demandais comment d'autres boutiques de développement géraient ces détails sémantiques lors de l'écriture de leurs cas d'utilisation et scénarios.

• Existe-t-il des termes génériques d'un seul mot qui peuvent s'appliquer à tout produit impliquant un acteur de troisième niveau?
• Outre l'utilisation des rôles spécifiques, Opérateur et Visiteur, quels mots pourraient être utilisés pour identifier un client d'un client?

Le mot devra être suffisamment court pour être adopté au sein d'une organisation. Si elle est plus longue que quelques syllabes, sa forme raccourcie doit tout de même la différencier des autres acteurs.

pour expliquer les cas d'utilisation et les scénarios

C'est la clé: utilisez la terminologie du domaine, c'est-à-dire les noms des rôles. Qui peut jouer les rôles n'est pas important. Assurez-vous que les rôles sont bien définis (pour chaque scénario).

Il est tout à fait possible pour moi de visiter mon propre site Web et d'acheter mes propres produits. C'est idiot, mais c'est possible [mais je l'ai fait pour tester le logiciel de commerce électronique!]. Ce fait que je suis le fournisseur, hôte, auteur, webmaster, concepteur - rédacteur, programmeur, client, client, visiteur, acheteur, invité, propriétaire et employé en même temps ne modifie pas la terminologie de l'utilisation cas: « client achète le produit du propriétaire via le formulaire Web "

Pour être clair, appelez votre client en tant que clients , puis les clients de vos clients en tant que clients . Ce sera plus clair, non?

Je vous recommande de renommer les termes et de personnaliser (un peu) votre progiciel pour chacun de vos clients en fonction de leurs préférences. Certains clients peuvent souhaiter appeler leurs clients clients ou utilisateurs.

De plus, la relation est un peu drôle. Comment votre employé peut-il interagir avec les clients des clients?

La question devient donc plus simple lorsque l'on considère les rôles comme étant l'entité relative a joue un rôle par rapport à l'entité b. Votre client se considère comme un utilisateur et ses clients sont des clients pour lui. La seule personne qui se soucie de votre client en tant que client est vous. Vous avez deux rôles dans le système en tant qu'administrateur et en tant qu'utilisateur.

J'ai vu l'explication selon laquelle vous avez des employés qui interagissent avec les clients finaux via votre logiciel de chat (appelons ce rôle Agent). Pour plus de précision, l'agent se représente-t-il en tant qu'employé de votre utilisateur?

Je dirais que le rôle est toujours Agent, Utilisateur, Client. Faire référence à votre utilisateur en tant que client ne fait que confondre les choses. (Comme vous pouvez le voir).

Je l'ai eu pire ... J'ai dû travailler sur trois niveaux d'indirection. Il y avait une entité de la société qui, dans certains cas, était des utilisateurs directs de notre application. Ils avaient des comptes auxquels ils vendaient divers packages de nos offres et ils suivaient les clients pour ces comptes.

Peut-être un peu tangente mais ...

J'aime moi-même le design d'interaction, et là on n'utilise jamais de "rôles" ou d '"utilisateurs" abstraits mais quelque chose appelé "personas". Fondamentalement, vous créez un personnage avec un nom, une description et une photographie, puis vous l'utilisez dans votre processus de conception

"Bob est directeur de banque au milieu de son enfance, il a une certaine expérience en informatique mais ne les aime pas particulièrement."

Ensuite, dans votre projet, vous pouvez utiliser leurs vrais noms "Non, Bob ne le voudrait pas", "Si Bob le fait, Alice doit être notifiée d'une manière ou d'une autre". Les personas sont particulièrement utiles lorsque vous faites des scénarios.

Je recommande fortement Les détenus gèrent l'asile et About face

On m'a demandé de poster ce commentaire comme réponse, donc:

Le projet sur lequel je travaille en ce moment a des clients de clients de mon client. Le jargon du projet est que les clients de mon client sont appelés "abonnés" et leurs clients sont appelés "consommateurs". En utilisant la métaphore du marché d'Amazon, ils pourraient plutôt être des commerçants et des commerçants.

L'opérateur et le visiteur semblent assez bien définis. Pas sûr qu'il y ait une différence quand un opérateur devient un visiteur ou un visiteur devient un visiteur. À ce stade, tout le monde est un visiteur.

En fonction de ce que le logiciel est censé faire, utilisez des personnages fictifs bien connus, par exemple, Dumbledore perd toujours des connaissances sur Harry (lui enseignant des choses qu'il ne savait pas auparavant et / ou répondant à ses questions). Utilisez des personnages qui correspondent à la culture de vos développeurs. Ensuite, vous pouvez vous y référer dans les cas d'utilisation en tant que tels: lorsque A est assis sur la chaise de Dumbledore ou lorsque B joue Harry.

Si vous pensez que cela rendrait vos spécifications informelles et manquent de professionnalisme, vous devriez lire cet article de Joel et consulter son exemple de spécifications fonctionnelles.