Documentation - Spécifications

Documentation - Spécifications
TD IL n°3 – Mr Jean-Daniel KANT– 04 Mars 2004
Documentation - Spécifications
I – Discussion sur l'exercice de la semaine précédente
II – Documentation d'un projet logiciel
2.1 Lister les différents types de documents susceptibles d'être produits lors d'un projet logiciel.
Norme DoD – std 2167 (1988)
1. Plan de développement : conditions, organisation des activités du projet, rôles, responsabilité,
planning...
2. Spécifications du système
3. Document d'étude du système
4. Spécifications des besoins informatiques
5. Document d'étude informatique
6. Spécifications des interfaces
7. Document d'étude d'interfaces
8. Document descriptif de la version / journal des versions
9. Plan d'essai : planification des tests
10. Description des tests
11. Rapport de tests
12. Manuel d'exploitation du système
13. Manuel d'utilisateur
14. Manuel du programmeur
15. Manuel de maintenance : conseils pour maintenir le logiciel, description des interventions
2.2 On s'intéresse ici au plan de développement, dont la structure vous est fourni en document
annexe (non représenté ici).
Parmi les (nombreuses) rubriques de ce plan, quelles sont celles que vous pensez pouvoir renseigner
pour le projet SIGB compte tenu des informations dont vous disposez ? Faites en une rédaction
sommaire.
On peut pratiquement tout renseigner sauf les prévisions budgétaires.
III – Spécifications
3.1 Rappeler la différence entre spécifications fonctionnelles et non fonctionnelles.
−
−
Spécifications fonctionnelles : ensemble des services et fonctionnalités rendus par le système
: traitements et comportement, limites.
Spécifications non fonctionnelles : contraintes, qualité, fiabilité, temps de réponse, espace
d'occupation (mémoire).
3.2 Nous allons maintenant nous intéresser au diagramme de cas d'utilisation. Lisez attentivement la
cahier des charges du projet "Téléphone Portable" qui va vous être distribué (non représenté ici).
Identifier les acteurs et les cas d'utilisation, et construisez le diagramme de cas d'utilisation
correspondant.
3.3 Même question pour le projet "Flotte aérienne" (non représenté ici)
3.4 Afin de mieux préciser les différents cas d'utilisation, il faut remplir une fiche de description de cas
d'utilisation :
1) Projet Téléphone
Cas "Allumer" : rkouatchet
Nom du cas d'utilisation
Acteurs
Description
Pré-conditions
Suite des interactions
Post conditions
Acteurs secondaires
Hypothèses
Exigences non fonctionnelles
Exceptions / alternatives
Allumer
Utilisateur, réseau GSM
L’utilisateur appuie sur le touche « No » jusqu'à l’émission d’un
bip sonore. L’écran du téléphone s’allume et il est demandé à
l’utilisateur de rentrer son code PIN. Après l’émission d’un bip
sonore indiquant la validation du code, l’écran affiche le nom de
l’opérateur, les différents indicateurs et se connecte au réseau.
L’utilisateur se trouve dans une zone où le réseau GSM est
accessible et opérationnel
+ Appuie long sur la touche « No ».
+ Entrer code PIN.
+ Appuyer sur la touche « Yes ».
+ Affichage des indicateurs.
+ Connexion au réseau
NA
il existe un opérateur téléphonique utilisant le réseau GSM
+ Affichage clair des indicateurs.
+ Connexion rapide au réseau.
+ L’utilisateur rentre 3 codes PIN erroné. Cela entraîne l’arrêt
du téléphone.
+ Appuie pas assez long sur la touche « No ». Le téléphone
reste éteint.
+ Le téléphone est en panne.
+ L’utilisateur se trouve dans une zone non couverte par le
réseau GSM.
Cas "Eteindre" : binôme Yannick LIMBALLE et Yves TAVEL
Eteindre
Nom du cas d'utilisation
Acteurs
utilisateur
Description
mise hors service du mobile phone
Pré-conditions
allumé
Suite des interactions
appui long sur la touche 'NO'
Post conditions
eteint
Acteurs secondaires
NA
Hypothèses
NA
Exigences non fonctionnelles
Temps maximal pour l'appui long = 3s
Exceptions / alternatives
NA
Cas "Régler Volume" : binôme Sosa G. et Hélène BOYE-ROCHE
Régler Volume
Nom du cas d'utilisation
Acteurs
Utilisateur
Description
Augmenter ou diminuer le volume du haut-parleur
Pré-conditions
Le téléphone doit être allumé
Suite des interactions
appui sur les boutons de volume
Post conditions
Le volume est augmenté ou diminue
Acteurs secondaires
NA
Hypothèses
Le haut-parleur fonctionne correctement
Exigences non fonctionnelles
Niveaux de volume prédéfinis
Exceptions / alternatives
NA
Cas "Emettre appel" : Denesh DOUGLAS
Emettre appel
Nom du cas d'utilisation
Acteurs
Utilisateur et opérateur GSM
Description
Emettre un appel
Pré-conditions
Téléphone allumé - réseau OK - batterie OK
Suite des interactions
Composer numéro - clear pour effacer - yes
Post conditions
Parler – NO pour mettre fin à l'appel
Acteurs secondaires
NA
Hypothèses
Numéro OK – forfait OK
Exigences non fonctionnelles
Qualité sonore de la communication
Exceptions / alternatives
Laisser message si occupé ou sans réponse
Nom du cas d'utilisation
Acteurs
Description
Pré-conditions
Suite des interactions
Post conditions
Acteurs secondaires
Hypothèses
Exigences non fonctionnelles
Exceptions / alternatives
Emettre appel d'urgence
Nom du cas d'utilisation
Acteurs
Description
Pré-conditions
Suite des interactions
Post conditions
Acteurs secondaires
Hypothèses
Exigences non fonctionnelles
Exceptions / alternatives
Recevoir appel
2) Projet Flotte aérienne
Cas "notification d'incidents" : rkouatchet
Notification incidents
Nom du cas d'utilisation
Acteurs
Opérateur ZéroStress
Description
Il y a deux moyens possibles pour notifier un accident :
- Le commandant de bord transmet des informations
concernant l’incident au système Cassandre par téléphone
ou par radio. Cassandre se charge ensuite de donner ses
informations au système ZéroStress.
- Un opérateur ZéroStress saisie directement les informations
sur l’incident sur un écran de saisie du système ZéroStress.
Pré-conditions
Dans le cas où l’incident est notifié par le système Cassandre, il
faut qu’un comandant de bord ait au préalable déclaré un
incident.
Suite des interactions
Cassandre transmet les informations sur l’incident au logiciel
connecté à ZéroStress.
OU
L’opérateur ZéroStress saisie les informations sur son écran.
Post conditions
NA
Acteurs secondaires
Cassandre
Hypothèses
Bon fonctionnement du système Cassandre.
Exigences non fonctionnelles
La transmission des données entre Cassandre et ZéroStress
grâce au logiciel est rapide.
Exceptions / alternatives
Le commandant de bord est dans l’incapacité de joindre le
système Cassandre, ou le logiciel liant Cassandre à ZéroStress
fonctionne mal, ou Cassandre est surchargé.
-> Un opérateur ZéroStress est prévenu pour effectuer lui-même
la notification.
Cas "Traitement simple local" : binôme Yannick LIMBALLE et Yves TAVEL
Traitement simple local
Nom du cas d'utilisation
Acteurs
"SiToutBaigne"
Description
sélectionne l'appareil du même aéroport en réserve depuis le +
longtemps
Pré-conditions
notification d'incident a eu lieu, disponibilité d'avions en réserve
sur le même aéroport
Suite des interactions
1. réception notification ;
2. interroger "SiToutBaigne" ;
3. choix automatique de l'avion de remplacement
Post conditions
retour a la situation normale, avion remplacé
Acteurs secondaires
NA
Hypothèses
NA
Exigences non fonctionnelles
NA
Exceptions / alternatives
pas d'avions disponibles sur le même aéroport
Cas "Traitement simple délocalisé" : Denesh DOUGLAS
Traitement simple délocalisé
Nom du cas d'utilisation
Acteurs
"SiToutBaigne"
Description
Traitement si plus d'avions disponibles sur aéroport local
Pré-conditions
Plus d'avions disponibles sur l'aéroport local – appareil en panne
Suite des interactions
Récupérer depuis "SiToutBaigne" la liste des appareils
disponibles sur les aéroports voisins. Choix de l'appareil dans
l'aéroport le plus porche de l'aéroport local
Post conditions
Acheminer l'appareil de remplacement vers l'aéroport local
Acteurs secondaires
NA
Hypothèses
NA
Exigences non fonctionnelles
Appareil de remplacement OK
Appareil de remplacement de même capacité
Exceptions / alternatives
Si pas d'avions disponibles
cas "Traitement complexe"
Nom du cas d'utilisation
Acteurs
Description
Pré-conditions
Suite des interactions
Post conditions
Acteurs secondaires
Hypothèses
Exigences non fonctionnelles
Exceptions / alternatives
Traitement complexe
Cas "Annulation vol" : binôme Sosa G. et Hélène BOYE-ROCHE
Annulation vol
Nom du cas d'utilisation
Acteurs
Opérateur "ZéroStress"
Description
Annuler un vol prévu
Pré-conditions
Il n'a pas été possible de remplacer le vol
Suite des interactions
Le vol est annulé
Post conditions
Modification des plans de vol
il faut rediriger les passagers
Acteurs secondaires
"SiToutBaigne"
Hypothèses
Exigences non fonctionnelles
Exceptions / alternatives
NA
NA
NA
Nom du cas d'utilisation
Acteurs
Description
Pré-conditions
Suite des interactions
Post conditions
Acteurs secondaires
Hypothèses
Exigences non fonctionnelles
Exceptions / alternatives
Affichage plan de vol
IV – Exercice à remettre la semaine suivante
1. Identifier les acteurs et les cas d'utilisation pour le projet SIGB
2. Construire le diagramme de cas d'utilisation correspondant
3. Remplir les fiches de description de 2 cas d'utilisation au choix
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising