Comment savoir si l'authentification est vraiment une exigence

Question

Nous avons une petite application WebApplication où les utilisateurs peuvent marquer des taches sur une carte. Nous ne authentifions pas les utilisateurs, car nous n'avons pas besoin de. Les endroits marqués ne sont pas secrets du tout, tout le monde devrait les voir et que les choses devraient être très ouvertes et transparentes pour tout le monde. Parce qu'il n'y a rien à autoriser, nous n'avons pas non plus besoin d'authentifier. Néanmoins, nous gardons quelque chose comme un profil d'utilisateur dans un cookie. Un utilisateur peut stocker des valeurs par défaut pour certains champs de ce cookie "portefeuille" afin qu'il n'a besoin que de le taper une fois.

C'est notre petite application d'anarchie;) ... Mais comme dit: c'est simple et c'est rapide et les utilisateurs comme ça.

mais:

• Il est essentiellement est un besoin de sécurité, juste pour vous assurer que le système n'est pas rempli de bêtises de personnes qui ne sont pas intéressées par l'intention de l'application. Donc, de mon point de vue, il s'agit d'une exigence non fonctionnelle (mon point de vue comme architecte système)
• également les utilisateurs (groupe d') disent qu'ils veulent "un login" pour une raison quelconque, mais ils ne peuvent en fait pas dire pourquoi

Ce que j'essaie de faire maintenant, c'est de savoir ce qu'ils veulent vraiment. Je suppose que leur exigence n'est pas "Authentification", mais quelque chose qu'ils pensent qu'un login est nécessaire. Donc, pour nos prochains sprints, j'essaie de formuler des histoires d'utilisateurs pour couvrir ces exigences et pour demander aux utilisateurs de leurs objectifs et leurs avantages.

Ma question est maintenant: a-t-il de sens d'écrire une histoire d'utilisateur comme celle-ci?

en tant qu'utilisateurs de System XY, nous voulons une authentification de l'utilisateur par connexion, afin que nous puissions être sûrs que seules les entrées sérieuses sont générées.

En d'autres termes: Comment diriez-vous la nécessité d'authentification et de la manière dont cela devrait être fait (pour garder les choses simples et ne pas fournir un obstacle pour les utilisateurs)? La "authentification" peut-elle être un objectif dans une exigence?

Quelques considérations supplémentaires sur ce numéro:

• Les utilisateurs ne veulent pas taper de mots de passe. Ils veulent une sorte de SSO
• Certains utilisateurs ont dit qu'ils veulent que tout le monde marque des taches, mais ils ne veulent pas que tout le monde les voient (afin que tout le monde soit autorisé à écrire, seuls sont autorisés à lire). C'est un but totalement nouveau dans notre application, mais je n'ai toujours pas encore bénéficié de l'avantage.
• Cela implique également, qu'il existe des utilisateurs privilégiés et qu'il est nécessaire de la gestion des utilisateurs, de l'administration de l'UIS et des groupes, etc.

Answer 1

Oui, ça a du sens.

Le problème avec des cookies simples est que si vous perdez le cookie, il n'ya aucun moyen de devenir cet utilisateur à nouveau.

Cela dit, je pense que ces histoires sont ce dont vous avez besoin (ceci incluent les points supplémentaires que vous faites):

1. En tant qu'utilisateur connecté, je souhaite devenir anonyme, un autre utilisateur du même navigateur ne sera pas identifié comme moi
2. En tant qu'utilisateur, je veux identifier en tant qu'utilisateur précédent afin que je puisse reprendre mon travail
3. En tant qu'utilisateur, je souhaite vous enregistrer en tant qu'utilisateur (Google) afin que je n'ai pas à créer de nouvelles informations d'identification
4. En tant qu'utilisateur connecté, je veux que certaines de mes taches soient privées afin que je puisse marquer des endroits, je ne veux pas que le grand public connaisse
5. [EPIC] En tant qu'utilisateur connecté, je veux pouvoir gérer mes taches

Comme vous pouvez le voir, aucune de ces histoires est normative de la façon dont vous le résolvez ou que vous suivez qui est à qui.Ils décrivent tous des problèmes réels et précieux que vos utilisateurs voudraient vouloir résoudre.