COE691: User Requirements Notation (URN)

• COE691 covers software requirements and specifications.
• Previous topics have been:
  • Requirements Classifications and Organizations
  • Requirements Conflicts
  • Requirements Prioritization and Negotiation
• This weeks topics are:
  • User Requirements Notation (URN)
  • Goal Modelling Tools
  • Goal-oriented Requirements Language (GRL)
    • Notations
    • Examples
    • Strategies and Evaluations

Goals

• Goals are a representation of stakeholder objectives
• Goal models demonstrate relationships between hierarchically arranged goals.
• A camera sensor having a 180-degree field of view and a radar sensor being always on are examples of goals
• Examples of non-goals are camera software being implemented in C, or radar housing is painted red.
• Goals can be decomposed from high-level objectives to low-level requirements.
• Goals are refined with sub-goals that define how they are satisfied, and leaf-level goals are considered requirements
• Functional goals are functions that a system will perform and have well-defined criteria for satisfaction
• Non-functional goals are desired system qualities that are hard to define and quantify
• Goals are objectives a system should achieve through the cooperation of actors in the defined software and its surrounding environment
• Goal modelling is especially useful in the early phases of a project.

Goal Model

• A Goal model expresses the relationships between a system and its environment.
• A Goal model includes what the system is supposed to do, and for why it is supposed to do it.
• Goal models clarify requirements and specifying goals leads to asking "why", "how" and "how else."
• Stakeholders' requirements are revealed in this process with less risk.
• Goal models allow large goals to be analyzed in small, realizable goals.
• Goal modeling can identify and help to resolve trade-offs between cost, performance, flexibility, security and other goals.
• Reveals divergent interests between stakeholders.
• Identifies conflicts because meeting one goal can interfere with meeting other goals.
• Enables measuring requirement completeness within the goal model.
• Connects requirements and design where the i* Non-Functional Requirements (NFR framework) uses goals to guide the design process.
• Goal models provide rationale for requirements.
• Goal models identify stable information in system objectives.
• Goal models guide requirements elicitation.
• Goal models provide visual depiction of relationships and dependencies between objectives

When to use Goal Models

• Early in requirements engineering process.
• To identify problems.
• To explore solutions and alternatives.
• Before UML modelling.
• To continually refine goal model as new requirements or obstacles surface.

Notations

• There are several notations in use for goal models in software development.
• These include:
  • i* (pronounced "eye-star") and a variant, GRL.
  • KAOS.
  • UML Use Case diagram.
• Other notations have been proposed by researchers.
• The Goal Structuring Notation (GSN) and GRL are sometimes used to make safety cases to satisfy the regulator in safety-related industries

Goal Modeling in i*, GRU

• The i* goal modeling notation provides two diagrams:
  • "Strategic Dependency" (SD): Defines relationships between roles in terms of specific goals, where one role depends on the other.
  • "Strategic Rationale" (SR): Analyzes the goals identified on the SD model into subsidiary goals and tasks.
• In i*, each role, whether an actor, agent, or position, is shown as a large circle containing the owned goals, tasks, and resources.
• Ownership in i* means that the role wants satisfaction of the goals for its own/another's benefit.
• Goals may be accompanied by "obstacles" (negative goals) to be surmounted.
• Non-functional goals are modeled as "soft goals" in i*, diagrammed as clouds or indented ovals.
• The i* Framework shares many GRL concepts, but it also incorporates multiple actor types and associations not differentiated by GRL.
• Links defined in both languages have more restrictions in i* than in GRL.
• The OpenOME tool enables both the creation and analysis of i* models.

Goal Modeling in KAOS

• KAOS captures software requirements in requirements engineering.
• KAOS is a goal modeling method.
• KAOS allows for requirements to be calculated from goal diagrams.
• KAOS stands for Knowledge Acquisition in automated specification or Keep All Objectives Satisfied.
• The University of Oregon and the University of Louvain (Belgium) designed the KAOS in 1990.
• The KAOS goal modelling notation provides a way of defining goals and obstacles.

Goal Modeling in UML

• UML's use case diagram provides a simple goal modeling notation
• The bubbles name functional goals, use cases cover only behavioral requirements.
• Roles are shown as actors linked to the use cases in which they take part.
• The use cases are drawn as elliptical bubbles, representing desired behavioural goals.

Goal Modelling Tools

• jUCMNav (Eclipse Plug-in):
  • Features for GRL
    • 7 GRL evaluation algorithms are provided, with colour highlight
    • Supports one model and multiple diagrams
    • Has reference to actors and intentional elements
    • Has drag&drop from outline or via properties
    • Auto-layout
    • Catalogues
      • Supports exporting/importing/reusing common models
    • graphics exportation is available in .bmp, .gif, .jpg format
    • supports evaluations of strategy in .csv format
    • Contains URN links (for integration with UCMs)
    • Supports exporting to DOORS
• Tool Support – SanDriLa (Plug-in for Visio)
• Web Tool – piStar http://www.cin.ufpe.br/~jhcp/pistar/
• Web Tool – Creative Leaf
  • Online: http://semvm02.city.ac.uk/cgm/
  • Videos: https://www.youtube.com/channel/UCjU8aqp-93qP8DnbDKXQpMQ
• Commercial Tool: Objectiver (for KAOS) http://www.objectiver.com/

User Requirements Notation (URN)

• URN focuses on the early stages of development with goals and scenarios.
• URN uses two notations:
  • Goal-oriented Requirement Language (GRL): for goals and non-functional requirements
    • http://www.cs.toronto.edu/km/GRL/
  • Use Case Maps (UCM): for operational requirements and architectures
    • http://www.UseCaseMaps.org/
    • http://www.UseCaseMaps.org/pub

Goal-oriented Requirements Language (GRL)

• Goal-oriented Requirements Language (GRL) is an i*-based modeling language used in systems development.
• It supports goal-oriented modeling and reasoning about requirements, especially non-functional ones
• Application and Research Areas:
  • Transformations to Message Sequence Charts and test goals
  • Architectural Evaluations
  • Performance engineering
  • Business process modelling and management
  • Requirements management and policy compliance
  • Pattern formalization
  • Reverse engineering
  • Aspect-oriented requirements engineering
• Goals are an important driver for requirements elaboration
• GRL expresses and clarifies tentative, ill-defined, and ambiguous requirements
• Supports argumentation, negotiation, conflict detection & resolution, and decisions
• GRL captures decision rationale and criteria (documentation!)
• GRL identifies alternatives in requirements, architectures, means, and etc...
• GRL provides traceability from strategic objectives to technical requirements
• GRL enables reuse of stable higher-level goals when the system evolves
• Unlike UML

GRL in a Nutshell

• GRL is:
  • Goal-oriented Requirement Language
  • graphical notation
  • a way to connects requirements to business objectives
  • Allows for reasoning about (non-functional) requirements
  • rooted in i* and the NFR framework
• GRL Models the "Why" aspect
• GRL has Objectives, alternatives, and decision rationales
• GRL is little or no operational details
• GRL Supports goal and trade-off analysis and evaluations

UCMs in a Nutshell

• UCMs are:
  • Use Case Maps
  • a graphical scenario notation
  • causal relationships between responsibilities
  • scenario elements may be allocated to components
• UCMs model the "what" aspects
• They contain functional requirements as scenarios
• They are for integration and reusability of scenarios
• They provide guidance for architecture and detailed behaviour
• They are for Performance analysis, conflict detection, transformations

GRL - UCM Relationship

• Approach:
  • Goal-based -Focuses on answering "why" questions -Functional and non-functional requirements
  • Scenario-based -Focuses on answering "what" questions
• operationalized Goals are linked into tasks, and tasks are elaborated in UCM scenarios
• Focus on answering “how” questions
• Enables completeness and consistency analysis
• User-defined links for requirements management
• Can link any GRL element to an UCM element

GRL Categories

• Goal-oriented Requirements Language (GRL) allows conflict expression between goals.
• It allows for decision making that resolves conflicts.
• Three main categories of concepts in GRL:
  • Intentional elements
  • Relationships
  • Actors
• Because they are used in models that answer the "why" of requirements, they are called conceptual
• This also covers why behavior or structure choices were made, what alternatives existed, and what was the reason for the chosen one.

Intentional elements

• Intentional elements are goal, soft goal, task, belief, and resource
• Goal is condition or situation that that can be achieved or not, and defines the systems functional requirements and is represented by a rounded rectangle
• Task shows ways of accomplishing goals indicated by a hexagon
  • A task is a proposed solution that can achieve a goal and contribute to softgoals/qualities
• Softgoal: defines non-functional requirements,is a quality attribute of one of the intentional elements, represented in notation
• Resource: physical or informational object used in a task
• Belief shows relevant assumptions
• Indicator: transforms a measure to a satisfaction level

Relationships

• Relationships are: means-ends, decomposition, contribution, correlation and dependency
• Means-ends: connects task to a goal, shows how the goal can be achieved
• Decomposition: Shows the sub-components of a task
• Contribution: describes the way in which the other element influences the other
  • +ve and -ve contribution allows for defeasible reasoning by way of Defenders and Defeaters.
• Correlation: shows the effect of one element to others
• Dependency: describes how agents interdepend

Relationship Links

• Contribution
  • A contribution indicates the result of side effects, either positive or negative. It can be represented by numbers or symbols.
• Decompostion
  • AND
  • OR
  • XOR
• Dependency
  • The source of dependencies cannot be more satisfied than its target.

Actors

• Actor is an active object that carries out actions to achieve and are circles with the actor's name written inside
• Agent is a concrete actor
• Role is a behavioral aspect of an Actor

Recurring Pattern in Goal Modelling

• In goal modelling, the system (actor) has several functional goals
• The system also has alternative ways of performing each goal (shown with tasks)
• Stakeholders (actors) are involved, with their functional and non-functional concerns known.
• The stakeholders' roles are captured with softgoals.
• The contributions and side effects from potential solutions of softgoals are identified

Advanced GRL Notation

• actors are allocated to GRL graphs
• actors are defined by dependencies between each other
• resources are also intermediate

GRL Tool Features

• GRL graphs can be allocated to actors
• Dependencies and intermediate resources can be included between actors

GRL Notation

• The User Story Model pattern is: As an [Actor], I want to [Task] in order to [Contribution] achieve [Goal]
• The User Story Model pattern identifies the task of an actor, a contribution level, and a contribution from the task to a goal.

GRL - Strategies and Evaluation Mechanism

• GRL enables a defined strategy of intentional elements
• GRL captures the initial, user-defined satisfaction levels for these elements separately from the GRL graphs Intentional elements are tagged with (*) in jUCMNav
• Strategies can be compared to each other for trade-off analysis
• JuCMNav implements a customizable evaluation mechanism that executes GRL Strategies
• It also shows the impact on higher level goals by propagating satisfaction levels down to elements and actors

Evaluations with GRL

• show the impact of qualitative decisions on high-level softgoals
• Propagation is usually bottom-up
• Fuzzy evaluation of satisfaction level
• GRL uses for parameters:
  • degrees of satisfaction of children
  • importance of composition operators
  • correlations and dependencies -Importance defined for actors and intentional elements.
  • GRL uses the numerical values and function instead of qualitative values (see jUCMNav tool)
• complete in comparison to other evaluation tools

Numerical Evaluation

• For each contribution a conversion from levels of contribution to corresponding factor is required
• Level of contribution and factor correspondence:
• Make = 100
• Help = 25
• Some Positive = 75
• Unknown = 0
• Some Negative = -75
• Hurt = -25
• Break = -100
• Minimum value applies for AND, maximum value applies for OR

GRL - Numerical Evaluation

• Numerical intentional element evaluation is fixed to a minimal value in the set of dependencies evaluation
• The satisfaction with A will be limited by the fact that B is 0

Benefits of GRL

• GRL evaluates to help evaluate the negotiation with share stakeholders
• Helps analyze the satisfaction levels of actors base on selection

Summary of URN, GRL and UCM Models URN:

• Allows engineers to specify or discover requirements for proposed and evolving systems, and review such requirements for correctness and completeness.
• Combines goals and scenarios
• Helps bridging the gap between informal and formal concepts, and between requirements models and design models
• Big benefits for a little modelling investment

URN, GRL and UCM Models

• GRL gives a means to express incomplete, tentative, or non-functional requirements, and can capture goals, objectives and alternatives
• UCM Models:
  • Operational requirements and architectural specifications
  • analysis and transformation
  • dynamic systems and architectural alternatives.