Contribution à l’évolution des exigences et son impact sur la sécurité

Les objectifs de l’ingénierie des exigences 

Ci-dessous, nous allons présenter les objectifs des processus de l’ingénierie d’exigences: • L’identification des parties prenantes, • L’éliçitation des exigences, • L’analyse des exigences • La formalisation des exigences, • La vérification/ validation des exigences, • La modification des exigences. 

 L’identification des parties prenantes 

Selon [GIB-04], on remarque qu’il faut identifier les parties prenantes du système avant de le développer, C’est à dire autrement la connaissance des personnes liées au développement du système. Alors, lorsqu’on commence à exécuter le processus d’identification des parties prenantes, on répond explicitement à la question suivante: Qui fait Quoi ? Plusieurs définitions existent dans la littérature pour expliquer la signification des parties prenantes, mais pour faciliter la compréhension on peut dire que : les parties prenantes signifient l’ensemble des personnes ou des groupes qui sont mises en relation avec un produit au cours de son cycle de vie. Parmi les parties prenantes on peut rencontrer: le développeur, le vérificateur, le concepteur, les clients, le fournisseur, etc.

 L’élicitation des exigences

 Après l’identification de toutes les parties prenantes, il faut exécuter le deuxième processus de l’ingénierie d’exigences qui est le processus d’élicitation d’exigences4 [SAH-02a]. La majeure partie de l’effort dans le cycle du développement des systèmes n’entre pas dans le processus d’écriture d’exigences (vue la diversité des technologies existantes), mais dans le 4 Eliciter : expliquer, capturer, rendre explicite, et permettre la compréhension de l’information. OBJECTIF DE L’IE Modifier les exigences Identification des parties prenantes Élicitation des exigences Analyse des exigences Modification des exigences Vérification t et validation d exigences Impact du modification formalisation des exigences des / Chapitre I- Introduction de la Problématique -18- processus de découverte, en essayant de répondre à la question “qu’est ce que doit faire le système?” et non pas “comment faut-il le faire ?”. Ce processus de découverte et d’élicitation des exigences est souvent vu par beaucoup de chefs de projets comme trop laborieux, trop long, ou trop difficile à entreprendre. Il est quelque fois négligé comme si les exigences sont déjà présentes, et qu’il suffit de les exprimer. Mais, si les exigences sont intangibles, contradictoires, ou imprécises, il devient très difficile d’estimer le temps qu’il faut dépenser durant la conception et l’implémentation. Actuellement, plusieurs approches existent pour faciliter l’exécution de ce processus. Les travaux de C.Coulin [COU-05a] [COU-5b], ont porté sur cet aspect de manière spécifique et le développement d’un outil correspondant, MUSTER [COU-05c]. Mais ce n’est pas un processus automatique, et les exigences ne seront présentées qu’avec le langage naturel. La plupart des chercheurs pensent que ce processus doit obligatoirement contenir deux types de méthodes : Brainstorming (séance de réflexion) et Interview. 

A) Brainstorming

La première méthode d’élicitation des exigences, est la séance de réflexion ou brainstorming. En effet, cette méthode est une manière efficace d’inventer, car c’est un moyen pour obtenir des idées intéressantes, et claires. Pour que la session soit efficace, la plupart des chercheurs dans le domaine de l’ingénierie des exigences indiquent qu’il faut d’abord préciser l’objectif de la session [ROB-04], puis regarder des exemples des produits semblables. Durant la session il faut numéroter les idées pour que les participants puissent se référer à elles facilement, les expliciter, chaque idée de n’importe quel participant peut être intéressante, mais il faut toujours que les idées servent l’objectif final de la session. Dans [ROB-04] ils ont précisé l’importance d’utilisation des tableaux, des papiers, la numérotation de toutes les idées. Et, ils ont suggéré que dans ce type de session, parfois l’écriture des idées sur des tableaux sera beaucoup plus efficace que l’utilisation des écrans d’ordinateurs, car il est plus intéressant que chaque participant puisse regarder toutes les idées produites. 

B) Interview

La deuxième méthode d’élicitation des exigences est les interviews. Cette méthode est très répandue dans le milieu industriel, car l’application de cette méthode n’exige pas beaucoup de temps comme la séance de réflexion présentée ci-dessus, vu que la plupart des personnes qui Chapitre I- Introduction de la Problématique -19- utilisent cette méthode sont des spécialistes d’analyse commerciale ou des ingénieurs des exigences qui sont déjà familiers avec ce type de méthode. 

 L’analyse des exigences

 Après l’exécution du processus d’élicitation. Il faut lancer le processus d’analyse d’exigences en étudiant l’ensemble des exigences soumis par les parties prenantes pour les analyser, les compléter, les arranger, les tracer, et pour éliminer l’ambiguïté et la redondance entre les exigences [MAC-01]. Tous cela pour obtenir à la fin un document cohérent, qui sera présenté en langage naturel (contenant parfois des diagrammes d’UML5 ). En fait, ce document définit les exigences que devra respecter le système qu’il faut réaliser selon le point de vue du maître d’ouvrage6 , mais après une validation par le maître d’œuvre7 . La spécification présentée dans ce document définit complètement le problème auquel les activités de conception devront apporter une solution, son importance est capitale car elle engage directement la quasi-totalité du coût du système. C’est souvent à ce niveau, que le projet joue un rôle en termes de rentabilité pour le maître d’œuvre, et en termes de satisfaction pour le maître d’ouvrage. Les échecs au niveau du projet sont le plus souvent dus à une spécification non figée conduisant à des nombreuses remises en cause. Les échecs au niveau de la mise en œuvre sont presque toujours dus à une spécification inadéquate, et à une mauvaise exécution de ce processus. Enfin, ce processus est le processus le plus critique pour tout au long du cycle du développement du système. Ce n’est pas du point de vue sécurité qu’il est critique, mais c’est à ce niveau qu’il faut détecter la majorité des erreurs de développement. En fait, après ce processus, les développeurs s’engagent pour lancer effectivement le développement du système. Alors, on peut en conclure que, plus la qualité de ce processus sera prise en considération plus la qualité du produit sera améliorée.