Je te fais une liste?
Oui tout ce à quoi tu penses, on fera le tri après.
Voilà ce que j'imagine : - Composer le code de carte
- Retirer de l'argent
- Sélectionner un montant
- Voir l'historique récent d'un compte
- Obtenir un RIB
- Écran d'attente
- Écran de remerciement
- Proposer un ticket
Il y en a probablement d'autres, mais je ne trouve pas d'idées.
C'est déjà un bon début. Pour les cas d'utilisation, on ne va conserver que les fonctionnalités auxquelles un utilisateur a accès, ou si tu préfères, on peut imaginer qu'un cas d'utilisation représente un bouton sur lequel l'utilisateur peut appuyer pour réaliser une action ou faire une choix. Donc les écrans d'attente ou de remerciement n'en font pas partie, ce sont des traitements du système qui n'engendrent aucun cas d'utilisation.
Donc proposer un ticket non plus, c'est le système qui propose.
Cette fonctionnalité est simplement mal formulée, il faut toujours se placer côté utilisateur pour formuler un cas d'utilisation. Effectivement c'est le système qui propose un ticket, mais l'utilisateur doit choisir s'il souhaite en avoir un ou pas.
Donc si je reformule en "Choisir avec ou sans ticket" ce serait mieux
Pas tout à fait, comme je te l'ai dit, imagine un bouton sur lequel peut appuyer l'utilisateur, penses-tu qu'un seul bouton "Choisir avec ou sans ticket" conviendrait ?
Je vois ce que tu veux dire, il faudrait donc prévoir deux cas d'utilisations qui seraient "Accepter le ticket" et "Refuser le ticket"
C'est tout à fait ça, on va les représenter. Pour commencer un diagramme de cas d'utilisation, la norme recommande un grand rectangle, avec noté en haut le titre du diagramme, et pour chaque cas d'utilisation, on note ce cas dans une bulle.
Ok ça a l'air assez simple, je commence?
Je t'en prie !
Parfait, on va pouvoir passer à la suite. J'ai terminé cette partie