Catherine Letondal catherine.letondal@enac.fr Ingénierie Système Analyse des besoins Catherine Letondal catherine.letondal@enac.fr 3/12/2010.

Présentation au sujet: "Catherine Letondal catherine.letondal@enac.fr Ingénierie Système Analyse des besoins Catherine Letondal catherine.letondal@enac.fr 3/12/2010."— Transcription de la présentation:

1 Catherine Letondal catherine.letondal@enac.fr
Ingénierie Système Analyse des besoins Catherine Letondal 3/12/2010

2 Plan L’analyse de besoins dans la démarche A/COO
Principes et définitions de base Acteur Cas d’utilisation Scénario Etude d’un guichet automatique de banque

3 L’analyse de besoins dans la démarche A/COO
+ diagrammes activité (UC complexes) + organisation UC packages UML

4 Principes et définitions de base 

5 Définition d’acteur Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit avec le système Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteurs de données - aussi un autre système ? - EME ?(sauf contrainte comme texte législatif)

6 Comment identifier les acteurs ?
Les utilisateurs humains directs : il faut identifier tous les profils possibles, sans oublier l’administrateur, l’opérateur de maintenance, etc. (acteurs principaux) Ex. Internaute, l’administrateur du site, l’opérateur mettant à jour le catalogue d’ouvrages, … Les autres systèmes interagissant directement avec le système étudié (acteurs secondaires) Ex. Système de paiement par carte bleue

7 Acteur principal ou secondaire
Celui pour qui le système produit un résultat observable, une plus-value métier Le système est conçu pour satisfaire les besoins des acteurs principaux ! Acteur secondaire Les autres sollicités par le système pour des informations complémentaires Ils peuvent uniquement consulter ou informer le système lors de l’exécution d’un service (cas d’utilisation)

8 Définition d’un cas d’utilisation
Un cas d’utilisation décrit la façon dont un ou plusieurs acteurs utilisent un système pour atteindre un but Les cas d’utilisation représentent les services rendus par le système – les fonctions - du point de vue de l’acteur Ex. « Rechercher des ouvrages », « Gérer son panier », … sont des besoins/buts d’un site web de vente de livres

9 Comment identifier les cas d’utilisation?
Pour chaque acteur : Rechercher les différentes intentions métier avec lesquelles il utilise le système Utiliser les observations et les résultats de la conception participative (scénarios, storyboards, prototypes vidéo, ...) Déterminer dans le cahier des charges les services fonctionnels attendus du système Nommez les cas d’utilisation par un verbe à l’infinitif suivi d’un complément, du point de vue de l’acteur (et non pas du système)

10 Comment représenter les acteurs et les cas d’utilisation ?
Le diagramme de cas d’utilisation est un schéma qui montre les cas d’utilisation (ovales) reliés par des associations (lignes) à leurs acteurs Chaque association signifie « participe à » Un cas d’utilisation doit être relié à au moins un acteur Un acteur secondaire de type « système » peut optionnellement être représenté par une classe

11 Scénario Un scénario est une suite spécifique d’actions et d’interactions entre un ou plusieurs acteurs et le système dans le contexte d’un cas d’utilisation Un cas d’utilisation contient en général un scénario nominal et plusieurs scénarios alternatifs (qui se terminent de façon normale) ou d’erreur (qui se terminent en échec)

12 Etude d’un guichet automatique de banque (GAB)

13 Etapes de l’analyse de besoins
Identifier les acteurs Identifier les cas d’utilisation Construire le diagramme de cas d’utilisation Décrire textuellement les cas d’utilisation Décrire les cas d’utilisation avec UML Organiser et structurer les cas d’utilisation

14 Exigences Le GAB offre les services suivants :
Distribution d’argent à tout porteur de carte de crédit, via un lecteur de carte et un distributeur de billets Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les clients porteurs d’une carte de crédit de la banque adossée au GAB N’oubliez pas non plus que : Toutes les transactions sont sécurisées Il est parfois nécessaire de recharger le distributeur

15 Identifier les acteurs du GAB (Phrases 1 et 2)
Phrase 1 -> acteur « Porteur de carte » Le lecteur de carte et le distributeur de billets ne sont acteurs car ils font partie du GAB Autre piège : la carte bancaire est externe au système, mais celui qui bénéficie de l’utilisation du système est le porteur de carte, pas la carte (éliminer les acteurs « physiques » au profit des acteurs « logiques ») Phrase 2 -> acteur « Client banque » La phrase identifie des services supplémentaires qui ne sont proposés qu’aux clients de la banque porteurs d’une carte de crédit de cette dernière (il s’agit donc d’un profil différent représenté par un nouvel acteur)

16 Identifier les acteurs du GAB (Phrases 3 et 4)
Phrase 3 -> toutes les transactions sont sécurisées, mais par qui ? Pas par le GAB, sinon par 2 nouveaux acteurs (d’après la réponse d’un expert métier) : « Système d’autorisation global Carte Bancaire» : pour les transactions de retrait « Système d’information » : pour autoriser toutes les transactions effectués par un client avec sa carte de la banque Phrase 4 -> acteur « Opérateur de maintenance » Le GAB nécessite des actions de maintenance telles que le rechargement en billets du distributeur, la récupération de cartes avalées, etc.

17 Identifier des cas d’utilisation du GAB
Porteur de carte Retirer de l’argent Client banque Consulter le solde de son compte courant Déposer du numéraire Déposer de l’argent Opérateur de maintenance Recharger le distributeur Maintenir l’état opérationnel Système d’autorisation (Sys. Auto.) Néant Système d’information (SI) banque Acteurs principaux (ceux pour qui les cas d’utilisation produisent un résultat observable) Acteurs secondaires (les autres participants des cas d’utilisation sollicités pour des informations complémentaires)

18 Construire le diagramme de cas d’utilisation (préliminaire)
D’autres solutions existent Ne perdez trop de temps avec les détails des diagrammes de cas d’utilisation Diagramme utile pour montrer le périmètre du système

19 Décrire les cas d’utilisation

20 Description textuelle d’un cas d’utilisation
Sommaire d’identification (obligatoire) Inclut titre, résumé, dates de création et de modification, version, responsable, acteurs… Description des scénarios (obligatoire) Décrit le scénario nominal, les scénarios alternatifs, les scénarios d’erreur, les préconditions et les postconditions Exigences non fonctionnelles (optionnel) Fréquence, volumétrie, disponibilité, fiabilité, intégrité, confidentialité, performances, concurrence, etc. Précise également les contraintes d’IHM comme des règles d’ergonomie, une charte graphique, etc.

21 Décrire textuellement les cas d’utilisation (ex
Décrire textuellement les cas d’utilisation (ex. « Retirer de l’argent » ) Sommaire d’identification Titre : Retirer de l’argent Résumé : ce cas d’utilisation permet à un Porteur de carte, qui n’est pas client de la banque, de retirer de l’argent, si son crédit hebdomadaire le permet. Acteurs : Porteur de la carte (principal), Système d’autorisation (secondaire) Date de création : 01/11/09 Date de mise à jour : 15/11/09 Version : Responsable : Luis Basora

22 Décrire textuellement les cas d’utilisation (ex
Décrire textuellement les cas d’utilisation (ex. « Retirer de l’argent » ) Description des scénarios Préconditions La caisse du GAB est alimentée (il reste au moins un billet !). Aucune carte ne se trouve déjà coincée dans le lecteur. La connexion avec le Système Scénario nominal Le Porteur de carte introduit sa carte dans le le lecteur de cartes du GAB. Le GAB vérifie que la carte introduite est bien une carte bancaire. Le GAB demande au Porteur de carte de saisir son code d’identification. Le Porteur de carte saisit son code d’identification. Le GAB compare le code code d’identification avec celui qui est codé sur la puce de la carte. Le GAB demande une autorisation au Système d’autorisation. Le Système d’autorisation donne son accord et indique le crédit hebdomadaire. … Le porteur de carte prend les billets et le ticket.

23 Décrire textuellement les cas d’utilisation (ex
Décrire textuellement les cas d’utilisation (ex. « Retirer de l’argent » ) Enchaînements alternatifs A1 : code d’identification provisoirement erroné L’enchaînement A1 démarre au point 5 du scénario nominal. Le GAB indique au Porteur de carte que le code est erroné, pour la première ou deuxième fois. Le GAB enregistre l’échec sur la carte. Le scénario nominal reprend au point 3. … Enchaînements d’erreur E1 : carte non-valide L’enchaînement E1 démarre au point 2 du scénario nominal. Le GAB indique au Porteur que la carte n’est pas valide (illisible, périmée, etc.), la confisque ; le cas d’utilisation se termine en échec.

24 Décrire textuellement les cas d’utilisation (ex
Décrire textuellement les cas d’utilisation (ex. « Retirer de l’argent » ) Postconditions La caisse du GAB contient moins de billets qu’au début du cas d’utilisation (le nombre de billets manquants est fonction du montant du retrait). Une transaction de retrait a été enregistrée par le GAB avec toutes les informations pertinentes (montant, numéro de carte, date, etc.). Les détails de la transaction doivent être enregistrés aussi bien en cas de succès que d’échec. Exigences non fonctionnelles Contraintes Descriptif Temps de réponse L’interface du GAB doit réagir en l’espace de 2 secondes au maximum. Concurrence Non applicable (mono-utilisateur). Disponibilité 7j/7, 24h/24. L’absence de papier pour les tickets ne doit empêcher les retraits. Intégrité Les interfaces du GAB doivent être très robustes pour prévenir le vandalisme. Confidentialité La comparaison du code d’identification saisi sur le clavier du GAB avec celui de la carte doit être fiable à 10-6

25 Décrire textuellement les cas d’utilisation (ex
Décrire textuellement les cas d’utilisation (ex. « Retirer de l’argent » ) Besoins IHM Les dispositifs d’entrée/sortie à la disposition du Porteur de carte doivent être : Un lecteur de carte bancaire Un clavier numérique avec des touches « validation », « correction » et « annulation » Un écran pour l’affichage des messages du GAB Des touches autour de l’écran pour sélectionner un montant de retrait parmi ceux qui sont proposés Un distributeur de billets Un distributeur de tickets

26 Décrire les cas d’utilisation avec UML
La description textuelle est indispensable, car elle permet de communiquer facilement avec les utilisateurs En revanche, le texte présente des désavantages : il est difficile de montrer comment les enchaînements se succèdent, ou à quel moment les acteurs secondaires sont sollicités Il est recommandé de compléter la description textuelle par un ou plusieurs diagrammes dynamiques UML, tels que les diagrammes de séquence ou les diagrammes d’activités

27 Diagrammes UML dynamiques les plus utilisés pour les cas d’utilisation
Pour documenter les cas d’utilisation Pour illustrer des scénarios particuliers

28 Ex. Diagramme d’activité du cas d’utilisation « Retirer de l’argent »
- même niveau que eFFBD

29 Diagrammes de séquence système
traduction directe d’un scénario de use case le diagramme UC sert plutôt à représenter les liens entre acteurs et use case le DSS : lien UC (paradigme fonctionnel) et modèles OO début du diagramme d’interaction

30 Ex. Diagramme de séquence système du scénario nominal « Retirer de l’argent »

31 Servez-vous des cas d’utilisation pour définir vos itérations !
Dans le cadre d’un développement itératif et incrémental, il est très utile de recourir au découpage en cas d’utilisation pour définir les itérations À cet effet, il convient en premier lieu d’identifier les cas d’utilisation les plus critiques en termes de gestion des risques Ces cas d’utilisation devront être traités prioritairement afin de lever au plus tôt les risques majeurs. Il sera également demandé au client d’affecter une priorité fonctionnelle à chaque cas d’utilisation, afin de livrer d’abord les cas d’utilisation les plus demandés. Ces deux critères pouvant être contradictoires, la décision du découpage en itérations incombe au chef de projet, qui doit le faire valider par le client

32 Exemple de découpage du projet en itérations
Cas d’utilisation Risque Priorité Itération Retirer de l’argent haut haute 1 Consulter le solde de son compte courant moyen 2 Déposer de l’argent moyenne Recharger le distributeur bas 3 Maintenir l’état opérationnel À chaque cas d’utilisation, on peut affecter : un risque (haut, moyen, bas), une priorité fonctionnelle (haute, moyenne, basse).

33 Conseils méthodologiques
Pas plus de 20 cas d’utilisation de base Ne pas tomber dans le piège de la granularité trop fine Le plus important est la description textuelle et l’identification des scénarios (la robustesse du système en dépend) N’abusez pas des relations entre cas d’utilisation (surtout extension) : Diagrammes difficiles à lire pour les experts métier Soyez agiles et itératifs ! Faire évoluer les cas d’utilisation et les diagrammes à travers les itérations DSS pour les scénarios choisis pour l’itération suivante (seulement les scénarios nominaux et les alternatifs les plus complexes) Avancez en parallèle dans l’élaboration du modèle du domaine et de l’architecture

34 EME de l’analyse fonctionnelle et acteurs
Identifier les éléments extérieurs en relation avec le système : physique, technique, humain, économique La relation est un lien physique ou virtuel Question typique : Limite du système ? Exemple : pilote de l’avion ? Exemples : Utilisateurs, environnement, normes, législation … EME1 EME2 system EME3

35 Fonctions de l’analyse fonctionnelle et use cases
Critère Niveau Flexibilité PF 1: Permettre aux passagers d’écouter une station radio sélectionnée. Niveau sonore Uniformisation du niveau sonore dans l’habitacle jusqu’à 90 DB 12,5% d’écart entre chacune des places + ou - 5% + ou – 10% PF 2: Permettre à l’opérateur de sélectionner une station radio pour l’écouter. Facilité de sélection Taux d’erreur Nombre de manipulations nécessaire : <=2 Moins d’une fois sur 10 Non 1 fois sur 20 PF 3: Permettre à l’opérateur de contrôler la restitution sonore de la station radio sélectionnée. Facilité de contrôle Précision Précision de + ou – 1 DB Précision de + ou – 2 DB

36 eFFBD de l’analyse fonctionnelle et diagrammes de séquences