Analyse et définition des besoins

Présentation au sujet: "Analyse et définition des besoins"— Transcription de la présentation:

1 Analyse et définition des besoins
BOURBET Mouloud Génie Logiciel ENSI-2011

2 Introduction Les problèmes qui étaient soumis aux fabricants de logiciel étaient trop complexe (souvent ils n’arrivaient pas a comprendre la nature du problème) Des fois le système est nouveau et ne dispose pas de modèle automatisé

3 Un processus visant à établir les fonctionnalités du futur système ainsi que les contraintes aux quelles sera soumis le système. Donc : L’ensemble des informations concernant le problème doivent être : Rassemblé Analysé Définis de manière compréhensible

4 Remarque : différence entre le but et le besoin
But : caractéristique générale que devra vérifier le système mais on ne peut pas tester. Besoin : caractéristique que devra vérifier le système et qu’on peut tester. Exemple : But : produire un logiciel agréable a utilisé Besoin : avoir un logiciel qui permet de manipuler les commandes par menu ou par souris

5 Le document de définition des besoins (Cahier des charges)
C’est le document qui contient des indications pour les phases suivantes du cycle de vie d’un logiciel. Il comporte un ensemble de propriétés et de contrainte décrite de façon précise et que devra satisfaire le logiciel. Il doit décrire ce que doit faire le système sans spécifier comment réaliser ces fonctionnalités. Les besoins doivent constituer un ensemble cohérent et complet.

6 Les critères que doit vérifier un cahier des charges :
Il doit spécifier le comportement externe du système. Il doit spécifier les contraintes de réalisation. Il doit être facile a mettre à jour. Il doit servir d’outil de référence aux programmeurs de maintenance. Il doit contenir des indications concernant les étapes ultérieures du cycle de vie du logiciel. Il doit spécifier les réponses acceptables aux événements non désirables.

7 La structure d’un cahier des charges : Introduction : elle décrit:
La raison d’être du système, L’environnement du système, Les fonctionnalités du système de manière très brève, La structure du document, Les notations utilisées. Matériel : dans cette partie on doit spécifier : Le matériel et les interfaces, si le systèmes nécessite du matériel spécifique, Les configurations minimales et optimales sur lesquelles le système peut s’exécuter en cas de matériel standard.

8 Modèle conceptuel : Le modèle doit décrire une vue générale à haut niveau des fonctions du système ainsi que leurs relations. Remarque : les notations graphiques sont les plus appropriés pour décrire ce type de modèle. Il contient deux phases: La modélisation du système global. La modélisation des fonctions principales. Les modèles utilisés : Les automates d’état fini; États/transitions Le diagramme de flux de données

9 1ière phase : modélisation du système.
Exemple : considérant un système bureautique composé de : Courrier électronique, Tableur, Service de préparation de document, Recherche d’information. 1ière phase : modélisation du système. Utilisateur Courier électronique Système de communication Communication externe Préparation de document Recherche d’information Tableur Base de données

10 2ième phase : modéliser la fonction courrier électronique
Utilisateur Lire courrier Base de données Sauvegarder courrier Envoyer courrier Système de communication Accuser réception courrier Classer courrier Détruire courrier

11 Besoins fonctionnels :
C’est la description selon la nature des services que le système va fournir à l’utilisateur. La notation utilisée peut être : Un langage naturel. Un langage semi formel. Un langage formel. Un mélange entre toutes les autres notations.

12 Besoins non fonctionnels :
Besoins en matière de base de données :L’organisation logique des données manipulées par le système et leurs relations doivent être décrites dans cette section. Besoins non fonctionnels : Les contraintes sous lesquelles le système va opérer doivent être décrites dans cette partie. Exemple : Contraintes temporelles Espace mémoire Représentation des données Langage de programmation.

13 Information donnée à la maintenance :
Dans cette section on doit décrire : Les hypothèses fondamentales sur lesquelles est basé le système, Les changements prévus du fait de l’évolution du matériel, des besoins des utilisateurs…etc. Et dans les mesures du possible décrire : Les fonctions, et les contraintes particulièrement sujette au changement.

14 Glossaire : Il doit définir et de manière précise et sans faire des pré supposition sur l’expérience et la formation du lecteur, les termes techniques utilisés dans le cahier des charges Index : C’est un revois au document. Remarque : Il est préférable d’avoir plusieurs type d’index : Alphabétique, Par chapitre, Par fonction.

15 SADT (Structured Analysis and Design Technique) : crée en 1976 aux USA.
Définition : est une méthode générale qui cherche à favoriser la communication entre les demandeurs et les utilisateurs d’une part et les concepteurs et les réalisateurs d’autre part.

16 Les concepts fondamentaux du SADT:
La modélisation : aborde un système en le modélisant afin d’obtenir un enchaînement d’action et des données moins complexes que celle de départ. Démarche d’analyse : SADT est une méthode d’analyse des systèmes selon un approche descendante, modulaire et hiérarchique, on commence par la description la plus générale et la plus abstraite du système représenté par une seul boite, en suite on éclate celle-ci en plusieurs petites boites moins complexe, les petites boites on a leur tours décomposé et ainsi de suite. SADT limite le nombre de nouvelle boite généré a chaque étape entre 3 et 6 pour des raisons d’efficacité.

17 Niveaux d’abstraction : consiste à séparer les 3 niveaux d’abstraction
niveau conceptuel : répond aux questions quoi? et pourquoi? niveau organisationnel : répond aux questions quoi? où? et quand? niveau opérationnel : répond à la question comment?

18 Les modèles du SADT Il est composé de trois éléments principaux: Le diagramme d’activités (Actigramme) Le diagramme de données (Datagramme) Les conditions d’activation

19 Mécanisme ou support de l’activité
Le diagramme d’activité (Actigramme) : représenté par les boites manipulant les données véhiculé par les flèches. Actions (Activités) Données de contrôle Données en entré Données en sortie Mécanisme ou support de l’activité

20 Exemple : Actigramme de la fonction calculer
Type d’opération Opérandes Résultats Méthode de calcul Calculateur

21 Le diagramme de données (Datagramme) : également représenté par des boites où les flèches sont cette fois les activités qui créent et utilisent les données Nom de la donnée Activité de contrôle Activités génératrices Activités utilisatrices Mécanisme ou support de données

22 Exemple : de passation de paramètre
Saisir Afficher Sélectionner le type d’opération Registre du calculateur

23 Les conditions d’activation : Syntaxe :
N° boite /N° Activation Précondition → Postcondition Exemple 1 / 1 E1 et C1 → S1 ou S2 et ! C1 : le module modifier n’et disponible en sortie e l’activité « modifier » que si il n y a pas d’erreur détecté. 2 / 1 E1 et C1 → S1 ou S2 et ! E1 : le module testé en sortie de l’activité « tester » implique q’il n’est plus en entré de « modifier ». Modifier (1) Tester (2) E1 S2 C1 S1 Module testé Jeu de teste Erreur détectée Module Nmbr d’erreur > 0