ANALYSE ET SPECIFICATION DES BESOINS (A) - 4 Slides

GL / Chapitre 3 : Analyse des besoins A.U.
: 2007/2008
ENSI – II2
M04a - Expression des besoins
Cours GL-2006 © / YJ & IBH

Spécification Cours GL-2006 © / YJ & IBH Spécification 2
La résolution d’un problème Sommaire
Solution
Problème
1. Problématique
2. Les besoins
3. Analyse des besoins
• Techniques informelles d’analyse
• Le cahier des charges
problème: Ensemble discret (séquence, hiérarchie ou combinaison des deux) de transformations
Résolution d’un problème:
de l’énoncé du problème en solution.
4. Spécification des besoins
Toute transformation implique une décision dont les effets sont: • Informelle
Réduire le champs des solutions possibles
d’imposer des contraintes sur les décisions ultérieures • Semi--formelle
Semi
• Formelle
5. Conclusion
Cours GL-2006 © / YJ & IBH Spécification 3 Cours GL-2006 © / YJ & IBH Spécification 4
Prénom - Nom de l’étudiant :……………................. 1

GL / Chapitre 3 : Analyse des besoins A.U. : 2007/2008
ENSI – II2
Avant projet Développement

1. Problématique
Beaucoup de systèmes existants sont mal utilisés voir

Etude même jamais utilisés car ils ne correspondent pas aux
Préalable besoins du client !
« Ce n’est pas ce que je voulais… »
Validation
« Ca ne sert à rien… »
Etape « Comment je fais ça… »
Analyse « Ce n’est pas le bon résultat… »
Première
définition « je vous avais dis que je voulais ça… »
du Validation
problème
Causes
Le client ne sait pas toujours ce qu’il veut et n’exprime pas toujours ces besoins
clairement.
L’informaticien ne comprend pas le client (et vice versa !)
Ce que le client demande n’est pas forcement ce dont il a besoin.
Le client exprime souvent la solution à laquelle il pense et non son besoin réel (que vous
ne connaîtrez peut-
peut-être jamais).
Le client ne connaît pas toujours l’informatique : il ne sait pas ce qui est possible et ce
qui ne l’est pas.

ENSI – II2
Les problèmes potentiels 2. Les Besoins

Difficultés de communiquer Besoins (« requirement ») = exigence de ce que le système devrait satisfaire
difficulté d’être précis, cohérent, complet,… Exemples 1: Système de contrôle d’un ascenseur
différences de culture :
les utilisateurs ne sont pas des informaticiens… B1. Le système doit planifier les activités de l’ascenseur de façon efficace et
les informaticiens ne connaissent pas le domaine … raisonnable
Complexité du problème B2. Le système doit illuminer l’indicateur panneau d’arrivée correspondant à
l’étage où l’ascenseur arrive
problème non formalisé B3. Au dernier (resp. premier) étage, le panneau d’appel ne contient qu’un seul
problème complexe bouton, soit celui pour descendre (resp. monter)
Evolutivité B4. etc…
Exemple 2 (suite)
Exemple 2
1- Le système sera installé dans l’unité de soins intensifs de l’hôpital. Cette
Problème : Réaliser un système de surveillance des unité comporte 8 lits destinés à recevoir des patients dont l’état est critique
et dont les signes vitaux doivent être surveillés 24/24.
patients dans une unité de soins intensifs.
2- Les signes vitaux à surveiller sont l’électrocardiogramme, le rythme
respiratoire et la pression artérielle.
3- La surveillance consiste à saisir les signes vitaux, à les afficher sur des
moniteurs aux lits et au poste des infirmières, à les comparer avec une
banque de référence et à émettre éventuellement des alarmes.
énoncé en langage naturel, imprécis, incomplet, parfois confus
4- Le système doit produire des rapports sur chaque patient.
5- Des capteurs en place devront être utilisés
6- Le système devra être opérationnel dans un an.

ENSI – II2
Type de besoins Différents types de besoins

Environnement physique Besoins fonctionnels
À quoi sert le système
Les utilisateurs Ce que doit faire le système, les fonctions utiles
Les fonctionnalités Description des données manipulés
Les données
Besoins non fonctionnels : une restriction ou une contrainte qui pèse sur un
Les ressources service du système
La sécurité description des contraintes,
…. Pour chaque fonction et pour le système global, il est possible d’exprimer
différents types de contraintes
Besoins du domaine
Requis qui proviennent du domaine d’application du système et qui reflètent les
caractéristiques de ce domaine
Besoins fonctionnels Exemples de Besoins fonctionnels
L’usager devra pouvoir de faire une recherche dans soit

Décrivent la fonctionnalité ou les services du système
l’ensemble initial des bases de données u soit choisir un sous
sous--
Dépendent sur le type de logiciel, les usagers prévus et le ensemble de celles
celles--ci
ci..
type de système où le logiciel sera utilisé
Le système fournira des visualisateurs appropriées pour que
Les requis fonctionnels de l’usager peuvent être des énoncés les usagers puissent lire les documents archivés sur le
de haut niveau de ce que le système devrait faire mais les système.
système.
requis fonctionnels du système devraient décrire en détails
Chaque commande recevra un identificateur unique
les services du système (ORDER_ID) que l’usager pourra copier dans l’espace
permanent de storage du compte

ENSI – II2
Complétude et cohérence des requis Besoins non-

non-fonctionnels
En principe, les requis devraient être complets et cohérents Définit les propriétés et contraintes du système p.ex. fiabilité,
temps de réponse et besoins d’espace mémoire. Les contraintes sont
Complet
la capacité des périphériques I/O, les représentations des systèmes,
Devraient inclure les descriptions de toutes les facilités requises etc
Cohérent Des requis de processus peuvent aussi spécifier l’usage d’un système
Il ne devrait pas y avoir de conflits ou contradictions dans les CASE particulier, d’un langage (programmation) ou d’une méthode de
descriptions des facilités du système développement
En pratique, il est impossible de produire un document complet et Peuvent être plus critiques que les requis fonctionnels. S’ils ne sont
cohérent des requis pas rencontrés, le système est inutile
Classifications des Besoins non-

non-fonctionnels Besoins non fonctionnels [Ian Sommerville]
Requis de produit Moins maîtrisés que les besoins fonctionnels

Requis qui spécifie que le produit livré doit se comporter d’une certaine
façon p.ex. vitesse d’exécution, fiabilité, etc. Besoins non fonctionnels
Requis organisationnel
Requis qui est une conséquence de politiques et procédures
organisationnelles p.ex. normes de traitement, requis d’implantation, etc. sur le processus sur le produit externes
Requis externe en en en en
Requis qui provient de facteurs qui sont externes au système et à son utilisabilité efficacité fiabilité portabilité
processus de développement p.ex. requis de compatibilité, requis
législatif , etc. en en en
livraison implémentation standards légaux en en
coûts interopérabilité
en en
performance taille

ENSI – II2
Exemples de Besoins non fonctionnels Buts et Besoins

Requis de produit Les requis non fonctionnels peuvent être difficile à énoncer précisément et
4.C.8 It shall be possible for all necessary communication between des requis imprécis peuvent être difficile à vérifier.
the APSE and the user to be expressed in the standard Ada Buts
character set.
Une intention générale de l’usager tel la facilité d’usage
Requis organisationnel Requis non fonctionnels vérifiables
9.3.2 The system development process and deliverable documents L’énoncé utilisant une mesure qui peut objectivement testée
shall conform to the process and deliverables defined in XYZCo-
XYZCo-SP
SP--
Les buts aident les développeurs parce qu’ils font ressortir les intention des
STAN--95.
STAN
usagers du système
Requis externe
7.6.5 The system shall provide facilities that allow any user to check
if personal data is maintained on the system. A procedure must be
defined and supported in the software that will allow users to inspect
personal data and to correct any errors in that data.
Exemples Mesures des requis

Propriété Mesure
Un but de système Vitesse Transactions traitées par seconde

Temps de réponse
Le système devra être facile à utiliser par des contrôleurs expérimentés Temps de réécriture d’écran
et doit être organisé de tel sorte que les erreurs d’usagers soient
minimisées..
minimisées Taille Kilo octets
Nombre de puces électroniques
Un requis non fonctionnel vérifiable
Facilité d’usage Temps d,entraînement
Les contrôleurs expérimentés devraient pouvoir utiliser toutes les Nombres de pages d,aides
fonctions du système en dedans de deux heures d’entraînement.
d’entraînement. Après
cet entraînement, le nombre moyens d’erreurs fait par ces utilisateurs Fiabilité Temps moyen avant échec
Probabilité de non disponibilité
expérimentés ne devrait pas dépasser deux par jours.
jours. Taux d’échecs
Disponibilité
Robustesse Temps de redémarrage après échec

Pourcenatge d’évènements causant des échecs
Probabilité de corruption de données lors d’échec
Portabilité Pourcentage d’énoncés qui sont dépendants sur le système cible

Nombre de systèmes cibles

ENSI – II2
Interaction des requis Requis de domaines

Les conflits entre différents requis non
non--fonctionnels sont communs Dérivés du domaine d’application, il décrit les caractéristiques et
dans les systèmes complexes fonctions du système qui reflètent le domaine
Système d’astronefs Peuvent être de nouveaux requis fonctionnels, des contraintes sur
Afin de minimiser le poids, le nombre de puces, dans le système, devrait des requis existants ou définissent des calculs
être minimisé. Si les requis de domaines ne sont pas respectés, le système peut ne
Afin de minimiser la consommation d’énergie, des puces à faible pas être utilisable
consommation devraient être utilisés
Toutefois, l’usage de puces à faible consommation d’énergie peut vouloir
dire davantage de puces devront être utilisés. Lequel de ces requis est le
plus critique?
Ex: Requis du domaine du système de bibliothèque Ex: Système de protection de train

Il doit y avoir un interface usager standard à toutes les bases de
données qui sera basé sur la norme Z39.
39.50.
50. La décélération d’un train sera calculé comme suit:
suit:
En raison des restrictions de copyright, certains documents devront Dtrain = Dcontrol + Dgradient
être effacés immédiatement sur réception
réception.. Dependemment des 81ms2 * compensé selon le gradient/alpha
où Dgradient est 9.81ms
requis de l’usager, ces documents seront soit imprimés localement et où les valeurs de 9.81ms 81ms2 /alpha sont connus pour
sur le serveur du système pour être envoyé manuellement à l’usager différents types de trains.
trains.
ou est acheminé vers une imprimante réseau

ENSI – II2
Problèmes des requis de domaine Requis de l’usager

Compréhension Devraient décrire les requis fonctionnels et non fonctionnels tel
Les requis sont exprimés dans la langue d’application du domaine qu’ils soient comprenables par les usagers du système qui n’ont pas de
Ceci est souvent non compris par les développeurs du système connaissances techniques détaillées
Implicite Les requis de l’usager sont définis en utilisant un langage naturel, des
Les spécialistes du domaine comprennent ce domaine si bien qu’ils ne tables et des diagrammes
pensent pas à rendre les requis de domaine explicites
Problèmes avec les langages naturels Ex: Requis de bases de données

Manque de clarté
La précision est difficle à obtenir sans rendre le document difficile à lire
Confusion dans les requis 4.A.5 The database shall support the generation and control of
Les requis fonctionnels et non fonctionnels tendent à se mêler configuration objects; that is, objects which are themselves groupings
Amalgamation de requis of other objects in the database. The configuration control facilities
Plusieurs requis différents peuvent être exprimés ensemble shall allow access to the objects in a version group by the use of an
incomplete name.

ENSI – II2
Ex: Requis de la grille de l’éditeur Problèmes de requis

Les requis de bases de données incluent les informations
conceptuelles et détaillées
2.6 Grid facilities To assist in the positioning of entities on a diagram, Décrit le concept de facilités de contrôle de configuration
the user may turn on a grid in either centimetres or inches, via an Inclut le détail que les objets peuvent être accéder en utilisant un nom
incomplet
option on the control panel. Initially, the grid is off. The grid may be
Les requis de la grille mélangent trois différents types de requis
turned on and off at any time during an editing session and can be
Un requis fonctionnel conceptuel (le besoin d’une grille)
toggled between inches and centimetres at any time. A grid option
Un requis non fonctionnel (Les unités de la grillegrid units)
will be provided on the reduce-to-fit view but the number of grid Un requis non fonctionnel d’interface usager (changement de grille)
lines shown will be reduced to avoid filling the smaller diagram
with grid lines.
Présentation structurée Requis détaillés de l’usager

ENSI – II2
Principes directeurs pour l’écriture de requis Caractéristiques des besoins

Inventer un format standard et utilisez-
utilisez-le pour tous les requis Corrects
Utilisez le langage de façon cohérente. Utilisez ‘devra …’ pour les Clairs, sans ambiguïtés, intelligibles
requis obligatoire et ‘pourrait …’ pour les requis désirables
Cohérents
Utilisez un rehaut textuel (highlight) pour identifier les parties clés
du requis Complets (interne et externe)
Éviter l’utilisation du jargon informatique Réalistes
Pertinents pour le client
Vérifiables
Traçable
3. Analyse des besoins Le rôle de l’analyse des besoins

Au sens large, c’est l’étude d’un problème avant d’entreprendre une L’une des étapes les plus difficiles
quelconque action.
différents intervenants: le client, les utilisateurs, les développeurs
En informatique, c’est l’étude d’un domaine d’application pour engendrer la 1. clarifier les rôles (identifier, associer des priorités,…)
spécification d’un nouveau système.
2. document orientée utilisateur (cahier des charges)
Le problème peut être orienté application (inventaire), affaire(compétition), 3. document orientée développeur (dossier analyse & spécification)
ou évolution(changement) et sa solution peut toucher le matériel et le
logiciel. difficile d’imaginer un système (surtout dans un nouveau domaine)
Son but est de définir ce que le système (à développer) doit faire (le quoi)
quoi) travailler méthodiquement
sans se préoccuper de la façon dont il doit le faire (le comment).
comment). L’une des étapes les plus importantes
Le résultat de l’analyse des besoins est le document de spécifications: Étape déterminante pour la suite
Connu aussi sous: spécification fonctionnelle, spécification externe, Aspects contractuels
étude détaillée, cahier des charges du logiciel, CCL.
Il établit les objectifs d’un projet en énonçant ce qu’il doit produire pour valider les besoins
être considéré un succès.

ENSI – II2
Principes de l’analyse 3.1 Le processus d’analyse des besoins
Détermination A. Expression des besoins

des besoins
Analyse fonctionnelle Cahier
Les données
Détermination Validation & Gestion des
Modélisation Les fonctions
des besoins négociation des besoins Charges
L’abstraction
Le raffinement
Analyse objet
Vérification validation Objets B. Spécification des besoins
Document
non Assez oui d’analyse &
Détaillé ? Modélisation
Validation spécification
Et spécification
Raffinement Spécifications A//B ou A;B
Expression des besoins : Expression des besoins

3.1.1. détermination 3.1.2. Validation
Cahier Cahier
des des
Détermination Validation & Gestion Détermination Validation & Gestion
Charges Charges
des besoins négociation des besoins des besoins négociation des besoins
1. Méthodes traditionnelles 2. Méthodes actuelles Tester le modèle auprès de l’usager pour le valider
• Entrevue avec clients • JAD, FAST, QFD… (être sûr qu’on a décrit le bon problème)
• Questionnaire (Analyse de la valeur/
• Observation Analyse fonctionnelle) 1. Vérifier que la description des besoins est complète:
• Étude de l’existant • Prototypage 2. Éliminer les besoins ( non pertinents, irréalisables, Conflictuel, …)
(documents/logiciels) • Use-Cases

ENSI – II2
Expression des besoins

Validation des besoins
3.1.3. Gestion des besoins
Les exigences telles que recueillies par l’analyste ont besoin d’être révisées
Produire un rapport:
Qu’est ce qui a été révisé?
Qui a effectué la révision? Cahier
Problèmes décelés?
Actions prises? Détermination Validation & Gestion des
Revues (informelle ou formelle) régulières pendant la formulation des des besoins négociation des besoins Charges
besoins
Revue informelle
discussion simple avec le client
Revue formelle
1. Identification et classification des besoins

groupe important de lecteurs à la fois chez le client et le développeur, dont l’objectif et
d’expliquer au client l’implication de chaque besoin, i.e. pbs pour faire les modifications
nécessaires • Numérotation (séquentielle avec ou sans catégories)
2. Hiérarchisation des besoins
• Un besoin peut se composer d’un ou plusieurs besoins
plus spécifiques, moins abstraits
Exemple 3.1.4. FAST/QFD/JAD/

B1. Le programme doit planifier les activités de l’ascenseur de façon
B1. Les méthodes utilisées relèvent parfois plus des sciences cognitives
efficace et raisonnable. ou sociologiques que de l’informatique.
1.1.. Si l’ascenseur ne contient pas de passager, il devrait demeurer au
B 1.1
rez--de-
rez de-chaussée en attendant la prochaine requête. FAST
1.2. L’ascenseur ne devrait pas modifier le sens de son déplacement s’il
B 1.2.
contient des passagers qui n’ont pas encore atteint leur destination. Développeur Client
B 1.3 ….

ENSI – II2
Cahier
des
Charges
QFD : Maison de la qualité 3.2 Cahier des charges
Un CC doit :
spécifier uniquement les comportements externes du système
spécifier les contraintes de réalisation
être facile à mettre à jour
servir de référence à la maintenance
spécifier les réponses aux événements non désirables
Cahier
des
Charges Exemple: plus de détails sur les besoins
Organisation du CC
de la gestion de bibliothèques
Les exigences formulées dans un CC peuvent être regroupées Livres et Journaux
suivant différents critères:
La bibliothèque contient des livres et des journaux
Même type de stimulation externe
Même catégorie de réponses du système
Livres sont disponibles en plusieurs exemplaires
Même type de caractéristiques du système Quelques livres sont à consulter sur place et les autres peuvent être
Même catégorie d’utilisateurs du système empruntés pour 3 semaines
Même type de fonctions du système Les journaux sont empruntés que par les enseignants
Même catégorie d’objets dans le système Les étudiants ne peuvent pas empruntés plus de 6 livres en même
Dans la pratique, on procède à une combinaison de plusieurs critères temps
mais à des niveaux différents. Les enseignants ne peuvent empruntés plus de 12 livres et/ou journaux
Plusieurs normes (IEEE, DoD, ANSI, ISO, …) en même temps

ENSI – II2
Cahier
des
Charges
Exemple: plus de détails… (suite) Cahier des charges (en général)
Prêt Document de spécification doit contenir :
Le système doit garder une trace des éléments empruntés et retournés Présentation générale du système
Le système doit produire un état des livres empruntés et qui sont en • objectifs, concepts d'utilisation
retard expression complète des fonctions à satisfaire
• du point de vue de l'utilisateur et de l'environnement externe
(Futur) Extension du prêt dans le cas où le livre n’est pas réservé • Hiérarchie des fonctions + description de chaque fonction
Recherche expression des performances exigées
L’utilisateur peut chercher un livre par titre ou auteur(s) • vitesse, précision,…
définition précise des interfaces (Homme-
(Homme-Machine)
L’utilisateur peut sélectionner un livre s’il est disponible
problèmes particuliers relatifs aux données
L’utilisateur peut réserver un livre
Cahier
Cahier des charges des
Charges Standard IEEE/ANSI 830-
830-1993
(organisation possible)
(1) Introduction Table des matières
(2) Environnement physique (équipements, locaux,…) Listes des figures et tableaux
(3) Modèle conceptuel 1. Introduction
Vue à très haut niveau des fonctions du système et de leur relations (par notations
graphiques)
1.1. Objectif du document
(4) Besoins fonctionnels - Décrire le but du présent SRS et l’audience visée
Services fournis à l'utilisateur 1.2. Portée du produit
(5) Besoins non fonctionnels - Identifier le produit à livrer
Contraintes
(6) Besoins en données - Expliquer ce que le produit fera
(7) Informations destinées à la maintenance - Décrire les usages du produit, ses avantages, les bénéfices attendus et/ou les
(8) Glossaire problèmes qu’il résoudra
(9) Index 1.3. Définitions, acronymes et abréviations (glossaire)
1.4. Références (mentionnées dans ce document)
1.5. Aperçu du document
Ce que contient le reste du document

ENSI – II2
Standard IEEE/ANSI 830-

830-1993
830-1993
2. Description générale du produit 2.3. Caractéristiques des utilisateurs

Cette partie décrit les facteurs généraux qui affectent le produit et ses exigences - définir le caractéristiques des utilisateurs auxquels le produit est destiné (niveau de
connaissance, expérience, expertise technique, existence de sous-
sous-catégorie d’usagers)
2.1. Perspective du produit
2.4. Contraintes d’ordre général
- décrire la relation du produit avec son environnement
- décrire les facteurs qui limitent les options de l’équipe de développement
- mettre le produit en perspective par rapport à d’autres produits similaires
en matériel
- mentionner si le produit est autonome ou s’il fait partie d’un système plus large
considérations de sécurité,
- joindre toutes les figures et diagrammes
contraintes au niveau du langage de programmation,
2.2. Vue d’ensemble des fonctionnalités
facteurs organisationnels
- décrire brièvement les fonctions essentielles du produit
2.5. Hypothèses et dépendances
- si possible, produire des représentations graphiques qui résument ces fonctions
et/ou qui montrent leurs interactions - identifier tout facteur ou hypothèse implicite qui, si changé, peut modifier les
exigences
- en particulier, définir les interfaces suivantes:
interfaces utilisateurs, avec le matériel, avec les autres produits
logiciels et interfaces de communication
Cahier
des
Cahier des charges Charges
830-1993
(quelques conseils …)
3. Description détaillée
Cette partie décrit toutes les exigences du produit à un niveau de détail
suffisant pour permettre au concepteur de satisfaire ces exigences et au
testeur de démontrer que les exigences sont respectées Langue naturelle… mais technique
Les aspects suivant doivent être documentés: Faire des phrases courtes
- interfaces externes Éviter le conditionnel, le futur
- Fonctions Éviter les termes ambigus ou subjectifs,…
- Performances requises Parler en termes de rôle plutôt que de personnes
- Bases de données requises
Numéroter les paragraphes si nécessaire
- Attributs et autres propriétés du produit
Utilisation de références précises
- Contraintes sur la conception
- toutes les figures et diagrammes de ces aspects. Éviter les références en avant
Annexes
Index

ENSI – II2
Cahier
des
Charges
Caractéristiques d'un cahier des charges
Correct

Non--ambiguë
Non
• Modifiable
Complet • Traçable, tracé
vérifiable • Indépendant de la Merci…
Cohérent (consistant)

Compréhensible par le client
conception
• Annoté
• Concis
• organisé

ANALYSE ET SPECIFICATION DES BESOINS (A) - 4 Slides

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ANALYSE ET SPECIFICATION DES BESOINS (A) - 4 Slides

Transféré par

Droits d'auteur :

Formats disponibles

GL / Chapitre 3 : Analyse des besoins A.U.

M04a - Expression des besoins

Cours GL-2006 © / YJ & IBH

La résolution d’un problème Sommaire

Prénom - Nom de l’étudiant :……………................. 1

Avant projet Développement

Beaucoup de systèmes existants sont mal utilisés voir

Prénom - Nom de l’étudiant :……………................. 2

Les problèmes potentiels 2. Les Besoins

5- Des capteurs en place devront être utilisés

6- Le système devra être opérationnel dans un an.

Prénom - Nom de l’étudiant :……………................. 3

Type de besoins Différents types de besoins

Besoins fonctionnels Exemples de Besoins fonctionnels

L’usager devra pouvoir de faire une recherche dans soit

Prénom - Nom de l’étudiant :……………................. 4

Complétude et cohérence des requis Besoins non-

Classifications des Besoins non-

Requis de produit Moins maîtrisés que les besoins fonctionnels

Prénom - Nom de l’étudiant :……………................. 5

Exemples de Besoins non fonctionnels Buts et Besoins

Exemples Mesures des requis

Un but de système Vitesse Transactions traitées par seconde

Robustesse Temps de redémarrage après échec

Portabilité Pourcentage d’énoncés qui sont dépendants sur le système cible

Prénom - Nom de l’étudiant :……………................. 6

Interaction des requis Requis de domaines

Ex: Requis du domaine du système de bibliothèque Ex: Système de protection de train

Prénom - Nom de l’étudiant :……………................. 7

Problèmes des requis de domaine Requis de l’usager

Problèmes avec les langages naturels Ex: Requis de bases de données

Prénom - Nom de l’étudiant :……………................. 8

Ex: Requis de la grille de l’éditeur Problèmes de requis

Présentation structurée Requis détaillés de l’usager

Prénom - Nom de l’étudiant :……………................. 9

Principes directeurs pour l’écriture de requis Caractéristiques des besoins

3. Analyse des besoins Le rôle de l’analyse des besoins

Prénom - Nom de l’étudiant :……………................. 10

Principes de l’analyse 3.1 Le processus d’analyse des besoins

Détermination A. Expression des besoins

Raffinement Spécifications A//B ou A;B

Expression des besoins : Expression des besoins

Prénom - Nom de l’étudiant :……………................. 11

Expression des besoins

Exemple 3.1.4. FAST/QFD/JAD/

Prénom - Nom de l’étudiant :……………................. 12

Prénom - Nom de l’étudiant :……………................. 13

Prénom - Nom de l’étudiant :……………................. 14

Standard IEEE/ANSI 830-

2. Description générale du produit 2.3. Caractéristiques des utilisateurs

Prénom - Nom de l’étudiant :……………................. 15

Prénom - Nom de l’étudiant :……………................. 16

Vous aimerez peut-être aussi