Analyse et définition des besoins

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. Utilisateur Courier électronique Préparation de document Tableur Système de communication Recherche d’information Communication externe Base de données • 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.

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

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 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. Données de contrôle Données en entré Données en sortie Actions (Activités) 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.

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

21. Activité de contrôle Activités génératrices Activités utilisatrices Nom de la donnée Mécanisme ou support de données 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

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

23. Nmbr d’erreur > 0 Erreur détectée C1 Modifier (1) Module testé Module S1 E1 Jeu de teste C1 S1 Tester (2) Module testé E1 S2 • 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 ».