Vous êtes ici : Accueil SysML La capture des besoins

La capture des besoins

Nous reprenons dans notre étude SysML le processus 2TUP que nous avons utilisé pour l'étude UML et nous commençons donc par la spécification des besoins.

Nous avons déjà vu à quel point la capture des besoins est une phase fondamentale dans la réalisation du projet. Je vous laisse donc revoir la partie 2.1 qui traite spécifiquement de ce point dans le cadre d'un projet UML.

L'avantage de SysML est que nous disposons en plus du diagramme d'exigence  « Requirement diagram », du diagramme paramétrique et des représentations en vue du diagramme de package. On dispose aussi des blocs « block def diagram » et « internal block def diagram ».

Objectifs

  • Définir le contexte général (métier, juridique, etc...) et organiser tous ces éléments à travers le diagramme d'exigence.
  • Définir les acteurs humains ou non qui vont interagir avec le système.
  • Définir les fonctionnalités attendues du système avec un diagramme de Use Case.
  • Définir le contexte technique du projet (serveurs, réseau, etc...) en donnant une représentation des blocs qui le définissent.
  • Définir le fonctionnement dynamique du système avec en plus des diagrammes de séquence, d'activité et d'état, le diagramme paramétrique.
  • Définir les besoins en interface homme machine (IHM) s'il y en a.
  • Rédiger un cahier des charges fonctionnel et technique qui permettra à la fois de réaliser le projet et de le valider au fur et à mesure jusqu'à la phase de recette finale. (Voir le cycle en V)

Diagrammes

  • Requirement Diagram
  • Block Diagram
  • Use Case Diagram
  • Sequence Diagram
  • State Diagram
  • Activity Diagram
  • Parametric Diagram

 Documents

Documents collectés :

Il est difficile de donner une liste précise des documents à collecter mais pour résumer il faut collecter un maximum de documents existants ou d'informations sur l'existant.

Toutes les normes, les études et les spécifications existantes doivent être collectées et organisées à travers le « Requirement Diagram ».

Tous les documents papier et/ou informatique en rapport avec le projet peuvent contenir une part d'information que le client ne soupçonne pas forcément.

Il est aussi intéressant quand c'est possible d'interroger les utilisateurs finaux du système car ils ne sont pas toujours impliqués dans le processus de conception.

Documents livrés :

Un cahier des charges contenant sous forme compréhensible :
  • Le modèle SysML commenté.
  • La liste et la description des acteurs qui interagissent avec le système.
  • La liste des fonctionnalités à livrer.
  • La description du fonctionnement dynamique du système.

Démarche

Tout comme dans l'étude UML précédente, nous n'avons pas de méthode parfaite ou universelle pour aborder une modélisation SysML.

Nous allons vous proposer ici une démarche qui se présente de façon chronologique du fait que la rédaction nous oblige à mettre les choses dans un certain ordre. Cependant dans la réalité des faits nous avons souvent à faire des aller et retours entre ces différentes parties de la capture des besoins.

Pour être tout à fait honnête durant la mise en œuvre d'un projet il est même possible de revenir sur la définition des besoins techniques ou fonctionnels quand on est en phase de modélisation ou de réalisation.

Cependant il est préférable de limiter ce genre de retour en arrière qui peut déstabiliser complètement le projet.

Définition du métier et du contexte

SysML est beaucoup plus performant que UML pour décrire le contexte général d'un projet car les diagrammes d'exigence, de bloc et paramétrique permettent une description bien plus complète.

Cependant la toute première action va consister a collecter les spécifications (ci-dessous « Requirements) pour ensuite faire l'analyse qui nous amènera à la définition puis à la validation du système.

SysML_systemModeling.jpg

                   OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

Afin de décrire le contexte général de l'étude nous utilisons ci-dessous un « Internal Block Diagram » qui modélise tous les éléments qui vont influer sur l'étude.
SysML_ContextDiagram.jpg                   OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

Il est possible de définir le contexte général dans lequel l'étude va être menée et ainsi de spécifier quel système de grandeur et quelle norme vont être utilisés grâce au diagramme de package ci-dessous.

                                  SysML_ModelingDomain.jpg

         OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

Le système de grandeur utilisé est alors à son tour défini et réutilisable, modifiable, maintenable pour d'autres projets.
L'ensemble des unités définies ci-dessous seront ensuite ré-utilisées dans les spécifications et dans les équations de description du système.

SysML_parametricDiagram.jpg               OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

 Enfin pour préparer le cadre général de l'étude, chaque entreprise, chaque projet peut nécessiter une organisation spécifique.

Dans l'exemple donné par le tutoriel officiel de SysML nous avons l'organisation ci-dessous qui regroupe en package les différentes parties de l'étude afin de faciliter la recherche et la création de diagrammes dans un projet qui en contiendra beaucoup à la fin.

Cette démarche peut sembler un peu complexe mais en réalité cela revient au même que de préparer l'arborescence de dossiers communs à un groupe de travail avant de commencer un projet.

C'est donc une étape très importante dont les modifications éventuelles doivent être portées à la connaissance de tous.

SysML_ModelOrganisation.jpg

                  OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

Identification des acteurs et des cas d'utilisation

Tout comme dans l'étude UML nous allons identifier qui va interagir avec le système et quelles fonctionnalités le système va fournir aux acteurs ou requérir des acteurs.
Nous allons ainsi définir toutes les interactions entre le système et son environnement.
Comme nous pouvons le constater ci-dessous aucun changement entre UML et SysML

          SysML_UseCases.jpg

        OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

     SysML_UseCaseDetail.jpg

              OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008

 

Définition du comportement dynamique du système (Chronologie des traitements et comportement)

Une fois les cas d'utilisation du système définies il faut pour chacune d'entre elles définir leur fonctionnement dynamique à l'aide des diagrammes de séquence, d'état et d'activité.

La syntaxe des diagrammes est la même qu'en UML cependant la sémantique n'est pas exactement la même puisque nous ne traitons pas forcément et systématiquement de fonctions informatiques.

Ainsi, les messages qui étaient obligatoirement traduits par des opérations ou des signaux au sens informatique du terme dans le modèle UML, seront cette fois traduit par toutes sortes d'opérations et de signaux en fonction de la technologie qui mettra réellement en œuvre ces messages.

Afin de fournir un modèle le plus juste, le plus générique et le plus ré-utilisable possible nous avons choisi d'utiliser l'approche Top-Down du processus 2TUP. Durant la phase de capture des besoins dans laquelle nous sommes, nous définissons la dynamique de notre système vu comme une boîte noire.

Cette description de la dynamique de très haut niveau nous servira de base pour valider l'architecture des blocs que nous définirons durant la phase d'analyse.

Nous suivons donc exactement le même processus que dans notre étude UML mais sur un système complexe qui contiendra différentes technologies et pas seulement de l'informatique.

Ci-dessous la description générique du fonctionnement de notre véhicule.

             SysML_SequenceBlackBox.jpg

                 OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

 

De même nous pouvons définir le fonctionnement général du système avec des diagrammes d'activité et des diagrammes d'état comme ci-dessous.

               SysML_StateMachineBlackBox.jpg

                   OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

Collecte et structuration des spécifications ( Requirement Diagram )

Nous n'avons pas attendu SysML pour collecter et structurer les exigences et documentations relatives à un projet.

Cependant, SysML nous permet grâce au diagramme de spécification « Requirement Diagram » et grâce aux tableaux récapitulatifs de structurer parfaitement toutes les exigences requises.

Nous pourrons ainsi les organiser entre eux et les associer ensuite aux différents packages, blocs et autres afin de lier les responsables de chaque élément aux spécifications qui le concerne.

C'est aussi une façon de donner une vue transversale des spécifications à tous les responsables collaborant à la réalisation du système.

Certains environnements de modélisation UML permettent même de lier les spécifications à des documents Word, Excel ou autre afin de gérer le stockage et les versions de ceux-ci.

Ci-dessous la vue de l'organisation des spécifications grâce au « Requirement diagram » représentant l'organisation des packages de spécifications.

SysML_RequirementDiagram.jpg

                  OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

 

Ci-dessous la vue des relations entre spécifications grâce à un autre « Requirement diagram », on peut ainsi bien comprendre l'intérêt des vues dans SysML.

SysML_RequirementDiagramDer.jpg

               OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

Enfin, dans une vue encore différente, nous pouvons associer les spécifications aux différents éléments du modèle pour préciser comment celles-ci vont interagir dans le système.

SysML_RequirementDiagramAss.jpg              OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

Enfin, pour récapituler les exigences et générer des tableaux de bord de suivi de projet, le regroupement des spécifications dans les tableaux SysML offre une vue synthétique comme dans l'exemple ci-dessous.

28-TableRequirements.jpg                OMG SysML Tutorial. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008.

Rédaction du cahier des charges fonctionnel

Notre modèle fournit à ce stade une description complète des fonctionnalités, des spécifications et du fonctionnement dynamique du futur système.

Nous avons même éventuellement déjà identifié un certain nombre de blocs ou de packages qui préparent la phase d'analyse.

Nous sommes donc en mesure à partir de tous ces diagrammes de générer un cahier des charges fonctionnel qui pourra être utilisé au moment de la recette du système.

Actions sur le document
Références
 
Site réalisé et hébergé par www.optragroup.fr