Les besoins préliminaires représentent un travail d’intercompréhension et/ou une des- cription consensuelle du problème du cahier des charges entre clients, utilisateurs et concep- teurs sur ce que doit être et ce que doit faire le système, ses limites et ses contraintes. Cette phase doit permettre de transformer le cahier des charges ou des besoins exprimés par le client en un cahier des charges consensuel entre client et fournisseur (cf. figure 3.2). Dans un contexte multi-agent adaptatif, le système à étudier doit s’adapter à des événements im- prévus qui peuvent provenir de l’environnement. Par rapport à une méthode orientée objet, ADELFE ajoute donc une caractérisation de cet environnement après ces travaux des be- soins préliminaires. Par contre, les travaux des besoins préliminaires ne manipule pas le terme agent. En effet, ADELFE se propose d’être une méthode applicable à n’importe quel contexte, et ne peut donc limiter l’expression des besoins en y ajoutant des éléments spéci- fiques aux agents coopératifs.
Les activités des besoins préliminaires et leur ordonnancement sont résumés dans le dia- gramme d’activité SPEM de la figure 3.2. Les acteurs de cette activité sont le client, l’utilisa- teur final et l’analyste des besoins. Une activité, représentée par un "empennage de flèche", est réalisée par un acteur si elle apparaît dans la ligne correspondant aux rôles de partici- pants (par exemple, la définition des besoins de l’utilisateur est faite par le client). Les flèches pointillées indique les flots des produits d’activité en activité. Certaines activités sont condi- tionnées, grâce à des branchements type UML.
3.3.1 Définir les besoins utilisateur (A1)
Cette activité représente la première activité du processus des besoins préliminaires, qui s’étend de l’activité A1 à l’activité A5. Cette première activité concerne la description du système et de l’environnement dans lequel le système sera déployé. Elle consiste à définir ce qu’il faut construire ou ce que sera le système le plus adapté aux utilisateurs finals.
Les utilisateurs finals, les clients, les analystes et concepteurs doivent lister les besoins potentiels. Le contexte dans lequel le système sera déployé doit être compris. Les besoins fonctionnels et non fonctionnels doivent être établis. Cette information doit être dans le do- cument intitulé cahier des charges (ou requirements set dans la figure 3.2) préliminaire.
Exemple 3.1. Le système à réaliser est un gestionnaire d’emplois du temps (d’enseignements). À partir d’informations données par l’utilisateur, il affiche une répartition des cours sur un emploi du temps. On peut donner une description des données qui sont reçues par le système concernant les enseignants, les groupes d’étudiants et les salles dans lesquelles sont donnés les cours :
3 Une description d’enseignant qui contient les informations suivantes :
– Le nom de l’enseignant ;
– Ses indisponibilités (les jours ou les plages horaires durant lesquels il ne peut pas enseigner, ...) ;
– Ses capacités (les sujets qu’il enseigne, ....) ;
– Les besoins qu’il a à propos d’équipements pédagogiques particuliers (rétro-projecteur, vidéo- projecteur, salle de TP, ...).
3.3. Les besoins préliminaires (WD1)
: Client : Utilisateur Final : Analyste des Besoins
! " # $ % & ' % &' ( &' ( &'
Figure 3.2 — La définition de travaux WD1: les besoins préliminaires.
3 Une description de groupe d’étudiants qui contient les informations suivantes :
– Son identifiant ;
– Les sujets qu’il doit étudier ;
– Le nombre d’heures à suivre dans chaque matière.
3 Une définition de salle de cours qui comprend :
– Son numéro ;
– Le matériel spécifique dont elle est équipée (rétro-projecteur, vidéo-projecteur, salle de TP, ....).
3.3.2 Valider les besoins utilisateur (A2)
Dans cette activité, il faut vérifier et approuver le contenu du document cahier des charges précédemment établi. Si ce document n’est pas approuvé, il est nécessaire de ré- appliquer l’activité précédente. C’est une activité typique dans les méthodes orientées objet qui mènent les projets de bout en bout. Cependant, ces considérations ne soulèvent aucune problématique agent.
3.3.3 Définir les besoins consensuels (A3)
Dans cette activité, il faut mettre à jour et compléter le document intitulé cahier des charges en prenant en compte les besoins consensuels. De même que pour l’étape 2, une non appro- bation de ce document entraînera un retour à l’ activité précédente. Un besoin consensuel est une condition ou une fonctionnalité à laquelle le système doit se conformer et sur laquelle les utilisateurs finals, les concepteurs et les développeurs sont d’accord.
Exemple 3.2. L’ensemble des besoins utilisateur est totalement réécrit par l’analyste des besoins. Voici la nouvelle version. Dans ce problème, les parties impliquées sont des enseignants, des groupes d’étudiants et des salles de cours.
Chaque acteur possède individuellement des contraintes qui doivent être respectées au mieux. Un enseignant possède des contraintes concernant ses disponibilités (e.g. les jours ou les créneaux horaires pendant lesquels il peut enseigner), ses compétences (e.g. les matières qu’il enseigne) et ses besoins concernant des équipements pédagogiques particuliers (rétroprojecteur, vidéoprojecteur, salle de TPs, livres, etc.).
Un groupe d’étudiants doit suivre un ensemble d’enseignements constitué d’un certain nombre de créneaux horaires pour un certain nombre de matières (x créneaux pour la matière m1, y créneaux
pour la matière m2, etc.) ce qui est défini dans le PPN ou Plan Pédagogique National.
Une salle de cours est pourvue ou non d’équipement spécifique (projecteurs, accès pour les per- sonnes handicapées, équipement de TP, etc.) et peut être occupée ou non (e.g. durant un certain créneau ou un certain jour).
Pour chaque acteur, des contraintes doivent être données sous la forme d’une liste ordonnée. L’ordre des contraintes dans la liste donne leur importance relative ; ainsi la première contrainte donnée est celle qui sera, si c’est nécessaire, le plus facilement relâchée.
Résoudre le problème consiste à satisfaire le plus de contraintes possibles pour établir un emploi du temps sur une durée donnée.
3.4. Les besoins nals (WD2)
3.3.4 Établir la liste des mots-clés (A4)
Cette étape consiste à lister les principaux concepts utilisés pour décrire l’application et son domaine (le système et son environnement). Une définition de chaque mot-clé sera don- née dans un document intitulé ensemble de mots-clés. Cette étape est une première abstraction du système en devenir (i.e. quels seront les concepts manipulés ?) mais il est encore trop tôt pour introduire le concept d’agent. Il est à noter que cette étape peut se dérouler en parallèle avec l’activité A5comme le montre la figure 3.2.
Exemple 3.3. D’après les besoins utilisateur, les mots-clés et concepts suivants sont mis en exergue :
– Planning : l’action de résoudre (établir) un emploi du temps ;
– Salles : lieux où les cours peuvent être donnés ;
– Enseignants : personnes dispensant les cours ;
– Étudiants : personnes assistant au cours ;
– Contraintes : règles que le système doit respecter ;
– Organisation : un état de distribution des cours ;
– Gestion des contraintes : action de vérifier le respect des règles et de changer l’organisation
afin de respecter plus de règles.
3.3.5 Extraire les limites et les contraintes (A5)
Dans cette activité, il faut définir les limites et les contraintes du système à construire (l’application). Elles peuvent être déduites de l’expression des besoins non fonctionnels et de la définition du contexte dans lequel le système sera déployé. Un besoin non fonction- nel est un besoin qui spécifie les propriétés du système, telles que des contraintes environ- nementales ou d’implantation, de performance, de dépendance à la plate-forme cible, de maintenance, d’extensibilité et de sûreté. Un besoin qui spécifie des contraintes physiques sur un besoin fonctionnel [Jacobson et al., 1999]. Cette information servira à raffiner le docu- ment ensemble de mots-clés précédemment établi. Cette activité peut donc se dérouler aussi en parallèle avec l’activité A4précédente.
Exemple 3.4. Le problème est simplifié par le fait que seuls des créneaux horaires de deux heures sont gérés. Sinon, la principale contrainte du système est qu’un enseignant ne peut pas donner un cours à plus d’un groupe d’étudiants à la fois. Cela signifie que le système ne peut associer un enseignant qu’à un groupe d’étudiants et une salle de cours pour une tranche horaire donnée.