L'analyse se fait généralement à partir de l'expression des besoins d'un client. Dans le cas de ce tutoriel, vous êtes votre propre client qui demande simplement de pouvoir joueur au jeu "The Hole". Cette analyse permet de répertorier des fonctionnalités, qui sont indépendantes de la façon de les coder et avec quel langage/environnement. En revanche, certaines fonctionnalités vont apparaître à cause de la façon d'utiliser l'application = scénario d'utilisation. C'est pourquoi l'analyse doit aussi fixer ces scénario, qui sont généralement illustrés par des storyboards et des maquettes lorsqu'il y a des interfaces graphiques pour "naviguer" dans l'application.
Cependant, le fait que le jeu soit en mode texte implique des façons d'interagir avec le jeu complètement différentes de celles en mode graphique. Par exemple, en mode texte, la choix du type des joueurs et le lancement d'une partie, se fera sans via des questions affichées à l'écran et des réponses au clavier. Alors qu'en mode graphique, il y aurait une une fenêtre de dialogue, avec des cases à cocher, des boutons, etc.
La phase d'analyse doit donc absolument prendre en compte cette différence afin de ne pas produire un cahier des charges irréalisable.
Pour ce tutoriel, on suppose qu'après discussion avec nous-même, on établit un seul scénario global :
- lancement de l'application => le premier paramètre de l'application (c.a.d. args[0] ) permet de sélectionner le type de partie, à savoir 2 humains, 2 ordinateurs, ou bien humain contre ordinateur.
- la partie commence directement.
- fin de partie => affichage d'un message indiquant quel est le gagnant puis le programme d'arrête.
Parallèlement, on choisit d'avoir une maquette dans le style suivant :
Le scénario d'une partie est le suivant :
- le joueur humain est le premier joueur et reçoit les pions noirs, l'ordinateur les rouges.
- lorsque c'est le tour de l'humain, il doit taper après le prompt player > un ordre de mouvement.
- cet ordre est constitué de 3 caractères : le premier désigne la valeur du pion à jouer, le deuxième est la colonne de destination, et le troisième la ligne.
- par exemple, 1A1 désigne le fait de placer le pion de vlaeur 1 dans la case A1.
- si le joueur tape un ordre invalide, un message d'erreur est affiché, puis de nouveau le prompt.
A partir de ces élément, on peut établir une liste synthétique des fonctionnalités et de sous-fonctionnalités dont elles dépendent :
- analyser args[0] pour créer les 2 joueurs,
- construire le visuel du panneau de jeu,
- demander à un joueur humain de taper un ordre,
- déterminer quelles cases sont valide pour poser un pion de valeur n,
- déplacer un pion,
- calculer un déplacement de pion (pour l'ordinateur)
- détecter la fin de partie,
- calculer le résultat de la partie.
Nous allons voir que grâce à boardifier-console, l'essentiel de ces fonctionnalités sont déjà partiellement écrites.