MODULE No 06

Titre : Fiches : pourquoi ?

But : Justifier les différents champs des fiches (problèmes, besoins et exigences) par rapport aux exigences du génie des exigences

Antécédents : Avoir travaillé avec des fiches

Corps :

Les fiches sont un moyen pour mieux structurer l’information et empêcher d’oublier certains éléments essentiels.

La figure suivante présente les fiches employées pour les exigences dans le cadre de la méthode ER (Extreme Requirements).

Une Fiche_Problème a 0 ou plusieurs Fiche_Besoins et une Fiche_Besoins a une ou plusieurs

Fiche_Problème. Même si un besoin peut être décrit sans connaître le ou les problèmes qui en sont à l’origine, normalement un besoin est une conséquence de un ou plusieurs problème. Il est important de souligner que souvent problème et besoin sont à des niveaux d’abstraction différents. Un problème est presque toujours du genre : à la date x, la personne y, n’a pas eu ce qu’elle s’attendait étant donné les conditions dans lesquelles elle agissait. Dans le besoin la date x et la personne y disparaissent pour faire place à une formulation plus abstraite.

Une Fiche_ Besoins a 0 ou plusieurs Fiche_Exigences et une Fiche_ Exigences a une ou plusieurs Fiche_ Besoins. Une Fiche_ Exigences a 0 ou plusieurs Fiche_ Exigences dérivées. Une Fiche_ Exigences a des Fiche_ Raison et a des Fiches_Rôles. Dans la méthode ER on fait l’hypothèse que les besoins et les problèmes, contrairement aux exigences n’ont pas de parties. Ce qui implique qu’une fiche décrit complètement un problème ou un besoin. Les exigences dérivées sont l’équivalent des exigences dérivée de SysUML.

Les Fiche_Besoins et les Fiche_Exigences ont 0 ou plusieurs Descr_CUs. Un Descr_CU a ou une ou plusieurs Fiche_Besoins ou a une ou plusieurs Fiche_ Exigences. Une Descr_CUs a une Fiche_CUs et une Fiche_CUs a une Descr_CU

Une Descr_CUs a 0 ou plusiseurs Diag_Seq_Sys et une Diag_Seq_Sys a 0 ou plusieurs Descr_CU.

Fiche_Problèmes.

Structure

N^o. PR-	Application / machine :
Contexte :
Signalé par :		Date (Problème) :
Concerne :		Importance :
Description :
Commentaire:
Date (Fiche) :	Auteur :

Description des éléments

Nom	Description (O) obligatoire (F) Facultatif	Justification
No	Un numéro unique qui identifie le problème. Il faut compléter en respectant le format : PR-nnnn, où n est un chiffre décimal. (O)	Pour faciliter la gestion dans une base de données.
Application/Machine	Le nom et la version de l’application ou/et de la machine. S’il n’y a pas de système informatique existant, il faut indiquer « aucun ». (F)	Permet d’associer le problème à une machine bien définie.
Contexte	Le contexte dans lequel le problème a surgi. Peut contenir « Inconnu ».	Ce champ avec le champ « Applicatio/Machine » établit le contexte précis dans lequel le problème a été ressenti (trouvé).
Signalé par	Il faut spécifier la personne ou le groupe de personnes qui a signalé le problème. (O)	Permet de remonter à l’origine du problème pour éventuellement avoir plus de détails.
Date (problème)	Data à laquelle le problème a été trouvé. (F)	Utile pour la gestion de projet et le calcul des temps nécessaire pour passer du problème à la description détaillée ou au code.
Concerne	Il faut spécifier la personne ou le groupe de personnes concerné par le problème. (O)	Important lorsque la personne qui signale le problème n’est pas la même qui en est concerné. Ce champ permet d’aller à la « vraie » origine.
Importance	Le niveau d’importance de sa satisfaction. Peut valoir : énorme, grande, moyenne, petite, non définie. (O)	Permet de créer des priorités.
Description	La description du problème. (O)	Pour que les humains comprennent.
Commentaire	Commentaire (F)	Pour présenter des éléments qui favorisent la compréhension du problème.
Date (Fiche)	La date de création/modification de la fiche (O)	Pour faciliter la gestion des fiches.
Auteur	L’auteur de la fiche (O)	Pour connaître la personne à laquelle s’adresser.

Fiche_Besoins.

Structure

N^o. B-		Id. projet :
Ressenti par :
Depuis :				Importance :
Déclencheur :				N^o problème :
Conflits :
Description :
Commentaire:
Version :	Date :		Auteur :

Description des éléments

Nom	Description (O) obligatoire (F) Facultatif	Justification
No	Un numéro unique qui identifie le besoin. Il faut compléter en respectant le format : B-nnnn, où n est un chiffre décimal. (O)	Pour faciliter la gestion dans une base de données.
Id projet	L’identificateur unique du projet.	Pour la gestion dans une base de données.
Ressenti par :	Il faut spécifier la personne ou le groupe de personnes qui ont ce besoin	Permet de remonter à l’origine du besoin pour éventuellement avoir plus de détails. Si le besoin est une conséquence d’un problème alors on a aussi le champ No problème.
Depuis	Il faut spécifier depuis combien de temps le besoin est ressenti. Il faut écrire « Inconnu » si l’on cette information n’est pas disponible. Il n’est pas nécessaire que l’intervalle soit précis. Des formules comme « depuis toujours », « depuis le changement des ordinateurs », etc. sont acceptables. (O)	Utile pour la gestion de projet pour connaître depuis combien de temps le besoin existe sans qu’il soit décrit dans une fiche.
Importance	Le niveau d’importance de sa satisfaction. Peut valoir : énorme, grande, moyenne, petite, non définie. (O)	Permet de créer des priorités.
Déclencheur	Il faut spécifier l’événement déclencheur du besoin. Il faut écrire « Inconnu » si on n’en connaît pas. (O)	Pour connaître l’événement ce qui a transformé le problème en besoin.
Description	La description du besoin. (O)	Pour que les humains comprennent.
N^o problème	Il faut spécifier le numéro du problème associé. Peut valoir « aucun ». (O)	Pour la traçabilité.
Conflits	Il faut spécifier les groupes ou les personnes qui se trouvent en conflit sur ce besoin. Il faut écrire « Aucun » si tout le monde est d’accord (O)	Favoriser la discussion entre les parties-prenantes.
Commentaire	Commentaire (F)	Pour mieux comprendre le besoin.
Date (Fiche)	La date de création/modification de la fiche (O)	Pour faciliter la gestion des fiches.
Version	Version de la fiche (O)	Pour suivre l’évolution du besoin.
Auteur	L’auteur de la fiche (O)	Pour connaître la personne à laquelle s’adresser.

Fiche_Exigences.

Structure

ID^o :		Prj. :				Titre. :
But :
Utilisateurs :
Type :	Nec. :		Sta :	Pri. :		Pack :
Or : ID				Der : ID
Ea : ID				Ec : ID
Test : ID				Aide : ID
Antécédent :
Intrants :
Description :
Conséquents :
Conflits :
Documents :
Raisons :
Questions temporaires :
V. : n.n		Date : aa-mm-jj			Aut. : xxxx.		A : xxxx

Description des éléments

Nom	Description (O) obligatoire (F) Facultatif	Justification
ID (Identificateur)	Identificateur unique. La structure doit être définie dans chaque entreprise. Unique au niveau du projet ou de l’entreprise	Pour faciliter la gestion dans une base de données.
Prj (Projet)	L’identification du projet (unique dans l’entreprise).	Pour faciliter la réutilisation inter-projet des « projets » entreprise peuvent être définis.
Titre	Le titre (nom) de l’exigence.	Pour faciliter les échanges entre les parties prenantes.
But	Les objectifs que l’exigence doit satisfaire.	Pour « encadrer » l’exigence et mieux évaluer son utilité.
Utilisateur	L’utilisateur concerné par l’exigence.	Pour faciliter la validation (Fiches des rôles).
Type	Peut être : Fo (fonctionnel) Pe (performance) Ut (facilité d’utilisation), Se (Sécurité), Su (Sûreté), Fi (Fiabilité), Di (disponibilité), Te (Test), Au (qualité autre).	Pour catégoriser l’exigence et faciliter ainsi la validation.
Nec (Nécessité)	Peut valoir 1, 2 ou 3. La nécessité max. est 1.	Pour faciliter la gestion de projet. Décider dans quelle version insérer une exigence.
Sta (Stabilité)	Peut valoir 1, 2 ou 3. La nécessité max. est 1.	Pour faciliter la gestion de projet. Permet d’appliquer la méthode Extreme Requitements.
Pri (Priorité)	Peut valoir 1, 2 ou 3. La priorité max. est 1.	Pour faciliter la gestion de projet. Donne l’ordre d’intégration des fonctions. Permet de gérer la priorité indépendamment de la nécessité.
Pack (package)	Indique le package dans lequel l’exigence est insérée.	Pour faciliter la gestion des exigences. Pour grouper les exigences et faciliter la livraison.
Or (Origine)	La personne ou le document (fiche) qui est à l’origine de l’exigence. Si le champ contient « copie », l’exigence ne peut pas être modifiée (elle est une copie d’une exigence original qui, elle, peut être modifiée).	Pour la traçabilité.
Der (Dérivées)	Les exigences dérivées de celle-ci	Pour structurer les exigences dans une relation de tout-partie.
Ea (Élément d’analyse)	Les numéros des éléments d’analyse (CU, diagrammes UML, prototypes, autres exigences, etc.) reliés à cette exigence	Pour améliorer la compréhension.
Ec (Élément de conception)	Les numéros des éléments de conception (classe, sous-système, etc.) reliés à cette exigence,	Pour la traçabilité en avant.
Test (Cas à tester)	Renvoi aux cas à tester pour vérifier si l’exigence est satisfaite.	Pour faciliter la validation.
Aide	Renvoi aux fichiers d’aide ou aux tutoriels	Pour mieux intégrer l’aide à l’application.
Antécédents	Les conditions qui doivent être « vraies » afin que la « fonction » accomplisse ce qu’elle doit. (Seulement pour exigences fonctionnelles).	Pour la validation et la clarification du contexte.
Intrants	Les types des objets que la fonction reçoit du monde extérieur. (Seulement pour les exigences fonctionnelles).	Faciliter la compréhension (lien avec les diagrammes conceptuels)
Description	La description détaillée de l’exigence. Elle peut renvoyer à un prototype	Permettre de comprendre le détail de l’exigence.
Conséquents	Les conditions qui doivent être « vraies » après la fonction. (Seulement pour les exigences fonctionnelles.)	Faciliter la validation.
Conflits	Les exigences en conflit avec celle-ci	Favoriser la discussion entre les parties-prenantes. Ce qui n’implique pas que le conflit doit être réglé tout de suite.
Documents (documents pour le détail)	Les documents ou le chapitre de documents qui contiennent des détails utiles pour comprendre l’exigence.	Ne pas écrire ce qui est déjà écrit (souvent avec un grand détail).
Raisons	Raisons qui justifient l’introduction des exigences ou les liens avec d’autres éléments (Ec, Test, Ea). Il existe une fiche des « raisons » dotée d’un numéro, un corps et des liens avec les éléments qu’elle justifie	Empêcher des discussions inutiles (ou presque).
Notes/Questions	Notes temporaires ou questions à propos de l’exigence auxquelles il faudra répondre	Faciliter le dialogue
Date	La date de création/modification de la fiche (O)	Pour faciliter la gestion des fiches.
V. (Version)	Version de la fiche (O)	Pour suivre l’évolution de l’exigence.
Aut. (Auteur)	L’auteur de la fiche (O)	Pour connaître la personne à laquelle s’adresser.
A (Action)	Ce qui a été fait (création, ajout, suppression, modification).	Pour mieux connaître l’évolution de l’exigence.

Caractéristiques des champs de la fiche des exigences fonctionnelles

Champ	Oblig.	Valeur par défaut	Commentaire
ID	Oui	Non
Prj	Oui	Non
Titre	Oui	Non
But	Oui	Non
Utilisateur	Oui	« Tous »
Type	Oui	Non	Choix dans une liste
Nec	Oui	« 3 »	Choix dans une liste
Sta	Oui	« 3 »	Choix dans une liste
Pri	Oui	« 3 »	Choix dans une liste
Package	Non	Non
Or	Oui	« À venir »
Der	Non	Non
Ea	Non	Non
Ec	Non	Non
Test	Oui	« À venir »
Aide	Non	« Inconnu »
Antécédents	Oui	« Aucun »
Intrants	Oui	« Aucun »
Description	Oui	Non
Conséquents	Oui	Non
Conflits	Non	« Aucun »
Documents	Non	« Aucun »
Raisons	Non	« Non explicitées »
Question	Non	« Aucune »
Date	Oui	Date de l’écriture
Auteur	Oui	« Aucune »	Préférablement choix dans une liste
Action	Oui	Création	Choix dans une liste

Conséquents : Avoir une bonne connaissance des fiches des problèmes, des besoins et des exigences.

Notes :

· Travail avec les fiches dans le cadre des TP.