Le livre décrit une méthode pour rédiger une partie d’un énoncé de problème, à savoir la méthode des cas d’utilisation.
Ce que c'est? Il s'agit d'une description du scénario d'interaction de l'utilisateur avec le système (ou avec l'entreprise). Dans ce cas, le système agit comme une boîte noire (ce qui permet de diviser la tâche de conception complexe en concevoir l'interaction et assurer cette interaction). Parallèlement, des normes de notation sont introduites, ce qui garantit une lecture aisée, y compris pour les non-participants, et permet certains contrôles d'exhaustivité et de conformité aux objectifs de la partie prenante.
Exemple de cas d'utilisation
À quoi ressemble le scénario, en prenant l'exemple d'une autorisation sur le site par email :
(Système) Connectez-vous au site Web pour accéder à votre compte personnel. ~~ (niveau de la mer)
Contexte: Un client non autorisé se connecte au site afin que le site le reconnaisse et lui affiche des informations personnelles : historique de navigation, historique d'achats, nombre actuel de points bonus, etc., en utilisant l'e-mail comme identifiant.
Niveau: objectif utilisateur
Personnage principal: client (visiteur de notre boutique en ligne)
Portée: Interaction du client avec le site Web de la boutique en ligne
Parties prenantes et intérêts :
- le marketeur souhaite que le nombre maximum de visiteurs du site soit identifié pour une plus grande couverture des mailings personnels,
- le spécialiste de la sécurité veut s'assurer qu'il n'y a aucun cas d'accès non autorisé aux données personnelles du visiteur, y compris les tentatives de deviner le mot de passe d'un compte ou de rechercher un compte avec un mot de passe faible,
- l’attaquant veut accéder aux bonus de la victime,
- les concurrents veulent laisser des avis négatifs sur les produits,
- Le botnet souhaite obtenir la clientèle du magasin et utiliser une attaque pour rendre le site inutilisable.
Conditions préalables : le visiteur ne doit pas être autorisé.
Garanties minimales : le visiteur saura si la tentative d'autorisation a réussi ou échoué.
Garanties de réussite : le visiteur est autorisé.
Scénario principal :
- Le client initie l'autorisation.
- Le système confirme que le client n'est pas autorisé et ne dépasse pas le nombre de tentatives d'autorisation infructueuses d'une session donnée (recherche d'un mot de passe faible pour plusieurs comptes) selon 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 au client.
- Le client saisit son email et son mot de passe.
- Le système confirme la présence d'un client avec un tel e-mail dans le système et que le mot de passe correspond et que le nombre de tentatives de connexion à ce compte n'est pas dépassé 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 avec la dernière session de ce compte client.
- Le système affiche un message de réussite de l'autorisation et passe à l'action de script à partir de laquelle le client a été interrompu pour autorisation. Dans ce cas, les données de la page sont rechargées en tenant compte des données du compte personnel.
Extensions :
2.a. Le client est déjà autorisé :
2.a.1. Le système informe le client du fait de l'autorisation précédemment effectuée et propose soit d'interrompre le script, soit de passer à l'étape 4, et si l'étape 6 est terminée avec succès, l'étape 7 est effectuée avec 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 et ne sont pas transférés vers le nouveau. Ensuite, passez à l'étape 8.
2.b Le nombre de tentatives d'autorisation a dépassé le seuil selon la « Règle de sécurité n° 23 » :
2.b.1 Passez à l'étape 4, un captcha s'affiche en plus sur le formulaire d'autorisation
2.b.6 Le système confirme la saisie correcte du captcha
2.b.6.1 Captcha mal saisi :
2.b.6.1.1. le système augmente également le compteur de tentatives d'autorisation 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 cette adresse e-mail n'a été trouvé :
6.a.1 Le système affiche un message d'échec et propose le choix de passer à l'étape 2 ou d'aller au scénario « Enregistrement de l'utilisateur » et d'enregistrer l'e-mail saisi,
6.b. Le mot de passe du compte avec cet email ne correspond pas à celui saisi :
6.b.1 Le système augmente le compteur de tentatives de connexion infructueuses à ce compte.
6.b.2 Le système affiche un message d'échec et propose le choix entre passer au scénario « Récupération de mot de passe » ou passer à l'étape 2.
6.c : Le compteur de tentatives de connexion pour ce compte a dépassé le seuil de la « Règle de sécurité n° 24 ».
6.c.1 Le système affiche un message concernant le blocage de la connexion au compte pendant X minutes et passe à l'étape 2.
Qu'est-ce qui est génial
Vérifie l'exhaustivité et le respect des objectifs, c'est-à-dire que vous pouvez confier des exigences à un autre analyste pour vérification, en faisant moins d'erreurs au stade de la formulation du problème.
Travailler avec un système de boîte noire permet de séparer le développement et la coordination avec le client de ce qui sera automatisé des méthodes de mise en œuvre.
Cela fait partie du parcours de l'analyste, l'un des principaux éléments de convivialité. Le scénario 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 de la conception.
Je suis très satisfait de l'endroit dans la description où les exceptions à chaque étape d'interaction sont identifiées. Un système informatique complet doit prévoir une certaine sorte de gestion des exceptions, certaines manuellement, d'autres automatiquement (comme dans l'exemple ci-dessus).
L'expérience montre qu'une gestion des exceptions mal pensée peut facilement transformer un système en un système terriblement gênant. Je me souviens de l'histoire où, à l'époque soviétique, pour obtenir une décision, vous deviez obtenir plusieurs approbations de différents services, et à quel point il est douloureux lorsque le dernier service dit - mais votre candidature porte un mauvais nom ou une autre erreur dans ponctuation, tout refaire et tout re-coordonner.
Je rencontre souvent des situations où la logique de fonctionnement d'un système qui n'a pas été pensé pour les exceptions nécessitait une refonte importante du système. Pour cette raison, la part du lion du travail de l'analyste est consacrée à la gestion des exceptions.
La notation textuelle, contrairement aux diagrammes, permet d'identifier et de couvrir davantage d'exceptions.
Ajout à la méthode de la pratique
Le cas d’utilisation n’est pas une partie indépendamment prioritaire de la déclaration, contrairement à la user story.
Dans le scénario ci-dessus, considérez l’exception « 6.a. Aucun compte avec cette adresse e-mail n'a été trouvé. et l'étape suivante « 6.a.1 Le système affiche un message d'échec et passe à l'étape 2. » Quelles choses négatives ont été laissées dans les coulisses ? Pour le client, tout retour équivaut au fait que tout le travail qu'il a effectué pour saisir des données est jeté dans une décharge. (Ce n’est tout simplement pas visible dans le script !) Que peut-on faire ? Reconstruisez le script pour que cela n'arrive pas. Est-il possible de faire cela? Vous pouvez - à titre d'exemple, consulter le script d'autorisation de Google.
Optimisation des scénarios
Le livre parle de formalisation, mais parle peu des méthodes permettant d'optimiser de tels scénarios.
Mais il est possible de renforcer la méthode en optimisant les scénarios, et la méthode de formalisation des cas d’usage permet de le faire. Plus précisément, vous devez réfléchir à chaque exception qui se produit, déterminer la cause et reconstruire le script afin de supprimer l'exception ou de minimiser le parcours client.
Lorsque vous passez une commande sur une boutique en ligne, vous devez saisir la ville de livraison. Il se peut que le magasin ne puisse pas livrer les marchandises dans la ville choisie par le client parce qu'il n'y livre pas, en raison de restrictions de taille ou en raison du manque de marchandises dans l'entrepôt correspondant.
Si l'on décrit simplement le scénario d'interaction au stade de l'inscription, on peut écrire « informer le client que la livraison est impossible et lui proposer de changer la ville ou le contenu du panier » (et de nombreux analystes novices s'arrêtent là). Mais si de tels cas sont nombreux, le scénario peut être optimisé.
La première chose que vous devez faire est de vous laisser choisir uniquement la ville où nous pouvons livrer. Quand faire ça ? Avant de sélectionner un produit sur le site Internet (autodétection de la ville via IP avec clarification).
Deuxièmement, nous devons donner le choix uniquement aux produits que nous pouvons livrer au client. Quand faire ça ? Au moment de la sélection - sur la vignette produit et la fiche produit.
Ces deux changements contribuent grandement à éliminer cette exception.
Exigences relatives aux mesures et aux métriques
Lorsque vous envisagez de minimiser la gestion des exceptions, vous pouvez définir une tâche de reporting (le cas d'utilisation n'est pas décrit). Combien d'exceptions ont eu lieu, dans quels cas elles se sont produites, et combien de scénarios entrants ont réussi.
Mais hélas. L'expérience a montré que les exigences de reporting pour les scénarios sous cette forme ne suffisent pas ; il est nécessaire de prendre en compte les exigences de reporting pour les processus qui ne sont généralement pas décrits sous la forme d'un cas d'utilisation.
Accès à la convivialité
Dans notre pratique, nous avons élargi le formulaire de description de cas d'utilisation avec une description des attributs spécifiques des entités et des données permettant au client de prendre une décision, ce qui améliore la convivialité ultérieure.
Pour la conception de la convivialité, nous avons ajouté une section de saisie - afficher les données.
Dans un scénario avec autorisation, c'est le fait que le client est autorisé 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.
En général, il s'agit d'un affichage des informations nécessaires au client afin qu'il puisse prendre une décision sur ses actions ultérieures selon le scénario (vous pouvez demander si ces données sont suffisantes pour le client, quoi d'autre est nécessaire, quelles informations le client doit prendre des décisions).
Il convient également de diviser les informations saisies en champs de saisie si elles sont traitées séparément et avec la formation de différentes exceptions.
Dans l'exemple avec autorisation client, si vous séparez les informations saisies en identifiant et mot de passe, il vaut la peine de modifier le script d'autorisation pour mettre en évidence les étapes de saisie d'un identifiant et d'un mot de passe distincts (et cela se fait dans Yandex, Google, mais ce qui n'est pas fait dans la plupart des magasins en ligne).
Atteindre les transformations de données requises
Vous pouvez également extraire les exigences relatives aux algorithmes de conversion de données à partir du script.
Exemples:
- Pour prendre la décision d'acheter un produit dans une boutique en ligne, le client doit connaître sur la fiche produit 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é du produit dans entrepôts et paramètres de la chaîne d’approvisionnement).
- Lors de la saisie d'une phrase dans la ligne de recherche, le client voit des suggestions de recherche selon l'algorithme (qui sont générées par l'algorithme...).
En tout
En général, après avoir lu le livre, malheureusement, il n'est pas clair comment passer d'un analyste aux problèmes commerciaux à une spécification technique formalisée pour un développeur. Le livre ne raconte qu'une partie du processus, les étapes de saisie étant peu claires et les étapes suivantes peu claires. Le cas d’utilisation lui-même ne constitue 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 entre un objet et un sujet, lorsque l'interaction provoque un changement dans quelque chose chez le sujet. C'est l'une des rares méthodes d'écriture qui permet des exigences vérifiables avec des points de recherche d'exception explicites.
Le livre est une lecture incontournable pour les analystes qui souhaitent commencer à écrire des pièces testables.
Source: habr.com