Modélisation des exigences avec Enterprise Architect

La modélisation des exigences représente dans la vie d'un projet de développement logiciel, un moyen efficace de préparer l'analyse UML en structurant les besoins métier et techniques exprimés par la maîtrise d'ouvrage à travers son cahier des charges.

Dans cette présentation, je me prêterai à l'exercice de modélisation des exigences d'un logiciel de gestion commerciale simplifié, limité à la seule fonctionnalité de facuration clients.

Je m'appuierai pour illustrer cette étude de cas, sur l'AGL Enterprise Architect qui offre une solution de gestion des exigences intégrée aux modèles UML élaborés dans le cadre d'un projet.

Les bénéfices d'une modélisation des exigences

La modélisation des exigences constitue le premier trait d'union entre l'expression de besoins de la maîtrise d'ouvrage et la phase d'analyse du projet.
Pendant la vie du projet, il constitue la référence du projet dans les phases de conception et d'homologation du logiciel développé.

La modélisation des exigences contribue essentiellement à :

  • Maîtriser le périmètre du projet : les exigences une fois recensées dans leur totalité, représentent ni plus ni moins que ce que le logiciel devra fournir en termes de services. A ce stade, nous ne savons pas encore comment le logiciel réalisera les services attendus, mais nous devons en revanche être sûrs de ce qu'il devra faire et selon quelles conditions, et en conséquence, ce qu'il n'aura pas à faire.
    La modélisation des exigences peut être considérée terminée lorsque les deux parties, la MOA et la MOE, ont validé en nombre et en contenu les exigences recensées et modélisées.
  • Evaluer la complexité du projet : chaque exigence demande plus ou moins d'effort pour être traduite en une fonctionnalité du logiciel ou en conditions de fonctionnement (concernant par exemple les performances ou la sécurité du logiciel). Une estimation de la complexité peut être renseignée pour une exigence et ainsi servir de critère à la fois pour affiner l'estimation de charge du projet et pour orienter le phasage du projet.
    En général, en vue de maîtriser les risques sur un projet, il est préférable de concentrer ses efforts dès les premières itérations de développement, sur les exigences pour lesquelles la complexité est la plus élevée.
  • Guider l'équipe Maître d'Oeuvre dans les phases du projet : le modèle des exigences représente un référentiel servant de ligne directrice à l'équipe maître d'oeuvre du projet dans les phases d'analyse, de conception et d'homologation du logiciel. En effet, les éléments UML en jeu dans les modèles d'analyse, de conception et de tests du projet n'ont de raison d'exister que s'ils ont été créés pour répondre à une ou plusieurs exigences métier ou techniques (lien de Réalisation entre une exigence et l'élément UML qui intervient dans son implémentation). Aussi, l'Analyste, le Concepteur et l'Ingénieur de tests doivent être en capacité de maîtriser, pour chaque fonctionnalité ou objet du sytème sur lequel ils interviennent, les exigences qui sont satisfaites et celles qui ne le sont pas encore et qui devront l'être dans de futurs incréments du logiciel (dans le cas d'un développement itératif).

Démarche globale

Les objectifs de la démarche sont de s'assurer que les exigences seront clairement comprises par l'équipe maître d'oeuvre et partagées avec la maîtrise d'ouvrage à travers les modèles produits.

Les modèles sont élaborés sur la base d'un recensement exhaustif des exigences, d'un approfondissement quand c'est nécessaire de certaines d'entre-elles et enfin de leur regroupement par affinités en vue de préparer leur analyse.

La démarche globale de modélisation des exigences consiste en :

  • La lecture du cahier des charges : le premier support pour recencer les exigences est le cahier des charges. Sa lecture approfondie est indispensable pour établir un premier recueil des exigences. Une exigence fait état d'une fonctionnalité, d'une règle de gestion ou décrit les propriétés d'un objet à gérer par le système, ou bien encore exprime une contrainte que doit respecter le logiciel. A ce stade, chaque exigence recensée et annotée d'une description, représente un premier niveau de structuration des fonctionnalités du logiciel à réaliser.
  • La clarification et affinage des exigences : les exigences une fois recensées nécessitent pour un bon nombre d'entre-elles d'être clarifiées, notamment si les termes du cahier des charges sont trop ambigus ou imprécis. D'autres exigences quant à elles auront besoin d'être approfondies, ou davantage développées, pour s'assurer d'en comprendre la teneur. Cet exercice requiert l'interrogation directe des parties prenantes MOA du projet. Pour cela, des ateliers sont organisés en présence de la MOA, avec pour support le premier recueil des exigences, une liste des questions dressée à la lecture du cahier des charges, ainsi que des objectifs clairs à atteindre à l'issue de chacune des séances de travail.
  • La structuration des exigences : les exigences dès leur recueil peuvent être classées en deux grandes familles : les exigences métier qui traduisent les fonctionnalités du logiciel et les exigences techniques qui relèvent des aspects liés à ses performances, sa sécurité ou encore sa disponibilité. Au sein de ces deux grandes familles, elles peuvent encore être rangées par sous-domaines métier ou par thèmes. Enfin, des dépendances évidentes vont également se dégager entre certaines d'entre-elles et pourront être représentées sous la forme de diagrammes, en appliquant par exemple une hiérarchie entre exigences ou en encore en les reliant entre-elles par un connecteur UML de type agrégation ou par une simple dépendance.
  • La revue et validation des exigences : les modèles d'exigences obtenus peuvent enfin être soumis à validation de la MOA. Cette validation garantit que la compréhension des besoins et des contraintes est partagée par les deux parties MOA et MOE. Elle entérine également le périmètre des fonctionnalités du système à développer.
    Il est important de souligner qu'àprès une validation partielle ou totale des exigences, il ne doit pas être exclu dans la vie du projet, que de nouvelles exigences aient besoin d'être ajoutées (exigence révélée en phase d'analyse ou de conception) et que des exigences validées nécessitent d'être modifiées (évolution des besoins) voire supprimées (exigence difficile à implémenter ou réduction du périmètre du projet).

Quelque soit la méthode de conduite du projet retenue (Cycle en V, Processus Unifié, Scrum ou autres dérivés...) pour réaliser le système logiciel, la démarche telle qu'elle vous est présentée ici reste applicable, seuls le nombre et la durée des cycles vont varier dans l'application de la méthode.

Formalisme dans Enterprise Architect

Dans ce paragraphe, nous allons étudier la manière dont sont représentées les exigences dans EA.

Caractéristiques d'un exigence dans EA

Proprietes requirement - enterprise architect Ecran 1 : Propriétés d'un Requirement.

Une exigence est un élément de type Requirement dans EA.
Elle se caractérise en particulier par :

  • Une description courte (Short description) : il s'agit du titre donné à l'exigence qui est repris dans la fenêtre Project Browser pour l'identifier et qui est également affiché par défaut sur les diagrammes dans lesquels elle figure.
  • Un alias : il s'agit d'un titre de substitution à la description courte qui peut être affiché sur les diagrammes pour lesquels l'affichage des alias a été activé.
  • Un type : il permet de qualifier l'exigence parmi un ensemble de types prédéfinis qui peuvent être complétés ou enrichis. Le type permet ainsi de classifier les exigences par catégorie. Par exemple : Fonctionnel, Sécurité, Performance, Affichage...
  • Un statut : il s'agit du statut d'instruction de l'exigence. Il est principalement utilisé pour suivre l'état de validation d'une exigence. Les statuts proposés peuvent également être complétés ou personnalisés. Les statuts préconfigurés sont entre autres Proposé, Approuvé (validé par la MOA en tant qu'exigence à implémenter), Implémenté, Validé (l'exigence a été implémentée et testée dans le logiciel)...
  • Une complexité (Difficulty) : 3 niveaux de complexité peuvent être indiqués pour une exigence : Faible, Moyen ou Elevé. La complexité représente un critère intéressant pour le phasage du projet comme évoqué précédemment.
  • Une priorité : la priorité d'implémentation de l'exigence. Cette priorité est celle fixée par la MOA. Elle fait partie des critères avec la complexité qui sont pris en compte pour fixer les phases de développements du projet. Trois niveaux de priorité sont également disponibles : Faible, Moyen et Elevé.
  • Une phase : phase de développement pendant laquelle l'exigence est à implémenter. La saisie de la phase est laissée libre mais généralement un numéro de phase est renseigné . Cette phase est à préciser pour les logiciels développés par itérations successives et doit reprendre autant que possible le code ou intitulé figurant sur le planning du projet (par exemple Itération n°3). Cette phase correspond à la notion d'itération et elle est fixée en fonction des critères de complexité et de priorité d'implémentation de l'exigence.
  • Une version : elle correspond à la version de l'exigence. Elle est initialisée à sa création à la version 1.0. Cette version est à incrémenter à chaque modification des propriétés de l'exigence pour permettre à la MOA d'identifier plus rapidement les exigences qui ont été modifiées entre deux revues.
  • L'auteur : utilisateur de EA qui a créé l'exigence. Cette propriété a son importance quand plusieurs ressources travaillent ensemble à la modélisation des exigences.
  • Des mots-clé (Key Words) : un ou plusieurs mots clés peuvent être associés à une exigence. Il est alors possible de rechercher dans le modèle les exigences correspondant à un mot clé particulier. Les mots clés peuvent également être affichés dans les documents RTF générés par EA.
  • Une description détaillée (Notes) : c'est dans cette zone de saisie que l'exigence est détaillée en langage humain. La validation par la MOA de l'exigence portera essentiellement sur les informations contenues dans cette description.

Je vous encourage vivement à préfixer la description courte des exigences d'un identifiant unique ou d'un numéro, afin de faciliter leur référencement au cours des ateliers de travail, dans les comptes-rendus ou dans tout autre document y faisant référence.
Sachez que EA offre la possibilité de numéroter automatiquement les exigences (menu Settings | Auto Name Counters...).

A noter également qu'il est possible de relier l'exigence à des documents électroniques, fichiers ou URL externes depuis l'onglet Files, par exemple pour faire référence à un compte-rendu d'atelier ou de réunion, à un document ou un article traitant de la fonctionnalité décrite dans l'exigence, ou encore à une image pouvant illustrer les concepts abordés.

Enfin, sachez que les propriétés qui vous ont été décrites ci-dessus peuvent être complétées de propriétés sur mesure à partir de l'onglet Tagged Values, dans le cas où vous auriez besoin d'associer des informations supplémentaires à une exigence, comme par exemple un niveau de stabilité du besoin, le n° de paragraphe du cahier des charges dont est issue l'exigence ou encore sa date de validation par la MOA.
Je vous invite pour ce point particulier à consulter dans la FAQ Enterprise Architect les sujets suivants :

Présentation des exigences sous forme de diagrammes

Deux diagrammes en particulier peuvent servir de support pour représenter les modèles d'exigences avant que ne débutent l'analyse et la conception UML du logiciel à développer.

Le premier est le diagramme de packages (ou diagramme de paquetages si j'emploie la version francisée du terme anglais package) qui offre une vue d'ensemble des exigences et de leur regroupement par package.

Le regroupement des exigences par package est un moyen supplémentaire d'organiser les exigences en fonction de leurs affinités.

Si plusieurs niveaux de packages sont créés, le diagramme des packages de niveau le plus haut n'affiche alors que le nom des sous-packages contenus dans les packages parents.
A l'écran 2 ci-dessous, vous constaterez que j'ai fait le choix de classer les exigences en 2 grandes familles :

diagramme de packages de packages - enterprise architectEcran 2 : exemple de diagramme de packages des exigences métier et techniques dans EA.
  • Les Exigences Métier : elles correspondent aux besoins qui ont trait au métier des futurs utilisateurs du système. Les exigences métier sont relativement stables dans le temps. Elles sont également désignées par les termes Exigences fonctionnelles.
  • Les Exigences Techniques : ce sont les exigences directement dépendantes du système à développer et des technologies retenues. Contrairement aux exigences métier, les exigences techniques sont plutôt enclines à évoluer dans le temps pour une majorité d'entre-elles, au rythme de l'évolution des technologies de l'information. Ces exigences sont généralement désignées sous le vocable Exigences non fonctionnelles car ne décrivent pas les fonctions du systèmes mais davantage des contraintes et des conditions particulières auxquelles le système doit se conformer.

En revanche, si les packages présentés sur le diagramme contiennent directement des exigences, alors ces dernières sont affichées à l'intérieur de leur package d'appartenance, comme cela est illustré à l'écran 3 suivant.

diagramme de packages d'exigences - enterprise architect Ecran 3 : exemple de diagramme de packages d'exigences métier dans EA.

Le classement des exigences dans les sous-packages doit être effectué sans trop préjuger de la structure logique et technique finale de l'application. Ce sont en effet les phases d'analyse et de conception qui permettront d'architecturer l'application et d'identifier ses domaines fonctionnels et ses packages ou composants techniques.

Le second diagramme intéressant est quant à lui le diagramme d'exigences, qui ne restitue généralement qu'un sous-ensemble des exigences, celles d'un package donné, sous une forme rectangulaire avec représentation de leurs dépendances éventuelles.

A l'écran 4 ci-après, vous constaterez qu'un lien d'agrégation relie certaines exigences entre-elles pour formaliser la dépendance hiérarchique qui existe entre deux exigences.

diagramme des exigences - enterprise architect Ecran 4 : exemple de diagramme d'exigences métier dans EA.

En effet, si nous nous intéressons par exemple aux exigences XFAC05 - Facture de doit et XFAC06 - Numéro et date de la facture, nous comprenons que l'exigence XFAC06 qui précise la manière dont est numérotée d'une facture, contribue à répondre à l'exigence XFAC05 qui a trait à la facture dans son ensemble. En termes d'implémentation, l'exigence XFAC06 doit être totalement réalisée, ainsi que toutes les autres exigences connectées par un même lien d'agrégation à XFAC05, pour que l'implémentation de l'exigence XFAC05 soit considérée également terminée.
Ce même principe s'applique à l'homologation des fonctionnalités du système. Dans la hiérarchie des exigences, l'homologation des exigences de niveau le plus bas participe à l'homologation des exigences de niveau supérieur.

L'autre type de lien illustré à l'écran 4 est le lien de simple dépendance entre 2 exigences.

Si je reprends pour exemple l'exigence XFAC06 - Numéro et date de la facture, une dépendance a été matérialisée avec l'exigence XPAR03 - Compteurs Numéros Factures qui indique que le numéro attribué à une facture provient d'un compteur dont la valeur courante peut être ajustée si nécessaire, dans le cas notamment où une facture a été supprimée provoquant une rupture dans la numérotation des factures. On comprend ainsi à la visualisation de cette dépendance que le numéro de la facture est issu d'un compteur de numéros de factures et qu'il est paramétrable.

D'autres dépendances existent entre les exigences mais j'ai choisi de ne pas les représenter pour ne pas alourdir la lisibilité du diagramme.

Par exemple, on comprend bien qu'une dépendance existe nécessairement entre la fonction de consultation des factures (XFAC19) et les exigences décrivant la facture de doit (XFAC05) et la facture d'avoir (XFAC22).

Il faut savoir qu'en créant des dépendances entre les exigences, on réalise déjà un premier niveau d'analyse du système.
La question à se poser est de savoir si l'on préfère concentrer ses efforts d'analyse sur les modèles d'exigences ou bien sur les modèles UML (cas d'utilisation, classes d'analyse...). Personnellement, j'ai préféré jusqu'à présent ne pas me préoccuper des dépendances entre les exigences et enchaîner au plus tôt sur la modélisation des cas d'utilisations, l'identification des classes partcipantes et des domaines métier.

Le glossaire des termes du projet

glossaire projet - enterprise architect Ecran 5 : exemple de glossaire du projet dans EA.

Le glossaire des termes du projet ne constitue pas un recueil d'exigences à proprement parler, néanmoins, il participe à leur compréhension.

C'est pour cette raison que je prends la peine de l'évoquer dans cet article.
En effet, ce glossaire est à compléter dès la lecture du cahier des charges et doit comprendre la définition de tous les concepts, les objets, les technologies et procédés qui peuvent soulever des interrogations auprès des membres de l'équipe MOE.

Les définitions du glossaire sont également à valider par la MOA en même temps que les modèles d'exigences, toujours dans l'objectif de minimiser les risques d'écarts entre l'expression de besoins des utilisateurs et le système développé.

L'écran 5 montre un exemple de glossaire créé dans EA.

Les outils d'aide à la gestion des exigences dans EA

Saisie des exigences à partir d'une liste

Quand vous avez à saisir ou modifier un grand nombre d'exigences, il est pratique d'utiliser la vue d'affichage sous forme de liste.

Depuis la fenêtre Project Browser, sélectionnez le package contenant les exigences et dans le menu contextuel (clic droit), sélectionnez l'entrée de menu View Package as List.

glossaire projet - enterprise architect Ecran 6 : exemple d'affichage sous forme de liste dans EA.

Selon le même principe, les exigences figurant sur un diagramme peuvent également être représentées sous forme de liste. Pour cela, sélectionnez le diagramme des exigences de votre choix depuis la fenêtre Project Browser, affichez le menu contextuel et cliquez sur l'entrée de menu View Diagram as List.

Import / export Excel

specifications CSV - enterprise architect Ecran 7 : exemple de spécifications CSV dans EA.

Autre fonctionnalité intéressante disponible dans EA, l'export et import dans Excel des exigences, à travers un format de fichier CSV.

Pour les utilisateurs adeptes d'Excel, un premier recueil des exigences peut être constitué sous Excel pour ensuite être importé dans EA à l'aide de sa fonctionnalité d'import d'éléments, accessible depuis le menu Projet | Import/Export | CSV Import/Export...

Notez qu'il est nécessaire avant d'exporter ou importer des exigences, de configurer le format du fichier CSV servant de fichier pivot entre EA et Excel, par la configuration des spécifications CSV.

Ces spécifications consistent principalement à indiquer les propriétés des exigences qui figureront dans le fichier CSV à importer ou à exporter et à préciser l'ordre des colonnes correspondantes.

L'écran 7 fournit un exemple de spécifications CSV d'import / export des exigences.

Suivi des modifications (traçabilité)

Les modifications apportées aux exigences peuvent être tracées manuellement en appliquant l'une des deux solutions suivantes :

  1. La première consiste à créer un évènement Change interne à l'exigence en utilisant la vue de maintenance qui peut être affichée via le menu View | Other Element Tools | Maintenance ou en utilisant le raccourci clavier Alt + 4. Depuis l'onglet Changes, les modifications sont renseignées dans la zone de saisie Description et l'historique des modifications antérieures pour ce même événement, dans la zone de saisie History.
    Ces modifications peuvent alors être affichées sur un diagramme dédié au suivi des modifications, dans le compartiment Maintenance des exigences, par activation de l'option idoine dans les propriétés d'affichage des éléments du diagramme.
    maintenance view - enterprise architect Ecran 8 : exemple de suivi de modifications dans la vue de maintenance EA.
  2. L'autre solution quant à elle repose sur l'ajout au modèle d'un élément externe de type Change, reliée par une Association à l'exigence modifiée, et dont la description fournit le détail des modifications apportées à l'exigence.
    Dans l'exemple ci-dessous, l'exigence XFAC006 a été modifiée à deux reprises et le détail des modifications apportées a été inscrit dans les éléments Change sous les identifiants CHG001 et CHG002.
    change element - enterprise architect Ecran 9 : exemple d'élément Change dans EA.

Sachez que EA dispose d'un mécanisme d'Audit qui une fois activé (menu View | Other Project Tools | Audit View, trace automatiquement toutes les modifications apportées aux éléments du modèle, y compris aux exigences.
Pour en bénéficier, vous devez posséder à minima d'une licence de EA correspondant à l'édition Corporate (fonctionnalité absente dans les éditions Desktop et Professional).

Documentation HTML ou RTF

Une autre fonctionnalité qui mérite d'être présentée et qui s'avère très utile pour diffuser une documentation des exigences en dehors de l'outil EA, est la génération de documents aux formats HTML et RTF.

  • Pour générer un document HTML, sélectionnez le package contenant les exigences, affichez la fenêtre Generate HTML Report à partir du menu Project | Documentation | HTML Report... (raccourci clavier Maj + F8), saisissez dans le champ Output to: le chemin complet du dossier physique dans lequel générer la documentation, puis terminez en cliquant sur le bouton Generate.
    Un exemple de rapport HTML vous est présenté ci-dessous.
    rapport html - enterprise architect Ecran 10 : exemple de rapport HTML dans EA.
    Notez que les classes de styles de ce rapport HTML peuvent être personnalisées si vous souhaitez l'intégrer à un intranet avec application de la charte graphique de l'entreprise. Il vous faut pour cela créer un modèle de styles web depuis la fenêtre Resources (menu View | Other Project Tools | Resources pour l'afficher), en sélectionnant l'élément Web Style Templates dans l'arborescence Resources | Templates puis en cliquant sur Create HTML Template depuis le menu contextuel (clic droit de la souris).
    Une fois créé, le modèle de style peut être référencé dans le champ Style de l'écran de génération du rapport HTML.
  • Pour générer un document RTF, la démarche à suivre est assez similaire à celle indiquée pour le format HTML.
    Commencez par sélectionner le package contenant les exigences à documenter, puis affichez la fenêtre Generate RTF Documentation à partir du menu Project | Documentation | Rich Text Format (RTF) Report... (raccourci clavier F8). Indiquez le chemin complet du document RTF à générer dans le champ Output to File:, choisissez parmi les modèles proposés dans la liste Use Template:, le modèle (requirement template). Terminez en cliquant sur le bouton Generate.
    Les autres modèles intéressants pour documenter les exigences sont (maintenance template) ou encore (basic template).
    Le rapport RTF est alors prêt à être diffusé en l'état ou bien peut être intégré dans un document maître au format Word ou Open Office.
    rapport rtf - enterprise architect Ecran 11 : exemple de rapport RTF dans EA.
    A savoir enfin que des modèles RTF sur mesure peuvent être créés pour contrôler précisément les propriétés des exigences à afficher (y compris les Tagged Values), selon le formalisme souhaité et avec application des styles conformes à ceux définis dans le document maître destiné à accueillir le contenu du document RTF.

Intégration au langage UML

use case realization - enterprise architect Ecran 12 : exemple de réalisations d'un Cas d'Utilisation dans EA.

Dans les modèles UML, les exigences métier sont généralement rattachées aux Cas d'Utilisation qui sont la traduction directe des fonctionnalités du système à développer et constituent les éléments principaux sur lesquels s'appuie le Chef de Projet pour piloter la conception, la réalisation et les tests.

Les exigences non fonctionnelles peuvent être également rattachées aux cas d'utilisation quand elles s'appliquent spécifiquement à l'un d'eux, ou bien être reliées aux Composants développés spécifiquement dans le cadre du projet ou intégrés au système, notamment quand ces exigences sont applicables à plusieurs cas d'utilisation ou à l'ensemble du système à réaliser.

Le connecteur de type Réalisation est utilisé pour indiquer qu'un élément UML réalise une exigence donnée.

La liaison entre l'élément UML et l'exigence peut être établie depuis un diagramme contenant les éléments à relier (voir écran 12)

Une autre solution est d'utiliser la matrice de mises en relation des éléments, nommée Relationship Matrix dans EA (voir écran 13).

Elle peut être affichée en sélectionnant l'entrée de menu View | Relationship Matrix.

relationship matrix - enterprise architect Ecran 13 : exemple de matrice des relations dans EA.

Références