Processus  de  conception  de  
systèmes  d'information  
(C352)  
 
 
 
Pascal  ANDRÉ,  Alain  VAILLY  
(Université  de  Nantes)  
juin  2016  
 
 
version  imprimable  du  cours  
  
Chapitre  3  
Bien  analyser  son  besoin  
La  première  étape,  incontournable,  d’un  développement  logiciel  est  celle  de  la  définition  des  
besoins.   Elle   va   permettre   de   préciser   les   objectifs,   les   services   attendus   et   les   principales  
contraintes  pesant  sur  le  système  étudié.  Qu’il  s’agisse  d’un  système  existant  qu’il  faut  reprendre  
ou   d’une   création   ex   nihilo,   quel   que   soit   le   type   d’application   informatique   (système  
d’information,   système   industriel,   système   embarqué...),   la   première   étape   est   celle   qui   va  
permettre  de  comprendre  ce  que  veut  le  client.  
Cette  étude  n'est  pas  une  étude  théorique,  abstraite.  Elle  intervient  dans  un  contexte  précis,  
dans   une   organisation   ayant   ses   objectifs,   ses   lois,   ses   stratégies,   ses   contraintes...   L'analyse   du  
besoin   ne   peut   ignorer   cet   environnement   sauf   à   se   condamner   à   l'échec.   Elle   est   réalisée   par   des  
hommes  sur  des  hommes  et  cette  dimension  doit  également  être  prise  en  compte  (voir  infra).  
Ceci  est  valable  quel  que  soit  le  type  de  développement  mis  en  œuvre.  Que  l’on  travaille  par  
itérations  successives,  que  l’on  fasse  de  l’Extreme  Programming,  que  l'on  pratique  l'agilité  ou  que  
l’on   travaille   “à   l’ancienne”,   avec   un   style   en   cascade,   en   V,   en   W...   cette   étape   de   découverte   est  
indispensable.  
Elle  dépasse  du  reste  largement  le  cadre  du  développement  logiciel  et  se  retrouve  dans  tous  
les   processus   qui   mènent   à   la   création   d’un   artefact.   Que   veut   le   client   ?   Quels   sont   les   objectifs   à  
atteindre   ?   Ce   sont   des   questions   quasi   universelles.   Ne   pas   y   répondre   avant   de   se   lancer   dans   la  
conception  conduira  presque  inévitablement  à  la  catastrophe,  le  résultat  obtenu  n’ayant  aucune  
chance  de  correspondre  à  ce  qui  est  attendu.  C’est  aussi  l’étape  de  tous  les  dangers,  une  erreur  
faite  à  ce  niveau  risquant,  si  elle  n’est  pas  découverte  et  corrigée  très  vite,  de  conduire  à  un  outil  
inadapté.  Sa  non  correction  entraînera  “au  mieux”  de  mauvais  usages,  au  pire  un  abandon  pur  et  
simple  de  cet  outil.  
L’analyste  qui  se  situe  à  ce  niveau  est  pris,  quelque  part,  entre  deux  feux  :  d’un  côté,  il  doit  
composer  avec  des  personnes,  de  l’autre  il  ne  peut  pas  ignorer  le  mode  de  fonctionnement  de  la  
machine  sur  laquelle  le  logiciel  va  fonctionner.  
La  dimension  humaine  de  cette  étape  intervient  à  au  moins  deux  niveaux  :  les  informations  
dont   il   a   besoin   lui   seront   fournies   par   des   Hommes   (avec   tout   ce   que   cela   peut   comporter  
d’imprécision,   d’erreur,   de   subjectivité,   de   mauvaise   foi   quelque   fois)   et   les   procédures   qu’il   va  
créer,  développer,  seront  utilisées  par  des  Hommes  (avec  tout  ce  que  cela  induit  comme  risques  
d’erreurs,  de  mauvaises  pratiques,  de  peu  de  fiabilité).  
La   dimension   mécanique   est   celle   de   la   Machine.   Les   logiciels   seront   exécutés   par   ces  
machines.  Celles-­‐ci  font  strictement  (et  sans  état  d’âme)  ce  qu’on  leur  demande  de  faire.  Un  ordre  
erroné  sera  exécuté  sans  retard,  quelques  qu’en  soient  les  conséquences.  Une  ambiguïté  dans  une  

Chapitre  3  –  Bien  analyser  son  besoin   C352   2/71  

chaîne  de  commande  bloquera  le  mécanisme.  Par   ailleurs,   ces   machines   ne   sont   pas   fiables   à  100  
%.  Elles  connaissent,  elles  aussi,  des  pannes  (bourrage  papier,  panne  d’électricité...).  
L’analyste   devra   donc   prendre   en   compte   le   risque   de   comportement   dégradé   des  
équipements.  Face  à  ce  défi  (comprendre  le  monde  des  Hommes  et  le  reproduire  de  façon  telle  
que   des   Machines   puissent   le   mettre   en   œuvre),   il   (lui-­‐même   appartenant   au   monde   des  
Hommes)  va  être  aidé  par  son  expérience,  sa  rigueur  et  quelques  outils.  Son  expérience  fera  qu’il  
se   servira   de   ce   qu’il   a   fait   auparavant   pour   garder   les   bonnes   pratiques   et   ne   pas   refaire   les  
mêmes   erreurs.   Elle   lui   permettra   également,   lorsque   cela   est   possible,   de   réutiliser   une   partie  
d’un  ancien  logiciel.  Sa  rigueur  lui  évitera  de  laisser  passer  dans  les  documents  qu’il  produira  des  
informations  incohérentes.  Elle  lui  permettra  également  de  poser  les  bonnes  questions,  à  la  fois  
pour  dresser  un  constat  précis  de  l’existant  et  pour  rendre  plus  clair  un  point  obscur.  
Les   outils   sont   essentiellement   d’ordre   méthodologique.   Le   fait   d’utiliser   une   méthode   lui  
apportera  une  aide  au  niveau  de  la  notation,  une  logique  dans  le  déroulement  de  son  processus  
d’analyse   et   des   assistants   logiciels   qui   lui   feront   gagner   du   temps   lors   de   la   rédaction   (et   qui  
pourront  aussi  détecter  pour  lui  incohérences  et/ou  erreurs).  
Ce   chapitre   aborde   successivement   la   définition   du   périmètre   d'intervention,   celle   de  
l'équipe,  l'expression  des  besoins  fonctionnels  puis  non  fonctionnels  et  la  préparation  des  tests  de  
validation   qui   seront   réalisés   en   fin   de   "parcours".   Il   comprend   une   application   des   techniques  
présentées   tout   au   long   du   chapitre   à   un   cas   "concret",   celui   d'un   compte   bancaire.   Ce   cas   servira  
de  fil  rouge  tout  au  long  du  cours.  
Il   se   poursuit   par   une   approche   rapide,   mais   complète,   de   la   phase   d'analyse   qui   suit  
l'analyse  des  besoins.  Bien  que  n'en  faisant  pas  stricto  sensu  partie,  il  nous  a  paru  intéressant  de  
regrouper  les  deux.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   3/71  

  

Plan  
 
I.   Introduction................................................................................................................................................ 6  
A.   Localisation  dans  le  cycle  de  vie  du  logiciel........................................................................................... 6  
B.   Enjeux  et  risques.................................................................................................................................... 7  
C.   Processus  et  résultats ............................................................................................................................ 7  
D.   Ouvrages  de  référence .......................................................................................................................... 8  
II.   Bien  définir  son  périmètre  d'intervention ................................................................................................. 9  
A.   Différentes  "zones"  composant  le  périmètre........................................................................................ 9  
B.   Résultats  produits................................................................................................................................ 10  
C.   Application  au  cas  «  compte  bancaire  » .............................................................................................. 11  
III.   Mettre  en  place  une  équipe ................................................................................................................... 12  
A.   Catégories  de  personnes ..................................................................................................................... 12  
B.   Maîtrise  d'ouvrage,  maîtrise  d'œuvre ................................................................................................. 12  
C.   Composition  de  l'équipe...................................................................................................................... 13  
D.   Application  au  cas  «  compte  bancaire  » .............................................................................................. 13  
IV.   Exprimer  les  besoins  fonctionnels .......................................................................................................... 14  
A.   Bref  rappel  de  la  notation ................................................................................................................... 14  
B.   Processus  de  mise  en  évidence  des  besoins........................................................................................ 19  
C.   Application  au  cas  «  compte  bancaire  » .............................................................................................. 23  
V.   Exprimer  des  besoins  non  fonctionnels................................................................................................... 24  
A.   Qualité  et  contraintes.......................................................................................................................... 24  
B.   Application  au  cas  «  compte  bancaire  » .............................................................................................. 25  
VI.   Préparer  les  tests.................................................................................................................................... 26  
A.   Tests  de  type  «  boîte  noire»................................................................................................................ 26  
B.   Mesures  destinées  au  contrôle  qualité ............................................................................................... 28  
C.   Application  au  cas  «  compte  bancaire  » .............................................................................................. 29  
VII.   Analyse  de  l'application......................................................................................................................... 30  
A.   Objectif  central  de  cette  étape............................................................................................................ 30  
B.   Hypothèses  de  travail .......................................................................................................................... 31  
C.   Techniques  utilisées............................................................................................................................. 33  
D.   Processus  d'analyse............................................................................................................................. 38  
VIII.   Application  au  cas  «  compte  bancaire  » ............................................................................................... 40  
A.   Périmètre  d'intervention..................................................................................................................... 42  

Chapitre  3  –  Bien  analyser  son  besoin   C352   4/71  

 B.   Équipes ................................................................................................................................................ 42  
C.   Besoins  fonctionnels............................................................................................................................ 43  
D.   Besoins  non  fonctionnels .................................................................................................................... 54  
E.   Préparation  aux  tests........................................................................................................................... 54  
F.   Analyse  de  l'application ....................................................................................................................... 55  
G.   Eléments  de  gestion  de  projet  et  support........................................................................................... 67  
IX.   Conclusion .............................................................................................................................................. 70  
X.   Références ............................................................................................................................................... 71  
 

Chapitre  3  –  Bien  analyser  son  besoin   C352   5/71  

I. Introduction  
A. Localisation  dans  le  cycle  de  vie  du  logiciel  
Pour   mieux   localiser   l’activité   de   définition   des   besoins,   reprenons   la   figure   10   et  
positionnons  cette  activité  dans  le  processus  global.  L’analyse  des  besoins  est  la  première  étape  
mentionnée  du  côté  fonctionnel  (ou  applicatif)  comme  le  met  en  évidence  la  figure  suivante.  
 

 
figure  1  -­‐  processus  2TUP  

Il  s'agit  d'étudier  ce  que  demande  l'utilisateur,  de  le  formaliser,  puis  de  l'analyser  afin  d'en  
comprendre  les  tenants  et  les  aboutissants.  On  se  trouve  dans  l'espace  du  problème,  le  résultat  de  
cette   étape   étant   une   vision   complète   du   milieu   dans   lequel   les   développeurs   vont   devoir   se  
mouvoir.  
L'accent   est   essentiellement   mis   sur   les   besoins   fonctionnels,   c'est   à   dire   sur   ce   que   fait  
l'organisation  dans  laquelle  on  va  agir  et  ce  qu'elle  devra  faire.  Ces  "fonctions"  devront  être  prises  
en  charge  par  le  logiciel.  Il  y  a  donc,  quelque  part,  substitution  d'un  outil  humain  (en  totalité  ou  
partiellement)   par   un   outil   informatique.   Cette   substitution   ne   sera   complète   que   si  
l'environnement   a   été   correctement   étudié,   analysé,   compris...   Par   "dessus"   se   grefferont   les  
modifications  apportées  à  l'existant  pour  prendre  en  compte  les  nouveaux  besoins.  
Ces   besoins   devront,   plus   globalement,   être   positionnés   par   rapport   à   la   stratégie   de  
l'entreprise,  à  son  schéma  directeur.  Ils  prendront  aussi  en  compte  d'autres  éléments  comme  la  
disponibilité  des  équipes  de  la  DSI,  la  vie  de  l'entreprise...  
Outre  les  besoins  fonctionnels,  d'autres  demandes  sont  mises  en  avant  concernant  la  qualité  
des  produits  créés  et  les  contraintes  auxquelles  seront  soumis  ces  produits.  Tout  ceci  fait  partie  de  
ce  que  l'on  appelle  communément  les  besoins  non  fonctionnels.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   6/71  

B. Enjeux  et  risques  
Les   enjeux   de   cette   étape   sont   importants   :   rater   ne   serait-­‐ce   qu'une   infime   partie   des  
besoins  reviendrait  à  construire  un  outil  incomplet  (il  y  manquera  des  fonctionnalités)  et/ou  inutile  
(certaines   parties   sont   inutiles   car   non   demandées)   et/ou   inutilisable   (ce   qui   pourrait   être   le   cas   si  
l'usage  du  logiciel  s'avère  trop  lourd,  impossible  ou  incomplet).  
En   termes   de   retour   sur   investissement,   on   serait   alors   dans   une   situation   assez  
catastrophique   où   l'effort   financier   non   seulement   ne   pourrait   pas   être   rentabilisé   (puisque   cet  
effort  a  abouti  à  un  outil  mal  adapté)  mais  devrait  être  poursuivi  (pour  corriger  les  défauts).  
NB   :   il   n'est   question   ici   que   des   conséquences   d'une   mauvaise   analyse   des   besoins   sur   le   client.   Il  
est   bien   évident   que   l'organisation   informatique   qui   aurait   construit   cet   outil   inadapté   subirait  
également   des   conséquences   de   ce   mauvais   développement,   en   matière   de   réputation,   de  
bénéfices   (les   développements   font   le   plus   souvent   l'objet   de   contrats   entre   le   client   et  
l'organisation  informatique,  ceux-­‐ci  précisant  notamment  des  délais  d'achèvement,  des  exigences  
de  résultats...  et  incluant  des  pénalités  en  cas  de  retard,  de  manquement...).  
On  distingue  donc  des  risques  et  des  enjeux  "internes",  se  rapportant  au  produit  développé,  
et  des  risques  et  enjeux  "externes",  qui  ont  trait  au  projet  lui-­‐même.  
Le   fait   de   travailler   dans   un   "monde"   objets   a   fondamentalement   changé   la   façon   de  
travailler.   Le   processus   de   développement   est   itératif   et   incrémental.   Ceci   signifie   que   l'on   peut  
aborder  maintenant  le  développement  du  logiciel  petit  à  petit,  morceau  par  morceau.  Il  n'est  pas  
nécessaire  de  faire  toute  l'analyse  des  besoins  de  tout  le  système  avant  de  lancer  la  recherche  de  
solutions.   Le   point   clé   repose   alors   sur   le   choix   des   morceaux   à   développer   en   priorité,   choix   se  
basant  sur  la  criticité  de  ces  morceaux,  sur  la  stratégie  de  l'organisation...  
L'un   des   avantages   est   le   moindre   risque   (le   périmètre   est   restreint,   donc   les   risques  
d'erreurs  sont  limités  à  ce  périmètre).  Un  autre  est  l'implication  plus  importante  des  utilisateurs,  
ceux-­‐ci  voyant  plus  rapidement  l'application  arriver.  
Une   fois   la   première   version   (d'une   partie)   de   l'application   réalisée,   on   peut   rajouter  
quelques   fonctionnalités,   quelques   exigences...   Les   développeurs   n'ont   pas   tout     à   prendre   en  
compte  d'un  seul  coup.  Les  difficultés  sont  abordées  l'une  après  l'autre.  

C. Processus  et  résultats  

L'analyse  des  besoins  répond  à  des  objectifs  précis  et  doit  produire  des  résultats.  

1. Objectifs  de  l'analyse  des  besoins  

Les  objectifs  de  l'analyse  des  besoins  sont  les  suivants  :    
• Fournir   une   description   détaillée   des   fonctionnalités   que   devra   mettre   en   œuvre   le  
logiciel.  
• Fournir  une  description  détaillée  des  qualités  que  devra  respecter  ce  logiciel.  
• Lister  les  contraintes  auxquelles  sera  soumis  le  logiciel.  
• Documenter  les  décisions,  documenter  les  modèles.  
• S’assurer  de  la  qualité  des  résultats  et  du  processus.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   7/71  

 • Mettre  à  jour  la  gestion  du  projet.  
• Tracer  vis-­‐à-­‐vis  du  niveau  stratégique,  la  traçabilité  étant  ensuite  établie  lors  des  étapes  
suivantes  pour  devenir  de  bout  en  bout.  

2. Résultats  
Le   résultat   de   ce   travail   se   présente   sous   la   forme   d'un   recueil   complet   des   fonctionnalités   à  
développer,  des   exigences   en   matière   de   qualité   ainsi   que   des   contraintes   auxquelles   sera   soumis  
le  logiciel.  
Ce   recueil   sera   constitué   de   diagrammes   de   cas   d'utilisation,   de   scénarios   et,  
éventuellement,   d'un   diagramme   de   classes   et   d'une   description   des   processus   métiers   de  
l'organisation  ou  de  l'entreprise  pour  laquelle  le  travail  est  fait.  
Il  sera  enfin  complété  par  une  batterie  de  tests,  de  mesures  qui  seront  prises  en  compte  au  
moment   où   il   s'agira   de   valider   le   logiciel,   tant   d'un   point   de   vue   fonctionnel   que   non   fonctionnel.  
Ces  tests,  ces  mesures,  seront  accompagnés  des  résultats  attendus  lors  des  tests  et  des  mesures,  
ainsi,  pour  les  mesures,  que  des  définitions  de  ce  qui  doit  être  obtenu  (il  ne  suffit  pas  de  dire  que  
telle   mesure   devra   produire   un   résultat,   il   faut   aussi   dire   à   partir   de   quelle   valeur   ce   résultat  
constituera  une  "bonne"  valeur).  

D. Ouvrages  de  référence  

Nous   nous   sommes   principalement   servis   de   deux   ouvrages   pour   rédiger   ce   chapitre.   Le  
premier  est  l'ouvrage  ([CH301])  que  nous  avons  publié  sous  le  titre  "Développement  de  logiciels  
avec  UML2  et  OCL",  paru  en  2015  aux  Éditions  Ellipses.  Le  second  ([CH302])  est  un  ouvrage  plus  
spécialisé  de  Stéphane  BADREAU  et  Jean-­‐louis  BOULANGER.  Paru  en  2014,  sous  le  titre  "Ingénierie  
des  exigences",  il  a  une  portée  plus  générale  que  ce  chapitre  mais  sa  lecture  permet  de  se  faire  
une  bonne  idée  de  ce  qui  se  "cache"  sous  les  mots  "analyse  des  besoins".  
 

Chapitre  3  –  Bien  analyser  son  besoin   C352   8/71  

II. Bien  définir  son  périmètre  d'intervention  
La  définition  du  périmètre  d'action  est  essentielle  ;  elle  doit  être  réalisée  au  commencement  
de  l'étude.  Ne  pas  le  faire  expose  à  des  débordements,  à  l'initiative  des  utilisateurs  clients  ou  suite  
au  dérapage  de  l'équipe  de  développement.  
Les   utilisateurs   sont   de   plus   en   plus   impliqués   dans   le   processus   de   création   au   fur   et   à  
mesure  de  l'avancement  de  ce  développement.  Après  tout,  c'est  leur  outil  qui  est  construit.  Ils  le  
voient   "naître",   se   projettent   "dedans"   et   se   mettent   souvent   à   envisager   des   extensions   non  
prévues.   Céder   à   une   demande   des   utilisateurs   revient   à   augmenter   le   périmètre,   ce   qui   a   des  
conséquences  sur  les  plannings  (il  y  a  plus  de  "choses"  à  faire)  et  sur  les  budgets  (plus  de  travail  
donc  plus  de  dépenses).  
Les   développeurs   sont   guettés   par   un   danger   similaire.   Des   extensions   possibles   peuvent  
être  mises  en  évidence  lors  du  développement  et  la  tentation  de  les  inclure  dans  le  périmètre  peut  
être   grande.   Céder   à   cette   tentation   va   tendre   les   plannings   (il   y   a   plus   de   "choses"   à   faire   dans   le  
même  laps  de  temps)  et  les  budgets  (l'extension  étant  réalisée  à  budget  constant).  

A. Différentes  "zones"  composant  le  périmètre  

Dans  les  deux  cas,  donc,  il  faut  définir  le  périmètre  avant  de  commencer  le  développement  
et  s'y  tenir.  Il  y  a  le  système  et  son  contexte.  Le  système  correspond  au  logiciel  qui  est  en  cours  de    
développement.   Le   contexte   du   système   regroupe   les   acteurs,   humains   ou   mécaniques   qui  
agissent   sur   le   système   (qui   utilisent   le   logiciel)   ou   qui   l'exploitent   (qui   récupèrent   des  
informations   du   logiciel).   On   y   retrouvera   également   des   documents,   des   événements...   tout   ce  
qui,  de  près  ou  de  loin,  concerne  le  logiciel  à  développer.  

 
figure  2  -­‐  périmètre  du  logiciel  (extrait  de  [CH301])  

Définir  le  contexte  va  revenir  à  dresser  la  liste  de  tous  les  intervenants,  à  recenser  tous  les  
outils  qui  interagissent  avec  le  logiciel.  Il  faut  aussi  s'intéresser  aux  interfaces  entre  le  contexte  (les  
acteurs)  et  le  système.  
Connaître  le  périmètre  permet  aussi,  a  contrario,  de  déterminer  ce  qui  n'est  pas  pertinent  
pour  le  développement  du  logiciel.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   9/71  

  
figure  3  -­‐  cartographie  du  système  et  de  son  environnement  (extrait  de  [CH301])  

L'équipe   de   développement   sera   attentive   aux   informations   venant   du   côté   pertinent   et  

rejettera   tout   ce   qui   ne   l'est   pas.   Cette   classification   entre   pertinent   et   non   pertinent   n'est  
toutefois   pas   aussi   nette   que   nous   le   présentons.   Il   y   a   des   informations   que   l'on   sait  
pertinemment  (!)  être  inutiles  (utiles)  ;  il  y  en  a  d'autres  qu'on  ne  sait  pas  vraiment  caractériser.  

 
figure  4  -­‐  seconde  cartographie  (extrait  de  [CH301])  

Réduire   les   zones   floues,   les   zones   d'ombre,   est   nécessaire.   Il   faut   cependant   garder   en  
mémoire   que   cela   n'est   pas   toujours   facile,   pas   toujours   possible.   Pour   compliquer   le   "jeu",   ces  
zones  peuvent  fluctuer  au  cours  du  temps.  Un  projet  peut  se  voir  différer  au  profit  d'un  autre  ;  le  
périmètre  d'un  projet  peut  se  réduire  de  façon  importante  pour  dégager  des  ressources  qui  seront  
redéployées  sur  un  projet  plus  prioritaire.  La  stratégie  de  l'entreprise  joue  un  rôle  non  négligeable  
à  ce  niveau.  

B. Résultats  produits  
Recenser   les   acteurs   va   pousser   à   dresser   une   sorte   de   calepin   avec,   pour   chaque   personne,  
son   identité,   son   degré   d'implication   dans   le   processus   (est-­‐ce   un   usager   ?   un   décideur   ?   un  
développeur  ?...),  son  rôle  actuel  et  futur  (ceci  sera  utile  lors  de  la  définition  des  besoins  lorsqu'il  

Chapitre  3  –  Bien  analyser  son  besoin   C352   10/71  

s'agira  de  modéliser  les  acteurs).  On  pourra  se  servir  de  divers  outils  notationnels  (diagrammes  de  
contexte,  diagrammes  de  cas  d'utilisation,  actigrammes,  diagrammes  de  flots  de  données...).  Une  
description  des  matériels  ou  logiciels  qui  interagissent  avec  le  logiciel  doit  également  être  faite.  
Collecter   les   documents   permettra   de   réunir   une   sorte   de   dictionnaire   des   données   à  
connaître  (normes,  états  à  produire,  fichiers...).  
Cette  activité  de  définition  du  périmètre  doit  être  commentée,  datée.  Elle  conduit  donc  ceux  
qui  la  mènent  à  rédiger  des  documents,  des  comptes-­‐rendus,  à  faire  des  schémas  (de  processus,  
de   contexte,   d'acteurs).   Ceux-­‐ci   doivent   impérativement   être   soumis   aux   personnes   concernées  
pour  relecture  et  approbation.  

C. Application  au  cas  «  compte  bancaire  »  

Voir  la  section  VIII  qui  présente  une  application  de  ce  qui  précède  au  cas  Compte  bancaire.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   11/71  

III. Mettre  en  place  une  équipe  
Il   ne   s'agit   pas,   ici,   de   donner   des   recettes   pour   composer   la   "meilleure"   équipe   de  
développeurs  qui  soit.  Nous  savons  en  effet  fort  bien  que  les  équipes  sont  constituées  en  fonction  
de   critères   "purement   RH"   (tels   la   disponibilité   des   personnes,   leurs   compétences,   le   plan   de  
charge  du  groupe...),  financiers  (comme,  par  exemple,  le  budget  alloué  au  projet)  ou  stratégiques  
(selon   l'importance   du   client   et   les   retombées   attendues   du   projet,   l'équipe   sera   la   meilleure  
possible,  une  bonne  équipe,  une  équipe  "moyenne"...).  
Plus   simplement,   nous   voulons   mettre   l'accent   sur   la   composition   de   l'équipe   et   sur   les  
différents   types   de   personnes   qu'il   est   nécessaire   de   regrouper   pour   mener   à   bien   un   projet   de  
développement  de  logiciel.  

A. Catégories  de  personnes  

Grossièrement,   on   peut   dire   que   deux   catégories   de   personnes   vont   intervenir   lors   du  
développement,   les   clients   et   les   fournisseurs.   Les   clients   ont   pour   objectif   de   satisfaire   les  
utilisateurs   (objectif   qualitatif)   et   de   réduire,   autant   que   faire   se   peut,   le   délai   de   fourniture   du  
produit   (objectif   quantitatif).   Les   fournisseurs   sont   soumis   à   des   exigences   plus   importantes.   Ils  
vont   devoir   maîtriser   le   périmètre   du   projet,   d'en   baisser   les   coûts,   de   diminuer   les   risques   de  
divergence,   d'améliorer   le   pilotage   du   projet,   d'augmenter   la   qualité   des   livrables   et   enfin   de  
faciliter  la  communication  entre  les  membres  de  l'équipe.  
La  relation  entre  le  client  et  son  fournisseur  peut  se  représenter  ainsi  :  

 
figure  5  -­‐  relation  client  fournisseur  (extrait  de  [CH301])  

B. Maîtrise  d'ouvrage,  maîtrise  d'œuvre  

On   retrouve   cette   distinction   dans   les   notions   de   maîtrise   d'ouvrage   (MOA)   et   de   maîtrise  
d'œuvre   (MOE).   La   maîtrise   d'ouvrage   porte   la   responsabilité   de   la   construction   de   cet   ouvrage,  
elle  le  finance  et  elle  en  confie  la  réalisation  à  une  maîtrise  d'œuvre.  Le  maître  d'ouvrage  est  une  
personne  physique  qui  est  responsable  du  projet.  Il  fournit  le  cahier  des  charges,  est  responsable  

Chapitre  3  –  Bien  analyser  son  besoin   C352   12/71  

des  résultats  du  projet  et  valide  la  recette.  La  maîtrise  d'œuvre  réalise  l'ouvrage  pour  le  compte  du  
maître  d'ouvrage.  Elle  est  responsable  de  la  qualité  de  l'ouvrage,  des  délais  et  des  coûts.  Le  maître  
d'œuvre   (une   personne   physique)   réalise   la   conception,   la   réalisation,   les   tests   et   la   validation  
technique.  

C. Composition  de  l'équipe  

Une  équipe  doit  comporter  des  représentants  de  ces  deux  catégories.  Au  fur  et  à  mesure  de  
l'évolution   du   projet,   le   rôle   de   chacun   prendra   plus   ou   moins   d'importance.   La   MOA   sera   très  
présente   dans   les   "branches"   hautes   du   cycle   de   vie,   du   Y   (voir   la   figure   1)   alors   que   la   MOE  
deviendra  leader  lors  des  phases  "basses".  

D. Application  au  cas  «  compte  bancaire  »  

Voir  la  section  VIII  qui  présente  une  application  de  ce  qui  précède  au  cas  Compte  bancaire.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   13/71  

IV. Exprimer  les  besoins  fonctionnels  
Les   besoins   fonctionnels   expriment   ce   que   doit   faire   le   système.   Deux   diagrammes,   pour  
l'essentiel,  de  la  notation  UML  sont  utilisés  durant  cette  étape  :  les  diagrammes  de  cas  d'utilisation  
et  les  diagrammes  de  séquences,  dans  leur  version  simplifiée  que  nous  appelons  scénarios.  

A. Bref  rappel  de  la  notation  

Les   diagrammes   de   cas   d'utilisation   fournissent   une   description   de   ce   que   perçoivent   les  
utilisateurs  du  système  en  matière  de  fonctionnalités,  d'usages.  Ces  diagrammes  comprennent  des  
acteurs  et  des  utilisations.  Les  utilisateurs  sont  appelés  acteurs  dans  le  "jargon"  UML.  

1. Notion  d'acteur  
Un   utilisateur   peut   être   une   personne   unique,   une   personne   type   (représentant   un  
ensemble   de   personnes   physiques),   une   machine,   un   autre   logiciel...   De   fait,   l'analogie   la   plus  
proche  de  la  notion  d'acteur  est  celle  qui  consiste  à  dire  qu'un  acteur  est  un  rôle.  Un  acteur  joue  
un   rôle   par   rapport   au   logiciel   que   l'on   décrit.   Il   va   s'en   servir   ou   répondre   à   ses   questions   ou  
recevoir  une  information...  Il  est  concerné  par  le  fonctionnement  de  ce  logiciel,  de  façon  plus  ou  
moins  proche.  Une  personne  peut  jouer  plusieurs  rôles,  c'est  plus  rarement  le  cas  d'une  machine.  
Un   acteur   est   à   l'extérieur   du   logiciel   (ce   n'est   pas   une   partie   de   ce   logiciel   mais   de   son  
contexte)   qui   interagit   avec   lui,   soit   en   lui   posant   une   question,   soit   en   répondant   à   une   de   ses  
questions,  soit  les  deux.  On  n'étudie  pas  le  comportement  interne  d'un  acteur.  On  se  "contente"  
d'étudier  ses  stimuli  et  réactions.  
Un   acteur   peut,   dans   certains   cas,   prendre   la   "place"   d'un   autre   et   jouer   son   rôle.   C'est  
notamment   le   cas   lorsqu'un   responsable   se   met   à   la   place   d'un   de   ses   employés   et   exécute,  
provisoirement,   une   de   ses   tâches.   Cet   acteur   va   alors   hériter   de   ses   "pouvoirs"   (exactement  
comme   dans   un   jeu   de   rôle   ou,   en   fonction   de   données,   vous   pouvez   acquérir   de   nouveaux  
pouvoirs   et   faire   d'autres   "choses".   L'héritage   de   rôle   se   traduit   aisément   en   UML   par   la   notion  
d'héritage.  

 
figure  6  :  expression  de  l'héritage  entre  acteurs  

Dans   cette   figure,   les   acteurs   B   et   C   héritent   des   "pouvoirs"   de   l'acteur   A.   Ils   vont   donc  
pouvoir  utiliser  le  logiciel  comme  le  fait  A.  Cet  héritage  permet,  entre  autres  choses,  de  simplifier  
les  schémas.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   14/71  

 On  distingue  les  acteurs  primaires  et  les  acteurs  secondaires  :  
• un  acteur  primaire  est  celui  qui  a  l'initiative,  qui  lance  "l'exécution".  Le  système  est  utilisé  
à  sa  demande.  En  ce  sens,  il  est  actif.  Il  n'y  en  a  qu'un  seul  par  utilisation.  
• un   acteur   secondaire   est   un   acteur   qui   intervient   dans   le   processus   mais   sans   en   être  
l'instigateur.  Il  va  recevoir  une  information  du  système  ou  bien  fournir  une  information  au  
système.   Il   réagit   à   une   demande   du   système.   En   ce   sens,   il   est   passif.   Il   peut   y   avoir  
plusieurs  acteurs  secondaires  par  utilisation.  
Un  acteur  peut  fort  bien  être  primaire  pour  une  utilisation  et  secondaire  pour  une  autre.  
Qu'il   s'agisse   d'acteurs   primaires   ou   bien   d'acteurs   secondaires,   leur   mise   en   évidence   passe  
toujours  par  un  recensement  des  rôles  joués  par  les  personnes  et  les  organisations.  Ce  n'est  pas  
toujours  facile.  Ainsi,  dans  un  processus  de  prêt  de  livres  dans  une  bibliothèque,  qui  joue  le  rôle  
principal  ?  Le  lecteur  ?  La  bibliothécaire  ?  Il  n'y  a  pas  de  réponse  unique  dans  la  mesure  où  cela  
dépend  de  l'organisation  mise  en  place.  

2. Notion  d'utilisation  
Un  logiciel  est  constitué  de  programmes  et  de  données.  Les  programmes  "travaillent"  sur  les  
données,   les   saisissent,   les   mémorisent,   les   transforment,   les   analysent...   Un   logiciel   peut   être  
utilisé   par   différentes   personnes,   certaines   ayant   plus   de   droits,   de   pouvoirs   que   d'autres.  
Certaines   ne   feront   que   de   la   saisie,   d'autres   auront   accès   è   quelques   fonctionnalités,   d'autres  
pourront   tout   faire...   Chaque   utilisateur   perçoit   une   partie   de   ce   que   fait   réellement   le   logiciel,  
cette  perception  pouvant  du  reste  être  partiellement  erronée.  
En   UML,   les   fonctionnalités   sont   représentées,   pour   ce   qui   concerne   les   besoins,   par   la  
notion   de   cas  d'utilisation.   Cette  notion  intègre   celle   de   perception  plus   ou  moins  déformée,   de  
droits  plus  ou  moins  étendus...  Un  cas  d'utilisation  est  représenté  graphiquement  par  une  ellipse  :  

 
figure  7  :  représentation  graphique  d'un  cas  d'  utilisation  

Cette   notation   est   "pauvre".   Elle   ne   véhicule   que   très   peu   d'informations.   Dans   l'exemple   ci-­‐
dessus,   on   n'a   que   peu   de   renseignements   sur   ce   que   recouvre   vraiment   la   gestion   des   membres.  
Il   est   donc   vital   d'associer   à   cette   représentation   d'autres   éléments,   comme   une   description  
textuelle   et   des   scénarios,   la   première   précisant   les   choses,   les   seconds   les   illustrant   pour   les  
rendre  plus  conrêts,  notamment  pour  les  "clients".  
Le  système  est  utilisé,  par  différents  acteurs,  pour  faire  différentes  choses.  Compte-­‐tenu  du  
fait   que   la   modélisation   des   besoins   se   positionne   au   début   de   la   chaîne   de   développement   du  
logiciel,   la   perception   que   l'on   a   de   ce   que   fait   le   système   doit   se   représenter   au   niveau  
macroscopique   (en   identifiant   les   processus-­‐métier).   Un   cas   d'utilisation   n'est   pas   une   fonction.  
Dans   un   logiciel   de   gestion   d'une   bibliothèque,   par   exemple,   le   bon   niveau   sera   celui   de   la   gestion  
des  prêts  (celle-­‐ci  intégrant  les  emprunts,  les  retours,  les  non-­‐retours,  les  réservations...).  

Chapitre  3  –  Bien  analyser  son  besoin   C352   15/71  

 Assimiler   utilisation   et   fonction   conduirait   à   produire   des   diagrammes   beaucoup   trop  
détaillés   (il   suffit   de   jeter   un   coup   d'œil   sur   le   contre-­‐exemple   fourni   en   annexes   pour   s'en  
convaincre),   très   difficiles   à   valider   par   les   clients   et   très   consommateurs   de   temps   pour   les  
architectes.  

3. Description  textuelle  
Les   diagrammes   (cas   d'utilisation,   acteurs)   sont   peu   expressifs.   Ils   n'apparaissent   que   sous  
forme   graphique   restreinte   et   ne   sont   identifiés   que   par   quelques   caractères.   Que   signifie,   par  
exemple,  dans  le  schéma  ci-­‐dessous  qui  comprend  deux  cas  d'utilisation  et  trois  acteurs,  "Gérer  les  
membres"  ?  

 
figure  8  :  exemple  de  diagramme  pauvre  en  sens  

Ces   diagrammes   donnent   une   idée   générale   des   fonctionnalités   attendues.   Il   faut   leur  
donner  du  sens.  Cela  se  fait  de  deux  façons  différentes,  en  fournissant  une  description  textuelle  de  
chaque   cas   et   en   précisant,   par   un   scénario,   les   principales   interactions.   Nous   traiterons   les  
scénarios   un   peu   plus   loin.   Nous   proposons   une   description   textuelle   non   normalisée   pour  
spécifier  chaque  UC  :  

Chapitre  3  –  Bien  analyser  son  besoin   C352   16/71  

figure  9:  cadre  descriptif  d'un  cas  d'utilisation  

NB  :  il  y  a  d'autres  propositions.  

4. Structuration  du  cas  d'utilisation  en  scénarios  

Un  scénario  met  en  évidence  les  interactions  qui  existent  entre  le  système  et  les  acteurs  de  
son  contexte.  Un  scénario  illustre  un  cas  d'utilisation.  Par  abus  de  langage,  on  dit  qu'il  l'instancie  (il  
en  donne  un  exemple  concret  via  des  instances  d'acteurs  et  de  système).  
Un   cas   d'utilisation   peut   comporter   des   variantes,   des   factorisations   ou   des   extensions  
d'autres  cas.  La  description  des  cas  comportera  toujours  le  cas  nominal  (celui  qui  correspond  au  
"standard").   Il   pourra   être   complété   par   la   description   de   cas   alternatifs   et/ou   des   cas  
exceptionnels.  Pour  mieux  cerner  la  différence  entre  alternative  et  exception,  il  faut  revenir  à  la  
notion  d'objectif.  Un  cas  d'utilisation  est  une  réponse  à  une  demande  de  l'utilisateur.  Il  répond  à  
un  objectif  précis.  Nous  appellerons  :  
• cas  nominal  ce  qui  contribue  à  atteindre  directement  l'objectif,  
• cas   alternatif   une   variante   du   cas   nominal,   l'objectif   étant,   malgré   la   variante,   atteint   à   la  
fin,  
• exception  ce  qui  contribue  à  ne  pas  pouvoir  atteindre  l'objectif.  
La  figure  suivante  -­‐qui  nous  a  été  fournie  par  un  collègue  nantais,  Olivier  Le  Marrec-­‐  illustre  
bien  ces  différents  cas  :    

Chapitre  3  –  Bien  analyser  son  besoin   C352   17/71  

figure  10  :  cas  nominal,  alternatives  et  exception  

Chaque   alternative,   chaque   exception   peut   faire   l'objet   d'un   scénario.   Le   cas   nominal   est,  
bien  entendu,  lui  aussi  décrit  sous  forme  d'un  scénario.  Dans  le  cas  de  la  figure  10,  il  pourrait  donc  
y  avoir  quatre  scénarios.  En  pratique,  il  y  en  aura  entre  1  (le  cas  nominal)  et  4.  

5. Scénarios  
Un  scénario  décrit  le  dialogue  entre  le  système  et  les  acteurs  concernés.  Le  dialogue  va  donc  
être  basé  sur  ces  deux  "concepts",  le  système  étant  placé  au  centre  du  diagramme  et  les  acteurs  à  
la   "périphérie".   À   chaque   fois   qu'il   y   aura   transmission   d'information,   question...   une   flèche   la  
mettra  en  évidence  et  l'orientation  de  celle-­‐ci  désignera  l'émetteur  et  le  récepteur.  
Lorsque  le  système  mettra  en  œuvre  une  de  ses  fonctionnalités,  cela  sera  modélisé  par  une  
flèche  recourbée  (elle  partira  du  système  et  arrivera  au  système).  
Chaque   "traitement"   sera   matérialisé   par   un   petit   rectangle,   plus   ou   moins   long,  
représentant  un  temps  d'activité  et  donc  un  traitement.  

figure  11  :  exemple  de  scénario  

Chapitre  3  –  Bien  analyser  son  besoin   C352   18/71  

NB  :  ce  scénario  respecte  la  syntaxe  UML1.x.  
L'acteur   Secrétaire  envoie  un  message  au  système  (il  veut  ajouter  un  membre).  Le  système  
commence   par   vérifier   l'existence   du   membre   dans   sa   "base".   S'il   existe,   alors   un   message  
"Membre connu"  est  envoyé  à  l'acteur.  En  principe,  on  ne  représente  pas  les  opérations  exécutées  
par  les  acteurs  (on  ne  s'intéresse  pas  à  leur  comportement  interne.  Ce  qu'ils  font  des  informations  
reçues,  comment  ils  les  traitent...  tout  cela  est  hors  propos).  

6.  Autres  éléments  
On   pourra   être   amené   à   proposer   d'autres   modélisations,   notamment   pour   définir   les  
termes  techniques  (on  utilisera  alors  le  formalisme  des  diagrammes  de  classes)  ou  pour  formaliser  
le   fonctionnement   de   l'entreprise   (on   utilisera   les   diagrammes   d'activités   ou   bien   le   formalisme  
proposé  par  BPM),  en  produisant  le  modèle  du  domaine  (i.e.  les  classes)  et  le  modèle  métier  (i.e.  
les  activités).  
Ces  modèles  seront  toutefois  plutôt  élaborés  en  amont  de  l'analyse  des  besoins,  pour  bien  
comprendre  le  "monde"  dans  lequel  l'on  se  situe.  
 

B. Processus  de  mise  en  évidence  des  besoins  

Dans  ce  paragraphe,  nous  abordons  la  façon  de  faire  pour  mettre  en  évidence  les  besoins.  
Nous  commençons  par  la  mise  en  évidence  des  acteurs  puis  abordons  celle  des  utilisations.  

1. Acteurs  
Pour   mettre   en   évidence   les   acteurs   concernés,   nous   allons   utiliser   le   résultat   du   travail   que  
nous  avons  effectué  en  amont  avec  la  mise  en  place  de  l'équipe.  Durant  cette  mise  en  place,  nous  
avons  (normalement)  recensé  toutes  les  personnes  concernées,  de  près  ou  de  loin,  par  le  logiciel  à  
développer.  Il  est  donc  raisonnable  de  penser  que  les  acteurs  se  trouvent  dans  cette  liste.  
Ces  personnes  recensées,  il  faut  se  poser  deux  questions  :  
• Comment  est-­‐ce  qu'elle  utilise  le  système  ?  
• Joue-­‐t-­‐elle  un  rôle  essentiel  ou  bien  secondaire  ?  
Les   acteurs   utilisent   le   système.   Chaque   utilisation   se   traduit   d'abord   par   une   interaction  
entre  le  ou  les  acteurs  et  le  système.  

 
Chapitre  3  –  Bien  analyser  son  besoin   C352   19/71  
figure  12  :  utilisation  =  interaction  

Les   acteurs   ne   se   servent   pas   du   système   de   la   même   façon.   Certains   sont   très   actifs,  
moteurs   ;   d'autres   sont   passifs   et   se   contentent,   par   exemple,   de   répondre   à   une   question   du  
système.   Les   premiers   seront   appelés   acteurs   principaux   (ou   primaires),   les   seconds   acteurs  
secondaires.  Les  acteurs  principaux  déclenchent  l'utilisation,  les  acteurs  secondaires  y  participent.  
Il   faut   donc,   dans   un   premier   temps,   dresser   une   liste   des   tous   les   acteurs,   de   leurs  
utilisations  du    système.  
NB   :   un   acteur   peut   tout   à   fait   ne   pas   être   humain   (et   correspondre,   par   exemple,   à   une   machine,  
une  autre  organisation,  un  logiciel...).  

 
figure  13  :  utilisation  =  interaction  

Il   faut   ensuite   les   caractériser   "principal"   ou   "secondaire"   pour   CHAQUE   utilisation.   Un  

acteur  peut  en  effet  fort  bien  être  principal  pour  une  utilisation  et  secondaire  pour  une  autre.  

2. Interactions  
Le  recensement  effectué,  il  faut  aborder  de  la  façon  la  plus  précise  possible  les  interactions  
existantes  entre  acteur(s)  et  système.  Cela  peut  se  faire  en  utilisant  les  diagrammes  OMT  :  

 
figure  14  :  modélisation  OMT  d'une  interaction  

Chapitre  3  –  Bien  analyser  son  besoin   C352   20/71  

ou  bien  encore  leur  équivalent  dans  la  notation  UML  :  

 
figure  15  :  modélisation  UML  d'une  interaction  

Quel   que   soit   le   type   de   diagramme   choisi,   il   est   important   de   conserver   à   l'esprit   deux  
règles  de  modélisation  :  
• Les   dialogues   entre   les   acteurs   (i.e.   sans   passer   par   le   système)   ne   doivent   pas   être  
représentés.  Ils  sont  hors  contexte  et  ne  seront  pas  modélisés.  
• Les   acteurs   principaux   sont   ceux   qui   ont   intérêt   à   ce   que   le   système   fonctionne,   quelle  
que   soit   la   façon   dont   la   communication   avec   celui-­‐ci   est   opérée.   Dans   le   cas   d'un  
emprunt   d'ouvrage   en   bibliothèque,   par   exemple,   l'acteur   principal   de   l'utilisation  
Emprunt  c'est  bien  le  lecteur,  pas  la  bibliothécaire...  même  si  cette  personne  effectue  la  
saisie  des  informations  sur  l'emprunt.  Elle  n'est  qu'un  intermédiaire  entre  le  lecteur  et  le  
système.  

3. Description  détaillée  
Une  fois  que  les  acteurs  sont  recensés  et  que  les  interactions  qu'ils  ont  avec  le  système  sont  
répertoriées,  il  convient  d'approfondir  et  de  décrire  minutieusement  ces  interactions.  Cela  passe  
par   la   constitution   des   diagrammes   UML   (qu'il   s'agisse   des   diagrammes   de   cas   d'utilisation   ou   des  
scénarios)  et  par  leur  description  textuelle.  Cette  dernière  est  un  élément  fondamental  du  travail  
d'analyse  des  besoins  (cf.  [CH303]).  Elle  participe  à  l'appropriation  de  ces  besoins  par  les  analystes  
et   offre   aux   utilisateurs   un   support   pour   vérifier   si   ces   analystes   n'ont   pas   fait   d'erreur  
d'interprétation,  de  contre-­‐sens...  

Chapitre  3  –  Bien  analyser  son  besoin   C352   21/71  

 UML   ne   propose   pas   de   notation   spécifique   (en   dehors   de   celle   extrêmement   pauvre   des  
commentaires).  En  voici  une...  parmi  d'autres.  

 
figure  16  :  exemple  de  description  textuelle  

NB  :  la  signification  des  différentes  rubriques  est  détaillée  dans  la  figure  9.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   22/71  

 4. Structuration  des  utilisations  
Une  fois  que  toutes  les  utilisations  auront  été  décrites  de  façon  détaillée,  il  restera  une  tâche  
à  accomplir,  celle  de  structurer  celles-­‐ci  en  cas  nominal,  alternatives  et  exceptions  pour  produire  
des  graphes  analogues  à  celui  de  la  figure  10.  Ce  graphe  pourra  servir  pour  préparer  les  tests  de  
validation.  

C. Application  au  cas  «  compte  bancaire  »  

Voir  la  section  VIII  qui  présente  une  application  de  ce  qui  précède  au  cas  Compte  bancaire.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   23/71  

V. Exprimer  des  besoins  non  fonctionnels  
A. Qualité  et  contraintes  
On  peut  diviser  ces  besoins  non  fonctionnels  en  deux  catégories,  celle  relevant  de  la  qualité  
et  celle  relevant  des  contraintes.  

 
figure  17  -­‐  différentes  catégories  d'exigences  (extrait  de  [CH301])  

Au   niveau   qualité,   on   trouvera   des   préoccupations   liées   à   la   performance   (temps   de  

traitement  d'une  requête,  par  exemple),  la  sécurité  (protection  des  données),  la  fiabilité  (comme,  
par   exemple,   le   nombre   maximum   de   pannes   toléré),   la   disponibilité   (pourcentage   de   temps  
pendant  lequel  le  logiciel  est  disponible,  par  exemple),  l'ergonomie...    
Les   contraintes   définiront   les   limites   inhérentes   au   logiciel   (ce   sont   des   contraintes   internes)  
et   les   limites   imposées   par   l'environnement   (ce   sont   des   contraintes   externes,   comme,   par  
exemple  la  taille  maximale  des  programmes  –imposée  par  le  type  de  matériel  sur  lequel  le  logiciel  
sera  installé–,  l'existence  de  logiciels  précis  avec  lequel  celui  qui  est  développé  devra  coopérer...).  
Ces   besoins   ont   pour   caractéristique   principale   le   fait   qu'il   est   difficile   de   les   tester.   Ces  
exigences   expriment   non   pas   ce   que   fait   le   système   mais   comment   il   doit   se   comporter.   Il   faut  
donc  mettre  en  place  un  plan  de  vérification,  éventuellement  en  faisant  appel  à  l'observation  par  
un  expert  externe  du  comportement  du  système.  
Pour   cela,   il   faudra   définir   des   critères   entrant   dans   la   définition   de   la   qualité   recherchée,  
leurs   éventuelles   combinaisons   et   les   résultats   attendus.   De   la   comparaison   entre   les   résultats  
attendus   et   les   résultats   obtenus   découlera   la   réponse   à   la   question   :   les   besoins   sont-­‐ils  
satisfaits  ?  
L’analyse   des   besoins   est   donc   complétée   par   la   description   (textuelle)   des   besoins   non  
fonctionnels   en   termes   qualitatifs   (fiabilité,   sécurité...)   et   quantitatifs   (performances,   temps   de  
réponse,   tailles   des   programmes   embarqués)   et   par   divers   documents   relatifs   aux   interfaces  
utilisateurs   (dessins   préliminaires,   maquettes)   ou   aux   contraintes   de   l’environnement   de  
développement  (logiciels  existants,  politique  de  développement,  normes...).  

Chapitre  3  –  Bien  analyser  son  besoin   C352   24/71  

 Il   ne   faut   pas   non   plus   perdre   de   vue   que   ces   besoins   non   fonctionnels   peuvent   différer  
selon  le  point  de  vue  que  l'on  adopte,  celui  de  l'utilisateur  ou  celui  du  développeur.  

 
figure  18  -­‐  point  de  vue  client  et  point  de  vue  système  (extrait  de  [CH301])  

Ces   points   de   vue   ne   devraient   pas   être   opposés.   Si   tel   était   le   cas,   il   reviendra   à   l'équipe   de  
résoudre  le  problème  et  de  dire  lequel  doit  être  privilégié.  
D'autres   contraintes   pèsent   sur   le   produit   qui   sera   développer   :   elles   sont   liées   à  
l'environnement   technique   dans   lequel     ce   produit   sera   immergé,   à   l'urbanisation   du   système  
d'information,   aux   outils   méthodologiques   utilisés...   toutes   considérations   qui   proviennent   de  
l'autre  branche  du  processus  en  Y.  

B. Application  au  cas  «  compte  bancaire  »  

Voir  la  section  VIII  qui  présente  une  application  de  ce  qui  précède  au  cas  Compte  bancaire.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   25/71  

VI. Préparer  les  tests  
Dans  l'introduction  (voir  la  figure  1),  nous  avons  présenté  le  processus  2TUP.  Celui-­‐ci  est  "en  
Y",   les   deux   branches   hautes   correspondant   à   la   dimension   fonctionnelle   et   à   la   dimension  
technique   et   la   branche   basse   à   la   réalisation.   Avant   d'aborder   le   problème   des   tests,   nous  
voudrions  revenir  à  un  cycle  plus  classique,  celui  appelé  "cycle  en  V"  :  

Installation

V
Jeux d'essais
J1
1
Analyse des
Validation
besoins

Cahier des charges 1

J2
1
Conception
Vérification
d'une solution

Dossier analyse 1
+ algorithmes

Codage

 
figure  19  -­‐  une  autre  vision  du  processus  de  développement  d'un  logiciel,  le  cycle  en  V  

Ce  cycle  a  ceci  d'intéressant  qu'il  met  en  évidence  les  deux  types  de  contrôles  qu'il  faut  faire  
et,  pour  ce  qui  nous  concerne,  qu'il  met  en  parallèle  tests  (de  validation)  et  analyse  des  besoins.  Il  
montre   clairement   que   ces   tests   sont   conçus   dès   les   premières   étapes   du   développement   du  
logiciel  même  s'ils  sont  réalisés  dans  les  dernières.  
Il  faut  préparer  deux  types  de  tests  différents  :  
• Les  tests  de  type  "boîte  noire",  qui  serviront  à  observer  le  comportement  du  logiciel  et  à  
comparer  comportement  obtenu  et  comportement  prévu.  
• Les   mesures   qui   fourniront   des   résultats   aux   observateurs   chargés   de   contrôler   si   les  
exigences  de  qualité  et  de  respect  des  contraintes  sont  satisfaites.  
Ces  tests  concourront  à  la  validation  du  produit,  une  fois  les  tests  unitaires  réalisés  par  les  
équipes  de  développement.  

A. Tests  de  type  «  boîte  noire»  

Les  tests  de  type  "boîte  noire"  considèrent  le  système  à  contrôler  comme  une  boîte  noire,  
c'est-­‐à-­‐dire   quelque   chose   d'opaque.   Avec   un   système   de   ce   type,   on   ne   peut   "que"   poser   une  
question,   attendre   la   réponse   et   voir   si   celle-­‐ci   est   acceptable   (ce   qui   suppose   que   la   notion  
d'acceptabilité  ait  été  définie  auparavant).  
Les   tests   de   type   "boîte   noire"   ont   pour   but   de   vérifier   que   le   déroulement   du   logiciel   est  
conforme  à  ce  qui  est  prévu,  cette  conformité  se  décrétant  en  comparant  les  résultats  souhaités  et  

Chapitre  3  –  Bien  analyser  son  besoin   C352   26/71  

les  résultats  obtenus.  Le  point  de  départ  de  ces  tests  est  à  rechercher  dans  les  scénarios,  tels  qu'ils  
ont  été  définis  durant  l'expression  du  besoin.  
Reprenons   la   figure   10   pour   illustrer   ce   qu'il   y   a   à   faire.   Ce   schéma   comprend   un   scénario  
nominal,   deux   alternatives   et   une   exception.   C'est   une   utilisation   du   système.   Nous   pouvons   le  
considérer   comme   un   graphe   de   contrôle,   dans   lequel   il   est   possible   de   mettre   en   évidence  
plusieurs   chemins.   Tous   partent   du   nœud   haut   et   finissent   au   nœud   bas.   Tester   le   bon  
fonctionnement  de  l'utilisation  revient  à  parcourir  tous  les  chemins  possibles  dans  ce  graphe  et  à  
vérifier  si  les  résultats  sont  satisfaisants.  
Ces  chemins,  quels  sont-­‐ils  ?  

n° 1 n° 2 n° 3 n° 4 n° 5  
figure  20  -­‐  différents  chemins  possibles  dans  le  graphe  

En   théorie,   il   faut   passer   par   tous   les   chemins.   Il   est   toutefois   assez   évident   que   certains  
nœuds  sont  parcourus  plusieurs  fois.  Il  est  donc  possible  de  réduire  le  nombre  de  tests  (ce  qui  fait  
inévitablement  gagner  un  peu  d'argent)  tout  en  assurant  une  couverture  maximale.  Il  "suffit"  alors  
de  passer  une  seule  fois  dans  chaque  nœud.  
Dans  le  cas  présent,  on  peut  se  contenter  de  deux  passages  :  
chemin 1 : Début - Etape 1 - Etape 2 - Alternative 2 - Etape 4 - Etape 5 - Fin 1

chemin 2 : Début - Etape 1 - Alternative 1 - Etape 3 - Exception 1 - Fin 2

NB  :  le  chemin  1  porte  le  numéro  5  dans  la  figure  précédente,  le  chemin  2  le  numéro  4.  
Tester  le  bon  fonctionnement  d'une  utilisation  revient  à  parcourir  le  minimum  de  chemins  
dans  le  graphe  pour  assurer  une  couverture  de  tous  les  cas.  
Nous   envisageons   dans   ce   qui   précède   une   couverture   à   100  %,   c'est-­‐à-­‐dire   dans   laquelle  
tous   les   chemins   sont   testés.   Si   la   couverture   à   assurer   n'est   pas   de   100  %   mais   de   80...   ou   de  
70  %,   il   faut   "simplement"   choisir,   parmi   toutes   les   combinaisons,   lesquelles   feront   l'objet   d'un  
test  et  lesquelles  ne  le  subiront  pas.  Dans  notre  scénario  exemple,  il  est  parfaitement  envisageable  
de  considérer  que  l'exception  ne  se  rencontrant  quasiment  jamais,  il  est  inutile  de  la  tester.  
Alors,   deux   chemins   ou   trois   ou   quatre   ?   Deux   scénarios   ou   trois   ou   quatre   ?   Le   choix   relève  
de  l'équipe  et  en  particulier  des  deux  maîtres  d'ouvrage  (pour  l'aspect  satisfaction  des  exigences)  
et  d'œuvre  (pour  l'aspect  respect  des  délais  et  des  coûts).  

Chapitre  3  –  Bien  analyser  son  besoin   C352   27/71  

 Pour  chacun  des  chemins  sélectionnés,  il  faut  fournir  au  système  les  informations  requises  
(ou   bien   demander   l'exécution   d'un   ordre   précis)   et   observer   le   résultat   produit.   Ainsi,   dans   notre  
exemple   abstrait,   il   ne   s'agit   pas   de   tester   chacune   des   étapes   mais   bien   de   voir   ce   qui   est   produit  
à  la  fin  (que  ce  soit  la  fin  1  ou  bien  la  fin  2).  Les  données  à  fournir  au  système  sont  :  
• pour   le   chemin   1   :   des   données   qui   feront   que,   lors   de   l'étape   2,   c'est   la   branche  
correspondant  à  l'alternative  2  qui  sera  choisie  ;  
• pour   le   chemin   2   :   des   données   qui   feront   que,   lors   de   l'étape   1,   c'est   la   branche  
correspondant  à  l'alternative  1  qui  sera  choisie  et  que,  lors  de  l'étape  3,  c'est  la  branche  
correspondant  à  l'exception1  qui  sera  choisie.  

B. Mesures  destinées  au  contrôle  qualité  

La   qualité   peut   se   définir   de   bien   des   façons.   Pour   les   logiciels,   comme   pour   les   autres  
artefacts,  il  n'y  a  pas  d'autre  façon  d'évaluer  la  qualité  de  manière  objective  que  d'effectuer  des  
mesures.  La  question  qui  se  pose  alors  est  la  suivante  :  quelles  sont  les  mesures  adéquates  pour  
évaluer   la   qualité   d'un   logiciel   bâti   sur   le   paradigme   des   objets   (i.e.   ayant   des   spécifications  
rédigées  en  UML  et  des  programmes  développés  dans  un  langage  objet)  ?    
Il  n'est  pas  question,  ici,  de  faire  un  cours  sur  la  qualité  qui,  dans  tous  les  cas,  nécessiterait  
beaucoup   plus   d'heures   qu'il   est   imparti.   Tout   au   plus   nous   contenterons   nous   de   donner  
quelques   indications   et   de   fournir   des   références   qui   permettront   aux   lecteurs   souhaitant  
approfondir  ce  sujet  de  le  faire.  
Le  paradigme  orienté  objet  a  introduit  de  nouvelles  notions  qui  sont  spécifiques  du  monde  
des   objets   et   qui   doivent   être   prises   en   compte   dans   le   cadre   de   l'évaluation   de   la   qualité   du  
logiciel   du   point   de   vue   du   développeur...   ou   bien   de   l'utilisateur.   La   majorité   des   mesures   qui   ont  
été  développées  dans  le  monde  objet  l'ont  été  dans  le  domaine  de  la  programmation.  
Identifier   ce   qui   doit   être   mesuré   n'est   pas   simple.   Il   n'existe   pas   actuellement   de   consensus  
sur  les  mesures  appropriées  pour  mesurer  la  qualité  du  logiciel  orienté  objet.  Plusieurs  travaux  ont  
toutefois  montré  l'utilité  des  mesures  de  complexité  et  de  couplage.  Ces  mesures  sont  applicables  
au  logiciel  orienté  objet,  au  niveau  de  l'objet  lui-­‐même  (i.e.  la  classe).  
Pour   ce   qui   concerne   les   spécificités   du   monde   objet,   des   mesures   liées   à   la   classe,   à   ses  
attributs  et  à  ses  méthodes  ont  été  proposées  ainsi  que  d'autres  portant  plus  particulièrement  sur  
l'héritage  et  le  masquage  de  l'information.  
Voici  les  principales  :  
• mesures  de  la  complexité  :  
o nombre  cyclomatique  de  Mc  Cabe  ([CH304])  
o mesure  de  complexité  de  S.R.  Chidamber  et  C.F.  Kemerer  ([CH305])  
• mesures  de  couplage  ([CH305],  [CH306],  [CH307])  
• mesures  d'héritage  ([CH305])  
• mesures  de  visibilité  et  de  masquage  ([CH307])  

Chapitre  3  –  Bien  analyser  son  besoin   C352   28/71  

 • mesures  de  taille  ([CH308],  [CH309])  
• mesures  de  polymorphisme  ([CH309])  
Une   application   des   mesures   de   qualité   à   UML   a   été,   d'un   autre   côté,   proposée   dès   les  
années   1993.   G.   Banerjee   ([CH310])   a   adapté   la   méthode   dite   des   points   de   fonctions   aux  
diagrammes  de  cas  d'utilisation.  La  qualité  d'une  spécification  peut  aussi  être  évaluée  en  termes  
de   couplage   (entre   UC,   en   scénarios...),   de   taille   (nombre   de   scénarios,   nombre   de   messages  
échangés...)...  
L'utilisateur   pourra,   le   cas   échéant,   souhaiter   que   le   logiciel   soit   fiable,   que   le   code   soit  
commenté,   lisible,   que   les   documents   d'analyse   et   conception   soient   clairs...   tout   ceci   devant   être  
défini  précisément.  Quelque  soient  les  mesures  envisagées,  il  est  important  de  prendre  en  compte  
les  points  suivants  :  
• Quels  sont  les  critères  qui  peuvent  être  utilisés  ?  
• Comment  sont-­‐ils  liés  entre  eux  ?  
• Quelles  sont  les  mesures  que  l'on  peut  associer  à  chacun  d'entre  eux  ?  
• Comment  combiner  les  mesures  pour  obtenir  une  mesure  globale  de  la  qualité  ?  

C. Application  au  cas  «  compte  bancaire  »  

Voir  la  section  VIII  qui  présente  une  application  de  ce  qui  précède  au  cas  Compte  bancaire.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   29/71  

VII. Analyse  de  l'application  
L'analyse  des  besoins  se  termine  par  une  définition  aussi  précise  que  possible  de  ce  qu'il  faut  
mettre   en   place   en   termes   de   comportement   du   futur   logiciel   et   par   une   modélisation,   encore  
approximative,  des  données  qui  sont  traitées.  
L'étape  suivante  est  celle  d'analyse.  Après  avoir  étudié  les  besoins,  il  faut  s'atteler  à  l'analyse  
de  ce  qu'il  faut  mettre  en  place.  Dans  l'étape  d'analyse  des  besoins,  on  est  dans  la  dimension  du  
problème  ;  dans  celle  d'analyse,  on  se  place  dans  celle  de  la  solution.  

 
figure  21  -­‐  retour  sur  le  processus  2TUP  

Nous   avons   décidé   (et   il   s'agit   bien   d'une   décision   d'ordre   pédagogique)   de   regrouper   ces  
deux  étapes  situées  l'une  après  l'autre  sur  la  même  branche  du  Y.  Il  n'est  pas  impossible  que  les  
réactions  de  nos  apprenants  nous  disent  que  cette  option  n'est  pas  bonne.  Nous  reviendrons  alors  
en  "arrière"  et  ferons  deux  chapitres  au  lieu  d'un.  
Nous   avons   énormément   insisté,   dans   le   module   B350   Modélisation   à   objets   pour   la  
conception  de  systèmes  d'information,  sur  les  différentes  notations  UML  qui  sont  utilisées  durant  
cette   phase   d'analyse.   Aussi,   passerons   nous   très   vite   "dessus"   pour   nous   concentrer   sur   le  
processus,  sur  la  démarche.  
Nous   renvoyons   donc   le   lecteur   à   ce   module   pour   les   notations   et   au   fil   rouge   pour   les  
illustrations.  

A. Objectif  central  de  cette  étape  

Cette   étape   a   pour   unique   objectif   de   préciser   le   modèle   de   données   et   les   scénarios   mis   en  
évidence   dans   l'analyse   des   besoins.   Le   processus   que   nous   allons   suivre   est   itératif   et  
incrémental.   Il   peut   paraître   fastidieux,   surtout   si   l'on   est   pas   aidé   par   un   logiciel   d'aide   à   la  
conception  (il  en  existe  de  nombreux,  tels  StarUML,  ArgoUML,  PowerAMC,  Rational  Rose...  voir  à  

Chapitre  3  –  Bien  analyser  son  besoin   C352   30/71  

ce   sujet   le   chapitre   8   du   module   B350).   Le   diagramme   de   classes   va   petit   à   petit   s'enrichir   de  
nouveaux  attributs,  de  nouvelles  classes,  de  nouvelles  opérations.  
Les   scénarios   expriment   les   interactions   entre   les   acteurs   (situés   à   l'extérieur)   et   le   système.  
L'analyse  va  permettre  de  définir  les  échanges  internes  au  système,  entre  les  différents  objets  de  
ce  système.  

B. Hypothèses  de  travail  

À  ce  niveau,  nous  adoptons  plusieurs  hypothèses  importantes  qu'il  convient  de  bien  avoir  en  
mémoire  :  
1)  l'émission  d'un  message  se  traduit,  dans  la  classe  de  réception,  par  le  déclenchement  d'un  
événement   et   l'exécution   d'une   opération.   Pour   simplifier   la   lisibilité   de   nos   propos,   nous  
donnerons  le  même  nom  au  message  et  à  l'opération  qui  traite  le  message.  Cette  opération  fait  
partie  de  l'ensemble  des  opérations  de  la  classe  réceptrice.  

 
figure  22  -­‐  hypothèse  de  travail  n°  1,identité  de    nommage  

2)   de   façon   à   séparer   au   mieux   le   contrôle,   la   vue   et   le   modèle   (selon   le   principe   du   modèle  

MVC),   nous   utiliserons   systématiquement   une   classe   Interface   dont   le   rôle   est   de   s'interposer  
entre  les  acteurs  et  les  classes  "internes".  Le  passage  d'un  scénario  au  diagramme  de  séquences  lui  
correspondant   se   fera   donc   quasi   systématiquement   en   remplaçant   la   "colonne"   Système   par   la  
"colonne"  Interface  (ou  Contrôleur  comme  dans  la  figure  ci-­‐dessous)  :  

 
Chapitre  3  –  Bien  analyser  son  besoin   C352   31/71  
figure  23  -­‐  hypothèse  de  travail  n°  2,  la  classe  Interface  

 
figure  24  -­‐  le  système  est  remplacé  par  l'interface  

NB   :   cette   classe   Interface   (ou   ces   classes   Interface   s'il   y   en   a   plusieurs)   regroupent   le   V   et   le   C   du  
modèle  MVC.  
Il   y   a   au   moins   deux   avantages   à   respecter   cette   hypothèse.   Le   passage   du   scénario   au  
diagramme   de   séquences   est   simplifié   et   sa   traçabilité   est   facilitée   (le   dialogue   est   conservé   d'une  
étape   à   l'autre).   Par   ailleurs,   il   est   possible   de   mettre   en   place   simplement   un   contrôle   de   la  
visibilité  des  classes  (l'interface  est  public,  les  classes  internes  sont  masquées).  
3)   nous   privilégions   le   contrôle   centralisé   du   dialogue   entre   les   classes.   Le   contrôle   est  
localisé   dans   la   classe   Interface.   Il   est   possible   de   mettre   en   place   un   autre   type   de   contrôle,  
décentralisé  dans  chaque  classe,  mais  ce  n'est  pas  ce  que  nous  avons  choisi.  

 
figure  25  -­‐  hypothèse  de  travail  n°  3,  un  contrôle  centralisé  

4)  afin  de  pouvoir  résoudre  simplement  le  problème  de  l'existence  ou  non  d'un  objet,  nous  
associerons   systématiquement   à   chaque   classe   Xxx   une   classe   spéciale,   nommée   Ens.   Xxx   ou  
EnsDeXxx,  ayant  un  seul  objet,  et  ayant  pour  vocation  unique  de  tenir  à  jour  la  "liste"  des  objets  de  
Xxx   existant.   Cette   classe   sera   très   probablement   supprimée   lors   de   la   phase   de   conception   (au  
profit,  par  exemple,  d'un  vecteur  d'objets).  

Chapitre  3  –  Bien  analyser  son  besoin   C352   32/71  

figure  26  -­‐  hypothèse  de  travail  n°  4,  la  classe  Ensemble  

Nous  considérons  ces  hypothèses  de  travail  comme  une  sorte  de  patron  de  spécification.  On  
peut   faire   sans.   Nous   considérons   que   l'adopter   facilite   le   travail   de   création   des   différents  
diagrammes.  

C. Techniques  utilisées  
Nous   allons   développer   ces   techniques   au   travers   d'exemples,   le   plus   souvent   tirés   de   notre  
banque  de  sujet.  

1. Passage  d'un  scénario  à  un  diagramme  de  séquences  :  cas  Les  flots  bleus  

a) Contexte    

La  Société  Civile  Immobilière  Les  Flots  bleus  (ci-­‐après  appelée  l’Agence)  gère  un  parc  locatif  
d’un   millier   d’appartements   et   de   maisons.   Ses   dix   collaborateurs   accueillent   propriétaires   et  
locataires,   rédigent   les   baux   passés   entre   ceux-­‐ci,   encaissent   les   loyers   et   les   charges.   Chacun  
s’occupe   d’un   ensemble   de   locations   séparé   de   ceux   des   autres   et   est   rémunéré  
proportionnellement   à   son   activité.   C’est   le   gérant   de   l’Agence   qui   effectue   les   affectations   de  
collaborateurs  à  un  parc  d’immeubles,  qui  calcule  la  paye  de  ceux-­‐ci.    
L'énoncé  de  ce  cas  comprend,  notamment,  un  diagramme  de  classes  initial  et  un  scénario.  
Une   des   questions   portait   sur   la   transformation   de   ce   scénario   en   un   diagramme   de   séquences  
cohérent  avec  le  diagramme  de  classes.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   33/71  

 b) Éléments  de  départ  

 
figure  27  -­‐  diagramme  de  classes  originel  –  Cas  Les  flots  bleus  

 
figure  28  -­‐  scénario  calcul  des  gains  d'un  collaborateur  –  Cas    Les  flots  bleus  

c) Éléments  de  réponse  

Le   diagramme   de   séquences   est   un   scénario   dans   lequel   la   colonne   Système   est   développée  
pour  y  introduire  les  classes.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   34/71  

  
figure  29  -­‐  diagramme  de  séquences  calcul  des  gains  d'un  collaborateur  –  Cas  Les  Flots  bleus  

d) Commentaires  

Le  diagramme  de  classes  est  cohérent  si  toutes  les  classes  évoquées  dans  les  diagrammes  de  
séquences  y  figurent  et  si  les  messages  correspondent  à  des  opérations  des  classes  réceptrices.  Il  a  
donc   fallu   ajouter   au   modèle   de   données   une   classe,   ContrôleurGestionCollaborateurs.   Il   a   aussi  
fallu  ajouter  les  opérations  suivantes  :  

opération   classe  d'accueil  

portefeuille  ()   ContrôleurGestionCollaborateurs  

partAgence  ()   ContratLocatif  

2. Prise  en  compte  d'un  diagramme  de  collaborations  -­  Cas  Les  flots  bleus  
Dans  le  même  contexte  de  cette  agence  immobilière,  exprimons  ce  qui  se  passe  lors  de  la  
sélection,  par  un  futur  locataire,  via  un  portail  Web,  d’un  logement  libre.  Les  logements  libres  sont  
ceux   qui   n’ont   plus   de   bail   en   cours   associé   (tous   ceux   qui   les   concernent   sont   terminés).   Le  
locataire   fournit   le   nom   de   la   ville,   le   nombre   de   pièces   souhaité   et   un   budget   maximum   à   ne   pas  
dépasser.  Il  reçoit  en  réponse  une  liste  de  logements,  parmi  lesquels  il  va  en  choisir  un.  Une  fois  ce  
choix   transmis   au   système,   il   recevra   les   coordonnées   (téléphone   et   mail)   du   collaborateur   à  
contacter.    

Chapitre  3  –  Bien  analyser  son  besoin   C352   35/71  

 a) Élément  de  départ  

L'énoncé  fournissait  un  diagramme  de  séquences  et  demandait  de  traduire  ce  diagramme  en  
un  diagramme  de  collaborations.  

 
figure  30  -­‐  diagramme  de  séquences    recherche  d'un  logement  libre    –  Cas  Les  Flots  bleus  

b) Élément  de  réponse  

Le   diagramme   de   collaborations   n'est   "qu'un"   diagramme   de   séquences   "écrasé".   Le  

diagramme  suivant  a  été  produit  (voir  la  figure  31).  
NB  :  le  passage  du  diagramme  de  séquences  au  diagramme  de  collaborations  a  permis  de  détecter  
une  erreur  dans  le  premier.  Le  message  filtreVille  contient  un  seul  paramètre  (Logements),  alors  
qu’il  en  faut  deux  (ville  et  Logements).  Ceci  met  encore  plus  en  évidence,  si  besoin  était,  l’intérêt  
de  ce  travail.  
 

Chapitre  3  –  Bien  analyser  son  besoin   C352   36/71  

  
figure  31  -­‐  diagramme  de  collaborations    recherche  d'un  logement  libre    –  Cas  Les  flots  bleus  

c) Commentaires  

Le  diagramme  de  classes  est  cohérent  si  toutes  les  classes  évoquées  dans  les  diagrammes  de  
séquences   et   de   collaboration   y   figurent   et   si   les   messages   correspondent   à   des   opérations   des  
classes   réceptrices.   Il   a   donc   fallu   ajouter   au   modèle   de   données   initial   deux   classes,  
ContrôleurGestionLocation  et  EnsLogements.  Il  a  aussi  fallu  ajouter  les  opérations  suivantes  :  

opération   classe  d'accueil  

libre  (),  rdvVisite  (),  filtreBudget  (),  filtreVille  (),   ContrôleurGestionLocation  

filtrePiece  (),  filtreLibre  ()  

ListeLogements  ()   EnsLogements  

nbPieces  (),  situé  (),  infosCollaborateur  ()   Logement  

ville  ()   Adresse  

loyer  (),  courriel  (),  telephone  ()   ContratLocatif  

courriel  (),  telephone  ()   Collaborateur  

Ce  travail  est  quasiment  mécanique.  Il  est  grandement  facilité  par  l'emploi  d'un  logiciel.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   37/71  

 3. Prise  en  compte  d'un  diagramme  états-­transitions  -­  cas  Les  flots  bleus  
Un  tel  diagramme  est  rattaché  à  une  classe.  Les  différents  états  de  la  classe  seront,  en  fait,  
des   états   des   objets   de   la   classe.   Les   transitions   porteront   des   actions   ;   celles-­‐ci   sont   des  
opérations  de  la  classe.  Tout  ceci  doit  se  retrouver  sur  les  différents  diagrammes  :  

a) Éléments  de  départ  

Voici  le  diagramme  états-­‐transitions  qui  décrit  la  vie  d'un  logement  :  

 
figure  32  -­‐  diagramme  états-­‐transitions  Classe  Logement    –  Cas  Les  flots  bleus  

NB  :  la  transition  volontéDeSignature    part  bien  de  la  frontière  du  super-­‐état  Vacant  ;  elle  s’impose  
en  effet  à  tous  les  états  internes.  
NB  :  nous  n'avons  pas  envisagé  nous  n’avons  pas  envisagé  la  destruction  physique  du  logement,  
qui   pourrait   être   modélisée   par   un   état   final   atteint   à   partir   des   trois   états   Vacant   ,   Réservé   et  
Loué.  
Les  différents  numéros  sur  les  transitions  correspondent  aux  significations  suivantes  :  

1  :  miseEnLocation   2  :  arrêtLocation   3  :  volontéDeSignature  

4  :  [délai  <  8j]  rétractation   4  :  [délai  ≥    8j]  rétractation   6  :  libération  

ou  acceptation  

b) Commentaires  

Rendre  ce  diagramme  états-­‐transitions  cohérent  avec  les  autres  schémas,  c’est  :  
1. fournir   une   variable   état   dans   la   classe   Logement     qui   permette   de   mémoriser   l’état  
courant  du  logement  ;  
2. vérifier   que   toutes   les   actions   mentionnées   dans   le   diagramme   sont   présentes   dans   la  
classe   Logement,   les   événements   correspondant,   quant   à   eux,   à   la   réception   d’un  
message.  

D. Processus  d'analyse  
Le  processus  peut  se  résumer  simplement  comme  suit  :  

Chapitre  3  –  Bien  analyser  son  besoin   C352   38/71  

 • prendre   le   modèle   de   données   (le   diagramme   de   classes)   et   mettre   en   évidence   le  
comportement  des  classes  dynamiques  (celles  dont  la  vie  peut  être  exprimée  au  travers  
de   changements   d'états   et   de   transitions   entre   ces   états)   par   un   diagramme   états-­‐
transitions  PAR  CLASSE.  
• rendre  cohérent  le  modèle  de  données  avec  les  diagrammes  états-­‐transitions.  
• prendre   chaque   scénario   et   le   traduire   soit   par   un   diagramme   de   séquences   (nous  
recommandons  ce  type  de  diagramme)  ou  par  un  diagramme  de  collaborations.  
• rendre   chaque   diagramme   cohérent   avec   le   modèle   de   données   en   reportant   dans   le  
diagramme   de   classes   les   nouvelles   classes   et   les   opérations   servant   à   traiter   les  
messages.  
ATTENTION,   chaque   modification   dans   un   schéma   doit   être   répercuté   sur   les   autres  
diagrammes   (i.e.   les   diagrammes   doivent   être   refaits),   ce   qui   peut   entraîner   par   une   sorte   de  
ricochet  la  modification  d'autres  diagrammes.  
Le  processus  cesse  lorsque  tous  les  scénarios  ont  été  traduits  et  que  le  diagramme  de  classes  
est  cohérent  avec  l'ensemble  des  diagrammes  issus  de  la  traduction  des  scénarios.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   39/71  

VIII. Application  au  cas  «  compte  bancaire  »  
NB  :  Ce  cas  a  fait  l'objet  d'une  présentation  dans  le  chapitre  1.  
La   BICOMAT   (Banque   Industrielle   et   COmmerciale   du   Maine   Anjou   Touraine)   est   une  
fédération   de   banques   de   détail   dont   le   siège   social   se   trouve   à   Tours,   en   Indre-­‐et-­‐Loire.   Son  
secteur   d'activité   couvre   les   départements   de   l'Indre-­‐et-­‐Loire   (37),   du   Maine-­‐et-­‐Loire   (49),  
Mayenne   (53)   et   Sarthe   (72).   Ses   membres   sont   organisés   de   la   même   façon   ;   ils   partagent   les  
mêmes  processus  métier,  tout  en  se  gardant  la  possibilité  d'offrir,  en  plus,  des  services  spécifiques  
à  leurs  clients.  Le  fait  de  se  fédérer  permet  d'avoir  une  "surface"  marketting  plus  importante.  Cela  
permet   également   aux   banques   de   mutualiser   certains   services,   notamment   le   service  
Informatique,   le   service   Salle   des   Marché   (pour   les   achats/ventes   d'actions)   ou   bien   encore   le  
service  Gestion  des  DAB...  
La  Banque  Saumuroise  est  membre  de  la  BICOMAT  depuis  2010.  Elle  a  son  siège  à  Saumur  et  
dispose   de   trois   agences,   une   à   Saumur,   une   à   Montreuil-­‐Bellay   et   une   troisième   à   Doué   la  
fontaine.    
NB  :  le  lecteur  pourra  se  reporter  à  la  présentation  générale  qui  est  faite  du  cas  dans  le  chapitre  1.  
La   Banque   Saumuroise   veut   développer   une   agence   virtuelle   (qui   s'appellera   agency)   qui  
offrira   à   ses   clients   (presque)   tous   les   services   disponibles   en   agence.   Accessible   via   Internet,   à  
tous  les  clients  de  la  banque  en  ayant  fait  la  demande,  sécurisée,  elle  a  vocation  à  être  déployée  
dans  toute  la  BICOMAT  si  l'expérimentation  saumuroise  se  révèle  satisfaisante.  
Cette   agence   virtuelle   nécessite   l'usage   d'un   boîtier   spécial   fourni   aux   clients   adhérant   au  
service.  Ce  boîtier  sert  à  prouver  que  le  donneur  d'ordre  (i.e.  celui  qui  s'est  connecté  au  service  et  
qui  prétend  être  un  client    de  la  banque)  est  bien  celui  qu'il  prétend  être.  Le  boîtier  accueille  la  
carte  bancaire  du  client  et  fournit  un  code  de  contrôle  à  usage  unique.  

Insérez votre carte bancaire

Banque Saumuroise ici :

Bs

A tout moment, vous pouvez

consulter l'aide en ligne sur le
site de la Banque Saumuroise.
Prêt, partez !  
figure  33  -­‐  notice  explicative  du  boîtier  de  contrôle  

Chapitre  3  –  Bien  analyser  son  besoin   C352   40/71  

 Le  code  est  demandé  pour  valider  toute  opération  sur  agency.  
L'interface  d'agency  n'est  pas  encore  définitivement  fixé  mais  il  devrait  ressembler  à  ceci  :  

 
figure  34  -­‐  aspect,  non  définitif,  de  l'interface  d'agency  

Le   bandeau   d'information,   comme   son   nom   l'indique,   donne   accès   à   tout   un   ensemble  
d'informations,  classées  en  cinq  catégories  :  Comptes,  Cartes  &  Services,  Épargne  &  Placements,  
Crédits,   Assurances.   Cette   dernière   catégorie   ne   sera   pas   développée   dans   la   première   version  
d'agency.    

 
figure  35  -­‐  aspect,  non  définitif,  du  bandeau  d'information  de  l'interface  d'agency  

Dans  chaque  catégorie,  on  trouvera  soit  des  renseignements  généraux,  soit  des  informations  
propres  au  client.  L'onglet  Comptes,  par  exemple,  est  un  bouton  fournissant  le  solde  de  tous  les  
comptes  du  client  (ceux-­‐ci  étant  affichés  dans  l'espace  d'affichage).  
Le   bandeau   des   commandes   fournit   toutes   les   opérations   accessibles   selon   la   catégorie.   Ces  
menus  sont  contextuels  ;  ils  changent  en  fonction  du  type  des  données  manipulées.  Ils  ne  sont  pas  
exclusifs   (certaines   fonctions   sont   communes   à   plusieurs   catégories).   Voici,   à   titre   d'exemple,   la  
liste  des  fonctions  disponibles  pour  les  catégories  Comptes  (C)  et  Épargne  &  Placements  (E)  :  
Autorisation  découvert  (C)   Consulter  mes  contrats  (C,  E)  
Consulter  mes  documents  (C,  E)   Faire  opposition  carte  (C)  
Gérer  mes  alertes  (C,  E)   Gérer  virements  émis  (C)  
Imprimer  IBAN  RIB  (C)   Opposition  prélèvement  (C)  
Pointer  écritures  (C,  E)   Sécuriser  mes  opérations  (C)  
Souscrire  documents  électroniques  (C)   Télécharger  écritures  (C)  
Virement  entre  comptes  (C,  E)   Virement  permanent  (E)  
Virement  vers  un  tiers  (C)  

Chapitre  3  –  Bien  analyser  son  besoin   C352   41/71  

figure  36  -­‐  liste,  non  exhaustive,  des  fonctionnalités  d'agency  

Certaines  de  ces  opérations  sont  "à  tiroirs",  c'est-­‐à-­‐dire  qu'elles  donnent  elles  même  accès  à  
une  liste  de  sous-­‐opérations.  

 
figure  37  -­‐  exemple  de  menus  contextuels  

A. Périmètre  d'intervention  
Le   développement   d'agency   va   se   faire   en   plusieurs   étapes.   La   première   concernera   la  
gestion   des   comptes   et   des   placements   et   épargne   de   clients,   ainsi   que   leur   authentification   via   le  
boîtier  de  contrôle.  La  deuxième  étape  prendra  en  compte  les  onglets  Cartes  &  Services  et  Crédits.  
La  troisième  et  dernière  étape  traitera  des  assurances.  
Le   périmètre   correspond   donc   à   tout   ce   qui   concerne   Comptes,   Épargne   &   Placements   et  
authentification.   Les   autres   aspects   sont   "rejetés"   à   l'extérieur,   dans   une   zone   périphérique  
(correspondant  à  des  éléments  pouvant  éventuellement  interagir  avec  ceux  du  périmètre).  
Les   acteurs   impliqués   sont   essentiellement   les   clients   et,   éventuellement,   les   agents  
d'accueil.   Toutes   ces   personnes   seront   connectées   à   l'application   agency   au   travers   d'un   écran  
(voir  figure  34  et  figure  35),  les  clients  utilisant  en  plus  un  boîtier  de  contrôle.  
Les  transactions  effectuées  par  les  clients  via  les  automates  multifonctions  ne  font  pas  partie  
du  périmètre.  

B. Équipes  
Huit   types   distincts   de   personnes,   huit   "rôles"   ont   pu   être   mis   en   évidence   à   la   Banque  
Saumuroise  :  
-­‐  Directeur  agence,   -­‐  Responsable  RH,  
-­‐  Secrétaire,   -­‐  Responsable  agence,  
-­‐  Conseiller  chargé  de  clientèle  physique,   -­‐  Conseiller  chargé  de  clientèle  morale,  

Chapitre  3  –  Bien  analyser  son  besoin   C352   42/71  

 -­‐  Agent  d'accueil,   -­‐  Client.  
Ces   rôles   ne   recouvrent   pas   exactement   des   personnes   physiques,   certaines   pouvant   en  
effet  en  jouer  plusieurs.  Ainsi,  par  exemple,  un  responsable  d'agence  est-­‐il  également  chargé  de  
clientèle.   La   figure   ci-­‐dessous   recense   tous   les   types   de   "personnes"   et   leurs   relations,   celles-­‐ci  
pouvant  être  une  liaison  d'usage  (un  client  se  sert  d'agency)  ou  d'héritage  (un  chargé  de  clientèle  
est  aussi  un  secrétaire  ;  le  directeur  de  la  banque  est  également  un  responsable  d'agence...).  

 
figure  38  -­‐  différents  types  de  "personnes"  et  relations  entre  eux  

L'agence   virtuelle   servira   essentiellement   aux   clients   de   la   banque   et,   éventuellement,   aux  
agents   chargés   de   l'accueil.   A   priori,   les   conseillers   chargés   de   clientèle,   qui   disposent   dans   leur  
bureau  d'outils  plus  puissants,  n'utiliseront  pas  (en  tant  que  conseillers)  agency.  
La  direction  de  la  banque  ayant  renoncé  à  impliquer  un  de  ses  clients  dans  la  définition  de  
cet   outil,   c'est   un   membre   du   personnel   d'une   banque   membre   de   la   fédération   qui   jouera   le   rôle  
de  client.  Un  des  conseillers  de  Saumur  constituera,  avec  cette  personne,  la  maîtrise  d'ouvrage.  La  
responsabilité   de   cette   équipe   MOA   sera   assurée   par   le   responsable   de   l'agence   de   Montreuil-­‐
Bellay.  
La  maîtrise  d'œuvre  comprendra  deux  informaticiens  détachés  par  la  BICOMAT,  placés  sous  
la  direction  du  responsable  du  service  informatique  de  cette  même  BICOMAT.  

C. Besoins  fonctionnels  
Nous   détaillerons   ci-­‐après   les   cas   d'utilisation   suivants   :   Gérer   les   autorisations,   Gérer  
Épargne  &  Placements,  Gérer  les  comptes.  Ces  cas  nécessitent  l'intervention  de  deux  acteurs,  le  
client  et  le  conseiller.  
Tous  ces  cas  sont  liés  les  uns  aux  autres,  via  le  contrôle  d'accès.  
Chapitre  3  –  Bien  analyser  son  besoin   C352   43/71  
  
figure  39  -­‐  liaisons  entre  paquetages  

Cas d'utilisation : Gérer les autorisations

Acteurs : Client, Conseiller
Invariant : ---
Description générale
La gestion des autorisations comprend la création du compte (login, mot de passe) par le conseiller, le
contrôle d'accès lors de la connexion du client, le traitement de l'oubli du mot de passe et l'annulation de l'accès.
Cas : création du compte agency
précondition : le client a un compte bancaire à la Banque Saumuroise, il a une carte bancaire, il a souscrit un
contrat agency et n'a pas déjà de compte agency.
Le conseiller fourni un login et un mot de passe provisoire (les deux sont calculés par l'ordinateur) au client
qui veut se servir de l'application. Il lui propose de fournir une question (qui lui sera posée s'il a oublié son mot de
passe) et la réponse à cette question. Le client doit ensuite remplacer le mot de passe provisoire par le définitif.
Cas : traitement de l'oubli d'un mot de passe
précondition : le client a un compte agency.
Le client qui signale l'oubli de son mot de passe se voit poser deux questions.
NB : ces questions sont envoyées par mail à l'adresse électronique qu'a fourni le client au moment où il a
souscrit un contrat agency.
La première question concerne le numéro de sa carte bancaire. La deuxième est celle que le client a lui-même
choisie. En cas d'erreur, les questions sont reposées une deuxième fois. Si les réponses sont toujours mauvaises,
l'accès est annulé (voir le cas Annulation d'un accès). Si les réponses sont correctes, un nouveau mot de passe
provisoire est fourni, le client est invité à se reconnecter puis à changer au plus vite de mot de passe.
Cas : annulation d'un accès
précondition : le client a un compte agency.
Lors d'une annulation, le conseiller chargé du client est informé, tout accès au compte agency est refusé et les
mouvements sur les comptes (bancaires, d'épargne...) sont surveillés. Il y a trois sortes d'annulation :
- suite à une perte de mot de passe suivie d'une incapacité du client à répondre aux questions posées,
- suite à la demande (écrite) du client d'arrêt du service,
- suite à un échec de connexion.
Cas : contrôle d'accès
précondition : le client a un compte agency.
Le client qui veut accéder à agency doit fournir son login et son mot de passe. Il dispose de deux possibilités
d'erreurs. À la troisième, l'accès est annulé (voir le cas Annulation d'un accès). Une fois le contrôle d'accès
satisfait, le client peut se servir de toutes les fonctionnalités d'agency. Toutes ses opérations sont mémorisées.
En cas d'interruption en cours de contrôle (suite à une passe de courant, une panne d'ordinateur...), la
procédure doit être recommencée depuis le début.

Chapitre  3  –  Bien  analyser  son  besoin   C352   44/71  

  
figure  40  -­‐  diagramme  de  cas  d'utilisation  Gérer  les  autorisations  

Cas d'utilisation : Gérer Épargne & Placements

Acteurs : Client, Conseiller
Invariant : ---
Description générale
La gestion de l'épargne et des placements comprend la gestion des virements, la consultation des divers
documents et la gestion des alertes.
Cas : gestion des virements
précondition : le client a un compte bancaire à la Banque Saumuroise, il a souscrit un contrat agency.
Il y a deux types de virements, les virements ponctuels et les virements permanents. Au niveau de l'épargne,
le client peut, s'il le souhaite, avoir un livret A –LIV– (un seul par personnes quelque soit la banque), un livret
Développement durable (LDD), un livret d'Investissement Local (LIL) et un compte Dépôt Solidarité (CDS). Lors
du lancement de cette fonctionnalité, l'ensemble des comptes épargne du client est affiché avec le solde de chacun.
Le client peut effectuer des transferts d'un compte à un autre (sans dépasser les planchers minimum et maximum
existant pour chaque compte), demander la clôture d'un compte épargne (ce qui déclenche le calcul des intérêts
acquis et des impôts à payer). La création d'un compte épargne est faite par le conseiller chargé du client.
Les virements permanents sont des virements ponctuels mis en place pour une période donnée (d'une date d1
à une date d2), avec une périodicité donnée (une fois par mois, une fois par trimestre, une fois par an). La première
échéance doit être postérieure à la date de mise en place augmentée d'une quinzaine de jours. Il est possible de
lister l'ensemble des virements permanents mis en place, d'en annuler un, d'en modifier un ou bien d'en créer un.
Cette dernière opération nécessite la signature d'un contrat, établi par le conseiller chargé du client.
Cas : consultation des documents
précondition : le client a un compte agency.
Le client peut consulter les documents rédigés au moment de l'ouverture des comptes épargne (contrats) ou
demander un relevé des opérations effectuées sur ses comptes depuis une date d1 jusqu'à une date d2. Il peut
également télécharger un relevé au format xls (ce qui lui permettra de retraiter celui-ci avec Excel). Il peut enfin
effectuer le pointage des écritures passées, celui-ci étant mémorisé.
Cas : gestion des alertes
précondition : le client a un compte agency
Placer une alerte revient à positionner un marqueur temporel pour avertir le client d'effectuer une opération à
une date donnée. La gestion des alertes permet de lister, de modifier voire de supprimer un de ces marqueurs.
Le client reçoit une alerte, soit par mail, soit par SMS. Il a la possibilité de modifier le type d'envoi (passer
d'un SMS à un email ou inversement).

Chapitre  3  –  Bien  analyser  son  besoin   C352   45/71  

  
figure  41  -­‐  diagramme  de  cas  d'utilisation  Gérer  Épargne  &  Placements  

Cas d'utilisation : Gérer les comptes

Acteurs : Client; Conseiller
Invariant : ---
Description générale
La gestion des comprend la consultation des documents, la gestion des virements, la gestion des alertes et le
contrôle des mouvements.
Cas : gestion des alertes
précondition : le client a un compte agency
Placer une alerte revient à positionner un marqueur temporel pour avertir le client d'effectuer une opération à
une date donnée. La gestion des alertes permet de lister, de modifier voire de supprimer un de ces marqueurs.
Le client reçoit une alerte, soit par mail, soit par SMS. Il a la possibilité de modifier le type d'envoi (passer
d'un SMS à un email ou inversement).
Cas : consultation des documents
précondition : le client a un compte agency.
Le client peut consulter les documents rédigés au moment de l'ouverture des comptes épargne (contrats) ou
demander un relevé des opérations effectuées sur ses comptes depuis une date d1 jusqu'à une date d2. Il peut
également télécharger un relevé au format xls (ce qui lui permettra de retraiter celui-ci avec Excel). Il peut aussi
demander l'impression d'un RIB. Il peut effectuer le pointage des écritures passées, celui-ci étant mémorisé. Il peut
enfin demander à recevoir des relevés de comptes par voie électronique.
Cas : gestion des virements
précondition : le client a un compte agency
Les seuls virements autorisés sont des virements ponctuels, soit entre les comptes du client, soit vers un tiers.
Le client peut effectuer des transferts, immédiats ou différés, entre ses comptes, à la seule condition que le
plancher minimal du compte débité soit respecté (le compte ne peut devenir débiteur suite au virement).
Les virements vers un tiers sont soumis à deux conditions : le compte débité est suffisamment approvisionné
pour autoriser le versement, le tiers est actif. Pour rendre actif un tiers, il faut le créer puis, après avoir laissé
passer un délai de 24h, il faut l'activer. Créer un tiers revient à fournir son nom, ses coordonnées bancaires.
Activer un tiers nécessite l'usage du boîtier de contrôle. L'ordinateur extrait du numéro du compte du tiers une
série de 8 chiffres. Celle-ci est fournie au boitier qui retourne 8 autres chiffres. Ce sont ces derniers qu'il faut
fournir pour activer le bénéficiaire. Les virements vers un tiers actif sont, soit à effet immédiat, soit différés.
Le client dispose d'une dernière fonctionnalité, celle qui lui permet de gérer ses bénéficiaires (lister,
supprimer, modifier, créer, activer).
Cas : contrôle des mouvements
précondition : le client a un compte agency
Le client peut lister ses autorisations de découvert, faire une demande de modification (cette demande sera
traitée par le conseiller). Il peut également faire opposition sur sa carte bancaire (ou sur l'une de ses cartes s'il en a
plusieurs), cette opposition étant traitée en priorité par le logiciel. Il peut enfin faire opposition sur un prélèvement
automatique, lister ceux-ci, en supprimer un, en ajouter.

Chapitre  3  –  Bien  analyser  son  besoin   C352   46/71  

  
figure  42  -­‐  diagramme  de  cas  d'utilisation  Gérer  les  comptes  

Il   y   a   de   nombreux   scénarios   possibles.   Pour   Gérer   les   autorisations,   on   en   distingue   au  

moins  une  dizaine  :  
-­‐  Créer  un  compte  sans  erreur,   -­‐  Créer  un  compte  sans  être  client,  
-­‐  Créer  un  deuxième  compte  agency,   -­‐  Annuler  un  accès,  
-­‐  Restaurer  un  mot  de  passe  sans  erreur,   -­‐  Restaurer  un  mot  de  passe  avec  une  erreur,  
-­‐  Restaurer  un  mot  de  passe  avec  deux  erreurs,   -­‐  Contrôler  l'accès  sans  erreur,  
-­‐  Contrôler  l'accès  avec  une  erreur,   -­‐  Contrôler  l'accès  avec  deux  erreurs.  
La  gestion  des  comptes  comprend  au  minimum  dix-­‐huit  scénarios  :  
-­‐  Demander  la  clôture  d'un  compte,   -­‐  Créer  un  compte  épargne,  
-­‐  Effectuer  un  virement  sans  dépassement,   -­‐  Effectuer  un  virement  avec  dépassement,  
-­‐  Lister  les  virements  permanents,   -­‐  Mettre  en  place  un  virement  permanent,  
-­‐  Annuler  un  virement  permanent  à  temps,   -­‐  Annuler  un  virement  permanent  trop  tard,  
-­‐  Modifier  un  virement  permanent,   -­‐  Consulter  ses  contrats,  
-­‐  Demander  un  relevé  des  opérations,   -­‐  Télécharger  un  relevé  des  opérations,  
-­‐  Pointer  les  écritures,   -­‐  Placer  une  alerte,  
-­‐  Lister  les  alertes,   -­‐  Supprimer  une  alerte,  
-­‐  Modifier  le  type  d'envoi,   -­‐  Modifier  une  alerte.  
La  gestion  des  comptes,  quant  à  elle,  se  fait  par  au  moins  vingt-­‐cinq  opérations  :  
-­‐  Placer  une  alerte,   -­‐  Lister  les  alertes,  
-­‐  Supprimer  une  alerte,   -­‐  Modifier  le  type  d'envoi,  
-­‐  Modifier  une  alerte,   -­‐  Consulter  ses  contrats,  

Chapitre  3  –  Bien  analyser  son  besoin   C352   47/71  

-­‐  Demander  un  relevé  des  opérations,   -­‐  Télécharger  un  relevé  des  opérations,  
-­‐  Imprimer  un  RIB,   -­‐  Souscrire  documents  électroniques,  
-­‐  Pointer  les  écritures,   -­‐  Créer  un  tiers,  
-­‐  Activer  un  tiers,   -­‐  Lister  les  bénéficiaires,  
-­‐  Supprimer  un  bénéficiaire,   -­‐  Modifier  un  bénéficiaire,  
-­‐  Faire  un  virement  avec  dépassement,   -­‐  Faire  un  virement  sans  dépassement,  
-­‐  Demander  autorisation  de  découvert,   -­‐  Lister  autorisations  de  découvert,  
-­‐  Faire  opposition  sur  carte,   -­‐  Faire  opposition  prélèvement  automatique,  
-­‐  Lister  prélèvements  automatiques,   -­‐  Supprimer  prélèvement  automatique,  
-­‐  Ajouter  prélèvement  automatique.  
Nous  ne  les  développerons  pas  tous,  faute  de  place  et  de  temps.  En  voici  quelques-­‐uns.  

 
figure  43  -­‐  Créer  un  compte  sans  être  client  

 
figure  44  -­‐  Créer  un  deuxième  compte  agency  

Chapitre  3  –  Bien  analyser  son  besoin   C352   48/71  

  
figure  45  -­‐  Créer  un  compte  sans  erreur  

 
figure  46  -­‐  Lister  les  alertes  

 
figure  47  -­‐  Créer  un  tiers  

Chapitre  3  –  Bien  analyser  son  besoin   C352   49/71  

  
figure  48  -­‐  Modifier  le  type  d'envoi  

 
figure  49  -­‐  Activer  un  tiers  

 
figure  50  -­‐  Activation  possible  

Chapitre  3  –  Bien  analyser  son  besoin   C352   50/71  

  
figure  51  -­‐  Créer  un  virement  permanent  

 
figure  52  -­‐  Créer  un  virement  ponctuel  avec  dépassement  solde  compte  

 
figure  53  -­‐  Créer  un  compte  épargne  

Chapitre  3  –  Bien  analyser  son  besoin   C352   51/71  

  
figure  54  -­‐  Créer  un  virement  ponctuel  de  compte  à  compte  sans  dépassement  

 
figure  55  -­‐  Clôturer  un  compte  épargne  

 
figure  56  -­‐  Pointer  les  écritures  

Chapitre  3  –  Bien  analyser  son  besoin   C352   52/71  

 Il  y  a  bien  d'autres  scénarios  possibles.  Nous  ne  détaillerons  pas  davantage  et  laissons  aux  
apprenants  le  soin  de  le  faire  s'ils  le  souhaitent.  
Cette   partie   dédiée   à   l'expression   des   besoins   se   termine   souvent   par   la   production   d'un  
modèle   de   données,   ébauche   du   SI   du   client.   Compte-­‐tenu   de   tout   ce   qui   a   été   évoqué   plus   haut,  
nous  proposons  le  diagramme  suivant.  

 
figure  57  -­‐  Première  ébauche  du  modèle  métier  

Plusieurs  données  sont  exprimées  sous  forme  de  codes.  En  voici  la  signification  :  
TypeCarte  =  {Visa,  Mastercard,  VisaPlus,  Eurocard}  
TypeCompte  =  {Compte  Épargne,  Compte  chèques,  Compte  Placements}  
TypeClient  =  {privé,  moral}  
TypeOpération   =   {Retrait   liquide,   dépôt   liquide,   virement   interne,   virement   externe,  
paiement  chèque,  paiement  CB,  dépôt  chèque}  
Il   restera   à   affiner   ce   modèle   en   le   confrontant   aux   différents   diagrammes   de   séquences   qui  
seront  produits  à  partir  des  scénarios.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   53/71  

D. Besoins  non  fonctionnels  
S'agissant  d'une  application  en  ligne,  la  fiabilité  est  un  besoin  impérieux.  En  cas  de  panne  (ce  
qui   ne   devra   pas     arriver   plus   d'une   fois   par   semaine),   le   temps   d'indisponibilité   du   service   ne  
devra  pas  dépasser  une  heure.  
Lors   des   opérations   de   maintenance,   l'immobilisation   d'agency   ne   pourra   excéder   deux  
heures,  ces  interventions  devant  obligatoirement  se  faire  de  nuit,  entre  deux  et  quatre  heures  du  
matin  ;  les  clients  devront,  par  ailleurs,  être  avertis  des  dates  au  minimum  trois  jours  avant.  
La  clarté  des  informations  et  la  facilité  d'utilisation  seront  contrôlées  très  régulièrement  par  
un  organisme  extérieur  à  la  BICOMAT  et  le  taux  de  satisfaction  devra  dépasser  les  80%.  
Enfin,  la  sécurité  du  site  devra  être  maximale.  La  banque  étant  responsable  sur  ses  propres  
deniers,   aucun   accès   non   autorisé   sera   toléré.   En   cas   de   doute   (par   exemple   après   trois   tentatives  
d'accès   infructueux),   le   service   sera   suspendu   pour   le   client   et   il   devra   passer   par   un   conseiller  
pour  obtenir  un  nouveau  mot  de  passe.  

E. Préparation  aux  tests  

Les   scénarios   sont   les   éléments   qui   vont   servir   à   préparer   les   tests.   En   théorie,   chaque  
scénario  doit  faire  l'objet  d'au  moins  un  test  (voire  de  plusieurs  s'il  comprend  plusieurs  situations).  
Pour  illustrer  ceci,  prenons  le  cas  de  la  création  d'un  compte  agency.  Cette  création  recouvre  trois1  
cas  :  
-­‐  création  d'un  compte  par  une  personne  non  cliente  de  la  Banque  Saumuroise  (BS),  
-­‐  création  d'un  compte  par  une  personne  cliente  de  la  BS,  ayant  déjà  un  compte  agency,  
-­‐  création  d'un  compte  par  une  personne  cliente  de  la  BS,  n'ayant  pas  encore  de  compte  agency.  
Ce  dernier  cas  est  le  cas  nominal,  les  deux  autres  des  cas  alternatifs.  

 
figure  58  -­‐  Différents  scénarios  de  la  création  d'un  compte  

Prenons   un   autre   exemple,   celui   du   pointage   des   écritures.   Cette   fonctionnalité   est  
constituée  d'une  boucle  de  traitement  "autour"  de  chaque  mouvement  passé  sur  le  compte.    

                                                                                                                         
1
  Deux   tests   conduisent,   en   théorie,   à   quatre   situations   différentes.   Pour   autant,   trois   seulement   seront   prises   en  
compte.   Le   quatrième   cas   (celui   où   la   personne   qui   demande   la   création   n'est   pas   cliente   de   la   Banque   Saumuroise   et  
malgré  tout  a  déjà  un  compte  agency)  n'est  pas  possible.    

Chapitre  3  –  Bien  analyser  son  besoin   C352   54/71  

  
figure  59  -­‐  Différents  scénarios  de  pointage  des  écritures  

Il  y  a  trois  situations  possibles  (et  donc  trois  tests  à  effectuer)  :  

• le  client  demandant  le  pointage  n'est  pas  client  agency,  
• le  demandeur  est  client  agency  et  il  y  a  un  seul  mouvement  à  pointer,  
• le  demandeur  est  client  agency  et  il  y  a  plus  d'un  mouvement  à  pointer.  
Cette  dernière  situation  est  probablement  le  cas  nominal,  les  deux  autres  des  cas  alternatifs.  
Tous   les   scénarios   sont   susceptibles   d'être   examinés   de   la   même   façon.   Il   faut   toutefois  
prendre  en  compte  les  priorités  définies  par  la  MOA.  Ici,  c'est  la  sécurité  qui  est  mise  en  avant.  Les  
tests  seront  donc  renforcés  à  ce  niveau.  

F. Analyse  de  l'application  

NB  :  ne  pouvant  pas  réaliser  la  totalité  de  l'analyse  (cela  sera  l'objet  d'un  des  projets  du  module  
pratique   C353   associé   à   celui-­‐ci),   nous   savons   sélectionné   quelques   éléments   illustrant   bien,   selon  
nous,  le  travail  à  faire  durant  cette  étape.  Seront  successivement  présentés  :  
• trois   diagrammes   états-­‐transitions,   exprimant   la   "vie"   des   objets   Tiers,   Opération   et  
Virement  ;  
• huit  diagrammes  de  séquences  correspondant  aux  scénarios  suivants  :  
o créer  un  compte  agency  sans  erreur  (figure  45),  
o créer  un  tiers  (figure  47),  
o activation  possible  (figure  50),  
o activer  un  tiers  (figure  49),  
o créer  un  compte  épargne  (figure  53),  
o clôturer  un  compte  épargne  (figure  55),  
o créer  un  virement  permanent  (figure  51),  
o pointer  les  écritures  (figure  56).  

Chapitre  3  –  Bien  analyser  son  besoin   C352   55/71  

 1. Vie  des  objets  Tiers,  Opération  et  Virement  
NB  :  nous  remarquons  déjà  que  le  modèle  métier  que  nous  avons  fourni  en  fin  de  l'étape  d'analyse  
des   besoins   ne   fait   pas   apparaître   le   tiers.   Il   faudra   donc   le   modifier.   Par   ailleurs,   la   distinction  
opération-­‐virement  n'est  pas  très  claire.  Elle  va  devoir  être  précisée.  
Un  tiers  est  créé,  puis,  au  bout  de  24h,  activable.  Il  est  ensuite  activé.  Ce  tiers  sera  ensuite  
"utilisé"  (il  recevra  des  virements)  et,  un  jour,  supprimé.  Tout  ceci  peut  se  modéliser  ainsi  :  

 
figure  60  -­‐  différentes  étapes  dans  la  vie  d'un  tiers  

Outre   la   création   d'une   classe   Tiers   (avec   un   attribut   étatTiers   pour   mémoriser   l'état   du  
tiers),   ce   diagramme   génère   l'apparition   des   opérations   MettreTiers(),   Création(),   Activation()   et  
Suppression()  dans  cette  classe.  
Une  opération  est  créée,  pointée  ou  non,  archivée.  Elle  ne  peut  être  supprimée.  L'annulation  
d'une  opération  n'est  pas  non  plus  possible  (en  fait,  l'annulation  se  fait  en  créant  une  opération  
"contraire").  Une  opération  ne  peut  pas  être  différée  SAUF  s'il  s'agit  d'un  virement  ponctuel.  
Un  virement  est  une  opération.  La  caractéristique  d'un  virement  est  qu'il  peut  être  différé.  
Un  virement  permanent  est  en  fait  une  succession  de  virements  effectués  à  des  dates  régulières.  
Ces  virements  sont,  par  nature,  différés  –sauf,  peut-­‐être–  le  premier.  
Tout   ceci   peut   se   modéliser   ainsi   (la   partie   spécifique   d'un   virement   différé   étant  
matérialisée  par  des  traits  pointillés)  :  

Chapitre  3  –  Bien  analyser  son  besoin   C352   56/71  

  
figure  61  -­‐  différentes  étapes  dans  la  vie  d'une  opération  

L'existence   de   ce   diagramme   entraîne   la   création   d'un   attribut   étatOpération   (qui   servira  

pour  mémoriser  l'état  de  l'opération)  dans  la  classe  Opération,  des  opérations  MettreEnAttente()  
et   Exécuter()   dans   la   classe   correspondant   au   virement   différé   (elle   s'appelle   actuellement    
Différée   dans   le   modèle   métier),   de   Création(),   Archivage(),   EnregistrerPointage()   dans   la   classe  
correspondant  aux  opérations  ponctuelles  (elle  est  nommée  Ponctuelle).  

2. Détail  des  différentes  opérations  sélectionnées  

a) Créer  un  compte  agency  sans  erreur  

La  création  de  ce  compte  (une  fois  les  contrôles  passés)  revient  à  modifier  les  informations  
contenues  dans  la  classe  Client.  Le  diagramme  de  séquences  ci-­‐après  décrit  les  traitements  mis  en  
œuvre  :  

 
Chapitre  3  –  Bien  analyser  son  besoin   C352   57/71  
figure  62  -­‐  diagramme  de  séquences  Créer  un  compte  agency  sans  erreur  

Ce   diagramme   "apporte"   la   création   de   deux   classes   supplémentaires,   Interface   et   Ens.  

Clients,  ainsi  que  de  plusieurs  opérations  :  

opération   classe  d'accueil  

CréerCompteAgency  ()   Interface  

Existe?  ()   Ens.  Clients  

ClientAgency?  ()   Client  

CréerClientAgency  ()   Client  

b) Créer  un  tiers  

Le  tiers  est  un  client  (au  sens  du  modèle  métier)  "light",  c'est-­‐à-­‐dire  que  nous  n'avons  pas  
autant  d'informations  à  son  sujet.  Il  est  lié  à  une  banque  et  possède  un  compte.  Il  n'a  pas  de  carte  
bancaire  connue,  il  n'est  pas  assisté  par  un  conseiller  et  ne  réalise  aucune  opération.  
Le  modèle  métier  doit  donc  être  retouché  pour  faire  apparaître  ce  tiers  :  

 
figure  63  -­‐  nouveau  modèle  métier  

Chapitre  3  –  Bien  analyser  son  besoin   C352   58/71  

 Cette   modification   effectuée   (nous   n'avons   pas   répercuté   les   changements   signalés  
précédemment),   on   peut   visualiser   sur   le   diagramme   de   séquences   suivant   les   échanges   de  
messages  entre  les  différentes  classes  concernées  et  les  traitements  mis  en  œuvre  :  

 
figure  64  -­‐  diagramme  de  séquences  Créer  un  tiers  

NB   :   nous   avons   fait   l'hypothèse   d'un   timer   externe.   Si   tel   n'était   pas   le   cas,   il   faudrait   ajouter   une  
classe  et  la  doter  de  l'opération  Attendre  ().  
Le  diagramme  de  séquences  introduit  plusieurs  opérations  :  

opération   classe  d'accueil  

CréerTiers  ()   Interface  

CréerTier  ()   Client  

AjouterClient  ()   Ens.  Clients  

LierBqeTiers  ()   Banque  

LierCpteTiers  ()   Compte  

c) Activation  possible  

Rendre   un   tiers   activable   revient   simplement   à   changer   son   état.   Il   passe   de   "non   actif"   à  
"activable".  Le  diagramme  de  séquences  correspondant  est  le  suivant  :  

Chapitre  3  –  Bien  analyser  son  besoin   C352   59/71  

  
figure  65  -­‐  diagramme  de  séquences  Activation  possible  

Deux  opérations  sont  à  ajouter  au  modèle  de  données  :  

opération   classe  d'accueil  

Délai24hPassé  ()   Interface  

MettreTiers  ()   Client  

d) Activer  un  tiers  

Un   tiers   peut   être   activé   s'il   est   dans   l'état   "activable".   Le   traitement   présenté   dans   le  
scénario  met  en  œuvre  un  ensemble  de  contrôles  que  nous  allons  conserver  dans  le  diagramme  
de  séquences.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   60/71  

figure  66  -­‐  diagramme  de  séquences  Activer  un  tiers  

Cinq  nouvelles  opérations  sont  apparues  dans  le  diagramme  et  doivent  être  reportées  dans  
le  modèle  des  données  :  

opération   classe  d'accueil  

ActiverTiers  ()   Interface  

Etat  ?  ()   Client  

GénérerCode  ()   Interface  

AnalyserCode  ()   Interface  

Activation  ()   Client  

e) Créer  un  compte  épargne  

Un   compte   épargne   est   un   compte.   Il   a   un   taux   de   rémunération   et   ne   peut   pas   être   à  

découvert.   Il   est   alimenté   soit   par   un   virement   ponctuel,   soit   par   un   virement   permanent.   La  
création  d'un  tel  compte  est  décrite  par  le  diagramme  de  séquences  suivant  :  

 
figure  67  -­‐  diagramme  de  séquences  Créer  un  compte  épargne  

NB   :   le   traitement   décrit   ci-­‐dessus   est   celui   d'une   création   à   partir   d'un   virement   ponctuel.   La  
création   à   partir   d'un   virement   permanent   nécessiterait   la   mise   en   place   de   tous   les   virements  
différés.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   61/71  

 Le  solde  du  nouveau  compte  est  égal  au  montant  du  versement  initial.  Il  est  enregistré  lors  
de   la   création   du   compte   (par   l'opération   CreerCpteEpar).   La   prise   en   compte   de   ce   traitement  
modifie  le  modèle  de  données.  Outre  la  création  d'une  nouvelle  classe  Épargne,  fille  de  la  classe  
Compte,  il  y  a  ajout  de  plusieurs  opérations.  

 
figure  68  -­‐  modèle  de  données  modifié  

opération   classe  d'accueil  

CreerCompte  ()   Interface  

CreerCpteEpar  ()   Compte  

AjouterCpte  ()     Ens.  Comptes  

LierCpteBqe  ()   Banque  

LierCpteClient  ()   Client  

Prélever  ()   Opération  

AjouterOp  ()   Ens.  opérations  

VerserLier  ()   Opération  

LierOp1Op2  ()   Opération  

LierOpClient  ()   Client  

LierOpCpte  ()   Compte  

f) Clôturer  un  compte  épargne  

La  fermeture  d'un  compte  épargne,  en  soit,  revient  à  "marquer"  le  compte  comme  "clôturé".  

Chapitre  3  –  Bien  analyser  son  besoin   C352   62/71  

NB  :  il  faut  donc  ajouter  un  attribut  étatCompte  dans  la  classe  Compte  Épargne  pour  prendre  en  
compte  ceci.  
La   "difficulté"   (si   tant   est   que   cela   en   soit   une)   réside   dans   le   calcul   des   intérêts   qui   va  
nécessiter  de  reprendre  chaque  versement,  d'en  prendre  la  durée  et  de  procéder  au  calcul.  Une  
fois   ce   montant   total   obtenu,   le   calcul   des   impôts   à   payer   se   fera   simplement   par   application   d'un  
pourcentage,  celui  du  solde  à  imputer  au  compte  courant  du  client  également.  
NB   :   la   description   de   ce   qui   précède   a   montré   un   oubli   majeur   dans   notre   modèle   de  
données,  celui  du  montant  d'une  opération  !  

 
figure  69  -­‐  classe  Opération  modifiée  

Le  diagramme  de  séquences  suivant  décrit  tout  ceci.  

 
figure  70  -­‐  diagramme  de  séquences  Clôturer  un  compte  épargne  

Cette  fonctionnalité  met  en  évidence  plusieurs  opérations  :  

opération   classe  d'accueil  

ClôturerCompte  ()   Interface  

Chapitre  3  –  Bien  analyser  son  besoin   C352   63/71  

 ListeOper  ?  ()   Compte  

Date  ?  ()   Opération  

Montant  ?  ()   Opération  

CalculerIntérêts  ()   Interface  

CalculerImpôts  ()   Interface  

VerserSolde  ()   Opération  

g) Créer  un  virement  permanent  

Le  virement  permanent  envisagé  dans  le  scénario  (voir  la  figure  51)  est  en  faveur  d'un  tiers.  
Le  traitement  à  mettre  en  œuvre  est  le  suivant  :  

 
figure  71  -­‐  diagramme  de  séquences  Créer  un  virement  permanent  

Trois  nouvelles  opérations  sont  apparues  :  

opération   Classe  d'accueil  

CréerVirementPermanent  ()   Interface  

CalculerDates  ()   Interface  

CréerDiff  ()   Opération  

Chapitre  3  –  Bien  analyser  son  besoin   C352   64/71  

 h) Pointer  les  écritures  

Le  pointage  va  se  faire  par  marquage.  Une  opération  pointée  passera  dans  l'état  "pointée".  
L'idée   est   donc   de   parcourir   les   opérations   associées   à   un   compte   (pour   accélérer   le   traitement,   il  
serait   bon   que   celles-­‐ci   soient   triées   par   date   croissante,   les   plus   récentes   au   début),   de  
sélectionner  celles  qui  sont  dans  l'état  "réalisée"  et  de  les  proposer  au  client.  Une  fois  que  le  client  
aura  lu  les  informations  sur  l'écriture,  son  état  passera  à  "pointée".  
Le  diagramme  de  séquences  correspondant  à  ce  travail  est  donc  le  suivant  :  

 
figure  72  -­‐  diagramme  de  séquences  Pointer  les  écritures  

Quatre  nouvelles  opérations  sont  à  ajouter  au  modèle  de  données  :  

opération   classe  d'accueil  

PointerEcritures  ()   Interface  

ListerOper2  ()   Compte  

Etat  ?  ()   Opération  

Pointer  ()   Opération  

Ce  travail  doit  être  poursuivi,  chaque  scénario  devant  faire  l'objet  d'un  approfondissement  
et  donner  lieu  à  un  diagramme  de  séquences.  Nous  ne  le  ferons  pas,  faute  de  place.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   65/71  

 3. Nouveau  modèle  de  données  
L'analyse  de  ces  huit  scénarios  a  conduit  à  des  modifications  importantes  du  modèle  métier.  
Ainsi,  ont  été  ajoutées  quatre  classes-­‐filles,  Tiers  et  Interne  pour  Client,  Compte  chèques  et  Compte  
épargne  pour  Compte.  Ont  également  vu  le  jour  des  classes  "de  service"  :  Interface,  Ens.  Comptes,  
Ens.  Opérations  et  Ens.  Clients.  
La  nouvelle  structure  de  données  est  maintenant  la  suivante  :  

 
figure  73  -­‐  nouveau  modèle  de  données  

NB  :  ce  diagramme  de  classes  est  amputé,  pour  des  raisons  de  place,  de  ses  opérations  et  de  ces  
classes  dites  "de  service".  
Quarante  et  une  opérations  ont  été  recensées,  trouvant  leur  place  dans  huit  classes  :  

Chapitre  3  –  Bien  analyser  son  besoin   C352   66/71  

  
figure  74  -­‐  localisation  des  opérations  recensées  

Ce  travail  d'enrichissement  du  modèle  de  données  doit  se  poursuivre  avec  l'étude  des  autres  
scénarios.  Nous  laissons  le  lecteur  le  faire.  
Un   dernier   mot   avant   de   refermer   ce   chapitre,   à   propos   de   la   classe   Interface.   Il   est   fort  
possible  (il  est  même  souhaitable)  qu'il  y  en  ait  plusieurs.  Si  l'on  se  réfère  à  la  figure  35,  on  peut  
parfaitement   associer   interface   et   onglet.   Il   y   aurait   alors   une   classe   Interface   Épargne,   une   classe  
Interface  Compte  chèques...  
Ceci  obligera  toutefois  à  retoucher  les  différents  diagrammes...  

G. Eléments  de  gestion  de  projet  et  support  

Nous  traçons  les  grandes  lignes  des  éléments  de  gestion  de  projets,  une  version  allégée  sera  
appliquée  dans  le  module  projet  compte-­‐tenu  du  fait  qu’il  n’est  pas  a  priori  réalisé  en  équipe.  

1. Equipes  de  développement  

On   considère   que   l’équipe   comprend   principalement   la   MOA   (Maîtrise   d’ouvrage)   et   la   MOE  
(Maîtrise   d’œuvre)   et   la   gestion   de   projet   (pilotage,   équipes   méthodes   et   support).   La   MOA  
représente  le  client  et  le  volet  métier.  La  MOA  comprend  des  représentants  des  différents  métiers,  
une  assistance  à  la  MOA  pour  faciliter  les  échanges,  mais  aussi  une  direction  financière…  Sur  une  
application   complexe   on   peut   avoir   plusieurs   MOA.   La   MOE   représente   les   acteurs   du   système  
d’information   automatisé   à   savoir   avec   les   analystes,   les   développeurs,   les   architectes,   les  
testeurs,  l’exploitation,  etc.  On  y  inclut  aussi  des  experts  de  toutes  sortes,  le  support  maintenance,  
etc.    
Cet  aspect  des  choses  n’est  pas  prioritaire  pour  notre  démonstration.  Il  eût  été  intéressant  
de   commenter   un   développement   passé.   Nous   laissons   cet   aspect   des   choses   aux   modules   de  
gestion  de  projet.  De  manière  simplifiée,  le  chef  de  projet  est  responsable  du  suivi  des  objectifs,  
de  la  planification  des  ressources  et  de  la  gestion  des  risques.  Il  bénéficie  pour  cela  de  l’expérience  
acquise  lors  de  projets  et  de  stages  précédents.  Il  traite  des  problèmes  inhérents  à  la  gestion  de  
projet   (ressources   humaines,   communication,   délais).   Les   analystes   sont   responsables   de   la  

Chapitre  3  –  Bien  analyser  son  besoin   C352   67/71  

maintenance   des   modèles   d’analyse   et   des   tests.   Les   développeurs   sont   responsables   de   la  
conception,  de  la  programmation  et  des  tests  unitaires.  

2. Cycle  de  développement  

Le   cycle   suivi   est   itératif,   ce   qui   signifie   que   l’analyse   des   besoins   est   faite   en   plusieurs  
cycles.   Nous   pouvons   considérer   que   les   résultats   présentés   précédemment   sont   ceux   de   la  
première  itération,  il  y  en  aura  d’autres  qui  figeront  progressivement  les  besoins.    
Le   cycle   suivi   est   incrémental,   ce   qui   signifie   ici   que   toute   l’analyse   n’est   pas   réalisée.  
L’analyse   des   besoins   est   faite   en   plusieurs   lots.   Il   convient   de   prioriser   les   besoins   fonctionnels   et  
non   fonctionnels   pour   placer   les   éléments   de   priorité   forte   dans   les   premiers   lots.   On   dit   qu’on  
réalise  d’abord  le  cœur  ou  les  parties  critiques.    
La  figure  75  montre  un  exemple  d’historique  d'un  projet  étudiant,  où  le  cas  avait  été  d’abord  
implanté  dans  une  version  Java  sans  EJB  avant  de  l'être  en  Java  EJB.  

 
figure  75  -­‐  Cycle  itératif  et  incrémental  

Cette  double  nature  du  cycle  permet  de  mieux  gérer  les  risques,  d’anticiper  et  surtout  d’agir  
avant  qu’il  ne  soit  trop  tard.  
Nous   pouvons   considérer   que   les   résultats   présentés   précédemment   sont   ceux   de   la  
première  itération,  il  y  en  aura  d’autres  qui  figeront  progressivement  les  besoins.  

3. Normes  
On  utilise  des  normes  pour  les  modèles,  la  documentation  standard,  la  gestion  de  projets,  la  
qualité…  
Dans   le   module   projet,   la   présentation   des   documents   sera   normalisée   selon   le   modèle  
décrit  dans  le  document  de  référence.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   68/71  

 4. Outils  support  
Nous   avons   besoin   de   mettre   en   place   des   outils   de   gestion   des   documents   (gestion   de  
version,   éditeurs   textuels   personnalisés,   référentiel   de   documentation   2…),   outils   de   gestion   des  
modèles  (éditeurs  UML,  générateurs  de  documentation,  transformation  de  modèles,  vérification,  
référentiel   de   modèles…),   outils   collaboratifs   (partage   de   documents   et   d’annotations,  
communication,  forums,  synchronisation…).  
 

                                                                                                                         
2
 On  peut  utiliser  des  outils  GED  ;  gestion  électronique  documentaire.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   69/71  

IX. Conclusion  
Ce  chapitre  est  consacré  à  la  première  étape  du  développement  d'un  logiciel,  celle  d'analyse  
des  besoins.  Il  est  important  de  bien  garder  en  mémoire  que,  bien  que  première  étape,  l'analyse  
des  besoins  ne  part  pas  de  rien.  Elle  s'insère  dans  un  contexte  précis  qu'il  faut  étudier,  intégrer...  
C'est  une  étape  cruciale  car  d'elle  dépend  le  succès  ou  l'échec  du  développement.  
Nous   avons   successivement   abordé   la   définition   du   périmètre   d'intervention,   la   mise   en  
place   d'une   équipe,   l'expression   des   besoins   fonctionnels   (ce   que   doit   faire   le   système   à  
développer),   celle   des   besoins   non   fonctionnels   et   la   préparation   des   tests.   Tous   ces   sujets   sont  
ensuite  mis  en  pratique  dans  la  dernière  section,  consacrée  à  une  étude  de  cas.  
Cette   étape   se   termine   par   la   production   d'un   ensemble   de   documents   qui   décrivent   de  
façon   détaillée   ce   qui   peut   correspondre   aux   exigences   des   utilisateurs,   documents   qui   doivent  
être   validés  par   ceux-­‐ci.  Une  fois  cette  validation  effectuée,   il   sera   temps  de  passer  à  la   deuxième  
étape,  celle  dans  laquelle  on  "parlera"  de  solution.  Auparavant,  toutefois,  il  aura  été  nécessaire  de  
prendre  en  compte  l'environnement  technique  dans  lequel  la  solution  sera  développée.  

Chapitre  3  –  Bien  analyser  son  besoin   C352   70/71  

X. Références  
[CH301]   P.   André   and   A.   Vailly.   Développement   de   logiciel   avec   UML2   et   OCL   ;   cours   et  
exercices  corrigés,  Collection  Technosup.  Éditions  Ellipses,  2013.  ISBN  9782729883539.  
[CH302]   S.   Badreau   et   J-­‐L.   Boulanger.   Ingénierie   des   exigences   ;   méthodes   et   bonnes  
pratiques  pour  construire  et  maintenir  un  référentiel,  Collection  Management  des  systèmes  
d'information.  Éditions  Dunod,  2014.  ISBN  978  2  10  070640-­‐2.  
[CH303]   A.  Cockburn,  Rédiger  des  cas  d'utilisation  efficaces,  Éditions  Eyrolles,  2001.  ISBN  2-­‐
212-­‐09288-­‐1.
[CH304]   T.J.   Mc   Cabe,   A   Complexity   Measure,   IEEE   Transactions   on   Software   Engineering,  
Vol.  SE-­‐2(4),  1976,  pp.  308-­‐320.  
[CH305]   S.R.   Chidamber,   C.F.   Kemerer,   A   Metrics   Suite   for   Object   Oriented   Design,   IEEE  
Transactions  on  Software  Engineering,  vol.  20,  6  (june  1994),  p.  476-­‐493.  
[CH306]   L.H.   Rosenberg,   Metrics   for   Quality   Assurance   and   Risk   Assessment,   Actes   de   2nd  
International   Software   Quality   Week   Conference   Europe,   Brussels,   9-­‐13   novembre   1998,  
Software  Research  Institute,  Tutorial  G1.  
[CH307]   F.   Brito   e   Abreu,   W.L.   Melo,   Evaluating   the   Impact   of   Object-­‐Oriented   Design   on  
Software   Quality,   Proceedings   of   Symposium   on   Software   Metrics   (METRICS'96),   25-­‐26   mars  
1996,  Berlin,  Germany.  
[CH308]   T.  Drake,  Measuring  Quality  in  Object  Oriented  Software,  Actes  du  2nd  International  
Software   Quality   Week   Conference   Europe,   Brussels,   9-­‐13   novembre   1998,   Software  
Research  Institute,  Tutorial  C2.  
[CH309]   M.   Lorentz,   J.   Kidd,   Object-­‐oriented   software   metrics,   Prentice-­‐Hall   Object   Oriented  
Series,  Prentice-­‐Hall,  1994.  ISBN  0-­‐13-­‐179292-­‐X.  
[CH310]   G.  Banerjee,  Use  Case  Points,  an  Estimation  Approach,  August  2001.  
 

Chapitre  3  –  Bien  analyser  son  besoin   C352   71/71