Exemple de dossier fonctionnel

Mise en situation

La compagnie fictive « Bon débarras! » vous embauche pour faire l'analyse fonctionnelle d'un site web de petites annonces. Vous avez déterminé les principales fonctions du système :

• Gestion des accès;
• Gestion du profil des membres;
• Publication des articles à vendre;
• Recherche et classification des articles;
• Communication;
• Etc.

Et pour chaque fonctionnalité, vous avez décrit les cas d'utilisation. Par exemple, la fonctionnalité «Gestion des accès » contient les cas d'utilisation :

• S'inscrire;
• S'authentifier;
• Se rappeler son code utilisateur;
• Se rappeler son mot de passe.

Le dossier fonctionnel, présenté en exemple, ne couvre que le cas d'utilisation « S'inscrire ». Selon l'approche choisie par l'organisation pour laquelle vous travaillez, le document peut avoir comme portée, la fonctionnalité au complet (avec tous ses cas d'utilisation) ou seulement un cas d'utilisation.

Structure du document

1. Page de garde
2. Table des matières
3. Historique des modifications
4. Introduction
   • Description des cas d'utilisation
   • Objectifs et besoins d'affaires
   • Portée et limitations
   • Terminologie
5. Solution
   • Processus
   • Interface utilisateur
   • Traitement
6. Références
7. Annexes

Page de garde

La page de garde doit indiquer le nom du système, la fonctionnalité et le (ou les) cas d'utilisation qui en fait partie. Si les fonctionnalités et les cas d'utilisation sont numérotés, ces numéros peuvent être affichés. Le nom de l'analyste fonctionnel ayant créé le document ainsi que la date de création et de modification peuvent être utiles.

Table des matières

Historique des modifications

Il s'agit simplement d'un journal tenu par les auteurs et réviseurs indiquant qui a fait la dernière modification, à quelle date et pour quelle raison. Cet historique peut s'avérer inutile si le fichier du document est déposé dans un portail de collaboration qui gère les versions (tel que Microsoft SharePoint, Alfresco ou autre).

Description des cas d'utilisation

Cette section décrit le ou les cas d'utilisation couverts par le dossier. Elle permet au lecteur de se situer dans l'ensemble du système. Joindre au besoin un diagramme de type use-case.

Objectifs et besoins d'affaires

En collaboration avec le client (pilote, analyste d'affaires, directeur ou autre), identifiez, sous forme de liste à point, quels sont les objectifs qui doivent être atteints par la solution expliquée dans le document. Cette liste constitue les attentes par rapport à la solution. Plus les objectifs sont clairs, moins il y a de risque de faire des oublis lors de la conception de la solution.

Portée et limitations

Dans cette section, identifiez quels seront les objectifs qui seront atteints suite à la réalisation des spécifications décrites dans le dossier versus ceux qui ne le seront pas.

Cette section peut aussi servir à indiquer ce que la fonctionnalité développée ne fera pas, même s'il ne s'agit pas d'un objectif énoncé précédemment.

Il est bien de justifier rapidement pourquoi les limitations sont là. Cette information peut être utile aux personnes qui feront l'évolution du système plusieurs mois ou années après la mise en place de la fonctionnalité.

Terminologie

Lors de la réalisation du projet, les gens qui y participent utilisent un vocabulaire pour les entités définies dans le système. Il est bien que ces entités aient une définition propre qui permet de les situer dans le contexte d'utilisation.

Aussi, dans cette section on peut ajouter des termes propres au domaine d'affaires ou des acronymes pour aider les personnes qui sont moins habituées avec le vocabulaire utilisé.

Si les termes se répètent d'un document à l'autre, il est souhaitable d'avoir un document où ils y sont tous listés. Il peut s'agir d'un lexique ou d'un modèle conceptuel.

Processus

À l'aide d'un diagramme d'activité, d'un diagramme BPMN ou d'un simple diagramme de flux (flow chart), présentez dans cette section le processus qui exprime les interactions entre l'utilisateur et le système. À la suite de ce diagramme, fournir les explications complémentaires aidant à sa compréhension.

Interface utilisateur

Si la solution comporte une interface utilisateur (Fenêtre, page Web, formulaire, interface mobile, etc.), dessinez une maquette qui indique ce que doit contenir l'interface et comment le contenu doit y être disposé.

Sous la maquette, un tableau à deux colonnes présente le détail de celle-ci. La première colonne, simple, contient l'événement utilisateur, par exemple « L'utilisateur clique sur le bouton annuler ». La seconde décrit l'action ou la série d'actions engendrée par l'événement.

La présentation de la description de l'interface varie beaucoup selon les gabarits de dossier fonctionnel utilisés. Elle va parfois de grille complexe avec la taille des champs de saisie et les noms dans le modèle de données. L'exemple présenté ici est préféré par sa simplicité et son détachement à la couche organique sous-jacente.

Dans l'exemple ci-dessus, on voit l'utilisation de référence faite à l'aide d'hyperliens. Les liens notés RF-VAL-### évitent à l'auteur de réécrire la même règle dans chaque dossier fonctionnel en faisant une référence au document de règles fonctionnelles. Les liens sur les numéros de messages (ex.:#A01) réfèrent à une charte des messages utilisés dans le logiciel.

Traitement

Au besoin, inclure au document un diagramme représentant le traitement qui doit être décrit.

Si la solution comporte un traitement sans interaction avec l'utilisateur, décrire le traitement en mentionnant :

• Son nom;
• Une courte définition;
• Ses intrants (qu'a besoin le traitement en entrée pour s'exécuter correctement);
• Ses extrants (que retourne le traitement lorsqu'il a terminé);
• Son contexte d'exécution (à la demande, en différé, etc.);
• Ses préconditions (ce qui est doit être valide avant le début du traitement);
• Ses postconditions (ce qui doit être valide après la fin du traitement);
• La description, étape par étape, de son traitement.

Parfois la section traitement est absente du dossier fonctionnel car elle est jugée trop organique.

Références

Indiquer les autres documents auxquels fait référence votre dossier fonctionnel. Par exemple :

• Le document des règles fonctionnelles;
• La liste des messages du système;
• Le document des normes graphique;
• Le modèle conceptuel;
• Le document de référence organique;
• Liste des comptes rendus d'atelier qui ont servi à la production du dossier fonctionnel.
• Toutes autres références que vous jugerez pertinentes.

Annexes

Cette section sert à joindre des informations complémentaires pertinentes au dossier fonctionnel et qui ne servent qu'à celui-ci.