Dossier de Spécifications Détaillées Fonctionnelles et · PDF...
Transcript of Dossier de Spécifications Détaillées Fonctionnelles et · PDF...
Dossier de
Spécifications Détaillées
Fonctionnelles et Techniques
Projet Appli-Frais
Auteurs
Alexandre Papeil – Développeur
Clément Garcia – Développeur
Romain Lanos - Développeur
SUIVI DU DOCUMENT
Mises à
jour
Version Date Auteurs Objet de la mise à jour
1.0 21/11/13 Alexandre, Romain,
Clément
1.1 05/12/13 Alexandre, Romain,
Clément
Cas d’utilisation et test de jeu associé
Liste de diffusion
Corinne LEJOSNE V
Catherine BARANGER V
A = Application, O = Observations, I = Information – diffusion, V = Validation
Table des matières
Introduction
Objet du document
Domaine d’application
Cadre du projet
Enjeux et objectifs
Périmètre fonctionnel
Cadre technique
Spécifications fonctionnelles
Description générale
Gestion de la sécurité
Charte graphique
Les fonctionnalités
3.4.1 lancement de l’application
3.4.2 L’option Fichier
3.4.3 Consultation de tous les visiteurs
3.4.4 Consultation de tous les praticiens
3.4.5 Consultation d’un praticien
3.4.6 Consultation d’un visiteur
Le modèle des données
Spécifications Techniques
Environnement
Exigence de programmation
Déploiement de l’application
Sécurité
Organisation du projet
Planning prévisionnel
Glossaire
1. Introduction
1.1. O
bjet du document
L’objet de ce document est de définir les spécifications détaillées fonctionnelles et techniques de
l’application Projet Appli-Frais
Les spécifications fonctionnelles détaillées ont pour but de décrire précisément :
● L’ensemble des fonctionnalités de l’application.
● Les objets manipulés, leurs buts et leurs principes de fonctionnement.
● Les écrans utilisateurs mettant en œuvre les fonctionnalités de l’application.
● Le but, le type et le caractère obligatoire de chacun des champs présents sur les écrans de
saisie, ainsi que les actions possibles à partir des écrans.
Toutes les fonctionnalités prévues lors de la phase de conception sont précisées dans ce document en
indiquant l’implémentation de ces fonctionnalités dans l’application.
Les spécifications techniques détaillées présentent tous les aspects techniques utiles au projet, comme
les contraintes matérielles, logicielles et humaines.
Elles ont pour but de décrire précisément :
● Les environnements matériel et logiciel
● La mise en œuvre de l’application
● Les exigences de programmation
● Le déploiement de l’application
● Les éléments de sécurité mis en place
● Les jeux de tests effectués
● L’organisation du projet
1.2. D
omaine d’application Ce dossier de spécifications détaillées fonctionnelles et techniques est applicable pendant la phase de
développement de l’application Projet Appli-Frais
Le fonctionnement de l’application sera conforme aux éléments présents dans ce dossier.
2. Cadre du projet
2.1.
Enjeux et objectifs
Description général du projet : Contexte, besoins, objectifs
Contexte : Ce projet se place au sein du laboratoire Galaxy Swiss Bourdin (GSB) fruit de la fusion du
géant américain Galaxy et du conglomérat européen Swiss Bourdin.
Il s’opérera au sein du service informatique du siège parisien.
Besoins : La réalisation d’une classe technique permettant la connexion a la base de données et de
procédures stockées permettant l’exécution des requêtes.
Objectifs : Le développement d’une application accessible depuis un ordinateur windows. Permettant
la centralisation des comptes rendus de visite présentée par les praticiens et donnant une vision
individuelle et synthétique de l’activité de représentation.
2.2. P
érimètre fonctionnel
Présentation générale de l'ensemble des fonctionnalités du projet, regroupées au besoin par thème. On
peut y trouver un diagramme des cas d'utilisation.
2.3. C
adre technique
Pour réaliser ce projet, on a besoin de plusieurs outils
- L’application sera développée en C# avec l’IDE Visual .NET 2010
- Un outil pour gérer le temps du projet comme MS Project
- Un outil de base de données comme SQL Server 2008 R2
- Un outil de dessin comme Microsoft Visio 2010
3. Spécifications fonctionnelles
3.1. D
escription générale
On peut trouver dans cette partie, deux sous-parties :
● Un schéma des différents modules du projet ou le diagramme général des cas d’utilisation
● Les principes ergonomiques de l'application (Taille des écrans, défilement, accès aux
formulaires, repérage des champs obligatoires, principe des recherches, gestion des demandes
de suppression, présentation des erreurs, ...etc)
L’ergonomie de l’application est libre. Le logo doit apparaître dans chaque formulaire.
3.2. G
estion de la sécurité
3.3. C
harte graphique
L’ergonomie de l’application est libre. Le logo doit apparaître dans chaque formulaire.
3.4. L
es fonctionnalités Cette partie détaille toutes les fonctionnalités du projet avec pour chaque fonctionnalité les sous-
parties suivantes :
3.4.1 lancement de l’application
Son cas d’utilisation :
Nom cas d’utilisation : Lancement de l’application
Acteur déclencheur : Un utilisateur
Pré conditions : Néant
Post conditions :
Scénario nominal :
Le système affiche le menu principal
Exceptions :
Contraintes :
Le menu principal doit être un formulaire MDI parent (application d'interface
multidocument (MDI, Multiple Document Interface).
Il contiendra tous les autres les fenêtres MDI enfants, c'est-à-dire les sous-fenêtres dans
lesquelles l'utilisateur interagit avec l'application MDI.
Il contiendra les options suivantes :
· Fichier
· Visiteurs
· Praticiens
· Médicaments
· Comptes-Rendus
Le choix de l’interface est libre.
Son jeu de test associée :
N° Scénario et
exceptions
Action Attendu Obtenu
1 Lancement de l’application Affichage du Menu Principal
3.4.2 L’option Fichier
Son cas d’utilisation :
Nom cas d’utilisation : L’option Fichier
Acteur déclencheur : Un utilisateur
Pré conditions : Néant
Post conditions : Néant
Scénario nominal :
1. L'utilisateur choisit cette option
2. Le système affiche une sous-option Quitter qui ferme l’application
Exceptions :
Contraintes :
Son jeu de test associée :
N° Scénario et Action Attendu Obtenu
exceptions
1 L’utilisateur clique sur Fichier
dans le menu du haut.
Un menu déroulant s’affiche et
propose l’option “Quitter”.
2 L’utilisateur clique sur l’option
quitter.
L’application se ferme.
3.4.3 Consultation de tous les visiteurs
Son cas d’utilisation :
Nom cas d’utilisation : Consultation de tous les visiteurs
Acteur déclencheur : Un utilisateur
Pré conditions : Néant
Post conditions : Néant
Scénario nominal :
1. L'utilisateur demande à consulter la liste des visiteurs dans l’option Consultation du module
Gestion des visiteurs
2. Le système affiche la liste des visiteurs avec pour chacun son numéro, ses nom et prénom
ainsi que le nom du laboratoire pour lequel il travaille
Exceptions :
Contraintes :
Son jeu de test associée :
N° Scénario et
exceptions
Action Attendu Obtenu
1 On clique sur le lien menant à la
page de consultation du module
Gestion des visiteurs
La liste des visiteurs contenant
pour chacun son numéro, ses
nom et prénom et le nom du
laboratoire pour lequel il
travaille est affiché
3.4.4 Consultation de tous les praticiens
Son cas d’utilisation :
Nom cas d’utilisation : Consultation de tous les praticiens
Acteur déclencheur : Un utilisateur
Pré conditions : Néant
Post conditions : Néant
Scénario nominal :
1. L'utilisateur demande à consulter la liste des praticiens dans l’option Consultation
du module Gestion des praticiens
2. Le système affiche la liste des praticiens avec pour chacun son numéro, ses nom
et prénom ainsi que la fonction qu’il occupe.
Exceptions :
Contraintes :
Son jeu de test associé :
N° Scénario et
exceptions
Action Attendu Obtenu
1 Cliquer sur l’onglet Les
Praticiens ouvrant le sous onglet
Consultation et cliquer sur Tous
les praticiens.
La page de tous les praticiens
est affichée avec pour chacun
son numéro, son nom, son
prénom et sa fonction occupée.
3.4.5 Consultation d’un praticien
Son cas d’utilisation :
Nom cas d’utilisation : Consultation d’un praticien
Acteur déclencheur : Un utilisateur
Pré conditions : Néant
Post conditions : Néant
Scénario nominal :
1. Le visiteur demande à consulter les informations d’un praticien
2. Le système invite à sélectionner un praticien dans une liste déroulante (nom et
prénom).
3. Le visiteur sélectionne un praticien dans la liste déroulante
4. Le système affiche les informations (adresse, fonction occupée) du praticien
sélectionné
Exceptions :
Contraintes :
Son jeu de test associé :
N° Scénario et
exceptions
Action Attendu Obtenu
1 Cliquer sur l’onglet Les
Praticiens ouvrant le sous onglet
Consultation et cliquer sur
Information d’un praticien.
La page contenant la liste
déroulantes des praticiens avec
leur nom et leur prénom est
affichée
2 On sélectionne un praticien dans
la liste
Les informations du praticien
(adresse, fonction occupée)
sélectionné sont affichées
3.4.6 Consultation d’un visiteur
Nom cas d’utilisation : Consultation d’un visiteur
Acteur déclencheur : Un utilisateur
Pré conditions : Néant
Post conditions : Néant
Scénario nominal :
1. le visiteur demande à consulter les informations d’un visiteur
2. le système invite à sélectionner un visiteur dans une liste déroulante (nom et prénom).
3. Le visiteur sélectionne un visiteur dans la liste déroulante
4. le système affiche les informations (adresse, date d’embauche, laboratoire) du visiteur sélectionné
Exceptions :
Contraintes :
Son jeu de test associé :
N° Scénario et
exceptions
Action Attendu Obtenu
1 Cliquer sur l’onglet Les
Visiteurs ouvrant le sous onglet
Consultation et cliquer sur
Information d’un visiteur.
La page contenant la liste
déroulantes des visiteurs avec
leur nom et leur prénom est
affichée
2 On sélectionne un visiteur dans
la liste déroulante
Les informations (adresse,
date d’embauche, laboratoire)
du visiteur sélectionné sont
affichées
● La maquette des pages ou des écrans associée
Chaque zone de saisie doit être détaillée et les actions derrière chaque bouton de commande
doivent être présentées.
● Le descriptif des informations présentes sur les écrans (Information, Type (A = Champ alpha-
numérique, L = liste, N = Numérique, D = Date), Initialisation, Modifiable (O/N), Obligatoire
(O/N), Règle de gestion / Commentaire)0
Information Type(*) Initialisation Modifiable Obligatoire Règle de gestion /
Commentaire
Fichier L Non Oui Oui
Les Praticiens L Non Oui Oui
Les Visiteurs L Non Oui Oui
Les
médicaments
L Non Oui Oui
Les Comptes-
rendus
L Non Oui Oui
● Les actions possibles
Action Commentaires
Bouton « croix rouge » Ferme l’application
Bouton « menu » Permet d'accéder aux sections
Exemple :
Ecran Domaine OPUS
● Le descriptif des informations présentes sur les écrans (Information, Type (A = Champ alpha-
numérique, L = liste, N = Numérique, D = Date), Initialisation, Modifiable (O/N), Obligatoire
(O/N), Règle de gestion / Commentaire)0
Information Type(*) Initialisation Modifiable Obligatoire Règle de gestion /
Commentaire
Domaine
OPUS
A Non Oui Oui
● Les actions possibles
Action Commentaires
Bouton « enregistrer » Enregistre ….
Bouton « supprimer » Supprime ….
3.5. L
e modèle des données
Présentation du Modèle des Données (MCD, MPD ou diagramme de classe)
4. Spécifications Techniques
4.1. E
nvironnement
L’application sera développée sur des ordinateurs sous Windows 7 Professionnel.
Le logiciel utilisé sera Microsoft Visual Studio 2010 ainsi que SQL Server 2008 R2.
4.2. E
xigence de programmation
L’application possédera une vue destinée à la navigation des utilisateurs sur l’application et
comprenant l’interface graphique composée de pages HTML.
Elle possédera également un contrôleur qui répondra aux différentes requêtes des visiteurs et praticiens
sur l’application (connexions, consultation de pages, mise à jour de données).
Le développement de l’application en C# devra respecter un ensemble de normes présentées dans un
document séparé. L’application devra respecter toutes ces normes, y compris la normalisation des
noms des fichiers.
4.3. L
e développement de l’application
4.4. S
écurité
4.5. O
rganisation du projet
Numéro Description Livrables associés
1 Réalisation du dossier de spécifications fonctionnelles et techniques
Dossiers de spécifications au format microsoft word (.docx)
2 Création d’un projet MsProject
Projet MsProject au format microsoft project (.mpp)
3 Réalisation du Cas d'utilisation "Lancement de l'application"
diagramme du Cas d'utilisation "Lancement de l'application"
4 Réalisation du Cas d'utilisation "Consultation de tous les visiteurs"
diagramme du Cas d'utilisation "Consultation de tous les visiteurs"
5 Réalisation du Cas d'utilisation " Consultation de tous les praticiens"
diagramme du Cas d'utilisation " Consultation de tous les praticiens"
6 Réalisation du Cas d'utilisation "Consultation d'un praticien"
diagramme du Cas d'utilisation "Consultation d'un praticien"
7 Réalisation du Cas d'utilisation " Consultation d'un visiteur"
diagramme du Cas d'utilisation " Consultation d'un visiteur"
8 Création de la Base de données
Base de données
9 Réalisation des procédures stockées
Procédures stockées(.doc)
10 Codage de la solution en langage C#
Solution visual studio (.cs)
4.6. P
lanning prévisionnel
5. Glossaire
● IDE : Environnement de développement :
En programmation informatique, un environnement de développement est un ensemble d'outils pour
augmenter la productivité des programmeurs qui développent des logiciels. Il comporte un éditeur de
texte destiné à la programmation, des fonctions qui permettent, par pression sur un bouton, de
démarrer le compilateur ou l'éditeur de liens ainsi qu'un débogueur en ligne, qui permet d'exécuter
ligne par ligne le programme en cours de construction. Certains environnements sont dédiés à un
langage de programmation en particulier.
● MDI, Multiple Document Interface :
En Informatique, Multiple Document Interface ou MDI désigne l'organisation de l'interface graphique
d'une application où des fenêtres "parentes" contiennent en leur sein des fenêtres enfants. Le cas
typique d'application consiste en la fenêtre principale de l'application, avec un menu et des barres
d'outils, contenant une (sous-)fenêtre par fichier ou projet ouvert.
● Procédures stockées :
En informatique, dans la technologie des bases de données, une procédure stockée (ou stored
procedure en anglais) est un ensemble d'instructions SQL précompilées, stockées dans une base de
données et exécutées sur demande par le SGBD qui manipule la base de données.
Les procédures stockées peuvent être lancées par un utilisateur, un administrateur DBA ou encore de
façon automatique par un événement déclencheur (de l'anglais "trigger").
Il existe des procédures stockées pour ce qui est de la manipulation de données comme pour le 'tuning
de base'.