Analyse de besoins

Analyse de besoins

z Introduction

z Concepts de l’analyse de besoins

z Activités de l’analyse de besoins

z Gestion de l’analyse de besoins

Analyse de besoins

Introduction

z Description du but du système, concerne l’aspect externe du système

z Production de la spécification du système (=>communication avec usagers)

z => modèle d’analyse ( pour communication entre développeurs)

modèle fonctionnel:

Modèle

modèle d’objet:

Modèle

modèle dynamique:

Modèle

modèle d’analyse:

Modèle

diagramme de séquence: Vue diagramme

d’état: Vue diagramme de

classe: Vue diagramme de

use case: Vue

Analyse de besoins

Introduction

z Sources de problème: les malentendus – un terme -> plusieurs significations – plusieurs termes -> même signification

– domaine d’application -> langage de l’usager

– compréhension du domaine -> apprentissage du développeur

z Erreur détectée trop tard coûte très cher – Collaboration de l’usager (consensus)

– Entrevue de l’usager: analyse cognitive de tâches – Test et validation

Analyse de besoins

Concepts de l’analyse de besoins

z Besoins fonctionnels

interactions entre le système et son environnement (indépendant de l’implémentation)

z Besoins non fonctionnels

– Aspects visibles par l’usager mais pas reliés directement avec le comportement du système

– Contraintes quantitatives (précision)

– Pseudo besoins (langage d’implémentation, plate-forme)

z Niveaux de description (système et son environnement) – Division de travail -> définir des frontières (usager-système) – Fonctions reliées au domaine d’application

– Fonctions non reliées au domaine d’application

– Dialogue: interactions entre les usagers et l’interface du système

Analyse de besoins

Concepts de l’analyse de besoins

z Propriétés de spécification des besoins

– Correct: représente la vue du système par le client – Complète: tous les scénarios sont décrits

– Consistent: non contradictoire avec elle même – Sans ambiguïté: une seule interprétation possible

– Réaliste: peut être implémentée avec les contraintes – Vérifiable: sans des termes vagues, généraux

z Trois catégories d’activités de l’analyse de besoins:

– Greenfield ingénierie: pas de système existant

– Ré-ingénierie: ré-implémenter un système existant – Ingénierie d’interface: seulement l’interface sera changée

Analyse de besoins

Activités de l’analyse de besoins

1. Identifier les acteurs (entités externes)

z Un acteur est une abstraction d’un rôle

Questions à poser pour identifier les acteurs:

z Quels groupes d’usagers utiliseront le système?

z Quels groupes d’usagers exécuteront les fonctions principales?

z Quels groupes d’usagers qui exécuteront les fonctions secondaires comme l’entretien et l’administration?

z Y-a-t-il des interactions avec un dispositif ou un logiciel externe?

Déterminer la fonctionnalité accessible pour chaque acteur en utilisant des scénarios et des use cases

2. Identifier les scénarios

z Description narrative de ce que les usagers font

z Concrète, décrit du point de vue d’un seul acteur

z Un outil compréhensible par usagers

Un scénario = Nom – Acteurs participés – Flot d’événements

Analyse de besoins

Activités de l’analyse de besoins

Questions à poser pour identifier les scénarios:

z Quelles tâches à exécuter par le système?

z Quelle information à laquelle un acteur devra accéder? Qui créera ces données? Qui les modifiera ou les détruira?

z Quels changements externes dont un acteur informe le système?

z Quels événements dont le système informe un acteur?

Pour répondre à ces questions:

– Utiliser les documents existants – Interviewer les usagers

– Simuler l’interface du système

3. Identifier les use cases (formaliser des scénarios)

z Un use case spécifie tous les scénarios possibles pour une fonctionnalité donnée

z Amorcé par un acteur

z Peut avoir interactions avec d’autres acteurs

Use case = Scénario + Conditions d’entrée / sortie + Contraintes

Analyse de besoins

Activités de l’analyse de besoins

• Identifier les relations entre acteurs et use cases

Pour réduire la complexité du modèle et augmenter la compréhension z Relation de communication

représente le flot d’information et le contrôle d’accès aux données z Relation d’extension

– le comportement est étendu sous certaines conditions

(exemple: use case ConnectionDown dans le système FRIEND) – séparer le flot d’événements exceptionnels ou optionnels z Relation d’inclusion

– élimine les redondances (comportement partagé) comme les sous-routines (facteur commun) dans un programme (exemple: OpenIncident et AllocateResources incluent ViewMap)

Analyse de besoins

Activités de l’analyse de besoins

5. Identifier les objets initiaux

Un objet correspond à un concept du domaine d’application

Un seul terme est utilisé pour chaque concept Æ une entrée du glossaire Les objets participés dans un use case peuvent être identifiés par:

z Les termes nécessitant de clarification

z Les noms répétés

z Les entités dans le monde réel abordé par le système

z Les processus abordé par le système

z Le nom de use case lui même

z Les sources ou le dépôt de données (ex.: imprimante)

z Artefact d’interface (ex.: une station)

Note: Utilisez toujours les termes du domaine d’application

Analyse de besoins

Activités de l’analyse de besoins

Vérifier les objets participants et les use cases

L’intégration d’un nouveau use case entraîne des nouveaux objets Un nouveau objet détecté peut faire naître un nouveau use case Questions pour vérifier les objets:

z Quel use case crée cet objet? (durant lequel les valeurs d’attribut sont entrées). Quel acteur accède à cette information?

z Quels use cases modifient et détruisent cet objet? Quel acteur amorce ces use cases?

z Cet objet est-il nécessaire? (au moins, il y a un use case qui l’utilise) Il serait mieux de retarder la description des cas exceptionnels et le

raffinement des interfaces jusqu’à ce que les use cases sont stables

Analyse de besoins

Activités de l’analyse de besoins

6. Identifier les besoins non fonctionnels

Aspects visibles mais non reliés directement au comportement du système comme l’allure des interfaces, temps de réponse, problème de sécurité.

Questions pour identifier les besoins non fonctionnels:

z Quelle sorte d’interface à être implémentée par le système?

z Quel est le niveau d’expertise des usagers?

z Y-a-t-il le besoin de compatibilité entre les matériels?

z Quelle est la performance requise? Quel est la charge maximale?

z Quels sont les cas exceptionnels à traiter?

z Dans quel pire environnement le système devra opérer?

z Quelle est la portée prévue des changements futurs?

z Y-a-t-il des facteurs externes comme conditions climatiques?

z Faut-il protéger le système contre les intrusions?

z Quelle est la contrainte de ressources consommées par le système?

Analyse de besoins

Gestion de l’analyse de besoins

Analyse cognitive de tâches [Johnson, 1992]

Méthode d’analyse de tâche orientée objet:

ƒ

Identifier les objets et les actions par analyse de documents, entrevue, observation

ƒ

Identifier les procédures (ensemble d’actions, ordre des actions)

ƒ

Identifier les buts (par entrevue) et sous-buts (par décomposition)

ƒ

Identifier la fréquence et l’importance d’un élément pour achever un but

ƒ

Construire le modèle de la tâche (textuel ou graphique) Négociation de spécification du système avec clients

Méthode Joint Application Design

Assembler tous les participants responsables du projet pour préparer le document de spécification.

Validation du modèle fonctionnel (tests par les usagers du système) Document de l’analyse de besoins