Daniel Amyot, Université d’Ottawa Basé sur du materiel de:

Présentation au sujet: "Daniel Amyot, Université d’Ottawa Basé sur du materiel de:"— Transcription de la présentation:

1 User Requirements Notation (URN) Partie 1: Goal-oriented Requirement Language (GRL)
Daniel Amyot, Université d’Ottawa Basé sur du materiel de: Mussbacher et Amyot

2 GRL UCM URN en un coup d’œil
éléments intentionnels + acteurs + liens + indicateurs + stratégies Liens URN UCM responsabilités + causalité + composantes + scénarios

3 Contenu Introduction à User Requirements Notation (URN)
Buts et justifications Goal-oriented Requirement Language (GRL) Concepts de GRL Évaluations Exemples Outils Indicateurs Tous les modèles sont faux, mais quelques modèles sont utiles.1 [1] George Edward Pelham Box (1919-)

4 Aperçu d’URN (1) URN est un langage graphique simple et semi-formel permettant de modéliser et analyser des exigences sous formes de buts et de scénarios, de même que leurs relations Combines deux notations existantes Goal-oriented Requirement Language (GRL) (basé sur i* & NFR Framework) Use Case Maps (UCMs) Support pour l’élicitation, l’analyse, la spécification, et la validation d’exigences Permets aux ingénieurs système/logiciel/en exigences de découvrir et de spécifier des exigences pour des systèmes proposés ou en évolution, et d’analyser ces exigences en termes de rectitude et de complétude. 80 50 -10 40 60 Regular Bus Express Bus Take own car Hitch a ride -90 -20 20 OR 45 -40 -30 Commuter Work during commute Take public transport Take private transport Minimize travel time Minimize time lost by commute Minimize cost for commute Minimize infrastructure cost Share ongoing cost Car transport X drive car Hitch a Ride hitch a ride in car Express Bus commuter work deal with take #100 Regular Bus take #96 take #97 take #95 elevator take secure home ready to leave cubicle in commute stay Take Elevator call select floor stairs arrived Secure Home lock door arm system out2 out1 use alternative alarm system Arm System accept code check armed [matched] matched] [not not armed [quit] Commuting URN: jUCMNav: Virtual Library:

5 Aperçu d’URN (2) Les modèles URN peuvent être utilisés pour spécifier et analyser divers types de systèmes réactifs, de processus d’affaires, et de services en télécommunications jUCMNav Éditeur et analyseur URN Plug-in Eclipse Projet open source

6 Aperçu d’URN (2) vision Model business goals, stakeholders’ priorities, alternative solutions, rationale, and decisions GRL called strategies, compared with GRL evaluation mechanism traceability with URN links extensible with metadata with UCM traversal mechanism based on UCM scenario definitions Model & test use cases; investigate high level architecture; transform to more detailed models UCM more detailed models A GRL / UCM model visually communicates business objectives and constraints / high-level functional requirements to all stakeholders

7 ITU-T Z.151: URN - Language Definition
Première et seule norme internationale à supporter de façon explicite, graphique et intégrée les notions de buts et de scénarios, et les liens qui les unissent. Membre de la famille de langages de l’UIT-T Union internationale des télécommunications Organisme des Nations Unies: 193 pays + compagnies membres ITU-T Z.150 (02/03, revised 02/11): User Requirements Notation (URN) - Language requirements and framework ITU-T Z.151 (11/08, corrigendum 2011, revised 2012): User requirements notation (URN) - Language definition Méta-modèle, syntaxes abstraite/concrète, sémantique, analyse, exemples… Version 2018 soumise, avec syntaxe textuelle pour GRL/UCM

8 Langages de l’UIT-T SDL: Specification and Description Language
Pour définir et exécuter des systèmes réactifs complets MSC: Message Sequence Charts Pour définir des scénarios orientés-messages ASN.1: Abstract Syntax Notation One Pour définir des types de données TTCN-3: Testing and Test Control Notation Pour définir des cas et des environnements de test URN: User Requirements Notation Goal-oriented Requirement Language (GRL) Notation Use Case Map (UCM) Pour définir des buts, des scénarios, et des exigences Profiles UML 2.x pour certains de ces langages (e.g., SDL)…

9 Buts et justifications

10 Qu’est-ce qu’une justification (rationale)?
Une justification (ou raison-d’être) représente le raisonnement qui mène au système. Les justifications incluent: Les problèmes adressés Les alternatives qui ont été considérées Les décisions prises afin de résoudre les problèmes Les critères qui ont guidé les décisions Les débats que les participants ont eu lors de la prise de décision. [Bruegge et Dutoit, chapitre 12]

11 Utilisation de justifications en génie logiciel
Amélioration du support de conception Évite l’évaluation dupliquée d’alternatives faibles Produit des compromis explicites et cohérents. Amélioration de la documentation Facilite la revue de la conception par les non-développeurs (gestionnaires, avocats, scribes…) Amélioration du support de maintenance Offre un contexte de conception aux gens qui font l’entretien du logiciel Amélioration de l’apprentissage Les nouveaux employés peuvent apprendre et comprendre la conception en étudiant les décisions qui l’ont produite.

12 Exemple: Guichet automatique (Tableau)
Question: Mécanismes d’authentification alternatifs? Service: Authentification Décision: Carte à puce + NIP Critère 1: Coût unitaire Critère 2: Vie privée Option 1: Numéro de compte + – Option 2: Empreintes digitales + – Option 3: Carte à puce + NIP + Version qualitative…

13 Exemple: Guichet automatique (Tableau)
Question: Mécanismes d’authentification alternatifs? Service: Authentification Décision: Carte à puce + NIP Critère 1: Coût unitaire Critère 2: Vie privée Option 1: Numéro de compte 1 20 Option 2: Empreintes digitales 30 4 Option 3: Carte à puce + NIP 2 40 Version quantitative… Questions: Relations entre critères? Passage à l’échelle? Et les partie prenantes?... Peut-on faire mieux qu’un simple tableau?

14 Qu’est-ce qu’un but en général?
Un but (goal) représente un objectif d’affaires, d’organisation ou de système. Une exigence spécifie de quelle façon un but devrait être atteint par un système proposé. Opérationnalisation Le processus de définition d’un but avec suffisamment de détails pour permettre que ses sous-buts aient une définition opérationnelle Décomposition Le processus de subdivision d’un ensemble de buts en sous-groupes logiques afin de les exigences du système soient plus facilement comprises, définies et spécifiées Obstacles Comportements ou autres buts qui préviennent ou bloquent l’atteinte d’un but donné. En identifiant des obstacles aux buts abstraits nous pouvons considérer les façons de faire échouer les buts et anticiper les cas exceptionnels.

15 Rôles joués par les buts en I.E. [van Lamsveerde, 2009]
Décrire la justification des exigences Aider à identifier les exigences qui les satisferont Fournir une structure pour l’argumentation Offrir une base pour démontrer l’alignement du système futur avec les objectifs stratégiques de l’entreprise Offrir un critère précis pour la complétude des exigences Offrir un critère précis pour la pertinence des exigences Offrir une façon naturelle de structurer une spécification d’exigences, de même que les raffinements d’exigences Offrir une base pour l’analyse de risques Offrir un environnement pour gérer les conflits entre exigences Offrir un critère pour délimiter la portée du système Supporter l’analyse de dépendances entre composantes du système Supporter le raisonnement sur les diverses alternatives possibles Faciliter la gestion de la traçabilité Offrir un contexte pour supporter l’évolution …

16 Goal-oriented Requirement Language (GRL)

17 Aperçu de GRL Goal-oriented Requirement Language
Notation graphique (syntaxe textuelle en cours de normalisation) Basé sur i* et le NFR Framework (U. de Toronto) Relie les exigences aux objectifs d’affaires Permet de raisonner sur les exigences (surtout les non-fonctionnelles) et les compromis Indicateurs, stratégies, et mécanismes d’extension GRL modélise le « pourquoi » Objectifs, alternatives, et raisonnements (justifications!) Peu de détails opérationnels Supporte l’analyse de buts et l’évaluation d’alternatives et de compromis Quels acteurs seront heureux des décisions? Il n’y a rien de comparable dans UML, SysML, ou BPMN… The Goal-oriented Requirement Language (GRL) addresses most of URN’s additional objectives. Goal-oriented modeling has been proposed in the requirements engineering community for a number of years and several approaches have been published. GRL is a rather new addition to this growing list of techniques but builds on the well-established NFR framework (for non-functional requirements), and the agent-oriented language i* (for the modeling, analysis, and reengineering of organisations and business processes. GRL captures business or system goals, alternative means of achieving goals (either objectively or subjectively), and the rationale for goals and alternatives. The notation may be applied to non-functional as well as functional requirements.

18 Notation GRL . + . + Exemple GRL : Petit Magasin en Ligne Ressource +
Business Owner Increase Sales Online Shopper Payment Offer Online Shopping + + Contribution Have System Security Dépendance Bux-doux Acteur Minimize Cost of Terminal + + . Corrélation Have Security of Terminal Have Security of Host _ + Décomposition . + . + Access Authorization Biometrics is no regular, off-the-shelf technology Encryption Ensure Authentication AND OR Tâche Provide Identification Opinion Use Fingerprint Use Password Use Cardkey But

19 Notation GRL de base: Éléments intentionnels
But (Goal) Quantifiable (souvent fonctionnel) But-doux (Softgoal) Qualifiable mais non-mesurable (souvent non-fonctionnel) Tâche (Task) Solution ou activité qui atteint un but ou qui contribue partiellement à l’atteinte d’un but-doux Opinion (Belief) Décrit le raisonnement, la justification Ressource (Resource) Produit, objet ou autre ressource

20 Notation GRL de base: Liens
Contribution Liens pour éléments intentionnels Peuvent être qualifiés Ind+ : on hésite entre Réalise (suffisant) et Aide (insuffisant) Ind- : on hésite entre Brise (suffisant) et Nuit (insuffisant) Corrélation Comme une contribution, mais indique un effet de bord Décomposition (AND, OR, XOR) Définit ce dont un élément intentionnel a besoin pour être satisfait. Dépendances Entre acteurs (et leurs éléments intentionnels), avec un sujet de dépendance ? Brise Nuit Ind- Inconnu Réalise Aide Ind+ Égal

21 Acteurs et dépendances GRL
Les éléments intentionnels GRL peuvent être places dans des acteurs Des dépendances entre acteurs peuvent être définies Point de vue stratégique

22 Pourquoi GRL? Les buts auront une influence importante sur l’élaboration des exigences. Cependant, les buts et objectifs des parties prenantes sont complexes et vont entrer en conflit. GRL permet d’exprimer et de clarifier les exigences ambiguës, provisoires, et mal définies Supporte la prise de décision, les argumentations, la négociation, et la détection & résolution de conflits Documente les critères de décision et les justifications GRL identifie les exigences alternatives et diverses frontières possibles pour le système GRL offre un retraçage entre les objectifs stratégiques et les exigences techniques GRL permet la réutilisation de buts abstraits et stables lorsque le système évolue

23 Récits utilisateur et modèles orientés-buts
As a [Actor] I want to [Task] in order to [Contribution] achieve [Goal] En tant que [Acteur] je veux que [Tâche] afin de [Contribution] à [But] Ce récit utilisateur identifie la tâche d’un acteur et une contribution de la tâche au but (dans ou hors de l’acteur) As a professor, I want to use Brightspace in order to help minimize the number of lost assignments.

24 GRL – Stratégies d’évaluation #1
GRL Example: Tiny Online Business 25 Business Owner Business Owner 42 Increase Sales Increase Sales * 100 * 100 33 Online Shopper Online Shopper Payment Payment Offer Online Shopping Offer Online Shopping + high + 44 high System Security System Security Importance 75 medium Cost of Terminal Cost of Terminal + 25 + . * 100 Security of Terminal Security of Terminal Security of Host Security of Host _ + . + . + -75 * 100 Access Authorization Access Authorization Encryption Encryption Biometrics is no regular, off-the-shelf technology 100 Authentication Authentication AND OR * -75 * 100 Identification Identification Niveau de satisfaction initial Fingerprint Fingerprint Password Password Cardkey Cardkey

25 Évaluations avec GRL L’évaluation d’un graphe GRL montre l’impact de décisions qualitatives sur les buts de haut-niveau La propagation est habituellement de bas vers le haut Évaluation qualitative ou quantitative du niveau de satisfaction Prend en considération divers contributeurs: Degré de satisfaction (satisfait, insatisfait, …) Opérateurs de composition (ET, OU) Contributions et corrélations (+/-, suffisant ou non) Dépendances entre éléments intentionnels Plus complet qu’avec de simples tableaux d’avantages et inconvénients (exemple du guichet automatique)

26 Stratégies GRL Une stratégie GRL définit les valeurs de satisfaction initiales pour un ensemble d’éléments intentionnels du modèle Décrit une solution globale Peuvent être comparées les unes avec les autres lors de l’analyse de compromis L’analyse peut se faire de façon quantitative ou qualitative, et plusieurs algorithmes peuvent être définis

27 GRL – Approche qualitative ou quantitative
Qualitative Approach Contribution types: from Make to Break Importance: High, Medium, Low, or None Qualitative satisfaction levels Quantitative Approach Contribution types: [-100, 100] Importance: [0, 100] Quantitative satisfaction levels: [-100, 100] Hybrid Approach is also possible Qualitative contribution types Quantitative importance Quantitative satisfaction levels GRL Satisfaction Levels: (qualitative) Satisfied Weakly Satisfied Unknown Weakly Denied Denied Conflict None

28 GRL – Stratégies d’évaluation #2
GRL Example: Tiny Online Business -34 Business Owner Business Owner -17 Increase Sales Increase Sales * 100 * 100 Online Shopper Online Shopper -23 Payment Payment Offer Online Shopping Offer Online Shopping + high + -31 high System Security System Security -75 medium Cost of Terminal Cost of Terminal + -75 + . * 100 Security of Terminal Security of Terminal Security of Host Security of Host _ + . + . + -75 Access Authorization Access Authorization Encryption Encryption Biometrics is no regular, off-the-shelf technology 100 Authentication Authentication AND OR * -75 * 100 Identification Identification Fingerprint Fingerprint Password Password Cardkey Cardkey

29 GRL – Stratégies d’évaluation #3
GRL Example: Tiny Online Business 52 51 Business Owner Business Owner Increase Sales Increase Sales * 100 * 100 68 Online Shopper Online Shopper Payment Payment Offer Online Shopping Offer Online Shopping + high + 90 high System Security System Security medium Cost of Terminal Cost of Terminal + 100 + . * 100 Security of Terminal Security of Terminal Security of Host Security of Host _ + . + . + * 100 Access Authorization Access Authorization Encryption Encryption Biometrics is no regular, off-the-shelf technology Authentication Authentication AND OR Identification Identification Fingerprint Fingerprint Password Password Cardkey Cardkey

30 Échelle de satisfaction [0..100], plus intuitive
On peut passer de [0..100] à [ ] (bouton de droite sur URNspec). La satisfaction 25 n’est plus “bonne” (orange)! Option de visualisation avec [0..100] pour évaluations Une échelle de satisfaction [0..100] est plus intuitive que [ ] pour bien des personnes (surtout quand elle est combinée à des contributions négatives)

31 Outil jUCMNav 7, pour Eclipse

32 Métamodèle abstrait de URN (I)

33 Métamodèle abstrait de URN / GRL (II)

34 Stratégies dans jUCMNav
Étoile (*) ou forme au contour pointillé indique une valeur initiale d’une stratégie donnée. Si la ligne pointillée est rouge alors cette valeur aurait pu être calculée (overridden) Toutes les autres valeurs sont évaluées à l’aide d’un algorithme de propagation.

35 Stratégies GRL

36 Algorithmes de propagation sous jUCMNav
7 algorithmes de propagation inclus (incluant Quantitatif et Qualitatif) Supporte la résolution automatique de conflits Utilise les liens pour l’évaluation (dans cet ordre): 1) Décompositions, 2) Contributions, 3) Dépendances « Tolérance » utilisée par les contributions de poids autres que 100 et -100 (mettre à 0 svp!) - Automatic conflict resolution does not involve user

37 Propagation quantitative (1)

38 Propagation quantitative (2): Règles arithmétiques

39 Propagation quantitative (3): Exemples
Minimum pour AND, maximum pour OR/IOR Les contributions sont additives, mais elles sont aussi normalisées

40 Propagation quantitative (3): Évaluation d’acteurs
Évaluation pour gérer les négociations entre parties prenantes. Aide à analyser et à comparer les niveaux de satisfaction globaux de chaque acteur pour une stratégie donnée Calculée à partie des attributs importance (Wx) des éléments intentionnels liés à l’acteur Criticality and priority is high, medium or low

41 Propagation quantitative (5): Exemples
On ne peut pas être plus satisfait que ce de quoi on dépend. Telecom Provider (44) Low Cost (29) 100 Reliability (100) High Perf (60) - 75 Weight 25 La satisfaction d’acteur (A) aide à comprendre les compromis de stratégies à ce niveau. Calculée selon l’importance (Wx) et la satisfaction des éléments contenus.

42 Propagation qualitative: Décomposition ET/OU

43 Motif (pattern) récurrent en GRL

44 GRL Exemple I – Contexte
Nouveau service pour réseau sans-fil Où mettre l’intelligence (la logique du service)? Où mettre les données du service?

45 GRL Example I – Intentional Elements and Actors

46 GRL Example I – Links

47 GRL Example I – Contribution Types
Qualitative or quantitative

48 GRL Example I – Qualitative Model Evaluation

49 GRL Example I – Quantitative Model Evaluation

50 Exemple GRL #2 – Contexte
Modèle GRL qui se préoccupe de la protection de la vie privée dans un environnement hospitalier Researchers want access to patient data but the Health Information Custodian (HIC – i.e., the hospital) needs to protect patient privacy, as required by law (PHIPA in Ontario). The process of accessing databases must ensure privacy. As required by law, a Research Ethics Board (REB) is usually involved in assessing privacy risks for the research protocol proposed by a researcher. DB administrators also want to ensure that DB users are accountable for their acts.

51 Exemple GRL #2 – Modèle

52 Un modèle, plusieurs diagrammes

53 Exemple GRL #2– Évaluation quantitative
Échelle: [-100, 100]

54 Outil – SanDriLa (Plug-in pour Visio)

55 Outil – OpenOME, avec plug-in Eclipse

56 Outil Web – Creative Leaf
En ligne: Vidéos:

57 Outil commercial: Objectiver (pour KAOS)

58 jUCMNav (plug-in Eclipse)
Features for GRL 7 GRL evaluation algorithms, with color highlight One model, multiple diagrams References to actors and intentional elements Drag&drop from outline or via properties Auto-layout Catalogues For exporting/importing/reusing common models Export graphics (.bmp, .gif, .jpg) Export strategy evaluations (.csv) URN links (for integration with UCMs) Export to DOORS Navigator view Outline view Editor Scenarios and Strategies view Properties view Toolbar Palette

59 Inclusion de mesures dans les modèles GRL
GRL inclut une notion de satisfaction de buts, avec des échelles qualitative et quantitative ([ ], et maintenant [0..100]). Cependant, nous avons souvent besoin de mieux relier les observations sur le monde réel au modèle orienté-buts, avec des unités spécifiques au domaine telles que: Devises (p.ex., revenus en $) Durées (p.ex., temps d’attente à l’hôpital, en heures) Nombres (p.ex., nombre d’étudiants admis en SEG) GRL permet de définir ce genre d’information et de l’intégrer au reste du modèle Indicateur (Key Performance Indicator ― KPI) Les KPI aident à mesurer les buts et les ENF avec des métriques quantifiables. Les KPI en GRL peuvent être fournies par des sources externes d’informations, transformant ainsi un modèle GRL en un outil de surveillance (p.ex.: un tableau de bord ― dashboard). Average Work Time (in min)

60 Indicateurs GRL (KPI) En GRL, un KPI est défini comme étant un élément intentionnel, mais avec des caractéristiques supplémentaires: Attributs (pour une stratégie GRL donnée) Une valeur d’évaluation (evaluation), observée de l’extérieur ou simulée dans une stratégie (what-if) Une valeur cible (target); le KPI est entièrement satisfait si la valeur d’évaluation l’atteint Une pire valeur (worst); le KPI est entièrement insatisfait si la valeur d’évaluation l’atteint Une valeur de seuil (threshold); le KPI est neutre si la valeur d’évaluation l’atteint. Une unité (unit), par exemple $ Associations (pour un modèle GRL donné) Peut faire partie de contributions ou de décompositions

61 Sub-process Performance Model Link KPI Information Element (Dimension) KPI Value sets Strategies

62 Indicateurs: De Current à Satisfaction
Gestionnaire $1300 ??? ??? Coûts des employés Profits maximisés 50 Attribute Value GRL Satisfaction Target $1000 100 Threshold $1500 Worst-case $2500 -100 Current $1300 ???

63 Indicateurs: De Current à Satisfaction
Gestionnaire $1300 40(*) 20 Coûts des employés Profits maximisés 50 Attribute Value GRL Satisfaction Target $1000 100 Threshold $1500 Worst-case $2500 -100 Current $1300 40

64 Des KPI aux niveaux de satisfaction GRL
Note: Une interpolation linéaire est présentement utilisée pour calculer la satisfaction, qui est fonction des valeurs evaluation, target, threshold, and worst.

65 Conversion dans les indicateurs GRL [0..100]

66 Extensions de jUCMNav pour KPI et monitoring
Business Process Compliance with URN p. 66

67 KPI: Exemple de transport (de G. Mussbacher)
Commuter Minimize time lost by commute Minimize cost for commute 40 50 50 60 Work during commute Minimize travel time Minimize infrastructure cost Share ongoing cost -10 100 80 100 -30 80 45 -40 100 100 Average Travel Time (in min) Commuting Monthly Infrastructure Cost (in $) Average Work Time (in min) OR Average Ongoing Cost (in $) Take public transport Take private transport OR OR Key Performance Indicator (KPI) Regular Bus Express Bus Take own car Hitch a ride

68 KPI: Valeurs réelles vers valeurs de satisfaction
Model Value (Satisfaction Value) Real World Value Regular Bus Express Bus Take own car Hitch a ride Average Work Time (in min) 80  49 45  29.75 -10  4.5 -10  4.5 Target Value (60) Threshold Value (5) Worst Value (0) Average Travel Time (in min) -40  56 -30  52 80  24 80  24 Target Value (20) Threshold Value (40) Worst Value (80) Monthly Infrastructure Cost (in $) 80  10 80  10 -90  455 -20  140 Target Value (0) Threshold Value (50) Worst Value (500) Average Ongoing Cost (in $) 80  68 60  76 -20  120 20  92 Target Value (60) Threshold Value (100) Worst Value (200)

69 Exécution de stratégies avec indicateurs (1/2)
Strategy “Regular Bus”: Regular Bus = 100 Example: Commuting 40 Commuter Commuter 20 80 Minimize time lost by commute (100) Minimize time lost by commute Minimize time lost by commute Minimize cost for commute (50) Minimize cost for commute Minimize cost for commute 40 50 50 60 80 -40 80 80 Work during commute Work during commute Minimize travel time Minimize travel time Minimize infrastructure cost Minimize infrastructure cost Share ongoing cost Share ongoing cost 100 100 -40* 100 100 100 Average Travel Time (in min) Average Travel Time (in min) Average Travel Time (in min) Commuting Commuting 80* 80* Monthly Infrastructure Cost (in $) Monthly Infrastructure Cost (in $) Monthly Infrastructure Cost (in $) Average Work Time (in min) Average Work Time (in min) Average Work Time (in min) OR 80* 100 Average Ongoing Cost (in $) Average Ongoing Cost (in $) Average Ongoing Cost (in $) Take public transport Take public transport Take private transport Take private transport KPI “Regular Bus”: Av. Work Time = 4980 Av. Travel Time = 56-40 Mo. Infrast. Cost = 1080 Av. Ongoing Cost = 6880 OR OR 100* Regular Bus Regular Bus Regular Bus Express Bus Express Bus Take own car Take own car Hitch a ride Hitch a ride

70 Exécution de stratégies avec indicateurs (2/2)
Strategy “Hitch a ride”: Hitch a ride = 100 Example: Commuting 22 Commuter Commuter 35 -4 Minimize time lost by commute Minimize time lost by commute Minimize time lost by commute (100) Minimize cost for commute Minimize cost for commute Minimize cost for commute (50) 40 50 50 60 -10 80 -20 20 Work during commute Work during commute Minimize travel time Minimize travel time Minimize infrastructure cost Minimize infrastructure cost Share ongoing cost Share ongoing cost 100 100 80* 100 100 100 Average Travel Time (in min) Average Travel Time (in min) Average Travel Time (in min) Commuting Commuting -20* -10* Monthly Infrastructure Cost (in $) Monthly Infrastructure Cost (in $) Monthly Infrastructure Cost (in $) Average Work Time (in min) Average Work Time (in min) Average Work Time (in min) OR 20* 100 Average Ongoing Cost (in $) Average Ongoing Cost (in $) Average Ongoing Cost (in $) Take public transport Take public transport Take private transport Take private transport KPI “Hitch a ride”: Av. Work Time = 4.5-10 Av. Travel Time = 2480 Mo. Infrast. Cost = 140-20 Av. Ongoing Cost = 9220 OR OR 100* Regular Bus Regular Bus Express Bus Express Bus Take own car Take own car Hitch a ride Hitch a ride Hitch a ride

71 Agrégation de KPI Dans jUCMNav, les valeurs d’évaluation KPI peuvent aussi être calculées (agrégées) à partir d’autres KPI, un peu à la manière d’Excel Algorithme d’évaluation GRL avec formules pour KPI

72 Autres langages orientée-buts
NFR Framework, par Mylopoulos et al., Toronto: Analyse qualitative par propagation i* Framework, par Yu et al., Toronto: Modélisation d’organisation et de dépendances entre acteurs KAOS (Keep All Objectives Satisfied), par van Lamsweerde et al., Louvain & Oregon Analyse d’obstacles, logique temporelle et vérification de modèles GBRAM (Goal-Based Requirements Analysis Method), par Antón et al., Atlanta Tropos, par Fuxman, Giorgini , Mylopoulos et al., Trento & Toronto Pour conception de systèmes multi-agents, sécurité. Formal Tropos: logique temporelle et vérification SMILE (Structural Modeling, Inference, and Learning Engine) et GeNie, par Druzdzel et al., Pittsburgh Aide à la décision, approches avec probabilités, théorie de la décision, et réseaux de Bayes BIM (Business Intelligence Model), par Mylopoulos, Amyot et al., Toronto & Ottawa Buts, situations et indicateurs GRL est le premier à être standardisé Bon aperçu: Liste d’outils: (i* Wiki) iStar 2.0:

73 Applications industrielles?
Yu, E., Amyot, D., Mussbacher, G., Franch, X., Castro, J.: Practical Applications of i* in Industry: The State of the Art. Mini-tutorial, 21th IEEE International Requirements Engineering Conference (RE 2013), Rio de Janeiro, Brazil, July 18, IEEE CS, Alistair Mavin, Philip Wilkinson, Sabine Teufl, Henning Femmer, Jonas Eckhardt, Jakob Mund: Does Goal-Oriented Requirements Engineering Achieve Its Goal? 25th IEEE International Requirements Engineering Conference (RE 2017), Lisbon, Portugal, September IEEE CS, Discute de l’écart entre la recherche et la pratique

74 Dilbert et les buts

75 Métamodèle concret (pour diagrammes)

76 Sommaire de la notation GRL
(a) GRL Elements Belief Goal Softgoal Resource Task Actor with Boundary Collapsed Actor Satisfied Weakly Satisfied Unknown Denied Weakly Denied Conflict None Make Help Some Positive Break Hurt Some Negative (d) GRL Contributions Types (c) GRL Satisfaction Levels (b) GRL Links Contribution Correlation Dependency Decomposition Means-End Indicator Exceeds +

77 Quiz! Pourquoi les justifications sont-elles importantes?
Comment les modèles orientés-buts (p.ex. en GRL) peuvent-ils être supérieurs à l'utilisation des tableaux de comparaisons? GRL est-il plus approprié pour répondre à des questions «pourquoi» ou à des questions «quand»? Comment peut-on définir un obstacle avec GRL? Qu'est-ce qu'une stratégie GRL? Quelle est la différence entre une évaluation quantitative et une évaluation qualitative? Quels sont les trois types de poids que l’on peut spécifier dans un modèle GRL? Si un modèle GRL évalué retourne 48 comme évaluation d'un acteur, est- ce bon ou mauvais? Pourquoi les indicateurs sont-ils importants? Les contributions « 100 » et la décomposition AND sont-elles semblables?