Ingénierie Système

Analyse des besoins

3/12/2010Catherine Letondal catherine.letondal@enac.fr

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

2

Analyse de besoins

+ diagrammes activité (UC complexes)+ organisation UC packages UML

L’analyse de besoins dans la démarche

A/COO

3

Principes et définitions de base

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

5

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

6

Acteur principal ou secondaire

Acteur principal 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)

7

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

8

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)

9

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

10

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)

11

Etude d’un guichet automatique de banque (GAB)

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

13

Exigences• Le GAB offre les services suivants :

1. Distribution d’argent à tout porteur de carte de crédit, via un lecteur de carte et un distributeur de billets

2. 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 : 3. Toutes les transactions sont sécurisées4. Il est parfois nécessaire de recharger le

distributeur

14

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) 15

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.

16

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– Néant

Acteurs principaux (ceux pour qui lescas d’utilisation produisent un résultat observable)

Acteurs secondaires (les autres participants des cas d’utilisation sollicitéspour des informationscomplémentaires)17

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ème18

Décrire les cas d’utilisation

19

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.

20

Décrire textuellement les cas d’utilisation (ex. « Retirer de l’argent » )

Sommaire d’identificationTitre : 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 : 1.6Responsable : Luis Basora

21

Décrire textuellement les cas d’utilisation (ex. « Retirer de l’argent » )Description des scénariosPré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 nominal1. Le Porteur de carte introduit sa carte dans le le lecteur de cartes du

GAB.2. Le GAB vérifie que la carte introduite est bien une carte bancaire.3. Le GAB demande au Porteur de carte de saisir son code d’identification.4. Le Porteur de carte saisit son code d’identification.5. Le GAB compare le code code d’identification avec celui qui est codé

sur la puce de la carte.6. Le GAB demande une autorisation au Système d’autorisation.7. Le Système d’autorisation donne son accord et indique le crédit

hebdomadaire.8. …8. Le porteur de carte prend les billets et le ticket.22

Décrire textuellement les cas d’utilisation (ex. « Retirer de l’argent » )

Enchaînements alternatifsA1 : code d’identification provisoirement erronéL’enchaînement A1 démarre au point 5 du scénario nominal.6. Le GAB indique au Porteur de carte que le code est erroné, pour la

première ou deuxième fois.7. Le GAB enregistre l’échec sur la carte.Le scénario nominal reprend au point 3.…

Enchaînements d’erreurE1 : carte non-valideL’enchaînement E1 démarre au point 2 du scénario nominal.3. 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.

…23

Décrire textuellement les cas d’utilisation (ex. « Retirer de l’argent » )PostconditionsLa 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 fonctionnellesContraintes

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

24

Décrire textuellement les cas d’utilisation (ex. « Retirer de l’argent » )

Besoins IHMLes 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

25

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

26

Diagrammes UML dynamiques les plus utilisés pour les cas d’utilisation

Pour illustrer des scénarios particuliersPour documenter les cas d’utilisation27

Ex. Diagramme d’activité du cas d’utilisation « Retirer de l’argent »

28

Diagrammes de séquence système

29

• 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

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

30

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

31

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

haute 2

Déposer de l’argent haut moyenne

2

Recharger le distributeur bas haute 3

Maintenir l’état opérationnel bas haute 3

À chaque cas d’utilisation, on peut affecter :• un risque (haut, moyen, bas),• une priorité fonctionnelle (haute, moyenne, basse).32

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’architecture33

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 …

systemEME1 EME2

EME3

35

Fonctions de l’analyse fonctionnelle et use cases

Fonction 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

Nombre de manipulations nécessaire : <=2

Précision de + ou – 1 DB

Non

Précision de + ou – 2 DB

36

eFFBD de l’analyse fonctionnelle etdiagrammes de séquences