L’énoncé est suffisamment vague pour donner  lieu à de nombreuses  interprétations. Cela est typique d’une spécification textuelle des besoins, telle qu’on en trouve dans un cahier des charges. La solution proposée ici fixe donc un certain nombre de choix d’organisation de la procédure.

On se concentre  sur la partie concernant  l’authentification  de l’utilisateur, et la création d’un compte le cas échéant.

L’organisation proposée correspond  à une interface de type « wizard » : il faut valider tous les champs d’une page, cliquer sur Suivant, pour passer à la validation des prochains champs. Si les informations sont incorrectes, un message avertit l’utilisateur et l’écran suivant s’affiche. Cette vérification des champs n’est donc pas représentée ici : il revient à l’activité de saisie de se terminer quand la saisie est validée.

Chaque activité correspond donc assez bien à un écran d’interface, les transitions exprimant une navigation possible entre ces écrans. Vous pourrez  réutiliser ces activités ailleurs. Par exemple, la modification de l’adresse de livraison est accessible depuis un menu quand l’utilisateur est connecté à son compte.

Ce niveau de description  est bien adapté à la description  d’interfaces homme-machine et permet de se concentrer sur la vision logique d’un traitement, sans se perdre dans le modèle structurel en classes.