MODULE No 7

Titre : Pourquoi ces champs-là ?

But : Expliquer les raisons qui ont poussé l’auteur à introduire ce type de champs dans la fiche des exigences

Antécédents : Module 6 et avoir commencé le TP

Corps

Ce module est introduit pour essayer de vous convaincre que tous les champs répondent à un besoin spécifique dans un cadre d’ingénierie des exigences. Ce qui ne veut pas dire que ce soit la seule manière de faire (ni, sans doute, la meilleure).

Note Complément au module 6 Fin de la note

Pourquoi ?

ID (Identificateur) : Pour pouvoir identifier l’exigence de manière unique à l’intérieur d’un projet. C’est la « clef » qui permettra de faire des recherches dans la base de données des exigences (quand elle existe). S’il n’y a pas de base de données des exigences… c’est une approche inacceptable.

Prj (Projet) : Pour « situer » l’exigence dans l’entreprise. Une même exigence peut être réutilisée dans un autre projet dans lequel elle peut commencer une nouvelle vie. Pour les exigences communes à plusieurs projets dans une entreprise on va définir un projet fictif, comme par exemple « commun »,

Titre : Un nom ou un syntagme qui donne une première idée de l’exigence. Nécessaire car l’identificateur est utile pour la classification et les recherches dans la base de données mais n’est pas très utile pour les humains.

But : Permet de se situer et d’encadrer l’exigence par rapport aux « intentions » des parties prenantes. Attention : ce n’est pas une simple copie du titre : il s’agit d’une phrase, une phrase courte mais une phrase.

Utilisateur : Permet d’identifier les personnes qui sont le plus concernées per le fonctionnement du système. Il ne s’agit pas d’instances de personnes mais de rôles (voir la fiche 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).

Permet de classifier les exigences et donc de le traiter différemment. Le fait que les exigences de qualité (toutes celles qui ne sont pas fonctionnelles) soient classifiées à leur tour en sept (7) catégories, facilite le travail de ceux qui spécifient (s’ils oublient certaines qualités… c’est parce qu’ils l’ont voulu)

Nec (Nécessité) : Pour aider le gestionnaire de projet à établir les impacts sur la livraison du produit de l’absence de l’exigence. Attention : souvent on a la tendance à considérer toutes les exigences comme très nécessaires.

Pri (Priorité) : Pour aider le gestionnaire de projet à établir l’échéancier. « Nécessité » et « priorité » forment un tout du point de vue de la gestion de projet. La priorité est souvent une priorité de développement qui pourrait ne pas avoir un impact sur la livraison.

Sta (Stabilité) : Permet de faire la mise en œuvre avec un certain degré de confiance dans le fait qu’il n’y aura pas trop (ou il y aura trop !) de changements.

Note. Nec, Pri et Sta sont des éléments importants surtout pour la gestion de projet. Le choix de l’ordre de mise en œuvre des exigences dépend de l’approche du gestionnaire de projet. À titre d’exemple : mettre en œuvre en premier les exigences les plus stables permet de développer par itérations autour d’une base solide et donc de faciliter la croissance du système suite à des « changements d’idées » des clients ou des utilisateurs. Fin de la note

Package : Permet de grouper les exigences pour en faciliter la gestion. Important surtout pour de gros projets.

Or (Origine) : Permet de savoir où aller chercher les informations quand on a des doutes sur une exigence ou quand on a besoin de clarifications.

Der (Dérivées) : Permet d’organiser une exigence en plusieurs parties (comme des procédures dans un programme) quand l’exigence est trop complexe.

Ea (Élément d’analyse) : Permet de relier la fiche à d’autres documents qui traitent d’autres facettes de l’exigence ou qui montrent d’autres artefacts de l’ingénierie des exigences qui facilitent la compréhension.

Ec (Élément de conception) : Permet de relier l’exigence aux modules (aux classes) qui structurent l’application. Champs très important pour « suivre à la trace » l’exigences et savoir quoi modifier quand l’exigence change (traçabilité).

Test (Cas à tester) : Permet de connaître comment l’exigence sera testée ce qui aide aussi à mieux comprendre l’exigence. « Dis-moi comment tu testes et je te dirai ce que tu testes. »

Aide : Permet de lire l’aide en ligne pour mieux comprendre l’exigence. Ce champs comme le champ « test » force, d’une certaine façon, à écrire le cahier des essais et le guide d’utilisateur en même temps que la SEL.

Antécédents : Pour définir les limites au-delà desquelles la description n’est plus valable. Ne s’applique qu’aux exigences fonctionnelles.

Intrants : Pour comprendre ce dont l’exigence a besoin pour « faire » ce que la description dit qu’elle « fait ». Ne s’applique qu’aux exigences fonctionnelles. Lorsque l’on a une « classe » comme intrant on ne la détaille pas : on ne mets que son nom. Le champs Ea permet d’atteindre la classe.

Description : Pour… pour la décrire. La description n’est pas le but !

Conséquents : Pour faciliter l’écriture des tests et la validation de l’exigence. Ne s’applique qu’aux exigences fonctionnelles.

Conflits : Pour que l’on sache qu’il y a des risques d’incohérences et qu’un jour ou l’autre il faudra trouver une solution. Attention au danger de régler tout de suite les conflits.

Documents (documents pour le détail) : Pour ne pas tout écrire dans la fiche quand d’autres documents existent.

Raisons : Pour que les lecteurs puissent bien saisir la place de l’exigence dans le cadre du projet (surtout si on considère les raisons et le but en même temps),

Questions : Permet de faire évoluer l’exigence de manière interactive,

V. (Version) : Version de l’exigence. Date : date de la modification. Aut. (Auteur) : auteur A (Action) : Pour faire un suivi de la fiche.

Voici un exemple de fiche remplie d’Hydro-Québec (légèrement modifiée par rapport à votre gabarit).

Prj : SCALCID
GF : E-Norm.Com		No : 010	Titre. : Gestion lnClass
But : Permettre la création, la modification et la suppression des classes de NL (lnClass)
Utilisateurs : Normalisateur IEC et Normalisateur HQ
Type : Fo		Nec : 1	Pri : 1		Sta : 3
Or : À Venir			Der : À Venir
Ea : -			Ec : -
Test : À Venir			Aide : ln_Class aide
Antécédent : Les CDC doivent avoir été saisis
Intrants : Voir le prototype
Description : Un utilisateur ayant les privilèges lui permettant de modifier les lnClass doit pouvoir mettre à jour SCALCID en fonction de l’évolution de la norme IEC et/ou de la normalisation HQ. Il est fort probable qu’après une période initiale il y aura très peu d’ajouts ou de suppression de lnClass, par contre il est probable qu’il y aura des modifications. SCALCID doit permettre à l’utilisateur d’entrer les données manuellement ou en lisant des fichiers préparés hors ligne, par les normalisateurs, par exemple. La fréquence de création/suppression/modification des lnClass d’HQ est plus élevée que celle de la norme IEC. La nécessité d’une lecture de fichiers externes est donc moins forte que pour les lnClass IEC. Pour les fonctions à mettre en œuvre voir le prototype : 1. Partie IEC : menu Partie 7, sous-menu -4, item lnClass IEC 2. Partie HQ : menu Gestion des types, item lnClass d’Hydro Pour la suppression il y a des contrôles additionnels (voir E-Base.Tous.020)
Conséquents : Voir le prototype
Conflits : Aucun
Documents : aucun
Raisons : Pouvoir valider les ICD des constructeurs et générer des spécifications pour les IED normalisés d’HQ.
Questions temporaires : vaut-il la peine de prévoir une mise à jour en partant de fichiers une fois que la base de données a été peuplée ?
V. : 0.1	Date : 07-04-30			Aut. : I.M.		A : Création

Conséquent : Être un peu plus convaincus de l’utilité des fiches.

Note 01 :