1 - Objet et domaine d’application

Ce guide donne des recommandations pour produire un dossier d'étude détaillée. Il est destiné à l'équipe de spécification (équipe projet DSI) qui est chargée de produire un dossier d’étude détaillée lors de l’étape "étude détaillée" dans la phase de développement ou de maintenance/évolution d’un système d’information.
Il présente également des règles de représentation, de description des enchaînements d'écrans d'une application ou d'une évolution et l'outil support proposé (logiciel Visio).
Enfin, une liste de questions pouvant aider à relire et vérifier une étude détaillée est fournie en annexe du présent document.

• Plans types : plan-type-etude-detaillee
                      plan-type-enchaînement-écran
  

3 - Abréviations et terminologie

Cf glossaire " Conduite de projet Systèmes d’information "

4.1 - Etude détaillée

L'étude détaillée vise l'exhaustivité de la description de la solution. Les spécifications détaillées sont la traduction précise des besoins fonctionnels, techniques et organisationnels exprimés par la maîtrise d'ouvrage ou les utilisateurs, en termes de :

• traitements à proposer aux utilisateurs de l'application,
• données à gérer par l'application,
• interface utilisateurs : écrans, états, enchaînement d'écrans,
• contraintes de sécurité et techniques.

Une fois le dossier d'étude détaillée validé par la maîtrise d'ouvrage, il constitue le cahier des charges pour la production ou la maintenance d'une application. En cas de modifications ou d'évolutions du cahier des charges durant la phase d'élaboration de l'étude détaillée, il est important de veiller à ce qu'il soit maintenu à jour.

 4.2 - Description des enchaînements d'écrans

Lors de la spécification fonctionnelle de l'interface homme-machine d'une application, il est nécessaire de décrire les écrans (ergonomie de surface) ainsi que les enchaînements d'écrans (dialogue). Ce paragraphe présente le formalisme à utiliser ainsi que l'outil support utilisé (logiciel Visio). Il permet de représenter l'aspect dynamique de l'interface homme-machine en fonction des écrans prévus, des actions possibles de l'utilisateur et des "décisions" prises par l'application.

La liste des écrans et des enchaînements d'écran, avec pour chacun une référence et un nom, figure dans le document "étude détaillée" (Cf. contenu type d'une étude détaillée § 5.1 du présent document).

• Liste des enchaînements d'écrans :

• Liste des écrans :

Dans la suite du paragraphe, on utilisera la terminologie suivante :

4.2.1 - Formalisme

Les concepts représentés dans un diagramme d'enchaînement d'écrans sont les suivants :

Les conventions d'écriture des noms de ces concepts sont celles utilisées dans les documentations utilisateur des produits DSI. Voir le document :

Chaque diagramme contient la référence de l'enchaînement d'écran en conformité avec la liste définie dans le document "étude détaillée".
Le diagramme se lit de haut en bas et de gauche à droite selon l'ordre logique de navigation de l'utilisateur.

• Ecran (fenêtre)

L'écran (fenêtre) est représenté par un rectangle arrondi contenant le type d'écran et la référence de l'écran, écrits en texte normal.
Les types d'écran possibles sont :

• Actions utilisateur

Les actions utilisateur sont représentées par des noms sur ou à côté des flèches qui relient un écran à un autre.
Si plusieurs actions différentes permettent d'obtenir le même écran, il y aura autant de flèches que d'actions.

- Cliquer sur un bouton d'action
L'action utilisateur de "cliquer sur un bouton d'action" est représentée par le nom du bouton ou de l'icône, écrit entre <signe sup. et signe inf.>

Exemple : <Ajouter>

Les boutons d'action qui ont une action sur le même écran ne sont pas représentés dans les diagrammes.

Par exemple : les boutons <Précédent> et <Suivant> qui permettent de visualiser les informations de la donnée qui précède ou qui suit la donnée affichée parmi une liste de données.

Certains boutons "standards" ne sont pas représentés dans les diagrammes car leur comportement est le même quel que soit l'écran où ils apparaissent, par exemple :

Ces conventions doivent apparaître dans les normes d'ergonomie du projet.

 

- Sélectionner un menu et une option de menu
L'action utilisateur de "sélectionner une option d'un menu" est représentée par le nom du menu et de l'option, en gras italique, séparés par des / sans espace ni avant ni après le /.

Exemple : Fichier/Ouvrir

- Taper sur une touche système
L'action utilisateur de "taper sur une touche clavier" est représentée par le nom de la touche respectant la normalisation décrite dans le document : " guide-documentation-utilisateur ".

Exemple : Ctrl + M, Alt + P, Tab + ?, Pomme + P

Les raccourcis clavier qui sont équivalents à des clics de boutons ou à des sélections d'option de menus n'ont pas besoin d'être représentés. Ils doivent être décrits dans les normes d'ergonomie du projet.

• Action système

L'action système à effectuer après une action utilisateur est représentée par un ovale contenant l'interrogation qui conditionne le passage à tel ou tel autre écran. Les réponses à l'interrogation (par exemple : oui, non) apparaissent ensuite sur les flèches qui partent de cette action système.

Exemple de formalisme:

4.2.2 - Outil support

Pour réaliser ces enchaînements d'écran, il est recommandé d'utiliser le logiciel Visio. Très simple d'utilisation, il apporte un support au niveau graphique.
Pour obtenir le formalisme défini, il suffit de choisir le modèle "enchaînement d'écrans" dans Visio. Pour cela :

• ouvrez le logiciel Visio ;
• dans la fenêtre qui apparaît, sélectionnez le modèle "enchaînement-écran" qui se trouve dans : 'buzet' > Infos > Bqsd > Conduite-projet > Visio ;

La palette d'outil dont on dispose ensuite est la suivante :

Pour créer votre enchaînement d'écran, il suffit de faire glisser la forme désirée dans la page de dessin.

5.1 - Etude détaillée

Ce chapitre présente le contenu que l'on doit trouver dans chaque paragraphe du document "Etude détaillée".

1.1 Présentation générale de l'application

Ce paragraphe a pour but de présenter de manière générale l'ensemble de l'application.

• Dans le cas d'une étude détaillée pour une évolution :

Il s'agit de présenter de manière générale la demande d’évolution : ce qu’elle doit traiter, l’évolution du besoin utilisateur,... et de rappeler les principales fonctionnalités couvertes.
Il est également important d'indiquer si le dossier de spécification des évolutions concerne une nouvelle fonction (ou de nouvelles fonctionnalités) du système d’information ou si elle modifie une fonction existante.

Pour avoir une meilleure vision de l'évolution, les modules concernés sont regroupés dans un tableau :

Dans le cas d’une modification, les pages modifiées montreront aussi nettement que possible les évolutions par rapport à la version précédente : utilisation de l'option Révision de Word (marque de révision dans la marge).

Lors de la spécification d’une modification, le dossier de spécification des évolutions contiendra à minima le descriptif des opérations modifiées, la vue du MLD couvrant ces opérations, les écrans et les états modifiés de ces opérations. Cela veut dire que le dossier de spécification des évolutions ne contiendra pas obligatoirement une description des modules si ceux-ci ne sont pas directement concernés par la modification.

1.2 Description des principales fonctions

Ce paragraphe décrit les principales fonctionnalités de l'application.

2.1 Acteurs concernés
Identifier ici l'ensemble des acteurs impliqués. Un acteur est une entité organisationnelle identifiable par les missions qu’il remplit au sein du champ d’étude (acteur interne) ou à l’extérieur de celui-ci (acteur externe). Les acteurs sont organisés en postes de travail.

2.2 Principes d’organisation et de gestion
Décrire les principes d'organisation et de gestion mis en place.

2.3 Description des procédures
Une procédure est une suite de tâches exécutées par un ensemble d’acteurs et concourant au même but.
Une tâche est un ensemble logique de travaux exécutés par un poste de travail. Une tâche peut être de type temps différé (TD), temps réel (TR) ou manuel (MA).
L’enchaînement des tâches de la procédure est présenté sous la forme graphique (style MOT).
Chaque tâche est décrite par les conditions de son déclenchement, l’acteur, les travaux réalisés, les résultats produits, et le temps (durée, fréquence).

3. Description du module #nom-module#
Un module regroupe un ensemble d'opérations implémentées dans le logiciel.

3.1.1 Historique du module
Mentionner les différentes versions du module et décrire pour chacune d'elles les modifications par rapport à l'ancienne version.

3.1.2 Présentation générale du module
Faire une présentation rapide du module.

3.1.3 Habilitations
Définir ici les règles d'habilitations pour le module (droits d'accès, confidentialité…).

3.1.4 Liste des opérations
Donner dans ce paragraphe la liste des opérations du module en complétant le tableau ci-dessous. Une opération est un ensemble de traitements automatisés (temps différé ou temps réel) : création, mise à jour, annulation, consultation, édition, calcul... ou manuels.

TR = Temps Réel TD = Temps Différé MA = Manuel

Préciser éventuellement si Obligatoire ou Facultatif.

3.1.5 Références Entrées/sorties
Cette partie a pour but de décrire la liste des enchaînements d'écrans, la liste des écrans ainsi que la liste des états.

3.1.5.1 Liste des enchaînements d'écrans
Utiliser le tableau ci-dessous pour donner la liste des enchaînements d'écran.

3.1.5.2 Liste des écrans
Utiliser le tableau ci-dessous pour donner la liste des écrans.

3.1.5.3 Liste des Etats
Utiliser le tableau ci-dessous pour donner la liste des états.

3.1.6 Orientations techniques et contraintes.
Décrire dans ce paragraphe les orientations techniques et les contraintes du module considéré en terme de performance, sécurité…

3.1.7 Impacts sur la version courante
Il s'agit de donner ici la liste des modules à modifier.
Décrire les impacts sur la version courante pour chaque opération du module.

3.2.1 Présentation générale
Faire un texte introductif présentant d'une manière générale l'opération.

3.2.2 Références données

3.2.3 Description des tâches
Décrire l'ensemble des tâches effectuées par l'opération considérée à l'aide du tableau ci-dessous.

Type tâche : A = Affichage C = Contrôle E = Edition

M = mise à jour T = Traitement S = Saisie

Type erreur : A = Avertissement E = Erreur bloquante

3.2.4 Conditions d'exécution
Ce paragraphe permet de décrire les conditions d'exécution de l'opération (événements déclencheurs, états de données...).

3.2.5 Restriction d’habilitation
Décrire ici les restrictions par rapport aux acteurs indiqués dans le module.

3.2.6 Interfaces
Préciser dans ce paragraphe s'il existe des interfaces avec d’autres modules, d'autres applications ou d’autres systèmes d’information.

4. Description des données
Référencer ici le Modèle Relationnel de Données (modèle MRD) de l'application.
L'outil de modélisation SILVERRUN doit être utiliser pour réaliser le modèle MRD de l'application. Des recommandations sur l'utilisation du module MRD de SILVERRUN sont disponibles dans le guide méthodologique " Utilisation de SILVERRUN à la DSI ".

5.1 Enchaînements d'écrans
Insérer ici le diagramme d'enchaînements d'écrans. Pour réaliser ce diagramme, il est recommandé d'utiliser le logiciel Visio. Un plan type avec le formalisme à respecter est disponible (Cf. plan type "enchaînement-écran").Une fois le schéma réalisé sous Visio, utiliser l'option Insertion/Objet…/Créer d'après le fichier pour insérer le schéma dans le document Word (cocher la case Lier au fichier afin de pouvoir modifier le schéma ultérieurement en cliquant dessus à partir du document Word).

5.2 Ecrans
Les écrans seront présentés sous la forme d’une maquette écran.

5.3.2 Maquette

5.3.3 Contenu détaillé
Décrire dans ce paragraphe les liens entre les champs de la maquette et les données.

5.3.4 Champs calculés
Il s'agit de décrire ici le mode de calcul, la concaténation de champs, les valeurs forcées, etc...

5.3.5 Support d’impression
Préciser ici le support d'impression : écran ou imprimante.

5.3.6 Algorithme de construction

Définir ici :

6 - Annexe : Liste de vérification d'une étude détaillée

La liste ci dessous fournis un ensemble de questions qui peuvent aider à relire des documents d'étude détaillée.