LES TECHNIQUES POUR LELICITATION DES EXIGENCES 1

1

RÉALISÉ PAR: HAJJI JIHED

MANEL BELHADJ AHLEM LIMEM

LES TECHNIQUES POUR L’ELICITATION DES EXIGENCES

2

PLAN

I. IntroductionII. ButIII. TechniquesIV. Avantages/ InconvénientsV. Conclusion

3

INTRODUCTION

Enjeux des années 80: qualité/performance des produits 90: la pression sur les coûts Années 2000: délais qui préoccupent les industriels.

Le besoin d’accélérer les processus de conception impose l’utilisation de plate forme collaborative: la mise à disposition d’un espace de communication numérique entre les acteurs du processus.

Conséquences: + Partage des données structurelles et physiques du

système , les données projet. -Perte de temps dans le projet inhérent à la nature même

des exigences : complexes, floues, incomplètes et évolutives.

4

ÉLICITATION DES EXIGENCES

La complexité, l’imprécision et l’incomplétude peuvent être traitée selon nous par les méthodologies d’élicitation du besoin.

Elicitation des exigences: propriété concernant la capacité à faire sortir, émerger, découvrir les besoins de l’ensemble des clients .

5

BUT

Elicitation des exigences: capturer les besoins du client raffiner la compréhension du problème déterminer les limites de la solution identifier les contraintes à respecter. Déterminer les techniques d’acquisition Produire un premier document

6

POSITION DE L’ELICITATION DANS L’ETUDE D’UN PROJET

7

TECHNIQUES

Les concepteurs ont besoin de méthodes performantes pour pouvoir développer une activité:

Analyse des parties prenantes Analyse de systèmes existants Remue-méninge Sessions Joint Application Design (JAD) Entrevues Prototypage Cas d’usage et scénarios Analyse de risques

8

ANALYSE DES PARTIES PRENANTES(1)

Analyse des parties prenantes: L’analyse des parties prenantes est l’outil

identifiant les besoins et les préoccupations des différentes parties concernées. Client: Personne qui paye le développement du logiciel

Utilisateur: expert du système actuel et du système compétiteur

Acheteur: Personne qui paye le logiciel une fois développé

Expert du domaine: connait le travail et l’environnement d’utilisation

Ingénieur logiciel: Expert qui connait la technologie et le processus

Autres : Inspecteur, Spécialiste en études de marchés, Avocat..

9

ANALYSE DES PARTIES PRENANTES(2)

les étapes:

Établir la vision ou l’objectif Recueillir les renseignements Identifier explicitement toutes les personnes et

organisations, internes et externes Classer les parties prenantes Déterminer l’intérêt ou l’effet de l’enjeu Établir leur position et leur importance Déterminer les parties prenantes clés Développer un plan d’action.

10

EXEMPLEANALYSE DES PARTIES PRENANTES

11

ANALYSE DES PARTIES PRENANTES(3)

Avantages: importance trop grande accordée aux outils

analytiques questions trop vastes ou trop complexes pour

les décideurs portée de l’étude trop grande certaines parties prenantes sont laissées de

côté pas d’appartenance locale pas d’engagement face à la mise en oeuvre.

12

ANALYSE DE SYSTÈMES EXISTANTS(1)

Analyse de systèmes existants: Déterminer les vraies habitudes des

utilisateurs, les activités fréquentes, et l’importance relative des tâches et services

découvrir des améliorations possibles découvrir les fonctionnalités patrimoniales Étapes:

étude de documentation disponible Observations Questionnaires Entrevues

13

ANALYSE DE SYSTÈMES EXISTANTS(2)

14

ANALYSE DE SYSTÈMES EXISTANTS(3)

Etapes: Recueillir l'information sur l'existant et sur les attentes par rapport au

futur. Décrire et évaluer les fichiers existants Se procurer la documentation sur les données actuelles. Décrire et évaluer l'infrastructure d'organisation du système

informatique existant Décrire et évaluer les procédures. Décrire et évaluer les ressources technologiques du système existant. Recenser les défauts de sécurité. Résumer la description et l'évaluation des systèmes informatiques

existants (principaux faits saillants, avantages, inconvénients). Définir et chiffrer le plan d'amélioration à court terme de l'existant pour

des problèmes urgents. Définir le plan pour la sécurité de l'existant. Vérifier la cohérence de l'ensemble.

15

ANALYSE DE SYSTÈMES EXISTANTS(4)

Avantages : la méthode réduit les problèmes

d’incompréhension entre les deux catégories d’acteurs (analystes et utilisateurs ).

Inconvénients : L’utilisation de cette méthode présente le

risque de ne pas percevoir les évolutions souhaitables dans le système d’information.

16

REMUE-MÉNINGE

Remue-méninge (brainstorming): la récolte d'idées nombreuses et originales.

principes: la suspension du jugement la recherche la plus étendue possible. règles :• Ne pas critiquer.• S'attendre à des idées extravagantes ;tout est

possible (« freewheeling »).• Rebondir (« hitchhike ») sur les idées exprimées.• La quantité est plus importante que la qualité.

17

EXEMPLE (BRAINSTORMING)

Des universitaires veulent créer une entreprise de formation multimédia. Pour développer leur clientèle, ils décident de faire un remue-méninges. Ils demandent à deux amis de faire l’animation et le secrétariat de la rencontre. L’animateur rappelle le but de la rencontre Il rappelle les règles du remue-méninges Il laisse au groupe une période de réflexion silencieuse (5 mn

pour mettre leurs idées sur papier) Il invite chaque participant à exprimer une idée à la fois Le secrétaire note et numérote les idées. Il leur demande ensuite de regrouper les idées. Les participants sont ensuite invités à classer les suggestions

par ordre d’importance ou d’intérêt .

18

REMUE-MÉNINGE

19

REMUE-MÉNINGE

Avantages:

utile à la résolution des problèmes peut être utilisé par tous les élèves et encourage la participation aide les élèves à accepter d'autres points de vue peut fournir rapidement de nombreuses idées ou suggestions permet d'éviter les arguments puisque les commentaires négatifs ne sont pas

autorisés ne nécessite aucun équipement ou matériel spécial

Inconvénients:

la prise de notes peut ralentir le cours des idées tend à être bruyant si les élèves s'excitent un élève bavard peut dominer la discussion pour réussir, nécessite un bon animateur et un bon secrétaire il est difficile de ne pas juger

20

SESSIONS JOINT APPLICATION DESIGN

Sessions Joint Application Design (JAD): Utilisation d’aides visuelles pour améliorer la compréhension

Étapes : Planification: utilisée pour l’élicitation (remue-méninges) Conception: utilisée pour concevoir le logiciel

Rôle : Dirigeant de session Analyste Promoteur exécutif Représentants des utilisateurs Représentants du département d’informatique Spécialistes

21

ENTREVUES

Entrevues: Demande de la préparation et une bonne gestion de la

communication.objectifs:

Découvrir :l’information de façon précise et efficace

Documenter : l’information servant à la modélisation et l’analyse des exigences Rassurer :l’interlocuteur que sa compréhension du sujet a été entendue,

explorée , et prise en considération.

étapes: Planification et préparation Session d’entrevue Consolidation de l’information Suivi

22

ENTREVUES

Connaissance d’une entreprise lors d’une entrevue d’information avec un employeur :

▪ Quelle est la mission de votre entreprise?▪ Quel est l'historique de votre entreprise?▪ Quelles professions retrouve-t-on dans votre entreprise?▪ Quelles sont les perspectives de développement de

votre entreprise?▪ Quelles sont les opportunités d’emploi dans votre

entreprise?▪ Quel est l’organigramme de votre entreprise?▪ Quel environnement de travail offre votre entreprise?

23

ENTREVUES

24

ENTREVUES

Avantages : - Donne une crédibilité à l’information reçue. - Personnifie la source des informations. - Transmet rapidement et efficacement l’information. - Suscite la réflexion. - Favorise une recherche plus approfondie des informations. - Provoque des réactions spontanées. - Augmente la compréhension par la possibilité de clarification des

réponses - Peut être utilisée dans plusieurs contextes. Inconvénients : - Demande beaucoup de préparation de la part de l’intervieweur. - S’attarde parfois à une première impression désagréable. - Passe parfois à côté du message principal. - Ne différencie pas l’information objective de l’information subjective. - Se heurte parfois au manque d’expérience de l’intervieweur.

25

PROTOTYPAGE

Prototypage: découvrir les fonctionnalités, discuter les interfaces utilisateurs et de convivialité établir des priorités. Principe: la production d'un logiciel est le résultat d'un processus

cyclique d'évolution progressive d’une forme simple vers une forme complexe, chaque cycle d'évolution fournissant un prototype de plus en plus élaboré et de plus en plus proche du système à produire.

catégories: évolutif jetable

26

PROTOTYPAGE(EXEMPLE)

Développement d'un système expert :évolutif évolutif

27

PROTOTYPAGE(EXEMPLE)

Prototype d'un analyseur syntaxique avec une grammaire réduite : jetable

28

PROTOTYPAGE

Avantages : -un gain de temps - un gain d’argent -  faciliter l’implantation du SI et la collaboration des utilisateurs - trouver les modèles les plus appropriés aux styles cognitifs des utilisateurs  - une identification plus « concrète » des besoins en information des utilisateurs - améliorer la communication entre analystes et utilisateurs ; - une meilleure implication des utilisateurs durant le processus de

développement, ce qui conduit à une meilleure satisfaction Inconvénients : - la méthode s’avère difficilement applicable dès que les projets prennent de

l’envergure - le contrôle, la maîtrise de cette approche de développement ne sont pas

aisés ; - le développement de prototypes peut exiger l’acquisition de ressources

informatiques sophistiquées. 

29

CAS D’USAGE ET SCÉNARIOS

Cas d’usage : Un cas d’usage: séquence typique d’actions

qu’entreprend un utilisateur afin d’accomplir une tâche donnée

Scénarios: Un scénario (selon UML) est une instance d’un cas-type Décrit le flux des évènementsTypes: Scénario « tel quel » Scénario visionnaire Scénario d’évaluation Scénario de formation

30

CAS D’USAGE ET SCÉNARIOS

Règles d'écriture des scénarios: Décrire l'activité : "quoi" pas "comment "   Rester simple Décomposer avec <<uses>> or <<extends>> Autonomie Ne pas mélanger les cas d'utilisation Style direct Pas d'ambiguité ("très", "plutot", "peu", "souvent",

"en général") Un scénario est une transaction Il y a un début et une fin Il est exécuté complètement ou pas du tout

31

CAS D’USAGE ET SCÉNARIOS(EXEMPLE)

32

CAS D’USAGE ET SCÉNARIOS

Avantages: correction de la spécification relativement aux besoins modéliser le domaine du problème (UML). Distinguer la modélisation du problème et la conception de

la solution identifier (et corriger) les erreurs ou les omissions s'assurer de l'implication et la compréhension des parties

prenantes

Inconvénients:o difficulté avec les systèmes complexeso masquent les règles métier derrière les interactions

acteurs / système

33

CONCLUSION

Les principales caractéristiques de notre approche peuvent être résumées comme suit. Besoins/élicitation des besoins d’une part, spécification/élaboration de spécifications d’autre part sont clairement identifiés.

34

BIBLIOGRAPHIE

http://fr.wikipedia.org http://fr.wikipedia.org http://www.cours.polymtl.ca/log3410/la

boratoires/Lab_Ete10/log3410%20E2010%20Lab1%20v1-0.pdf

http://tel.archives-ouvertes.fr/docs/00/43/58/78/PDF/rapportThesis.pdf

http://www.google.fr/#hl=fr&source=hp&q=technique+d%27elicitation+des+exigences&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=c6754f687e3a6a87

35

MERCI POUR VOTRE ATTENTION