«SEG 3501» D. Amyot uOttawa SEG 3501- Module 4 Validation, vérification, et triage des exigences Basé en partie sur du matériel de K.E. Wiegers, D. Leffingwell.

Présentation au sujet: "«SEG 3501» D. Amyot uOttawa SEG 3501- Module 4 Validation, vérification, et triage des exigences Basé en partie sur du matériel de K.E. Wiegers, D. Leffingwell."— Transcription de la présentation:

1 «SEG 3501» D. Amyot uOttawa SEG 3501- Module 4 Validation, vérification, et triage des exigences 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

2 «SEG 3501» D. Amyot uOttawa Dlibert et la validation… Module 4 : Validation et vérification des exigences2

3 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences3 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 Besoin des deux à toutes les étapes de développement, et particulièrement pendant la spécification des exigences! Validation et vérification (V&V)

4 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences4 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 »

5 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences5 Vérifications simples Prototypage Conception de tests fonctionnels Révision formelle Analyse logique ―V&V à base de machines à état Techniques variées pour V&V The software is done. We are just trying to get it to work…

6 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences6 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). V&V: Vérifications simples

7 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences7 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 ―Bonne couverture, pas juste aléatoire V&V: Prototypage

8 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences8 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 ―Test-Driven Development (TDD) http://en.wikipedia.org/wiki/Test-driven_development http://en.wikipedia.org/wiki/Test-driven_development V&V: Conception de tests fonctionnels

9 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences9 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 V&V: Révision formelle

10 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences10 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.

11 «SEG 3501» D. Amyot uOttawa Équipe de révision 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. Module 4 : Validation et vérification des exigences11

12 «SEG 3501» D. Amyot uOttawa 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 ―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 exigences12

13 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences13 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.

14 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences14 Révision structurée Comme pour les sessions JAD et de remue- mé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: ―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

15 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences15 Inspection de Fagan Note: le patron n’est pas impliqué dans ce processus! Processus d’inspection structuré et formel

16 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences16 Inspection de Fagan Nouvelle inspection si >5% de modification ―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.

17 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences17 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

18 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences18 Révision active

19 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences19 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 ―Exemple de liste simpleliste simple ―Exemple de liste complexe (NASA)liste complexe ―Autres exemples dans la partie privée du sitepartie privée

20 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences20 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 les lisent – On prend de bonnes habitudes! ―Expliquer quelque chose aide à la comprendre ―Tout le monde devient familier avec le document (buy- in) ―Encourage le passage de connaissances et l’adhérence aux standards Risques: ―Problèmes de personnalités ―Politique de bureau, guerres saintes ―Les inspections sont épuisantes

21 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences21 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. V&V: Analyse logique

22 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences22 V&V basée sur machines à états Plusieurs alternatives possibles, qui dépendent des formalismes et outils utilisés ―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)

23 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences23 V&V basée sur machines à états ―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…

24 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences24 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 -Souvent, les outils de preuve sont interactifs ―Outils: SPIN, Alloy…SPINAlloy

25 «SEG 3501» D. Amyot uOttawa Conflits et négociation

26 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences26 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 En pratique, les causes sont souvent multiples.

27 «SEG 3501» D. Amyot uOttawa Résolution de conflits Quelques stratégies possibles: ―Entente ―Compromis ―Votes ―Définition de variantes ―Annulations ―Priorités ―Médiation ―Arbitration ―Analyse de buts (pensez à GRL…) Module 4 : Validation et vérification des exigences27

28 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences28 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 ―Intervenants, alternatives considérées, décision… Pensez à GRL!

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

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

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

32 «SEG 3501» D. Amyot uOttawa Triage des exigences Basées sur du matériel de Volere, Wiegers, Telelogic, et de D. Damian Objectifs: Pourquoi, difficultés, méthodes!

33 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences33 Difficultés Il y a trop d’exigences! Les budgets, le temps, et les autres ressources sont limités. Les exigences fusent de partout! ―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…

34 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences34 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

35 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences35 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… 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!

36 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences36 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%???

37 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences37 Importance du triage Le triage et l’établissement de priorités au niveau des exigences aident à: ―Rendre acceptables les 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!

38 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences38 Sur quel secteur se concentrer? 0 Beaucoup! Coût Beaucoup! Valeur R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14R15 R16 À éviter!

39 «SEG 3501» D. Amyot uOttawa Exemple: Volvo Car Corporation https://gupea.ub.gu.se/bitstream/2077/1789/1/stenbeck_svensson_0304.28.pdf Module 4 : Validation et vérification des exigences39

40 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences40 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 ―Cas d’usage, services, exigences détaillées…

41 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences41 1er exemple de technique: Approche par échelle Déterminer les critères et la granularité. Exemple fréquent (utilisés ensemble): ―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)

42 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences42 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 ―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

43 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences43 2e 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)) Encore limitée par les capacités à bien estimer!

44 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences44 Exemple pour un Chemical Tracking System Source: Wiegers, Karl E., First Things First: Prioritizing Requirements, http://www.processimpact.com/articles/prioritizing.html

45 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences45 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: ―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)

46 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences46

47 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences47 3e exemple de technique: Volere (tableau Excel éditable, semblable à la 2e) Source: Volere Prioritisation Analysis, http://www.volere.co.uk/prioritisationdownload.htm

48 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences48 4e 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 Utilisation de diagrammes de coûts- valeurs (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!

49 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences49 Exemple de technique: PAH Étapes 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=18GWVtVAAzs

50 «SEG 3501» D. Amyot uOttawa Exemple PAH Module 4 : Validation et vérification des exigences50

51 «SEG 3501» D. Amyot uOttawa Exemple PAH Module 4 : Validation et vérification des exigences51

52 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences52 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: ―Potentiellement beaucoup de paires! ―Plusieurs dépendances entre exigences.

53 «SEG 3501» D. Amyot uOttawa Défi: Gérer une complexité croissante Module 4 : Validation et vérification des exigences53

54 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences54 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)

55 «SEG 3501» D. Amyot uOttawa 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! Module 4 : Validation et vérification des exigences55

56 «SEG 3501» D. Amyot uOttawa 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 Module 4 : Validation et vérification des exigences56

57 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences57 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 ―Ventes/profits réalisés ou prévus ―Clients potentiels, compétition ―Taille du marché potentiel, croissance potentielle…

58 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences58 Distributions des priorités, en considérant des marchés égaux [Damian, 2005]

59 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences59 Distributions des priorités, en considérant le poids des marchés Ordre des priorités différent! (auparavant: P Z M H K…)

60 «SEG 3501» D. Amyot uOttawa 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, 3rd International Workshop on Requirements Engineering Visualization REV 08, Barcelona, Spain. Module 4 : Validation et vérification des exigences60

61 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences61

62 «SEG 3501» D. Amyot uOttawa Analyse qualitative des « Feature Survival Charts » Module 4 : Validation et vérification des exigences62

63 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences63 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 ―http://www-01.ibm.com/software/awdtools/focalpoint/http://www-01.ibm.com/software/awdtools/focalpoint/ ―http://www.youtube.com/watch?v=V7IChf577ishttp://www.youtube.com/watch?v=V7IChf577is

64 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences64 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

65 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences65 Références Volere Prioritisation Analysis ―http://www.volere.co.uk/pa1.htmhttp://www.volere.co.uk/pa1.htm Wiegers, Karl E., First Things First: Prioritizing Requirements. ―http://www.processimpact.com/articles/prioritizing.htmlhttp://www.processimpact.com/articles/prioritizing.html 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 1997A cost-value approach for prioritizing requirements Regnell, B. et al, An industrial case study on distributed prioritization in market-driven requirements engineering for packaged software, Requirements Engineering 6, 51-62

66 «SEG 3501» D. Amyot uOttawa Module 4 : Validation et vérification des exigences66 Dilbert et la vérification…