L'étude fonctionnelle de cette application de gestion a été faite. Vous avez un beau cahier des charges. La spécification générale a été réalisée, vous connaissez vos cas d'utilisation sur le bout des doigts. Il est donc temps de passer à la spécification fonctionnelle détaillée, et l'un des éléments clé, quelque soit la méthodologie mise en œuvre, c'est la spécification des écrans.

1) Le papier et le crayon :

Pour mettre un peu ses idées au clair, rien de tel qu'une feuille, un crayon à papier et une gomme. Commencer par dessiner au brouillon ses IHM permet de poser ses idées.

2) L'outil pour designer ses écrans :

Une fois qu'on voit grosso modo ce que l'on souhaite faire, on peut utiliser un outil pour dessiner ses écrans en mode "fil de fer" voire pour effectuer un story board (un genre de prototype pour illustrer la navigation).

Une suite bureautique standard permet de réaliser des dessins sommaires (OpenOffice.org - http://fr.openoffice.org/) de même qu'un outil dédié à la réalisation de schémas (Visio - http://office.microsoft.com/fr-fr/visio/default.aspx). Seulement ces outils très généralistes ne sont pas les plus performants pour cette tâche spécifique.

Il est beaucoup plus efficace d'utiliser un outil dédié à la réalisation de maquettes et de prototypes d'écrans comme par exemple :
Axure RP - http://www.axure.com/.

Cet outil est plutôt fait pour les applications Web à la base, mais fait très bien son office pour les applications "lourdes" également. Il vous permettra :
- De designer vos écrans à l'aide contrôles simples et d'autres personnalisés que vous pouvez créer et réutiliser.
- De spécifier le fonctionnement de vos écrans à l'aide d'annotations personnalisables.
Par exemple, vous pouvez créer des annotations pour créer un tableau ICAR (Intention - Contrôle - Action - Réponse). Exemple :
Intention = Supprimer un billet du blog
Contrôle = Menu contextuel, Item supprimer
Action = Clic
Réponse = Ouverture d'une fenêtre de confirmation "Etes vous sur de vouloir supprimer ce billet", puis suppression du billet si bouton OK cliqué.
- De définir la navigation entre vos écrans.
- De créer un prototype navigable en HTML pour présenter la navigation entre les écrans à vos utilisateurs par exemple.
- De générer un dossier de spécification fonctionnelle détaillée des écrans au format Word par exemple, à partir d'un template personnalisable.

Axure permet donc d'industrialiser la gestion des spécifications fonctionnelles détaillées des écrans. Il permet également de réaliser des prototypes à moindre coût. Les écrans sont une excellente base pour valider des concepts au départ un peu abstrait avec des utilisateurs. Organiser une réunion de validation des écrans permet de corriger certaines erreurs en tout début de projet, ce qui coute beaucoup moins cher que lorsque tous les développements on été effectués. Bien sur les écrans ne sont que la partie visible de l'iceberg, mais je pense que pour des projets d'applications de gestion classiques, une bonne spécification de l'IHM est un élément clé de la réussite. Un outil comme Axure est une bonne assurance contre les échecs dus à des spécifications trop imprécises.