Chapitre 3: Analyse et spécification

(1)

Julie Vachon, Hiver 2006

IFT2251:

Introduction au génie logiciel

Chapitre 3: Analyse et spécification

Section 1 : Développement des requis (cueillette et spécification)

J. Vachon - Chap.3, sect.1, p.2 Copyrights Julie Vachon, 2006

Sommaire

Chapitre 3, section 1

« Analyse – introduction aux techniques de cueillette d’informations et de spécification »

1. Les besoins (exigences)

2. Processus d’analyse des besoins

3. Expression des besoins Détermination des besoins Négociation et validation Gestion des besoins Cahier des charges

4. Spécification et modèles

Les modèles : utilité, types, etc.

Références

Satzinger et al.

Chapitres 4 et 5

Ghezzi et al.

Chapitre 5, sections 1 à 4

Pfleeger

Chapitre 4

Un problème de communication

Analyse des besoins:

souvent

Incomplète, imprécise, invalide

•Expertise, jargon du domaine

•Indécis, opinion changeant selon l’offre

•Besoins ambigus, éléments manquants

•Schémas

•Langages formels

•Spécifications souvent incompréhensibles pour les non initiés.

(2)

L’analyste

L’analyste doit devenir aussi informé du fonctionnement de l’entreprise que les

utilisateurs.

Il doit être devenir l’expert.

Avantages:

Meilleure crédibilité.

Solution innovatrice.

Prêt à comprendre tous les utilisateurs…

3.1.1 Besoins

Besoin («requirement») = exigence que le système devrait satisfaire.

Synonymes: exigences, caractéristiques, requis.

Exemples: Système de contrôle d’un ascenseur

B1.Le programme doit planifier les activités de l’ascenseur de façon efficace et raisonnable.

B2.Le programme doit illuminer l’indicateur du panneau d’arrivée correspondant à l’étage où l’ascenseur arrive.

B3.Au dernier (resp. premier) étage, le panneau d’appel ne contient qu’un seul bouton, soit celui pour descendre (resp. monter).

etc.

Catégories de besoins

Besoins fonctionnels(exigences fonctionnelles) description desservices(fonctions).

description des données manipulées

"Comment souhaite-on pouvoir utiliser le système".

Besoins non fonctionnels (spécifications techniques) description des contraintes

Pour chaque service et pour le système global, il est possible d’exprimer différents types de contraintes:

contraintes de performance

contraintes de sécurité

contrainte de convivialité et d'apparence

Etc.

?

(3)

Types de besoins

Les besoins peuvent traduire des exigences concernant

L’environnement physique

Les interfaces

Les humains et utilisateurs

Les fonctionnalités

La documentation

Les données

Les ressources

La sécurité

L’assurance de la qualité

Caractéristiques des besoins

Corrects

Clairs, sans ambiguïtés, intelligibles.

Cohérents

Complets

complétude interne (cohérence) et externe

Réalistes

Pertinents pour le client

Vérifiables

«Traçables»

3.1.2 Processus d’analyse des besoins

Cueillette d’informations

validation &

négociation Gestion

des besoins

Modélisation et spécification

A.Expression des besoins (requirements elicitation)

B.Spécification et modélisation des besoins

Cahier des charges

Validation

Document d’analyse &

spécification

A // B ou A;B

Processus d’analyse des besoins

Cueillette

d’informations validation &

des besoins

Cahier des charges

Validation

spécification

• Recueillir l’information.

• Définir les caractéristiques du système.

• Bâtir des prototype pour la découverte

• Prioriser les caractéristiques.

• Produire et évaluer des solutions de rechange.

• Examiner les recommandations avec la haute direction.

(4)

Processus d’analyse des besoins

Expression des besoins

Participants: analyste, client et utilisateurs.

Document: cahier des charges

Rédigé par: le client en collaboration avec l’analyste.

En langue naturelle.

Découpage: en paragraphes exprimant clairement les buts, les besoins et les contraintes.

Spécification et modélisation des besoins

Participants: analyste

Document: dossier d’analyse et de spécification

Rédigé par: l’analyste.

Notation graphique ou textuelle rigoureuse.

Découpage: modèles statique, fonctionnel et comportemental.

3.1.3 Expression des besoins

1. Collecte des informations

2. Validation &

négociation 3. Gestion des besoins

A. Expression des besoins

B. Spécification et modélisation des besoins

4. Cahier des charges

Validation

spécification

Collecte des informations

Collecte des informations

validation &

des besoins

Cahier des charges Thèmes pour les questions de cueillette d’informations

Quelles informations utilisez-vous?

Quels formulaires et quels rapports?

Identification des informations requises pour réaliser les opérations

Comment le faites-vous ? Quelle démarche suivez-vous ? Réalisation des opérations

Que faites-vous ? Identification des opérations et

procédés administratifs

Questions Thèmes

Quoi ? Comment ?

Avec quels moyens ?

Collecte des informations

1. Méthodes traditionnelles

Entrevue avec clients, utilisateurs et experts du domaine.

Questionnaires(accompagnent ou préparent l’entrevue)

Observation (passive ou active)

Documenter l’observation: diag. de flux des travaux

Étude des documents et des systèmes logiciels existants

Étude des solutions (déjà existantes) des fournisseurs

(5)

J. Vachon - Chap.3, sect.1, p.17 Copyrights Julie Vachon, 2006 Questions fermées objectives

Questions fermées subjectives

Questions ouvertes subjectives (explicatives) Satzinger et al

Questionnaire

J. Vachon - Chap.3, sect.1, p.18 Satzinger et al Copyrights Julie Vachon, 2006

Diagramme d’activités représentant le flux des travaux.

Sources à consulter ?

Description de la situation actuelle

Modèles du domaine

Composants réutilisables et politiques de réutilisation

Propositions des types de besoins à définir

Documentation existante

Systèmes et organisations existants

Besoins exprimés par les parties (clients, utilisateurs)

Collecte des informations

2. Méthodes actuelles

Prototypage

Maquette démonstrative, première étude de faisabilité.

Identification des besoins conflictuels, omis ou mal saisis

Prototype jetable:

Pour évaluer des solutions, puis jeté.

Attention portée sur les besoins les moins bien compris.

Prototype évolutif:

Raffiné pour produire versions intermédiaires jusqu’au produit final.

Attention portée sur les besoins les mieux compris.

(6)

Collecte des informations

Méthodes actuelles (suite)

Développement conjoint d'application (Joint Application Development - JAD)

Série d'ateliers/réunion de travail auxquelles participent clients et développeurs (workshop) Durée: quelques heures à une semaine.

Souvent organisé par firme de consultants.

Participants: chef modérateur, secrétaire, client/utilisateurs, développeurs.

But: efficacité.

Pour plus d’info: (html ici)

http://www.umsl.edu/~sauter/analysis/JAD.html

Collecte des informations

Méthodes actuelles (suite)

Cas d’utilisation

Description des scénarios d’utilisation du logiciel

1. Identification des services (cas d’utilisation) offerts par le système.

2. Identification des acteursparticipant à chacun des cas d’utilisation. Un acteur représente un rôlejoué par une entité (personne, machine, etc.) dans le système.

N.B. Un acteur est un rôle possiblement joué par plusieurs entités. Une même entité peut tenir le rôle de plus d’un acteur.

3. Description détaillée des scénariosd’exécution de chaque cas d’utilisation.

?

Collecte des informations

Méthodes actuelles (suite)

Cas d’utilisation

Exercice: Décrire le scénario principal d’un cas d’utilisation « Retrait à un guichet bancaire »

Négociation et validation

Collecte des informations

validation &

négociation Gestion des besoins

Cahier des charges

(7)

Validation & négociation

Les besoins répondent-ils aux exigences du client ?

Réviser la liste des besoins en vérifiant s’il sont complets, cohérents, réalistes, pertinents, vérifiables, traçables,…

Tout compromis doit être négocié avec le client.

Classer les besoins selon leur priorité et évaluer le risque associé à chacun.

Négociation et validation des besoins

1. Élimination des besoins non pertinents ou irréalistes

Bien définir les frontières du système.

Construire un diagramme de contexte pour identifier les entités externes, les entrées, les sorties.

Identifier les besoins qui ne répondent pas aux objectifs du système, qui sont hors plan, etc.

Faire la liste des besoins exclus pour cause de

trop grande difficulté de réalisation

mise en oeuvre par matériel hardware

inadéquation de la technologie existante

etc.

Négociation et validation

2. Élimination des besoins conflictuels et se recoupant

Numéroter besoins et construire matrice:

identification des paires de besoins

conflictuels:

discussion/négociation avec le client

se recoupant:

reformulation.

b3 b2

R

C

b1

ok

b3 b2 b1

Négociation et validation

3. Evaluation du risque associé aux besoins et évaluation de leur priorité

Quels sont les besoins susceptibles de causer des problèmes pendant le développement???

risques techniques, risques de performance, de sécurité, d'intégrité de la b.d., risques

politiques/légaux, risques de volatilité (besoins qui changent durant développement)

Priorité:

1. Essentiel 2. Utile 3. Difficile 4. À décider

(8)

Gestion des besoins

Collecte des informations

validation &

négociation Gestion des besoins

Cahier des charges

Gestion des besoins

1. Identification et classification des besoins dans le cahier des charges

identificateur unique (manuel ou automatique par b.d) numérotation séquentielle

numérotation séquentielle avec catégories

2. Hiérarchisation des besoins

Un besoin peut se composer d’un ou plusieurs sous- besoins plus spécifiques, moins abstraits.

On peut construire d'abord un modèle abstrait ne considérant pas les sous-besoins...

Gestions des besoins

Exemple.

B1. Le programme doit planifier les activités de l’ascenseur de façon efficace et raisonnable.

B1.1Si l’ascenseur ne contient pas de passager, il devrait demeurer au rez-de-chaussée en attendant la prochaine requête.

B1.2L’ascenseur ne devrait pas modifier le sens de son déplacement s’il contient des passagers qui n’ont pas encore atteint leur destination.

…

Exemple d’un cahier de charge (html ici).

Gestion des besoins

3. Gestion des modifications et traçabilité

Lorsqu’une exigence est changée, comment facilement retracer les documents, modèles et bout de code à modifier?

Modifications facilitée par l’utilisation d'un outil de gestion de configuration

Permet de tracer:

Les besoinsqui définissent ce que le système doit faire.

Les modules de conceptiongénérés à partir des besoins Le code qui implémente la conception

Les testsqui vérifient les fonctionnalités du système La documentationqui décrit le système

Gestion facilitée des versions et meilleure traçabilité lors des changements.

Pour en savoir plus (html ici): http://linas.org/linux/cmvc.html

?

(9)

Cahier des charges

Voici maintenant la structure standard d’un cahier des charges

(Il existe plusieurs templates de cahier des charges

(IEEE, ANSI, etc.))

Collecte des informations

Validation &

négociation

Gestion des besoins

Cahier des charges

1. Description générale du projet 1.1 Intention et portée du projet

1.2 Contexte d'entreprise (planification stratégique) 1.3 Parties prenantes

1.4 Idées de solution 1.5 Plan du document

2. Requis fonctionnels (services)

2.1 Portée du système (diagramme de contexte) 2.2 Besoins fonctionnels (entrées, sorties, calculs, synchronisations/contraintes temporelles, stokage de données, etc.)

Cahier des charges

3. Contraintes (requis relatifs à la qualité et la platefome) 3.1 Contraintes d'interface (convivialité)

3.2 Contraintes de performance (temps de réponse, etc.) 3.3 Contraintes de sécurité (protection des données,

confidentialité, etc.)

3.4 Contraintes de fiabilité (correction, robustesse, tolérance aux fautes & recouvrement)

3.5 Contraintes opérationnelles (débit des opérations, disponibilité)

3.6 Facilité de maintenance (extensibilité, portabilité, réutilisabilité)

3.7 Plateforme et technologies 3.8 Contraintes politiques et légales

Cahier des charges

4. Eléments du projet (requis relatifs aux processus de développement)

4.1 Problèmes ouverts 4.2 Planning préliminaire 4.3 Budget préliminaire

Appendices - Glossaire

- Documents et formulaires d'entreprise - Références bibliographiques

(10)

3.1.4 Spécification et modélisation

Détermination des besoins (« elicitation »)

Validation &

des besoins

A. Expression des besoins

B. Spécification et modélisation des besoins

Cahier des charges

Validation

spécification

Spécification et modélisation

Modèle

Représentation abstraite d’un aspect important quelconque du monde réel.

Moyen de décrire avec rigueur les caractéristiques d’un système.

Un ensemble de modèles différents sont nécessaires pour représenter les différentes vues d’un système

Système

Modèle X Vue de la structure Modèle Y

Vue des

interactions Modèle Z

Vue du comportement

Spécification et modélisation

Utilité de la modélisation

Approfondir la compréhension du problème.

Réduire la complexité par l’abstraction.

Retenir tous les détails.

Favoriser la communication avec les autres membres de l’équipe de développement, les utilisateurs, etc.

Documenter.

Styles de spécification

Trois axes de classification

Degré de formalisme

Spécifications informelles:

Ex. description en langue naturelle, croquis, etc.

Spécifications semi-formelles

Notation graphique dont la sémantique n’est pas formellement définie. Ex. UML

Spécifications formelles.

Ex.: Spéc. algébriques, spéc. logiques, réseaux de Petri, langages de programmation, etc.

Degré de formalisme

Nature des aspects décrits Style des

énoncés

(11)

Styles de spécification

Style des énoncés

Spécifications opérationnelles

Tout en décrivant le « quoi ? », on suggère aussi le « comment ».

Ex. Réseaux de Petri, DFD, FSM, etc.

Spécifications descriptives.

Description des propriétés désirées

Ex. Modèles E.-A., spéc. logiques, etc.

Nature des aspects décrits

Spécifications statiques:

On décrit ce qui ne change pas dans le système (format des données, propriétés des fonctions)

Ex. Modèle E.-A. définitions axiomatiques, etc.

Spécifications dynamiques

On décrit ce qui change dans le système: les états, les réactions aux stimuli.

Ex. FSM, réseaux de Petri, tables de décision, etc.