Comme annonc´e pr´ec´edemment, nous distinguons deux types de processus : les Processus d’Ing´enierie et les Processus de Collaboration. Les premiers sont d´ej`a offerts par la norme EIA-632, ils n’ont donc pas besoin d’ˆetre red´efinis tandis que les derniers doivent ˆetre con¸cus et d´efinis au moyen de l’Ing´enierie de la Collaboration. Dans cet objectif, le thinkLet devient un concept fondamental dans notre mod`ele. La figure III.5 (infra) montre un diagramme de classes avec les diff´erents concepts que nous utilisons :
Besoin - il est l’expression du souhait ou du probl`eme d’un utilisateur ou de toute autre partie prenante que nous appelons ici participant. Le besoin s’exprime de mani`ere non for- melle, de fa¸con orale ou ´ecrite de telle sorte que celui qui l’exprime se sente `a l’aise. Le besoin peut ˆetre exprim´e directement par le participant ou extrait par une autre personne, g´en´era- lement l’ing´enieur des exigences qui participe `a la session en tant que facilitateur pour poser des questions ou utiliser d’autres m´ethodes qui incitent `a produire plus de besoins.
Contrainte- il s’agit de toute limitation ou obligation r`eglementaire `a laquelle le syst`eme doit ˆetre soumis et qui peut donner lieu `a des exigences syst`eme. Les exigences r´esultant des contraintes de ce type sont souvent des exigences non fonctionnelles li´ees par exemple `a
la s´ecurit´e, tandis que les besoins des utilisateurs donnent en g´en´eral lieu `a des exigences fonctionnelles.
Exigence- elle est une expression formelle et technique du Besoin ou de la Contrainte. Toutefois, il faut noter que tous les besoins et toutes les contraintes ne sont pas technique- ment r´ealisables et ne sauraient ˆetre traduits en exigences techniques. En g´en´eral, on utilise les mod`eles (gabarit) de sp´ecification pour formaliser les besoins ce qui donne lieu `a des exi- gences qui sont techniquement satisfaisables. La transformation des besoins en exigences est n´ecessaire car seules les exigences sont exploitables par l’´equipe de r´ealisation. Les exigences ont un identifiant, un libell´e et un niveau de priorit´e d´efini en fonction du type de syst`eme `a concevoir.
Cahier de charges- il repr´esente un document dans lequel sont r´edig´ees les sp´ecifications des exigences selon les normes du domaine. En effet, selon que l’on soit dans l’a´eronautique ou dans les syst`emes d’information, les exigences ne sont pas sp´ecifi´ees de la mˆeme mani`ere. Outre les diff´erences de sp´ecification, tout cahier des charges doit ˆetre organis´e en Cat´egories et sous Cat´egories si n´ecessaires. Cela permet d’accroˆıte la facilit´e d’utilisation du document. Le cahier des charges est le document qui est transmis `a l’´equipe de d´ev´eloppement pour la conception et la r´ealisation du syst`eme final. La rigeur doit ˆetre de mise pour la r´edaction du cahier des charges car la r´eussite du projet d´epend de sa qualit´e en terme de structuration et de clart´e.
Cat´egorie- elle repr´esente une sous partie du document de sp´ecification, le cahier des charges qui correspond g´en´eralement `a un type d’exigences donn´e. En effet, les exigences sont de diff´erents types ; Elles peuvent ˆetre classifi´ees en exigences de type fonctionnel et de type non fonctionnel. Ces deux cat´egories peuvent aussi avoir des sous cat´egories. Cette organisation en cat´egories et sous cat´egories a pour avantage d’accroˆıtre la lisibilit´e, la clart´e et la compr´ehension du document.
Processus d’Ing´enierie- les exigences sont d´efinies suivant des processus qui sont ´eta- blis par des normes, nous avons retenu ici la norme EIA-632. Ces normes d´ecrivent en d´etail les diff´erentes ´etapes `a suivre pour d´efinir les exigences.
Tˆache- les ´etapes d´efinies par le processus d’ing´enierie correspondent `a l’ex´ecution d’une tˆache particuli`ere. Puisque nous sommes dans un contexte collaboratif, il s’agit ici de tˆaches collaboratives, celles qui sont men´ees conjointement par les participants.
Activit´e- chacune des tˆaches est compos´ee `a son tour d’activit´es. Les tˆaches sont souvent complexes et n´ecessitent d’ˆetre d´ecompos´ees en plusieurs activit´es.
ThinkLet - il est le support des activit´es des tˆaches collaboratives. Le thinkLet encapsule les informations qui d´ecrivent comment ex´ecuter une tˆache de mani`ere collaborative. Cette
description repr´esente un des composants du ThinkLet qui est appel´e Script dans la termino- logie de l’Ing´enierie de la Collaboration (infra, l’annexe 1). Puisqu’un thinkLet est un patron de conception, il peut ˆetre adapt´e selon la situation en changeant le script, tout en gardant les principes fondamentaux de la technique collaborative. Il est ´egalement possible de proposer un nouveau ThinkLet lorsqu’il n’existe pas encore un thinkLet adapt´e `a la situation en cours. Pour plus de d´etails, se reporter `a la section 2.3.4 `a la page 46.
Processus de Collaboration - il s’agit du processus ´elabor´e par un ing´enieur de la collaboration pour les participants `a une session d’Elicitation des Exigences par exemple. Ces processus sont construits `a partir de thinkLets et ils impliquent au moins trois Partici- pants. Les processus de collaboration sont document´es par l’ing´enieur de la collaboration et contiennent toutes les informations n´ecessaires permettant `a une ´equipe de r´ealiser un travail collaboratif de mani`ere autonome, voir la section 2.3.5 `a la page 48.
0..* ... type description description sousCategorie
nom nomdescription
nom nom but nom identifiant description contient participe à est construit à partir de donne lieu à donne lieu à contient
est définie à travers
est composé de est auteur de 0..1 0..1 3..n 1 0..1 0..n 1..n 1..n 1..n 1..n 1 1 1..n 1..n 1..n 1..n 1..n 1..n 0..n 0..1 1..n 1..n 0..1 0..n identifiant priorite justification 1..n 0..n
est émis par
1..n
est émis par
0..1 s’appuie sur 1..n predecesseur nom successeur 1..n 1..n est composé de nom ... Catégorie Besoin CahierDesCharges
Participant ProcessusDeCollaboration ThinkLet ProcessusIngenierie Tâche Activité Contrainte Exigence sousProcessus ThinkLetComposant sousProcessus
Figure III.5 – Un mod`ele de classes des processus d’ing´enierie et de collaboration [Kon08]
Le Mod`ele ci-dessus, que nous avons propos´e dans un de nos contributions [Kon08], for- malise la phase d’int´egration entre les deux types de processus en faisant le lien entre les tˆaches et les thinkLets suivant le mod`ele propos´e dans la section 3.1.
Comme pr´ec´edemment annonc´e, nous avons choisi l’Ing´enierie des Exigences comme contexte d’´etude et plus sp´ecifiquement la phase d’Elicitation des exigences. La section 3.4 pr´esente la situation et d´ecrit les diff´erents processus qui interviennent dans cette phase et aussi un diagramme d’interaction UML [RV04], un des objectifs ´etant l’impl´ementation d’un outil permetant de supporter le processus d’´elicitation collaborative des exigences.