SEG 3501 Module 4 Validation vrification et triage

SEG 3501 - Module 4 Validation, vérification, et triage des exigences «SEG 3 501» D. Am u. Otta yot wa Basé en partie sur du matériel de K. E. Wiegers, D. Leffingwell & D. Widrig, P. Heymans, I. K. Bray, I. Sommerville, D. Berry, J. Atlee, B. Selic, B. Regnell, G. Mussbacher, G. v. Bochmann

Dlibert et la validation… «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 2

Validation et vérification (V&V) • Vérification ― Est-ce que le système est bon? ― Par exemple: absence d’interblocage ou de messages inattendus • Validation ― A-t-on le bon système? ― Satisfaction de l’utilisateur (et exigences) ― Tests fonctionnels & d’acceptance, propriétés «SEG 3 501» D. Am u. Otta • Besoin des deux à toutes les étapes de développement, et particulièrement pendant la spécification des exigences! yot wa Module 4 : Validation et vérification des exigences 3

Analyse vs. V&V d’exigences • Les deux processus ont plusieurs activités communes ― Lecture d’exigences, découverte de problèmes, rencontres et discussions… • Mais les entrées sont différentes: ― Analyse et négociation: brouillon du document d’exigences, exigences incomplètes, emphase sur « avons-nous les bonnes exigences » ― V&V: spécification d’exigences (supposément complètes), emphase sur « avons-nous les bonnes exigences bien faites » «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 4

Techniques variées pour V&V • • • Vérifications simples Prototypage Conception de tests fonctionnels Révision formelle Analyse logique ― V&V à base de machines à état The software is done. We are just trying to get it to work… «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 5

V&V: Vérifications simples • Exemple: ― Une fois le document d’exigences complété, vérifier si les notes d’élicitation ont été couvertes adéquatement ― Une fois la spécification des exigences complétée, vérifier si toutes les exigences analysées ont été traitées. ― Utilisation d’une matrice de traçabilité ― Vérifier que les exigences soient bien formulées (selon les critères déjà vu). «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 6

V&V: Prototypage • Excellents pour la validation auprès des utilisateurs et des clients ― Plus accessible qu’une spécification • Peut varier en format ― De prototypes papier à un système informatisé, en passant par des modèles formels exécutables • Important de bien choisir les scénarios ou cas d’utilisation à parcourir «SEG 3 501» ― Bonne couverture, pas juste aléatoire D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 7

V&V: Conception de tests fonctionnels • Les tests fonctionnels au niveau du système doivent être conçus tôt ou tard… • Peuvent (et devraient) être dérivés de la spécification des exigences • Concevoir ces tests peut permettre de révéler des erreurs dans la spécification (avant même de concevoir et de construire le système)! • Certains processus de développement (dans les méthodes dites agiles) commencent avec les tests avant de programmer «SEG 3 501» D. Am u. Otta ― Test-Driven Development (TDD) http: //en. wikipedia. org/wiki/Test-driven_development yot wa Module 4 : Validation et vérification des exigences 8

V&V: Révision formelle • Plusieurs formes: ― Quelques variantes… ― Pré-révision ― Inspection de Fagan ― Révision active • Besoin de listes de contrôle (checklists) appropriées ― Doivent être développées si nécessaire ― Doivent être maintenues «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 9

Révision d’exigences • Un groupe de personnes lisent et analysent les exigences, cherchent des problèmes potentiels, se rencontrent pour discuter des problèmes et s’accordent sur une liste d’actions nécessaire pour les régler. «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 10

Équipe de révision «SEG 3 501» D. Am u. Otta • L’équipe devrait toujours avoir au moins un expert du domaine et un utilisateur • Des participants avec des bagages différents apportent des habiletés et des connaissances différentes • Les intervenants se sentent impliqués dans le processus d’ingénierie des exigences et améliorent leur compréhension des besoins des autres • La présence de participants plus séniors et de plus juniors offre une opportunité de transfert d’expertise. yot wa Module 4 : Validation et vérification des exigences 11

Catégories de problèmes typiques • Clarification d’exigence ― Exigence incorrectement exprimée ou où certaines information recueillies pendant l’élicitation ont été omises • Information manquante ― Des informations typiques sont absentes de la spécification • Conflit d’exigences ― Il y a un conflit significatif entre exigences ― Les intervenants impliqués doivent négocier pour le résoudre • Exigence irréaliste «SEG 3 501» D. Am u. Otta yot wa ― L’exigence ne peut être implémentée avec les contraintes imposées ― Les intervenants doivent être consultés pour décider de la façon de rendre l’exigence réaliste. Module 4 : Validation et vérification des exigences 12

Pré-révision • Les révisions peuvent devenir chères car elle impliquent de nombreuses personnes sur plusieurs heures. • On peut réduire ce coût en demandant à une personne de faire une première passe appelée pré -révision. • Recherche de problèmes évidents tels que section d’exigences manquantes ou non-triées, non-conformité aux standards, erreurs typographiques, etc. «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 13

Révision structurée • Comme pour les sessions JAD et de remueméninges, les sessions de révisions peuvent être plus ou moins structurées, et des rôles peuvent être assignés aux participants. • Plusieurs variantes existent: «SEG 3 501» D. Am u. Otta yot wa ― Lecture simple – Par une personne autre que l’auteur du document! ― Lecture et approbation (sign-off) – Encourage le lecteur à être plus soigné (et responsable) ― Inspection formelle – Qui fait quoi, préparation, condition de sortie – Inspection de Fagan – Révision active Module 4 : Validation et vérification des exigences 14

Inspection de Fagan Processus d’inspection structuré et formel «SEG 3 501» D. Am u. Otta yot wa Note: le patron n’est pas impliqué dans ce processus! Module 4 : Validation et vérification des exigences 15

Inspection de Fagan • Nouvelle inspection si >5% de modification «SEG 3 501» ― Certains sont moins tolérants… Trop facile d’introduire de nouvelles erreurs en corrigeant les précédentes! ― La rencontre d’inspection est un peu comme un remue-méninge pour trouver des problèmes (potentiels). Pas plus de 2 heures à la fois, pour garder les participants frais! ― Des métriques sont recueillies ― Important: le patron ne participe pas à l’inspection, et n’a pas accès aux données – Ce n’est pas une évaluation des employés. D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 16

Révision active • Demandez au réviseur d’utiliser la spécification! • L’auteur pose au réviseur des questions auxquelles il ne pourra répondre qu’après avoir lu la spécification. • Il peut aussi demander aux lecteurs de simuler un ensemble de scénarios «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 17

Révision active «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 18

Listes d’inspection • Des listes de critères peuvent être utilisées pour guider les participants. Elles peuvent contenir des questions sur plusieurs aspects de la qualité du document ― Compréhensibilité, redondance, complétude, ambigüités, cohérence, organisation, conformité aux normes, traçabilité… • Voir les exemples sur le site Web du cours «SEG 3 501» D. Am u. Otta yot wa ― Exemple de liste simple ― Exemple de liste complexe (NASA) ― Autres exemples dans la partie privée du site Module 4 : Validation et vérification des exigences 19

Bénéfices et risques des inspections • Bénéfices: ― Très efficaces, pour un coût minime ― Trouve les causes des erreurs (et non seulement leurs symptômes) ― Les auteurs écrivent des exigences en s’attendant à ce que d’autres lisent – On prend de bonnes habitudes! ― Expliquer quelque chose aide à la comprendre ― Tout le monde devient familier avec le document (buyin) ― Encourage le passage de connaissances et l’adhérence aux standards • Risques: «SEG 3 501» D. Am u. Otta yot wa ― Problèmes de personnalités ― Politique de bureau, guerres saintes ― Les inspections sont épuisantes Module 4 : Validation et vérification des exigences 20

V&V: Analyse logique • Besoin d’une spécification formelle (Z, VDM, FSM, UML profilé, LOTOS, réseaux de Petri, etc. ) • Les techniques de V&V disponibles vont varier d’un formalisme à l’autre ― Par exemple, avec les FSM (ou SDL), nous pouvons: – Vérifier que toutes les transitions sont atteignables et qu’elles ne mènent pas à des interblocage – Que chaque transition n’a qu’un seul événement déclencheur (pas de non-déterminisme) – Que chaque événement déclencheur va être reconnu par le système – Etc. «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 21

V&V basée sur machines à états • Plusieurs alternatives possibles, qui dépendent des formalismes et outils utilisés «SEG 3 501» ― Simulation – On laisse le comportement se développer plus ou moins au hasard – Peut être interactif ― Test – On vérifie que certaines traces sont supportées (ou refusées) par la machine ― Vérification de propriétés standards – Tous les états sont atteignables et toutes les transitions sont traversables – Absence d’événement non-traités dans chaque état – Absence d’impasses (dans les machines communicantes) D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 22

V&V basée sur machines à états «SEG 3 501» D. Am u. Otta ― Vérification de conformité – Entre deux machines (par exemple, l’une abstraite et l’autre plus concrète) – Réduction du non-déterminisme – Réduction des comportements optionnels (conforme, mais certains comportements ne sont pas supportés) – Extension (conforme, mais certains nouveaux événements sont traités et mènent à de nouveaux comportements) ― Vérification d’équivalence – Entre deux machines (par exemple, l’une abstraite et l’autre plus concrète) – Plusieurs niveaux d’équivalences: traces, refus, tests, congruence, équivalence observationnelle forte… yot wa Module 4 : Validation et vérification des exigences 23

V&V basée sur machines à états ― Vérification de modèles (model checking) – Vérification de propriétés logiques (exprimées séparément). Par exemple: - Si A survient, éventuellement B pourrait se produire - Si C survient, D se produira toujours – Traverse systématiquement tous les comportements possibles de la machine - Générés à l’avance ou à la volée ― Preuves par théorèmes – On prouve par déduction ou autre approche formelle que certaines propriétés découlent de la machine à états «SEG 3 501» D. Am u. Otta yot wa - Souvent, les outils de preuve sont interactifs ― Outils: SPIN, Alloy… Module 4 : Validation et vérification des exigences 24

Conflits et négociation «SEG 3 501» D. Am u. Otta yot wa

Conflits! • Il y a plusieurs types de conflits possibles entre intervenants ― Conflits de sujets, intérêts, valeurs, rôles, structure… ― Conflits entre fournisseurs et clients au niveau des coûts, bénéfices, risques ― Luttes de pouvoirs ― Conflits avec les autres projets au niveau des ressources ― Conflits d’objectifs, fonctionnalités, exigences… ― Cas de mésusages «SEG 3 501» D. Am u. Otta yot wa • En pratique, les causes sont souvent multiples. Module 4 : Validation et vérification des exigences 26

Résolution de conflits • Quelques stratégies possibles: «SEG 3 501» ― Entente ― Compromis ― Votes ― Définition de variantes ― Annulations ― Priorités ― Médiation ― Arbitration ― Analyse de buts (pensez à GRL…) D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 27

Négociation d’exigences • La résolution de conflits implique souvent la négociation d’un ensemble cohérent d’exigences ― Pas facile, mais il s’agit de l’une des tâches de l’analyste en exigences • Premièrement, vous devez détecter quand les exigences utilisateur sont incohérentes. • Ensuite, vous devez convaincre toutes les parties prenantes de comprendre les exigences essentielles du point de vue de l’un et l’autre. • Vous devez arriver à une entente sur un ensemble d’exigences cohérentes qui satisfont le plus possible les parties prenantes. • Il faut enfin documenter la résolution «SEG 3 501» D. Am u. Otta ― Intervenants, alternatives considérées, décision… Pensez à GRL! yot wa Module 4 : Validation et vérification des exigences 28

Laissez les contraintes de temps guider les exigences (et non l’inverse) “Okay, Here Are Our Requirements By When Can You Build Them? ” “Sorry, They Must Be Completed in 6 Months” “It Will Take Us 9 Months” Scénario typique NOW WHAT? «SEG 3 501» D. Am u. Otta yot wa Source: Davis, A. : “Just Enough Requirements Management”, Module 4 : Validation et vérification des exigences 29

Meilleur scénario. . . “Okay, we’re going to build in a series of 3 month increments. Here all the requirements. ” “But we really need reqt 17 in that first release. ” «SEG 3 501» “Let’s see. If we build reqts 1 through 9 and 12, we’ll be able to do them in 3 months” “Okay. How about if we add reqt 17 and drop reqt 12? ” D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 30

Meilleur scénario. . . “Hmmm. I really liked reqt 12. Can we drop reqt 3 instead? . ” “Okay” «SEG 3 501» D. Am u. Otta yot wa “Well if we drop requirements 3 and 4, we could do it. ” “Okay. How about if we add reqt 17 and drop reqt 12? ” Teamwork!!! Module 4 : Validation et vérification des exigences 31

Triage des exigences Basées sur du matériel de Volere, Wiegers, Telelogic, et de D. Damian Objectifs: Pourquoi, difficultés, méthodes! «SEG 3 501» D. Am u. Otta yot wa

Difficultés • Il y a trop d’exigences! • Les budgets, le temps, et les autres ressources sont limités. • Les exigences fusent de partout! ― ― «SEG 3 501» D. Am u. Otta yot wa Lesquelles sont importantes? Pour qui? Comment les prioriser ou en faire le triage? Sur quels critères? À quelle version/phase seront-elles associées? • Les développeurs ne connaissent pas la valeur des exigences demandées • les clients ne connaissent pas la complexité de leur développement… Module 4 : Validation et vérification des exigences 33

Difficultés • Différents intervenants auront différents buts et différentes priorités ― Différents marchés ― Les clients n’ont pas tous le même poids • Les entreprises manquent souvent de données, métriques et techniques systématiques pour supporter le triage ― Souvent fait manuellement, de façon ad hoc ― Difficiles à établir et à communiquer «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 34

Difficultés • Attitude! ― « Pas besoin de priorités, on peut tout faire ce qu’on retrouve dans la spécification! » – Oui mais quand et à quel coût? ― Soudain, alors que l’échéance arrive à grands pas, quelques exigences sont mises de côté pour pouvoir livrer quelque chose à temps… «SEG 3 501» D. Am u. Otta yot wa • Difficile de satisfaire tout le monde, d’atteindre tous les buts fixés, de prendre les bonnes décisions! • Besoins de compromis, de négociation, de priorités… de triage! Module 4 : Validation et vérification des exigences 35

Encore la règle du 80 -20 • 20% des fonctionnalités rapportent 80% des revenus ― Pensez à MS Word. . . • Le 80% de fonctionnalités qui restent ajoutent des délais, des coûts de développement, de maintenance… ― Abaisse le retour sur l’investissement et les bénéfices • Comment trouver ce fameux 20%? ? ? «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 36

Importance du triage • Le triage et l’établissement de priorités au niveau des exigences aident à: «SEG 3 501» ― Rendre acceptables compromis au niveaux des buts de qualité, de coûts, de mise en marché ― Planifier le projet et allouer les ressources ― Déterminer à l’avance à quel moment une exigence sera transformée en quelque chose de livrable (et éviter les surprises de dernière minute) ― Offrir le bon produit! D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 37

Beaucoup! Sur quel secteur se concentrer? R 11 R 10 R 6 R 9 Valeur R 13 R 7 R 3 R 15 R 8 R 14 R 12 R 4 R 5 R 16 «SEG 3 501» D. Am u. Otta yot wa 0 Coût À éviter! Beaucoup! Module 4 : Validation et vérification des exigences 38

Exemple: Volvo Car Corporation «SEG 3 501» D. Am u. Otta yot wa https: //gupea. ub. gu. se/bitstream/2077/1789/1/stenbeck_svensson_0304. 28. pdf Module 4 : Validation et vérification des exigences 39

Processus de triage • Doit être simple et rapide pour être adopté dans un milieu industriel • Offrir des résultats précis et fiables • Considérer des problèmes tels ― La valeur des exigences (à maximiser) ― Le coût d’implémentation (à minimiser) ― Temps de mise en marché (à minimiser) • Important de choisir la granularité des exigences «SEG 3 501» D. Am u. Otta ― Cas d’usage, services, exigences détaillées… yot wa Module 4 : Validation et vérification des exigences 40

1 er exemple de technique: Approche par échelle • Déterminer les critères et la granularité. • Exemple fréquent (utilisés ensemble): «SEG 3 501» D. Am u. Otta yot wa ― Urgence – Haute (critique à la mission, tout de suite) – Moyenne (supporte des fonctions importantes, mais peu attendre si nécessaire) – Basse (serait plaisant à avoir un jour, si les ressources le permettent) ― Importance – Essential (produit inacceptable sans sa présence) – Conditionnelle (pas essentiel mais souhaitable et améliorerait le produit) – Optionnelle (peut être considéré, ou non) Module 4 : Validation et vérification des exigences 41

Approches par coûts et valeurs • Calcule le retour sur l’investissement en: ― Déterminant la valeur de chaque exigence ― Déterminant le coût de chaque exigence ― Calculant le compromis coût-valeur • Difficultés «SEG 3 501» ― Difficile d’obtenir des valeurs et des coûts absolus – Les coûts/valeurs relatifs sont plus simples à obtenir – Les exigences interdépendantes sont difficiles à gérer individuellement – Les incohérences et les conflits sont assignés par des parties prenantes individuelles D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 42

2 e exemple de technique • Technique semi-quantitative de Wiegers inspirée de la méthode Quality Function Deployment (QFD) • Estimation des bénéfices, des pénalités, des coûts d’implémentation et des risques techniques relatifs (avec poids) pour chaque exigence/service • Priority=(value%) / ((cost% * cost weight) + (risk% * risk weight)) «SEG 3 501» D. Am u. Otta yot wa • Encore limitée par les capacités à bien estimer! Module 4 : Validation et vérification des exigences 43

Exemple pour un Chemical Tracking System «SEG 3 501» D. Am u. Otta yot wa Source: Wiegers, Karl E. , First Things First: Prioritizing Requirements, http: //www. processimpact. com/articles/prioritizing. html Module 4 : Validation et vérification des exigences 44

Autres critères à considérer • Les coûts et bénéfices, c’est bien, mais c’est parfois insuffisant • Les critères suivants ne sont pas tous applicables à tous les projets, mais nous pouvons considérer: ― ― ― «SEG 3 501» D. Am u. Otta yot wa Minimisation des coûts d’implémentation Valeur aux yeux du consommateur Temps d’implémentation Facilité d’implémentation au niveau technique Facilité d’implémentation au niveau organisationnel (processus d’affaires) ― Valeur aux yeux de l’entreprise ― Obligation envers des autorités externes (lois, normes et autres) Module 4 : Validation et vérification des exigences 45

«SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 46

3 e exemple de technique: Volere (tableau Excel éditable, semblable à la 2 e) «SEG 3 501» D. Am u. Otta yot wa Source: Volere Prioritisation Analysis, http: //www. volere. co. uk/prioritisationdownload. htm Module 4 : Validation et vérification des exigences 47

4 e exemple de technique: PAH • Processus d’analyse hiérarchique (PAH, AHP en anglais), pour déterminer les valeurs et coûts relatifs des exigences [Karlsson et Ryan, 1997], [Saaty 1970] ― Algorithmes et concepts mathématiques: http: //en. wikipedia. org/wiki/Analytic_Hierarchy_Process «SEG 3 501» D. Am u. Otta yot wa • Utilisation de diagrammes de coûtsvaleurs (p. ex. Rational Focal Point) pour analyser et discuter des exigences candidates • Utile pour les gestionnaires, mais l’usage de cette technique ne leur est pas limitée! Module 4 : Validation et vérification des exigences 48

Exemple de technique: PAH • Étapes «SEG 3 501» D. Am u. Otta yot wa 1. Vérification des exigences individuelles (ambigüités, complétude, …) 2. Utiliser une comparaison par paires pour estimer la valeur relative d’exigences candidates: A << < = > >> B 3. Estimation du coût de chaque exigence (par architecte / ingénieur logiciel) 4. Générer le diagramme de coûts-valeurs 5. Les parties prenantes peuvent utiliser cette information (analyse, tendances) http: //www. youtube. com/watch? v=18 GWVt. VAAzs Module 4 : Validation et vérification des exigences 49

Exemple PAH «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 50

Exemple PAH «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 51

Critique de PAH • Bons points: ― Indique ce qui est important aux yeux du client ― Identifie les exigences à haute valeur et bas coût (priorité!) ― Identifie les exigences à basse valeur et haut coût (pourrait justifier leur retrait) ― Déjà appliquées à plusieurs projets • Quelques limites: «SEG 3 501» ― Potentiellement beaucoup de paires! ― Plusieurs dépendances entre exigences. D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 52

Défi: Gérer une complexité croissante «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 53

Quelques solutions • Réduire le nombre de paires et gérer les dépendances en groupant les exigences connexes sous forme d’entités, fonctions ou services (en anglais: features) qui pourraient être considérés ou offerts “séparément”. • Optimiser (mathématiquement) le nombre de paires à considérer (pas besoin de tout couvrir) «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 54

Classification des exigences Afin de mieux gérer et comprendre un grand nombre d’exigences, il est important de les regrouper de façon logique • Par exemple, avec les catégories suivantes (IEEE 830): ― ― ― Service ou fonctionnalité (Feature) Cas d’usage Mode d’opération Classe d’utilisateurs Sous-système • Beaucoup simples à traiter et à prioriser! «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 55

Fonctionnalité (Feature) • Un ensemble d’exigences reliées logiquement qui offre une capacité d’exécution particulière à l’utilisateur et qui permet de satisfaire un objectif d’affaire • Une caractéristique d’un produit (logiciel) qui peut être vendue ou mise en marché individuellement «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 56

Considérations de marché • Chaque client est unique! • Chaque groupe d’intervenants peut avoir un poids différent. ― Par exemple, les marchés européens et japonais peuvent avoir des préférences et offrir des opportunités différentes • Des groupes (marchés) peuvent ainsi être créés et avoir des poids différents «SEG 3 501» D. Am u. Otta yot wa ― Ventes/profits réalisés ou prévus ― Clients potentiels, compétition ― Taille du marché potentiel, croissance potentielle… Module 4 : Validation et vérification des exigences 57

Distributions des priorités, en considérant des marchés égaux [Damian, 2005] «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 58

Distributions des priorités, en considérant le poids des marchés Ordre des priorités différent! (auparavant: P Z M H K…) «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 59

Les « features » évoluent aussi! • Les « Feature Survival Charts » donnent un aperçu des changements/décisions au cours d’un ou plusieurs projets. • Aussi utiles pour l’amélioration de processus • Source: Krzysztof Wnuk, Björn Regnell, Lena Karlsson: Visualization of Feature Survival in Platform‐Based Embedded Systems Development for Improved Understanding of Scope Dynamics, 3 rd International Workshop on Requirements Engineering Visualization REV 08, Barcelona, Spain. «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 60

«SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 61

Analyse qualitative des « Feature Survival Charts » «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 62

Exemple d’outil commercial • IBM Rational Focal Point ― Aide à la décision, gestion de portfolio ― Comparaisons par paires de features – Création et validation de questionnaires Web ― Algorithme dynamique de réduction du nombre de paires, selon les réponses fournies ― Détection d’incohérence entre les réponses ― Priorités – Pour différents marchés ― Représentation sous toutes sortes de représentations ― Intégration à DOORS «SEG 3 501» D. Am u. Otta yot wa ― http: //www-01. ibm. com/software/awdtools/focalpoint/ ― http: //www. youtube. com/watch? v=V 7 IChf 577 is Module 4 : Validation et vérification des exigences 63

Exemple d’un outil local • Sondage sur le Web, en deux phases 1. Importance des exigences ou fonctionnalités, entre 1 et 10 2. Respect d’une courbe de distribution imposée (ou suggérée) en demandant de “déplacer” les exigences vers le haut ou le bas dans la liste des priorités • Rapports par types d’exigences, catégories d’utilisateurs, etc. • Démonstration en ligne «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 64

Références • Volere Prioritisation Analysis ― http: //www. volere. co. uk/pa 1. htm • Wiegers, Karl E. , First Things First: Prioritizing Requirements. ― http: //www. processimpact. com/articles/prioritizing. html «SEG 3 501» • Davis, A. The art of requirements triage, IEEE Computer, March 2003 • Karlsson, J. and Ryan, K. A cost-value approach for prioritizing requirements, IEEE Software, Sept/Oct 1997 • Regnell, B. et al, An industrial case study on distributed prioritization in market-driven requirements engineering for packaged software, Requirements Engineering 6, 51 -62 D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 65

Dilbert et la vérification… «SEG 3 501» D. Am u. Otta yot wa Module 4 : Validation et vérification des exigences 66