Dans le livre «Méthodes modernes pour décrire les exigences fonctionnelles des systèmes», Alistair Coburn a décrit une méthode pour écrire une partie de l'énoncé du problème, à savoir la méthode du cas d'utilisation.
Qu'est ce que c'est Cette description de l'interaction de l'utilisateur avec le scénario du système (ou une entreprise). Le système agit en même temps comme une boîte noire (et cela permet de diviser la tâche de conception complexe en concevant l'interaction et en assurant cette interaction). Dans le même temps, des normes de notation sont introduites, ce qui garantit la facilité de lecture, y compris pour les non-participants, et vous permet de vérifier l'exhaustivité et la conformité avec les objectifs de la partie prenante.
Exemple de cas d'utilisation
A quoi ressemble le scénario, en utilisant l'exemple d'autorisation sur le site par email:
(Système) Connectez-vous au site pour accéder à votre compte personnel. ~~ (niveau de la mer)
Contexte: Un client non autorisé est autorisé sur le site afin que le site le reconnaisse et affiche des informations personnelles le concernant: historique de navigation, achats, nombre actuel de points bonus, etc., en utilisant le courrier électronique comme identifiant.
Niveau: objectif utilisateur
Acteur principal: client (visiteur de notre boutique en ligne)
Champ d'application: interaction du client avec le site Web de la boutique en ligne
Parties et intérêts intéressés:
- le marketeur souhaite que le nombre maximum de visiteurs du site soit identifié pour mieux accéder aux newsletters personnelles,
- un spécialiste de la sécurité souhaite empêcher tout accès non autorisé aux données personnelles du visiteur, y compris les tentatives de sélectionner un mot de passe pour un compte ou de rechercher un compte avec un mot de passe faible,
- un attaquant veut avoir accès aux bonus des victimes,
- les concurrents veulent laisser des commentaires négatifs sur les produits,
- le botnet veut obtenir la base de clients du magasin et utiliser l'attaque pour rendre le site inopérant.
Conditions préalables: le visiteur ne doit pas être connecté.
Garanties minimales: le visiteur découvrira le fait d'une tentative de connexion réussie ou infructueuse.
Garanties de réussite: le visiteur est autorisé.
Le scénario principal:- Les déclencheurs d'autorisation client.
- Le système confirme que le client n'est pas autorisé et ne dépasse pas le nombre de tentatives de connexion infructueuses de cette session (recherche d'un mot de passe faible pour de nombreux comptes) en vertu de la règle de sécurité n ° 23.
- Le système augmente le compteur du nombre de tentatives d'autorisation.
- Le système affiche un formulaire d'autorisation pour le client.
- Le client entre l'e-mail et le mot de passe.
- Le système confirme la présence d'un client avec un tel e-mail dans le système et le mot de passe correspond et ne dépasse pas le nombre de tentatives d'accès à ce compte conformément à la règle de sécurité n ° 24.
- Le système autorise le client, ajoute l'historique de navigation et le panier de cette session à la dernière session de ce compte client.
- Le système affiche un message de réussite d'autorisation et passe à l'étape du script à partir de laquelle le client s'est interrompu pour autorisation. Dans ce cas, les données de la page sont surchargées compte tenu des données personnelles du compte.
Extensions:2.a. Le client est déjà autorisé:
2.a.1. Le système informe le client du fait de l'autorisation effectuée plus tôt et suggère soit d'interrompre le script soit de passer à l'étape 4, tandis que si l'étape 6 a été effectuée avec succès, l'étape 7 est exécutée avec la clarification:
2.a.7. Le système désactive le client sous l'ancien compte, autorise le client sous le nouveau compte, tandis que l'historique de navigation et le panier de cette session d'interaction restent dans l'ancien compte, ne va pas dans le nouveau. Passez ensuite à l'étape 8.
nombre 2.b de tentatives de connexion a dépassé le seuil des « règles de sécurité №23»:
2.b.1 Passez à l'étape 4, le captcha est également affiché sur le formulaire d'autorisation
2.b.6 Le système confirme l'entrée correcte du captcha
2.b.6.1 Captcha saisi incorrectement:
2.b.6.1.1. le système augmente également le compteur des tentatives de connexion infructueuses pour ce compte
2.b.6.1.2. le système affiche un message d'échec et revient à l'étape 2
6.a. Aucun compte avec cet e-mail n'a été trouvé:
6.a.1 Le système affiche un message sur l'échec et offre le choix entre une transition vers l'étape 2 ou une transition vers le script «Enregistrement de l'utilisateur» avec enregistrement de l'e-mail saisi,
6.b. Le mot de passe du compte avec cet e-mail ne correspond pas à celui entré:
6.b.1 Le système augmente le compteur des tentatives infructueuses d'accès à ce compte.
6.b.2 Le système affiche un message d'échec et propose de choisir soit une transition vers le scénario «Récupération de mot de passe» ou une transition vers l'étape 2.
6.c: Le compteur de tentatives d'accès à ce compte a dépassé le seuil défini par la "règle de sécurité n ° 24".
6.v.1 Le système affiche un message sur le blocage de l'entrée du compte pendant X minutes et passe à l'étape 2.
C'est génial
Vérifie l'exhaustivité et la conformité aux objectifs, c'est-à-dire que vous pouvez confier les exigences de vérification à un autre analyste, ce qui permet de réduire le nombre d'erreurs lors de la définition de la tâche.
Travailler avec un système tel qu'une boîte noire vous permet de partager le développement et la coordination avec le client de ce qui sera automatisé à partir des méthodes de mise en œuvre.
Cela fait partie du parcours de l'analyste, l'une des principales parties de l'utilisabilité. Le script de l'utilisateur définit les principales voies de son mouvement, ce qui réduit considérablement la liberté de choix du concepteur et du client et contribue à augmenter la vitesse de développement du design.
C'est très agréable dans la description du lieu où se révèlent les exceptions de chaque étape d'interaction. Un système informatique holistique devrait prévoir l'une ou l'autre gestion des exceptions, en partie en mode manuel, en partie en automatique (comme dans l'exemple ci-dessus).
L'expérience a montré qu'une gestion des exceptions mal pensée peut facilement transformer un système en un système terriblement gênant. Je me souviens d'une histoire où à l'époque soviétique, il fallait plusieurs approbations de différents services pour prendre une décision, et ça fait mal quand le dernier service dit - et vous avez un mauvais nom ou une autre erreur de ponctuation, tout refaire et tout réconcilier.
Souvent, je rencontre des situations où une logique système qui n'a pas été pensée pour des exceptions nécessitait une modification importante de ce système. De ce fait, la part du travail des analystes du lion consacré à la gestion des exceptions.
Contrairement aux diagrammes, la notation textuelle vous permet d'identifier et de couvrir davantage d'exceptions.
Ajout à la méthode de pratique
Le cas d'utilisation n'est pas une partie de la production priorisée indépendamment, contrairement à une user story.
Dans ce scénario, considérez l'exception «6.a. Aucun compte n'a été trouvé avec cet e-mail. " et l'étape suivante "6.a.1. Le système affiche un message d'échec et passe à l'étape 2". Qu'en est-il du négatif dans les coulisses? Pour le client, tout retour équivaut au fait que tout le travail qu'il a effectué dans la saisie des données est jeté à la décharge. (Ce n'est tout simplement pas visible dans le script!) Que peut-on faire? Reconstruisez le script afin que cela ne se produise pas. Cela peut-il être fait? Vous pouvez - à titre d'exemple, consulter le script d'autorisation dans Google.
Optimisation de scénario
Le livre parle de formalisation, mais parle peu de méthodes d'optimisation pour de tels scénarios.
Mais il est possible de renforcer la méthode en optimisant les scripts, et la méthode de formalisation des cas d'utilisation le permet. Plus précisément, pour chaque exception qui se produit, vous devez y penser, déterminer la cause et reconstruire le script afin de vous débarrasser de l'exception ou de minimiser le chemin du client.
Pour commander la boutique en ligne, vous devez entrer la ville de livraison. Il se peut que le magasin de la ville client sélectionné ne peut pas livrer la marchandise, car il ne fournit pas, en raison de contraintes dimensionnelles ou en raison du manque de marchandises dans l'entrepôt concerné.
Si vous décrivez simplement le scénario d'interaction au stade de la conception, vous pouvez écrire «informer le client de l'impossibilité de livraison et proposer de changer la ville ou la composition du panier» (et de nombreux analystes débutants s'arrêtent là). Mais s'il y a beaucoup de tels cas, vous pouvez optimiser le scénario.
La première chose à faire est de ne donner que la ville où nous pouvons effectuer la livraison. Quand le faire? Avant le moment de choisir un produit sur le site (auto-détection de la ville via ip avec cahier des charges).
Deuxièmement - vous devez donner le choix uniquement des marchandises que nous pouvons livrer au client. Quand le faire? Au moment de la sélection - sur la vignette de marchandises et la fiche produit.
Ces deux modifications éliminent considérablement cette exception.
Mesures et exigences métriques
Compte tenu de la tâche de minimiser la gestion des exceptions, vous pouvez mettre la tâche sur la génération de rapports (le cas d'utilisation n'est pas décrit). Combien d'exceptions étaient, dans quels cas elles se sont produites, plus combien de scénarios ont réussi à partir de ceux entrants.
Mais hélas. L'expérience a montré que les exigences de rapport pour les scénarios dans ce formulaire ne suffisent pas, vous devez considérer les exigences de rapport pour les processus qui ne sont principalement pas décrits sous la forme d'un cas d'utilisation.
Accessibilité
Dans notre pratique, nous avons élargi la description de la description du cas d'utilisation avec la description des attributs spécifiques des entités et des données pour la prise de décision par le client, ce qui améliore l'utilisabilité ultérieure.
Pour la conception de l'utilisabilité, nous avons ajouté une section d'entrée - les données affichées.
Dans un scénario d'autorisation, il s'agit d'un fait d'autorisation client dans le système. Si le client est préautorisé, affichez un avertissement concernant le basculement de l'historique de navigation et du panier vers le nouveau compte après une autorisation réussie.
Dans le cas général, il s'agit d'une cartographie des informations nécessaires pour le client afin qu'il puisse prendre une décision sur ses actions futures selon le scénario (on peut demander si le client a suffisamment de ces données, quoi d'autre est nécessaire, quelles informations sont nécessaires pour que le client prenne des décisions).
Il est également utile de diviser les informations d'entrée dans les champs d'entrée si leur traitement se produit séparément et avec la formation de diverses exceptions.
Dans l'exemple avec l'autorisation du client, si vous mettez en surbrillance les informations saisies avec un nom d'utilisateur et un mot de passe, vous devez modifier le script d'autorisation avec les étapes distinctes pour entrer un identifiant et un mot de passe distincts (et cela se fait dans Yandex, Google, mais pas dans la plupart des magasins en ligne).
Le rendement de la conversion des données nécessaires
Les exigences relatives aux algorithmes de transformation des données peuvent également être retirées du script.
Exemples:
- Pour prendre une décision concernant l'achat d'un produit dans une boutique en ligne, un client doit connaître la possibilité, le coût, le délai de livraison de ce produit dans sa ville (qui sont calculés par l'algorithme en fonction de la disponibilité des marchandises dans les entrepôts et des paramètres de la chaîne d'approvisionnement).
- Lorsqu'une phrase est entrée dans la chaîne de recherche, le client voit les conseils de recherche par l'algorithme (qui sont formés par l'algorithme ...).
Total
En général, après avoir lu le livre, malheureusement, il n'est pas clair comment passer de l'analyste aux problèmes commerciaux aux savoirs traditionnels formalisés pour le développeur. Le livre ne raconte qu'une partie du processus avec des étapes entrantes formulées de manière imprécise et clairement présentées. En soi, le cas d'utilisation n'est le plus souvent pas une déclaration complète pour le développeur.
Néanmoins, c'est un très bon moyen de formaliser et de traiter des scénarios d'interaction d'un objet et d'un sujet, lorsque l'interaction change quelque chose dans le sujet. C'est l'une des rares méthodes d'écriture qui permettent des exigences vérifiables avec des points de recherche d'exceptions explicites.
Le livre doit être lu par les analystes afin qu'ils commencent à écrire des productions vérifiables.