1 / 75

User Requirements Notation (URN) Part 1: Goal-oriented Requirement Language (GRL)

SEG3101 (Fall 2014). User Requirements Notation (URN) Part 1: Goal-oriented Requirement Language (GRL). Daniel Amyot, University of Ottawa Based on material from: Mussbacher and Amyot 2009-2014. Bird’s Eye View of URN. GRL. intentional elements + actors + links+ indicators + strategies.

Télécharger la présentation

User Requirements Notation (URN) Part 1: Goal-oriented Requirement Language (GRL)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SEG3101 (Fall 2014) User Requirements Notation (URN)Part 1: Goal-oriented Requirement Language (GRL) Daniel Amyot, University of Ottawa Based on material from: Mussbacher and Amyot 2009-2014

  2. Bird’s Eye View of URN GRL intentional elements + actors +links+ indicators + strategies URN Links UCM responsibilities + causality + components + scenarios

  3. Table of Contents • Introduction to the User Requirements Notation (URN) • Goals and Rationales • Goal-oriented Requirement Language (GRL) • GRL Basics • Evaluations • Examples • Tools • Indicators • All models are false, but some models are useful.1 [1] George Edward Pelham Box (1919-)

  4. Commuter Minimize time lostby commute Minimize costfor commute 40 50 60 50 Work duringcommute Minimize travel time Minimizeinfrastructure cost Share ongoing cost -40 -30 80 80 45 80 80 -90 -20 20 -20 60 80 -10 Take publictransport Take privatetransport RegularBus Commuting ExpressBus Takeown car OR OR home transport elevator Hitch aride Car transport secure home take elevator commute RegularBus ExpressBus Hitch aride Takeown car ready to leave home drive car X in cubicle Hitch a Ride stay home transport Secure Home hitch a ride in car X home Take Elevator arm system lock door elevator X in out1 out2 use alternative alarm system call elevator select floor X Regular Bus X X stay home commuter deal with work email Arm System X take stairs transport home X elevator arrived take #95 not armed take #96 alarm system X X take #97 [quit] X armed accept code check code [matched] X X [not matched] Express Bus commuter deal with work email X transport take #100 X User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators URN Overview (1) • URN is a semi-formal, lightweight graphical language for modeling and analyzing requirements in the form of goals and scenarios and the links between them • Combines two existing notations • Goal-oriented Requirement Language (GRL)(based on i* & NFR Framework) • Use Case Maps (UCMs) • Support for the elicitation, analysis, specification, and validation of requirements • Allows systems, software, and requirements engineers to discover and specify requirements for a proposed system or an evolving system, and analyse such requirements for correctness and completeness URN: www.usecasemaps.org/urn jUCMNav: www.softwareengineering.ca/jucmnav Virtual Library: www.usecasemaps.org/pub

  5. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators URN Overview (2) • URN models can be used to specify and analyze various types of reactive systems, business processes, and telecommunications standards • jUCMNav • URN editor & analysis tool • Eclipse plug-in • Open source project

  6. GRL Model business goals, stakeholders’ priorities, alternative solutions, rationale, and decisions UCM Model & test use cases; investigate high level architecture; transform to more detailed models User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators URN Overview (3) vision called strategies, compared with GRL evaluation mechanism extensible withmetadata traceability with URN links with UCM traversal mechanism based on UCM scenario definitions more detailed models A GRL / UCM model visually communicates business objectives and constraints / high-level functional requirements to all stakeholders

  7. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators ITU-T Z.151: URN – Language Definition • URN is the first and currently only standard which explicitly addresses goals (non-functional requirements with GRL) in addition to scenarios (functional requirements with UCMs) in a graphical way in one unified language • International Telecommunication Union (ITU-T Z.150 series) • 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 • Metamodel, abstract/concrete syntaxes, semantics… ITU-T Z.150: http://www.itu.int/rec/T-REC-Z.150/en ITU-T Z.151: http://www.itu.int/rec/T-REC-Z.151/en

  8. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators About ITU-T • International Telecommunication Union • United Nations organization • 193 countries + hundreds of member companies • Free access to the definition of many standard languages • http://www.itu.int/ITU-T/studygroups/com17/index.html • Question 13 (Formal languages and telecommunication software) of Study Group 17 (Security) • Z.15x User Requirements Notation (URN) • Also SDL, MSC, and profiles • Other international bodies standardize languages • ANSI (C, C++), W3C (HTML, XML), IEEE (VHDL), ISO (LOTOS), OMG (UML), OASIS (XACML), etc.

  9. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators ITU-T Languages • SDL: Specification and Description Language • For defining and executing complete reactive systems • MSC: Message Sequence Charts • For defining message-oriented scenarios • ASN.1: Abstract Syntax Notation One • For defining data types/packets • TTCN-3: Testing and Test Control Notation • For defining test cases and test environments • URN: User Requirements Notation • Goal-oriented Requirements Language (GRL) • Use Case Map notation (UCM) • For defining abstract goals, scenarios, and requirements • UML 2.0 profiles for some of these languages (e.g., SDL)…

  10. Goal-oriented Requirement Language (GRL)

  11. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators What is a Rationale? • Rationale is the reasoning that leads to the system • Rationales include • Issues that were addressed • Alternatives that were considered • Decisions that were made to resolve the issues • Criteria that were used to guide decisions • Debate developers went through to reach a decision Source: Bruegge and Dutoit, chapter 12

  12. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Uses of Rationales in Software Engineering • Improve design support • Avoid duplicate evaluation of poor alternatives • Make consistent and explicit trade-offs • Improve documentation support • Makes it easier for non developers (e.g., managers, lawyers, technical writers) to review the design • Improve maintenance support • Provide maintainers with design context • Improve learning • New staff can learn the design by replaying the decisions that produced it

  13. Decision: Smart Card + PIN + – – + + + User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators ATM Example (Table) Question: Alternative Authentication Mechanisms? References: Service: Authenticate Criteria 1: ATM Unit Cost Criteria 2: Privacy Option 1: Account number Option 2: Fingerprint reader Option 3: Smart Card + PIN Qualitative version

  14. Decision: Smart Card + PIN 1 20 30 4 2 40 User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators ATM Example (Table) Question: Alternative Authentication Mechanisms? References: Service: Authenticate Criteria 1: ATM Unit Cost Criteria 2: Privacy Option 1: Account number Option 2: Fingerprint reader Option 3: Smart Card + PIN Quantitative version Questions: Relationships between criteria? Scalability?Stakeholders?... Can we do better than a simple table?

  15. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators What Is a Goal? • Goal: high level objective of the business, organization or system • A requirement specifies how a goal should be accomplished by a proposed system • Operationalization: the process of defining a goal with enough detail so that its sub-goals have an operational definition. • Decomposition: the process of subdividing a set of goals into a logical sub-grouping so that system requirements can be more easily understood, defined and specified. • Obstacles: behaviours or other goals that prevent or block the achievement of a given goal. • Abstracting and identifying goal obstacles allows one to consider the possible ways for goals to fail and anticipate exception cases. Source: A. Antón

  16. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Roles of Goals in RE [van Lamsveerde, 2009] • Goal refinement provides a natural mechanism for structuring complex specifications at different levels of concern. • Goals provide the rationale for requirements. • Goals drive the identification of requirements to support them. • Goals provide a richer structure for satisfaction arguments. • Goals provide a basis for showing the alignment of the system-to-be with the organization’s strategic objectives. • Goals provide a precise criterion for requirements completeness. • Goals provide a precise criterion for requirements relevance. • Goals provide a natural way of structuring the requirements domain. • Goals provide anchors for risk analysis. • Goals provide the roots for managing conflicts among requirements. • Goals provide a criterion for delimiting the scope of the system. • Goals support the analysis of dependencies among agents. • Goals provide a basis for reasoning about alternative options. • Goals support traceability management. • Goals provide essential information for evolution support.

  17. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Overview (1) • The Goal-oriented Requirement Language (GRL) • Graphical notation • Connects requirements to business objectives • Allows reasoning about (non-functional) requirements • Is based on i* (concepts / syntax) and the NFR Framework (evaluation mechanism) • Indicators, strategies, and extension mechanisms • GRL models the “why” aspect • Model goals and other intentional concepts • Little or no operational details • Supports goal and trade-off analysis and evaluations

  18. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Overview (2) • GRL is used to … • Visually describe business goals, objectives, stakeholders’ priorities, alternative solutions, rationale, and decisions • Decompose high-level goals into alternative solutions called tasks (this process is called operationalization) • Model positive & negative influences of goals and tasks on each other • Capture dependencies between actors (i.e., stakeholders) • Reason about alternatives and trade-offs

  19. Have System Security Increase Sales Biometrics is noregular, off-the-shelftechnology Offer OnlineShopping Minimize Cost ofTerminal Use Cardkey UseFingerprint Use Password User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Notation (1) GRL Example: Tiny Online Business Resource Business Owner Online Shopper Payment + + Contribution Dependency Softgoal Actor + +. Correlation Have Security of Host Have Security of Terminal _ + .+ .+ Decomposition AccessAuthorization Encryption EnsureAuthentication AND OR Task ProvideIdentification Belief Goal

  20. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Notation (2) • Intentional elements • Softgoal, goal, task ,resource, belief • Achievement of softgoal is qualifiable but not measurable; it is quantifiable for goals • Softgoal …often non-functional • Goal … often functional • Task is a proposed solution that achieves a goal or satisfies (satisfices) a softgoal • Belief captures rationale

  21. ? Unknown Break Hurt Some- Make Help Some+ User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Notation (3) • Contribution and Correlation Links • Contribution describes desired impact, correlation shows side effects • Qualitative or quantitative contribution types are used for these links • Decomposition Link • Defines what an intentional element needs to be satisfied • AND • OR • XOR • Dependency Link • An actor (the depender) depends on another actor (the dependee) for something (the dependum), e.g. the business owner depends on the online shopper for payment (the dependum is optional) GRL Contributions Types:(qualitative)

  22. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Notation (4) • GRL graphs can be allocated to actors • Dependencies can be defined between actorstogether with intermediate resources orother elements • Provides a strategic view Note: this is an i* model and therefore the syntax is slightly different

  23. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Why GRL? • Goals become an important driver for requirements elaboration – yet, stakeholders goals and objectives are complex and will conflict… • GRL expresses and clarifies tentative, ill-defined, and ambiguous requirements • Supports argumentation, negotiation, conflict detection & resolution, and in general decisions • Captures decision rationale and criteria (documentation!) • GRL identifies alternative requirements and alternative system boundaries • GRL provides clear traceability from strategic objectives to technical requirements • GRL allows reuse of stable higher-level goals when the system evolves • Nothing like this in UML, SysML or BPMN…

  24. GRL – Strategy Execution (Strategy 1) 33 Increase Sales Increase Sales System Security System Security Offer OnlineShopping 25 44 Biometrics is noregular, off-the-shelftechnology 0 0 * * * * 100 100 100 Security of Host Security of Host Security of Terminal Security of Terminal Offer OnlineShopping 75 Cost ofTerminal Cost ofTerminal -75 100 AccessAuthorization Encryption AccessAuthorization 100 Encryption Authentication Authentication * -75 * Identification Identification 100 Fingerprint Fingerprint Password Cardkey Cardkey Password User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Example: Tiny Online Business 25 42 Business Owner Business Owner Online Shopper Online Shopper Payment Payment + high + high Importance medium + +. _ + .+ .+ AND OR InitialSatisfactionLevel

  25. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL – Strategies and Evaluation Mechanism (1) • GRL allows a particular configuration of intentional elements to be defined in a strategy (i.e., one possible solution) • Captures the initial, user-defined satisfaction levels for these elements separately from the GRL graphs • Strategies can be compared with each other for trade-off analyses • In order to analyze the goal model and compare solutions with each other, jUCMNav’s customizable evaluation mechanism executes the strategies • Propagating satisfaction levels to the other elements and to actors shows impact of proposed solution on high level goals for each stakeholder • Propagation starts at user-defined satisfaction levels of intentional elements (usually bottom-up)

  26. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL – Strategies and Evaluation Mechanism (2) • Evaluations of GRL graphs show the impact of qualitative decisions on high level softgoals • Evaluation mechanism takes into consideration • Initial satisfaction levels of children (intentional elements) • Links, types of these links, and contribution/decomposition types • Importance defined for intentional elements • More complete than simple pros/cons tables or criteria evaluation matrices • See Chapter 11.1 and Appendix II of the Z.151 standard • Standard provides minimum requirements

  27. Satisfied WeaklyDenied Denied WeaklySatisfied Conflict Unknown None User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL – Qualitative or Quantitative Approach GRL Satisfaction Levels: (qualitative) • 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

  28. GRL – Strategy Execution (Strategy 2) Increase Sales Increase Sales System Security System Security Offer OnlineShopping Biometrics is noregular, off-the-shelftechnology 0 0 0 * * * 100 100 100 Security of Host Security of Host Security of Terminal Security of Terminal Offer OnlineShopping Cost ofTerminal Cost ofTerminal -75 -75 -31 -17 -23 -75 -34 AccessAuthorization Encryption AccessAuthorization 100 Encryption Authentication Authentication * -75 * Identification Identification 100 Fingerprint Fingerprint Password Cardkey Cardkey Password User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Example: Tiny Online Business Business Owner Business Owner Online Shopper Online Shopper Payment Payment + high + high medium + +. _ + .+ .+ AND OR

  29. GRL – Strategy Execution (Strategy 3) 51 52 68 Increase Sales Increase Sales System Security System Security Offer OnlineShopping 90 Biometrics is noregular, off-the-shelftechnology 0 0 0 0 0 0 * * * * 100 100 100 100 100 Security of Host Security of Host Security of Terminal Security of Terminal Offer OnlineShopping Cost ofTerminal Cost ofTerminal AccessAuthorization Encryption AccessAuthorization Encryption Authentication Authentication Identification Identification Fingerprint Fingerprint Password Cardkey Cardkey Password User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Example: Tiny Online Business Business Owner Business Owner Online Shopper Online Shopper Payment Payment + high + high medium + +. _ + .+ .+ AND OR

  30. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators New [0..100] GRL Satisfaction Scale Right-click on URNspec (in the Outline view) to switch between [0..100] and [-100..100]. The menu for quantitative values will change too. Suddenly, 25 is no longer good (orange)! Applies to new models. New visualization option with [0..100] for evaluations A [0..100] satisfaction scale instead of a [-100..100] scale in GRL is more intuitive to some types of stakeholders (especially in combination with negative contributions…)

  31. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators jUCMNav 5 Tool, for Eclipse Perspectives Menu Editor Toolbar Projects & Files Views Palette Details of Model Element Analysis Model Elements in File

  32. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators URN Abstract Metamodel

  33. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Abstract Metamodel

  34. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Strategies Abstract Metamodel

  35. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Strategies in jUCMNav A star (*) indicates an initial value part of a given strategy (element also shown in dashed lines). All the others are evaluated through a propagation algorithm. Dashed red linesare overridden values (could be computed)

  36. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Propagation Algorithms in jUCMNav • jUCMNav supports 6 propagation algorithms • 1 Quantitative, 1 Qualitative • 1 Quantitative/Qualitative hybrid • Experimental support for indicator propagation • Experimental support for conditions (legal compliance) • Experimental support for constraint-based • Most support the automatic resolution of conflicts • Most use links in this order: • Decompositions • Contributions • Dependencies

  37. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Quant. Alg. – Decompositions and Contributions • Minimum for AND, maximum for OR • Contributions are additive but normalized and take a tolerance into account

  38. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Quantitative Algorithm – Dependencies and Actors • Depender’s satisfaction level is not more than the dependum’s (and the dependee’s) • Evaluations deal with negotiations between stakeholders • Actor evaluations help analyzing and comparing the satisfaction levels of each actor basedon the selected strategy • Computed from importance attribute and satisfaction levels of intentional element references bound to actors

  39. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Qualitative Algorithm – AND Decomposition

  40. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Qualitative Algorithm – OR Decomposition

  41. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Qualitative Algorithm – Contributions and Actors

  42. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Qualitative Algorithm – Dependencies

  43. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators Recurring Pattern in GRL

  44. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Example I – Context • New service for wireless network • Where to put the service logic? • Where to put the service data?

  45. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Example I – Intentional Elements and Actors

  46. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Example I – Links

  47. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Example I –Contribution Types Qualitativeorquantitative

  48. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Example I – Qualitative Model Evaluation

  49. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Example I – Quantitative Model Evaluation

  50. User Requirements NotationjUCMNav Goals and Rationale GRL Basics Evaluations Examples Tools Indicators GRL Example II – Context • GRL model that addresses privacy protection in a hospital environment • 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.

More Related