Software Requirements المتطلبات البرمجية Cahier des Charges des Logiciels IF5, Automne 2008, Semaine 2.

Slides:



Advertisements
Présentations similaires
Définitions Analyse documentaire
Advertisements

Analyse et définition des besoins
Les Systèmes d’Information Financière Atelier conjoint ACBF / Banque Mondiale / AFRITAC de l’Ouest Gérer l’application dans le temps, sur les plans fonctionnel,
1 Modéliser Ou comment RE-présenter sa connaissance.
Ou comment partager la connaissance
1 IXERP consulting. L archivage consiste à extraire de la base de données opérationnelle les informations qu' il n est plus nécessaire de conserver «
Eléments de Génie Logiciel
Processus d'expression du besoin
L'installation et la diffusion 1 LInstallation et la Diffusion.
La Recette La recette.
Spécification et qualité du logiciel
Introduction : plasticité des IHMs – Page 1 IHM et plasticité 1 IHM et Différents supports Différents utilisateurs Différents environnements Problématique.
Projet n°4 : Objecteering
M.E.D.A.L. Module dEnseignement à Distance pour lArchitecture Logicielle Alain VAILLY Diapositive n° 1 IUP MIAGE - Université de NANTES IUP-MIAGE 3ème.
Les diagrammes d’interactions
Chapitre 7 : démarche de conception, conduite de projet SI
Phase de préparation des itérations Produit Story 11 Release1 Story 1mStory 21 Release2 Story 2m… …
Introduction au Génie Logiciel
Évaluation des IHM et ergonomie
le profil UML en temps réel MARTE
L’ELABORATION DES FICHES DE POSTE
Initiation à la conception de systèmes d'information
Introduction à la conception de Bases de Données Relationnelles
Gestion d’un projet SIG
1 Introduction : Management des systèmes dinformation version 1.1 du 13 Novembre 2001 Introduction : Management des systèmes dinformation ENSGI Cours MSI.
Etude globale de système.
SCIENCES DE L ’INGENIEUR
IGL301 - Spécification et vérification des exgiences 1 Chapitre 1 Introduction (ref : Bray chapitre 1)
IGL301 - Spécification et vérification des exgiences 1 Chapitre 2 Le processus dingénierie des exigences (ref : Bray chapitre 2)
Unified Modeling Langage
TESTING BUSINESS PROCESSES
Présentation du mémoire
Les étapes du cycle de développement du génie logiciel
Portée, arrimages et intervenants Évolution des méthodes
Sensibilisation a la modelisation
Langage de modélisation graphique de systèmes
UN THESAURUS Pourquoi ? Pour qui ? Comment ?
ANALYSE METHODE & OUTILS
Stratégie d’entreprise - Alstom Transport – Marco Férrogalini
Supports de formation au SQ Unifié
Institut Supérieur des Sciences Appliquées et de Technologie Sousse
Specifications de Systemes Logiciels المواصفات الشكلية Software Specifications Chapitre 7.
Interface Homme-machine (interaction humain-machine) Emna Hakem Université 7 novembre à Carthage Faculté des Sciences Economiques et de Gestion de Nabeul.
2003 (revisé 2008)SEG Chapitre 11 Chapitre 1 “The Systems Engineering Context” Le contexte du génie de systèmes.
Cycles de Vie du Logiciel LFI2 Genie Logiciel/ Gestion de Projets Septembre 2008.
Le contenu est basé aux transparents du 7 ème édition de «Software Engineering» de Ian Sommerville«Software Engineering» de Ian Sommerville B.Shishedjiev.
Introduction au Génie Logiciel
La crédibilité de la PFE IFAL en formation de formateurs CCC-IFAL Vendredi 14 mai 2010.
François CARCENAC,Frédéric BONIOL ONERA-DTIM Zoubir MAMMERI IRIT
Présentation AICHA REVEL INGENIEUR D’ÉTUDE STERIA DEPARTEMENT TRD
Management de la qualité
1 Vers la gestion de la cohérence dans les processus multi-modèles métier Wolfgang THEURER Ecole Nationale Supérieure d’Ingénieurs des Etudes et Techniques.
Principes et définitions
2 Tracks Unified Process
- Exemple de détermination de tolérance de localisation
Initiation aux SGBD Frédéric Gava (MCF)
Stage à Ontomantics Master Pro TILDE
1 Structure en MC Principes Stockage des données dans la mémoire volatile d’un ordinateur Problèmes Stockage temporaire «Petits» volumes de données Langages.
ISO 9001:2000 Interprétation (Introduction et Para 1-4)
Document de spécification d’exigences Normes IEEE et 29148:2011
Rénovation de l’enseignement spécifique des sciences de l’ingénieur PNF enseignement spécifique des sciences de l’ingénieur Paris 27 mars 2012 BACCALAUREAT.
ISO 9001:2000 Interprétation Article 7 Réalisation du produit
Introduction Module 1.
Du Cahier des Charges à la Spécification Formelle ?
© 2015 SAMARES ENGINEERING – All rights reserved Raphaël Faudou Groupe de travail sur les exigences Paris – 9 Octobre.
Modélisation des Actions Mécaniques Première sti2d
Les bases de données Séance 2 Méthodologies d’analyse.
ARIANE : Interopérabilité sémantique et accès aux sources d'information sur Internet Sylvain Aymard, Michel Joubert, Dominique Fieschi, Marius Fieschi.
THEMA : L’évaluation des politiques publiques Observatoire de l’Enfance, de la Jeunesse et de l’Aide à la Jeunesse – 23 septembre 2011.
Transcription de la présentation:

Software Requirements المتطلبات البرمجية Cahier des Charges des Logiciels IF5, Automne 2008, Semaine 2

Cahier des Charges Document qui stipule  Services rendus par le systeme envisage.  Contraintes d’exploitation.  Contraintes de developpement.

Cahier des Charges Ensemble de clauses  Chaque clause represente une contrainte/ un service/ une condition  Divers Niveaux d’abstraction/ Degres de precision.  Clause promotionnelle.  Clause de contrat.  Clause logique.

Trois Niveaux de Clauses Trois niveaux d’abstraction/ de detail  User requirements  System Requirements  Software specification

Trois Niveaux de Clauses

Clauses Fonctionnelles et non Fonctionnelles  Clauses Fonctionnelles (المتطلبات الوظيفية) Specifie les services rendus, les fonctions calculees, reactions a des entrees ou des circonstances, etc.  Clauses Fonctionnelles (المتطلبات اللاوظيفية) Contraintes sur les services rendus, les fonctions calculees, les circonstances operatoires… Contraintes sur le processus de developpement.  Clauses du Domaine (متطلبات الميدان) Contraintes qui emanent du domaine (contraintes physiques, dispositions legales, etc)..

Precision des Clauses  Problemes quand les clauses ne sont pas enoncees avec precision.  Des clauses ambigues peuvent etre interpretees differemment par les usagers, et les developpeurs.  Suffisemment non ambigues pour permettre a un parti impartial (juge) de determiner si une implementation satisfait la clause ou pas.

Proprietes des Clauses  Completude/ Completeness/ الإكتمال Representer toutes les exigences de l’usager.  Coherence/ Consistency/ التماسك Ne pas imposer de contraintes contradictoires.  Minimalite/ Minimality/ الإحتفاظ Ne pas imposer de contraintes autres que celles requises par l’usager ou le domaine.  Abstraction/ Abstraction/ التجرد WHAT vs HOW.

Clauses Non Fonctionnelles  Clauses Produit: Proprietes et contraintes du systeme, t.q. fiabilite, temps de reponse, limites d’espace memoire, capacite E/S, etc.  Clauses Processus: Specifier un langage, une methode, un outil, un standard, etc.  Clauses non fonctionnelles peuvent etre plus critiques que les clauses fonctionnelles (fiabilite, surete, temps de reponse, etc).

Classification de Clauses Non Fonctionnelles  Clauses du produit  Clauses de l’organisation Standards de processus, de langage, de methode, etc.  Clauses externes Externes au systeme et a son processus de developpement.

Classification de Clauses Non Fonctionnelles

Clauses Mesurables

Clauses du domaine  Derivees du domaine d’application.  Nouvelles clauses fonctionnelles, contraintes sur des clauses existantes ou calculs specifiques.  Si les clauses du domaine ne sont pas satisfaites, le systeme peut etre inoperable.

Difficultes des clauses du domaine  Understandability Clauses exprimees dans le vocabulaire du domaine. (Interet des PLE)  Implicitness Les experts du domaine ne pensent pas a formuler la connaissance implicite du domaine.

User Requirements  Formulees en termes comprehensibles par des non specialistes.  Representees en langage naturel, tables et diagrammes. Problemes du langage naturel: Informel/ qualitatif. Ambigu Confusion: plusieurs clauses

Recommendations pour representer des clauses  Inventer un format standard.  Utiliser le langage de maniere uniforme/ coherente.  Mettre en relief les clauses importantes du cagier des charges.

System requirements  Description detaillee des fonctions, services et contraintes du systemes.  Plus de detail que user requirements.  Base de conception.  Base de contract entre fournisseur et utilisateur.  Utilisent des modeles de systemes.

Cahier des Charges et Conception  En principe: CC  WHAT. Conception  HOW.  En pratique, le CC et la conception sont inseparable Une architecture du systeme peut etre concue pour structurer le CC. Le systeme peut interagir avec d’autres systemes qui generent des exigences de conception. L’utilisation d’une conception specifique peut etre une exigence du domaine.

Specification par formulaire

Specification Tabulaire

Digrammes de Sequence

Specification d’Interfaces  Interfaces entre systemes cooperatifs doivent etre specifiees.  Trois types d’interfaces peuvent etre specifees Interfaces Procedurales; Structures de donnees echangees; Representations de donnees.  Notations formelles, un moyen efficace a cet effet.

Exemple de Specification d’Interface

Document du Cahier des Charges  Charge des developpeurs du systeme.  User requirements + System requirements.  Pas un document de conception: what vs how.

Usagers du Cahier des Charges

Structure du Document  Preface  Introduction  Lexique  User requirements  Architecture du Systeme  Modeles du Systeme  System requirements  Evolution du Systeme  Appendices  Index