2- Spécifier les exigences

Requirements
© D. Ribouchon

Spécification des exigences et

modélisation du métier

• Les exigences décrivent ce que le système d'information doit

faire, pour répondre aux besoins utilisateur, aux besoins métier

• Une bonne compréhension du fonctionnement du métier est

donc essentielle

• Le Unified Process propose une discipline de modélisation,

"modélisation du métier", dont le résultat constitue en
données d'entrée du processus de développement du système
"SI" proprement dit
© D. Ribouchon

§2 2

1
 La modélisation du métier: donnée d'entrée
du processus de développement

"Besoins utilisateur"

Modélisation du
Déploiement
métier

Vision utilisateur, Tests système

Exigences
("de qualification")
externe

Vision développeur,
Tests
interne Conception
d'intégration

Implémentation
© D. Ribouchon

§2 3

Plan du chapitre

• Comprendre le métier
– Description des processus métier
– Description des informations du domaine métier
• Spécifier les exigences
– Exigences fonctionnelles
• Définir l'environnement externe du système
• Définir les fonctionnalités
• Notations avancées
– Exigences non fonctionnelles
– Description détaillée des interfaces
© D. Ribouchon

§2 4

2
 Objectifs de la modélisation
du métier

• Décrire la future organisation du système métier (la société, le

département …), de façon formalisée

• La compréhension du métier est essentielle à la création

d'applications répondant aux besoins "métier"

• Permet de définir un vocabulaire commun entre les différentes

parties: utilisateurs finaux, développeurs …
© D. Ribouchon

§2 5

Approche générale

• En entrée: la description générale et informelle des besoins

• La modélisation du métier consiste à décrire de façon formelle:
– l'organisation du métier (processus et rôles)
– les informations métier
• Utilisation d'un formalisme rigoureux et lisible:
– texte
– notations graphiques

• UML, et son profil "business modeling" défini dans le RUP, est

un formalisme bien adapté
© D. Ribouchon

§2 6

3
 Définir le périmètre d'étude:
Le système métier – Business system

• Système métier = "L'organisation, ou la partie

de l'organisation concernée par le projet."

• Il peut s'agir d'un ou plusieurs départements

de l'entreprise, d'une activité transversale à plusieurs
départements ou interne à l'un d'eux

• Exemple:
– "l'activité commerciale (vente, réparation …) au sein du
garage de Mr Martin.
Dans un soucis de simplification, nous l'appellerons "le
garage"".
© D. Ribouchon

§2 7

Plan du chapitre

• Comprendre le métier
– Description des processus métier
– Description des informations du domaine métier
• Spécifier les exigences
– Exigences fonctionnelles
• Définir l'environnement externe du système
• Définir les fonctionnalités
• Notations avancées
– Exigences non fonctionnelles
– Description détaillée des interfaces
© D. Ribouchon

§2 8

4
 Organisation du métier: les processus
métier

• Description du système métier – business system:

l'entreprise, une activité au sein de l'entreprise:
– que fait-il? => définition de son objectif, les services offerts
– comment le fait-il? => définition de son organisation
(qui fait quoi?)

• Vue par processus: tournée vers le "service client"

• Vue par l'organisation interne: structuration de l'organisation
en "rôles internes"

=> L'organisation interne est au service des processus

© D. Ribouchon

§2 9

Projet French chic –

Comprendre les processus métier

• S'approprier la description des processus métier réalisée par

l'AMOA

• L'approche "l'organisation interne au service des processus" a-

t-elle été appliquée?

• Pour gagner en lisibilité, quel aspect pourrait être complété par

une description graphique?
© D. Ribouchon

§2 10

5
 Identification des rôles externes
Acteur métier – Business Actor

• Acteur métier = "un rôle externe vis-à-vis du système métier"

• Exemples:
– Client , Fournisseur de pièces détachées
– Employé (système métier "gestion du personnel"),
– Electeur (système métier "gestion des listes électorales")

• Notation UML: acteur de stéréotype <<business actor>> avec

icône:
© D. Ribouchon

Client
§2 11

Acteurs métier
du système métier "garage"

• Diagramme représentant les acteurs métier

Client Fournisseur de pièces Banque

• Description textuelle pour chaque acteur

Client: Client du garage, désirant un service du garage
(réparation, vente de voiture …). Un client peut être un
particulier ou une société.
© D. Ribouchon

§2 12

6
 Identification des processus métier –
Business process

• Un processus métier correspond à un service offert à un acteur

métier
• Processus => un début, une fin (service obtenu)

• Exemples pour le garage:

– Réparer une voiture
– Vendre une voiture d’occasion
– Laver une voiture
© D. Ribouchon

§2 13

Les processus métier du garage

Représentation graphique

• Diagramme représentant les processus métier

Reparer v oiture

Fournisseur de pièces

Vendre v oiture

Client

Lav er v oiture

• Notations UML:
– Cas d'utilisation – use case, stéréotype <<business use
case>>
– Diagramme de cas d'utilisation
© D. Ribouchon

§2 14

7
 Les fonctions dans l'entreprise
Unités d'organisation – Organization unit

• Structuration "statique" du système métier en pôles d'expertise

et en responsabilités fonctionnelles: unités d'organisation
• Sous-ensemble du système métier =>interne
• Correspond souvent à un service, un département dans
l'entreprise
• Exemples: service facturation, département achats …
• Notation UML: package, stéréotype <<organization unit>>

«organizationUnit»
Departement achats

Serv ice location

© D. Ribouchon

§2 15

Les unités d'organisation

du garage

• Diagramme représentant les unités d'organisation

«organizationUnit» «organizationUnit» «organizationUnit»

Serv ice mecanique Serv ice commercial Serv ice facturation

• Description textuelle pour chaque unité d'organisation

Service commercial: il est responsable de ….. Il est situé …
• Une unité d'organisation contient des intervenants métier
© D. Ribouchon

§2 16

8
 Intervenant métier – Business worker

• Un intervenant métier représente le rôle d'un individu au sein

du système métier
• C'est une rôle interne au système métier
• Exemples: secrétaire, mécanicien, vendeur …

• Notation UML: acteur ou classe de stéréotype <<business

worker>>

Secretaire commerciale
© D. Ribouchon

§2 17

Les intervenants métier du garage

• Diagramme représentant les intervenants métier de l'unité

d'organisation "Service commercial"

Secretaire commerciale Vendeur Responsable commercial

• Description textuelle pour chaque intervenant métier

© D. Ribouchon

§2 18

9
 Description détaillée des processus

• Décrire ce qui se passe depuis l'initiation du processus jusqu'à

sa fin – résultat significatif pour un acteur métier
• Le "qui fait quoi quand?"

• Processus "réparer une voiture":

– Le client apporte sa voiture au garage
– La secrétaire commerciale l'accueille et enregistre le travail
à réaliser
– Le mécanicien fait le diagnostic et répare la voiture
– La secrétaire commerciale prépare la facture
– La secrétaire commerciale restitue la voiture au client qui
effectue le paiement
© D. Ribouchon

§2 19

Description de processus
Notations

• Deux notations complémentaires:

– Description textuelle
– Description graphique:
• UML: activity diagram
• BPMN (Business Process Modeling Notation)
© D. Ribouchon

§2 20

10
 Diagramme d'activité –
Activity diagram

• De façon générale, utilisé pour représenter les différentes

étapes d'un processus ou d'un algorithme

• Dans la modélisation du métier, utilisé pour décrire de façon

synthétique le séquencement des activités d'un processus
métier

• Particulièrement adapté pour décrire:

– la logique conditionnelle et les itérations
– le parallélisme
© D. Ribouchon

§2 21

Activité – Activity
et transition

• Un diagramme d'activité est un graphe dans lequel chaque

nœud représente une activité du processus
• Les transitions sont déclenchées par la terminaison de
l'activité

Faire le diagnostic
Activité

Transition

Effectuer réparation
© D. Ribouchon

§2 22

11
 Etat initial et état final

Accueillir client

Faire le diagnostic

Effectuer réparation

Preparer facture

Restituer v oiture
© D. Ribouchon

§2 23

Conditions

• Transition sur décision, fusion - merge et condition de garde –

guard condition
Calculer montant

Condition de garde

[montant > 500] [montant <= 500]

décision
Obtenir autorisation

fusion
© D. Ribouchon

Payer

§2 24

12
 Parallélisme

• Pour décrire des activités concurrentes ou s'effectuant dans

n'importe quel ordre
• Transition sur débranchement fourchette - fork ,jointure - join
Entrer dans v oiture

Fork

Verifier retro Attacher ceinture

Join
© D. Ribouchon

Demarrer

§2 25

Exercice
Formalisme diagramme d'activité

• Utiliser un diagramme d'activité pour décrire la préparation d'une

boisson par une personne:
– La personne a le choix entre café et Orangina
– Activités pour préparer un café:
• Mettre le filtre dans la machine
• Mettre le café dans le filtre
• Mettre l'eau dans le réservoir
• Prendre une tasse
• Allumer la machine
• Verser le café
• Boire
– Activités pour préparer l'Orangina:
• Prendre une canette
• Boire
© D. Ribouchon

§2 26

13
 Partition

:Secretaire :Mecanicien

• Pour affecter des

responsabilités aux activités
• Partition ou ligne de nage - Accueillir client
swimlane
Faire le diagnostic

Effectuer réparation

Preparer facture

Restituer v oiture
© D. Ribouchon

§2 27

Responsables d'activité partagée

:Secretaire :Mecanicien

• Problème de l'implication
partagée: lors de l'activité
"Accueillir client", le mécanicien et
la secrétaire sont impliqués (Mécanicien)
Accueillir
client
•
Faire le
Conseil: privilégier le responsable diagnostic
de l'activité (ligne de nage), et
nommer les autres entités
(acteurs, intervenants) Effectuer
réparation
concernées
Preparer
facture

Restituer
v oiture
© D. Ribouchon

§2 28

14
 Echange d'information
entre activités
:Secretaire :Mecanicien

• Data store et flot d'objet –

object flow
Accueillir client

«datastore»
:Reparation
[affectee]

Faire le diagnostic

Effectuer réparation

«datastore»
:Reparation
[terminee]
© D. Ribouchon

Preparer facture

§2 29

Description textuelle du processus

• Description exhaustive, détaillant chaque activité

• Faire ressortir les activités effectuées via le SI

• Exemple "Processus réparer une voiture"

© D. Ribouchon

§2 30

15
 "Processus réparer une voiture"

Résumé
Ce processus correspond à la réparation d'une voiture d'un client, depuis l'accueil du client
jusqu'à la récupération de la voiture par le client.
Flux normal
Ce processus se décompose en 5 grandes activités:
Accueil du client
Le client apporte sa voiture et décrit le travail à faire à la secrétaire.
La secrétaire enregistre la réparation et l'affecte à un mécanicien via le SI.
La secrétaire téléphone au mécanicien.
Diagnostic …
Réparation … activité effectuée via le SI
Préparation de la facture …
Restitution de la voiture …

Flux alternatif
Non récupération de la voiture: si après 20 jours …
© D. Ribouchon

§2 31

Modèle métier/processus
Structuration du navigateur
© D. Ribouchon

§2 32

16
 Projet French chic –
Compléter la description d'un processus par un
diagramme d'activité

• Décrire de façon synthétique le déroulement normal du

processus métier "Commander par le Web" à l'aide d'un
diagramme d'activité
© D. Ribouchon

§2 33

Plan du chapitre

• Comprendre le métier
– Description des processus métier
– Description des informations du domaine métier
• Spécifier les exigences
– Exigences fonctionnelles
• Définir l'environnement externe du système
• Définir les fonctionnalités
• Notations avancées
– Exigences non fonctionnelles
– Description détaillée des interfaces
© D. Ribouchon

§2 34

17
 Description des informations du domaine
métier

• Il est possible d'utiliser UML pour décrire de façon purement

conceptuelle (i.e. non technique)
les informations métier:
– Description structurelle, statique: diagramme de classe
– Description des états métier: diagramme de machine à états

• Cette modélisation est réalisée en complément d'un glossaire

métier
© D. Ribouchon

§2 35

Des classes pour décrire des informations

métier

• Classe <<business entity>>: représente un ensemble

cohérent d'informations métier (e.g. un type de fiche, de dossier
…)
«business entity»
Voiture

immatriculation
dateMiseEnCirculation
couleur Voiture

• Chaque information/donnée métier est représentée par un

attribut
• Les opérations ne sont pas pertinentes
© D. Ribouchon

§2 36

18
 Représentation de relations entre
informations

• Dans un diagramme de classe:

«business entity» «business entity»

Client Voiture

1 1..* immatriculation
dateMiseEnCirculation
couleur

0..*

«business entity» «business entity»

Reparation Facture
etat 1 0..1
© D. Ribouchon

§2 37

Description des états métier

• Dans un diagramme de machine à états

• Ne mentionner que les "états métier", i.e. non techniques

Affectee
fin reparation

Terminee

facturation

Facturee
recuperation

Recuperee

apres (10 ans)

© D. Ribouchon

§2 38

19
 Modèle métier/informations
Structuration du navigateur
© D. Ribouchon

§2 39

Projet French chic –

S'approprier les informations du domaine

• Comprendre les informations du domaine du système métier

"Ventes & stock du siège de French chic"

• L'activité "Modélisation du métier" est-elle finalisée? Peut-on

quand même passer à l'activité "Exigences"?
© D. Ribouchon

§2 40

20
 Modélisation du métier
Synthèse (1/3)

• Description des processus métier

– Identification des processus métier et des rôles externes
(acteurs métier)
Reparer v oiture

Fournisseur de pièces

Vendre v oiture

Client

– Identification des rôles internes (intervenant métier)

© D. Ribouchon

Secretaire commerciale Vendeur Responsable commercial

§2 41

Modélisation du métier
Synthèse (2/3)

• Description des processus métier - suite

– Description des processus: diagramme d'activité
:Secretaire :Mecanicien

Accueillir client

«datastore»
:Reparation
[affectee]

Faire le diagnostic

Effectuer réparation

«datastore»
:Reparation
[terminee]
© D. Ribouchon

Preparer facture

§2 42

21
 Modélisation du métier
Synthèse (3/3)

• Description des informations du domaine métier: diagrammes

de classe et de machine d'états

«business entity» «business entity»

Client Voiture
Affectee
1 1..* immatriculation fin reparation
dateMiseEnCirculation
couleur
Terminee
1

0..* facturation

«business entity» Facturee

Reparation recuperation

etat Recuperee

apres (10 ans)

© D. Ribouchon

§2 43

Plan du chapitre

• Comprendre le métier
– Description des processus métier
– Description des informations du domaine métier
• Spécifier les exigences
– Exigences fonctionnelles
• Définir l'environnement externe du système
• Définir les fonctionnalités
• Notations avancées
– Exigences non fonctionnelles
– Description détaillée des interfaces
© D. Ribouchon

§2 44

22
 La spécification des exigences
dans le Processus Unifié

"Besoins utilisateur"

Modélisation du
Déploiement
métier

Vision utilisateur, Tests système

Exigences
("de qualification")
externe

Vision développeur,
Tests
interne Conception
d'intégration

Implémentation
© D. Ribouchon

§2 45

Objectifs de la spécification
des exigences

• Définir ce que le système d'information fait: ce qui est visible

à l'extérieur du système
• Vision boîte noire du SI
• L'audience de cette description est:
– l'utilisateur/MOA
– l'équipe de développement/MOE
– les spécificateurs des tests

• Aussi appelé "Spécifications externes du système"

© D. Ribouchon

§2 46

23
 Avant de formaliser, il faut "créer" …

• Cette activité est une activité très créative: il s'agit de définir le

nouveau système

• Elle est réalisée en associant étroitement la MOA

(brainstorming, ateliers, …)
© D. Ribouchon

§2 47

Formalisation des exigences sous la

forme de spécifications externes du SI

• Fournir un cahier des charges formalisé, structuré

• A partir de:
– la description générale et informelle des besoins
– le modèle du métier

• Premier niveau de structuration:

– Exigences fonctionnelles
– Exigences non fonctionnelles
– Description détaillée des interfaces
© D. Ribouchon

§2 48

24
 Plan du chapitre

• Comprendre le métier
– Description des processus métier
– Description des informations du domaine métier
• Spécifier les exigences
– Exigences fonctionnelles
• Définir l'environnement externe du système
• Définir les fonctionnalités
• Notations avancées
– Exigences non fonctionnelles
– Description détaillée des interfaces
© D. Ribouchon

§2 49

Exigences fonctionnelles

• Les exigences fonctionnelles décrivent les caractéristiques

fonctionnelles du système d’information. Une exigence
fonctionnelle décrit :
– une information gérée par le système
– un comportement ou une fonction réalisé par le système,
au travers d'interactions entre le système et les entités
extérieures au système
© D. Ribouchon

§2 50

25
 Projet French chic -
Exigences fonctionnelles sur la gestion des
informations

• Observer dans les spécifications des exigences la façon dont

ces exigences ont été formalisées
© D. Ribouchon

§2 51

Plan du chapitre

• Comprendre le métier
– Description des processus métier
– Description des informations du domaine métier
• Spécifier les exigences
– Exigences fonctionnelles
• Définir l'environnement externe du système
• Définir les fonctionnalités
• Notations avancées
– Exigences non fonctionnelles
– Description détaillée des interfaces
© D. Ribouchon

§2 52

26
 Définir le périmètre du système

• Généralement, le périmètre est un sous-ensemble du SI du

système métier

• Dans le cas de "French chic", il s'agit du SI "Ventes & stock"

© D. Ribouchon

§2 53

Projet French chic -

Définir l'environnement externe

• Par rapport au périmètre défini, identifier les utilisateurs du

système
© D. Ribouchon

§2 54

27
 Acteur – Actor
Définition UML

• Acteur = "Classeur contenant les entités extérieures à un

sujet et qui interagissent directement avec lui. Il caractérise un
rôle joué par un utilisateur ou un ensemble d'utilisateurs en
rapport avec le sujet."

Secretaire

• Dans le cas des exigences du système logiciel, le sujet est le

système logiciel.
© D. Ribouchon

§2 55

Acteurs non humains

• Un autre système peut aussi être considéré comme acteur

Ex: le SI du garage s'interface à un autre système qui gère la
nomenclature:

Sys Nomenclature
© D. Ribouchon

§2 56

28
 Démarche de découverte
des acteurs humains

• Utiliser le modèle du métier

=> acteurs et intervenants métier

SI Secrétaire
Fournisseur pièces

Client Mécanicien
Le garage (système métier)
© D. Ribouchon

§2 57

Les acteurs du SI du garage

• Diagramme de cas d'utilisation avec uniquement des acteurs:

Secretaire Directeur Vendeur Sys Nomenclature

• Une alternative: le système logiciel est explicitement

représenté:

Vendeur

Directeur

SI garage

Sys Nomenclature
© D. Ribouchon

§2 Secretaire
58

29
 Plan du chapitre

• Comprendre le métier
– Description des processus métier
– Description des informations du domaine métier
• Spécifier les exigences
– Exigences fonctionnelles
• Définir l'environnement externe du système
• Définir les fonctionnalités
• Notations avancées
– Exigences non fonctionnelles
– Description détaillée des interfaces
© D. Ribouchon

§2 59

Projet French chic -

Identifier les fonctionnalités

• Pour chaque acteur humain, définir les "fonctionnalités" offertes

par le système
© D. Ribouchon

§2 60

30
 Cas d'utilisation – use case
Définition UML

• Cas d'utilisation = "Unité cohérente de fonctionnalité (i.e.

service de qualité) fournie par un système qui se manifeste par
des séquences de messages échangés entre le système et un
ou plusieurs acteurs, ainsi que par des actions accomplies par
le système."

• Un cas d'utilisation raconte une "histoire" entre un acteur et le

système

• Description orientée tests

© D. Ribouchon

§2 61

Diagramme de cas d'utilisation –

Use Case Diagram

• Décrit graphiquement les relations entre les acteurs et les cas

d'utilisation
• La relation est une association <<communicate>>
• Le placement de l'acteur peut préciser l'initiateur de la
communication

communique communique
initiateur

Preparer facture

Secretaire
Sys Nomenclature
© D. Ribouchon

§2 62

31
 Diagramme de cas d'utilisation (2)

Creer reparation

Secretaire

Preparer facture

Sys Nomenclature

Completer reparation

Mecanicien

• A noter: pas de notion temporelle

© D. Ribouchon

§2 63

Démarche de découverte
des cas d'utilisation

• Utiliser le modèle du métier :Secretaire :Mecanicien

=> activités informatisées

des processus métier
Accueillir client

Faire le diagnostic

Effectuer réparation

Preparer facture

Récuperer v oiture
© D. Ribouchon

§2 64

32
 Description textuelle
de cas d'utilisation

• Pour décrire en détails les interactions entre le système et les

acteurs concernés

• Plan type
– Résumé
– Acteur(s)
– Précondition
– Postcondition
– Flux normal d'évènements
– Flux alternatifs et exceptions
– Exigences non fonctionnelles
© D. Ribouchon

§2 65

Description textuelle – Exemple

Préparer une facture

Résumé
Ce cas d'utilisation décrit la préparation d'une facture de réparation par
la secrétaire, depuis la demande de préparation de la facture jusqu'à
son impression.
Precondition
– La réparation est dans l'état "terminée"
– L'écran courant est "écran d'accueil"
Postcondition
– La réparation est dans l'état "facturée". Une nouvelle facture est
enregistrée dans le système, dans l'état "imprimée".
– L'écran courant est "écran facture"
© D. Ribouchon

§2 66

33
 Préparer une facture - suite

Flux normal

Le CU commence quand la secrétaire demande à préparer la Facture

1. Sélection de la Réparation
1. Le système affiche toutes les réparations dans l'état "terminée" - écran
liste réparations
2. La secrétaire sélectionne une réparation
3. Le système affiche les informations de la réparation – écran réparation:
• la date de la réparation
• pour chaque ligne de réparation:
• titre
• quantité
• code de Nomenclature (si présent)
© D. Ribouchon

§2 67

Préparer une facture - fin

2. Création de la facture
1. La secrétaire demande la facturation
2. Le système calcule le montant de la facture:
• cf règle de calcul métier
• si des pièces ont été changées, le système envoie une demande de tarif au
système de nomenclature (except "erreur nomenclature")
• le système crée la facture et l'affiche - écran facture"
3. Impression de la facture
• La secrétaire demande l'impression de la facture
• Le système l'imprime et passe son état à "imprimée"
• Le cas d'utilisation est terminé
Flux alternatifs
Except erreur nomenclature:
Si le système de nomenclature renvoie une erreur, le système …

Exigences non fonctionnelles

La Facture est imprimée sur un papier spécial, référence 43ER
© D. Ribouchon

§2 68

34
 Description de CU et IHM

• L'interface utilisateur n'est pas détaillée d'un point de vue

graphique
© D. Ribouchon

§2 69

Scénario de cas d'utilisation

• Scénario = un chemin particulier dans un CU

• Exemple: Préparer facture – des pièces ont été changées

• Choisir des scénarios significatifs pour illustrer les cas

d'utilisation

• Descriptions des scénarios:

– Textuellement, ou bien
– Avec des diagrammes de séquence
© D. Ribouchon

§2 70

35
 Diagramme de séquence
Sequence Diagram
1 instance du système
:SI garage

:Secretaire :Sys Nomenclature

1 instance d'acteur
demande preparation facture()

affichage écran liste reparations()

selection reparation()

affichag écran reparation()

demande facturation()

requeteTarif()

tarif()

affichage écran facture()

• Le système est vu ...

comme une boîte noire

© D. Ribouchon

"Messages"
§2 71

Projet French chic -

Décrire un scénario de CU

• Illustrer un scénario significatif du cas d'utilisation "Passer

commande en ligne"
© D. Ribouchon

§2 72

36
 Plan du chapitre

• Comprendre le métier
– Description des processus métier
– Description des informations du domaine métier
• Spécifier les exigences
– Exigences fonctionnelles
• Définir l'environnement externe du système
• Définir les fonctionnalités
• Notations avancées
– Exigences non fonctionnelles
– Description détaillée des interfaces
© D. Ribouchon

§2 73

Inclusion entre cas d'utilisation –

Include

• Pour factoriser une partie commune à plusieurs cas d'utilisation

• Représentée par une relation de dépendance <<include>>
entre le cas d’utilisation de base et le cas d’utilisation inclus

Retirer argent

«include»

Faire un v irement S'identifier

«include»
Client

«include»
© D. Ribouchon

Consulter compte

§2 74

37
 Extension - Extend

• Sous-fonctionnalité étendant la fonctionnalité de base

Notifier le retrait par

Retirer argent SMS
«extend»

Client
© D. Ribouchon

§2 75

Généralisation entre acteurs

Comptable

Employe comptable Responsable comptable

© D. Ribouchon

§2 76

38
 Synthétiser la navigation
entre écrans

• Avec un diagramme de machine à états – state machine

diagram

demarrage appli

ecran accueil

demande facturation

ecran liste selection reparation

ecran reparation
reparations
revenir

demande facturation

ecran facture
© D. Ribouchon

§2 77

Structuration type du navigateur

© D. Ribouchon

§2 78

39
 Plan du chapitre

• Comprendre le métier
– Description des processus métier
– Description des informations du domaine métier
• Spécifier les exigences
– Exigences fonctionnelles
• Définir l'environnement externe du système
• Définir les fonctionnalités
• Notations avancées
– Exigences non fonctionnelles
– Description détaillée des interfaces
© D. Ribouchon

§2 79

L'approche "FURPS"

• 3 catégories d'exigences non fonctionnelles:

– Utilisabilité - Usability: ergonomie, esthétique …
– Robustesse/fiabilité – Reliability: fréquence et sévérité des
fautes, températures min/max …
– Performance: temps de réponse, charge, volume des
données, quantité mémoire …

• 1 catégorie pour la qualité interne:

– "Supportabilité" - Supportability: maintenabilité, évolutivité,
réutilisabilité, portabilité, testabilité, intégration à l'existant …
et aussi, sur le court terme, la "développabilité"
© D. Ribouchon

§2 80

40
 La notion de "requirement" en UML

• Les exigences non fonctionnelles sont généralement exprimées

de façon textuelle, sous la forme de petites exigences
élémentaires
• Certaines extensions d'UML (outils, profil UML SysML …),
propose une notation pour gérer les exigences sous cette forme
© D. Ribouchon

§2 81

Architecture technique et exigences

• L'architecture technique est choisie en réponse aux exigences

non fonctionnelles

Client leger Serv eur Web - Serv eur de

J2EE Web donnees -
container Oracle

Secretaire

• Définie en conception, sauf en cas de besoin d'intégration à un

existant
© D. Ribouchon

§2 82

41
 Projet French chic -
Les exigences non fonctionnelles

• Observer la façon dont les exigences non fonctionnelles ont été

formalisées
© D. Ribouchon

§2 83

Plan du chapitre

• Comprendre le métier
– Description des processus métier
– Description des informations du domaine métier
• Spécifier les exigences
– Exigences fonctionnelles
• Définir l'environnement externe du système
• Définir les fonctionnalités
• Notations avancées
– Exigences non fonctionnelles
– Description détaillée des interfaces
© D. Ribouchon

§2 84

42
 Description détaillée des interfaces
entre système et acteur humain

• Conception graphique des écrans

• A partir de la description des cas d'utilisation et des exigences
d’utilisabilité
• Généralement, pas de modélisation mais élaboration à l'aide
d'un outil de design graphique d'écran
© D. Ribouchon

§2 85

Description détaillée des interfaces

entre système et acteur non humain

• Description des protocoles de communication

• UML peut être utilisé pour la description fonctionnelle des
messages, sous la forme de classe <<interface>>

SI garage

NomenclatureServices
Sys Nomenclature

«interface»
NomenclatureServices SI garage
+ reqTarif(String) : long
+ reqIsCatalogueDispo() : Boolean

Sys Nomenclature
© D. Ribouchon

§2 86

43
 Projet French chic -
La description détaillée des interfaces

• Observer la façon dont les interfaces ont été formalisées de

façon détaillée
© D. Ribouchon

§2 87

Projet French chic -

On continue?

• L'activité "exigences" est-elle finalisée? Peut-on quand même

passer à l'activité "conception"?

• Soyons agiles! Prenons connaissance du plan de

développement du projet
© D. Ribouchon

§2 88

44
 Spécifier les exigences
Synthèse

• Spécifier les exigences fonctionnelles

– Acteurs et cas d'utilisation – use cas diagram

Creer reparation

Secretaire

Preparer facture

Sys Nomenclature

– Description détaillée des cas d'utilisation - textuelle

© D. Ribouchon

§2 89

Spécifier les exigences

Synthèse (2)

• Spécifier les exigences fonctionnelles – suite

– Scénario de cas d'utilisation – sequence diagram

:SI garage

:Secretaire :Sys Nomenclature

demande preparation facture()

ecran liste reparations()

selection reparation()

...
© D. Ribouchon

§2 90

45
 Spécifier les exigences
Synthèse (3)

• Spécifier les exigences non fonctionnelles: catégories "URPS"

• Description détaillée des interfaces

SI garage

NomenclatureServices
Sys Nomenclature
© D. Ribouchon

§2 91

Fin 2 - spécifier les exigences

© D. Ribouchon

§2 92

46
 Plan du cours

• Introduction
• Prise en main: COO UML/POO et processus de développement
• Spécifier les exigences du système
– Comprendre le métier
– Spécifier les exigences
• Concevoir le système
– Définir la plateforme technique
– Concevoir le code source
– Concevoir les composants déployables
• Pour aller plus loin
© D. Ribouchon

§2 93

La conception
dans le Processus Unifié

"Besoins utilisateur"

Modélisation du
Déploiement
métier

Vision utilisateur, Tests système

Exigences
("de qualification")
externe

Vision développeur,
Tests
interne Conception
d'intégration

Implémentation
© D. Ribouchon

§2 94

47