L'objectif de cette phase est triple :
- procéder à un examen critique de l'existant afin de faire ressortir les principaux dysfonctionnements,
- rechercher les cas d'utilisation permettant de traduire les résultats obtenus lors de la phase d'investigation en des termes mieux adaptés à leur informatisation,
- proposer à l’équipe dirigeante plusieurs niveaux de solutions accompagnés d'une évaluation de coût et de gain afin de mettre en évidence un éventuellement retour sur investissements (étude d'opportunité).
Examen critique
Dans beaucoup de cas, la mise en place d'une application informatique consiste en une reprise totale ou partielle d'un système déjà existant. Le logiciel à développer doit soit automatiser une organisation entièrement manuelle, soit faire évoluer un système déjà informatisé en lui rajoutant éventuellement de nouvelles fonctionnalités. Dans tous les cas il est quasiment certain que le système existant possède un certain nombre de défauts et de points de dysfonctionnement qui devront disparaître ou du moins être atténués dans le nouveau logiciel. C'est d'ailleurs bien souvent l'une des raisons essentielles du lancement du projet.
Une critique ne peut être constructive que si elle s'appuie sur des critères objectifs de comparaison. En matière de système d'information les critères sont au nombre de huit et portent essentiellement sur la qualité des informations utilisées. Les huit critères de qualité d'une information et les causes de dysfonctionnement d'un système d'information sont décrits ici.
Spécification des besoins
Le CCU (Cahier des Charges Utilisateur) est rédigé dans un langage lié au métier des utilisateurs, il s'avère maintenant nécessaire de présenter les informations recueillies dans un langage plus proche des informaticiens. Le moyen qui permet de réaliser ce passage est le cas d'utilisation (Use Case ou UC en abrégé). Rappelons ce qu'est un cas d'utilisation.
Un cas d'utilisation est la description d'une classe de séquences d'actions (scénarios) que le système doit exécuter pour produire un résultat observable par un acteur. Chaque scénario représente à un instant donné les interactions qui se produisent entre l'acteur et le système à informatiser
Le principal travail à réaliser dans cette étape est donc de trouver tous les UC possibles se dissimulant derrière les propos des utilisateurs. Certains UC seront obtenus en étudiant l'existant, d'autres seront déduits des nouveaux besoins, d'autres enfin pourront être rajoutés afin d'assurer la cohérence de l'ensemble.
Exemple :
Dans l'organisation existante, un employé enregistre les commandes des clients au fur et à mesure de leur arrivée afin qu'elles soient facturées le soir même. Cette activité se traduira par un UC de saisie des commandes.
Profitant de la réalisation du logiciel, l'utilisateur souhaite obtenir un récapitulatif des commandes arrivées depuis une date précise (à défaut depuis le début de l'année). Ceci produira un deuxième UC correspondant à un cas qui n'existait pas jusqu'à ce jour.
Afin de pouvoir réaliser cette nouvelle tâche il faudra rajouter un UC permettant d'archiver les commandes reçues qui démarrera après la saisie d'une commande.
Si un DCT a été réalisé on pourra l'utiliser afin de faire apparaître les tâches automatisables. Les tâches non automatisables sont celles qui sont purement intellectuelles (prise de décision non programmable non structurée) ou entièrement manuelles portant sur des objets concrets non informationnels. A chaque tâche automatisable on fera correspondre un UC.
L'utilisation du DCT permet également de mettre en évidence les divers types d'acteurs qui interviendront dans le processus : acteurs externes, principaux et administrateurs.
Chaque UC sera décrit avec un niveau de détail compatible avec l'état d'avancement du projet, c'est-à-dire bien souvent de façon assez grossière à ce niveau. La description d'un UC peut être faite en utilisant un diagramme d'activités ou une simple explication textuelle. On peut également représenter certains scénarios caractéristiques du cas d'utilisation par un diagramme d'interactions.
On procèdera à une codification des UC sous la forme : UC99 (UC01, UC02…) de façon à faciliter leur identification par la suite. Il est également recommandé d'attribuer un nom unique et court pour désigner chaque UC.
A partir de toutes ces informations on construit le diagramme des cas d'utilisation (DCT).
Dans toute la suite du projet, les cas d'utilisation (UC) seront et resteront l'unique moyen de communication entre les utilisateurs et les informaticiens. Ils permettront notamment d'assurer la traçabilité des évolutions (corrections et modifications) apportées au logiciel.
