User Requirements Notation

1
User Requirements Notation

• A New Standard for the Visual Description of
  Requirements
• Daniel Amyot and Gunter Mussbacher
• Presented by Vipul Kumar Mehra

2
What is URN?

• A notation for requirements engineering of
  complex reactive, distributed and dynamic systems
  and applications
• It combines two complementary languages
• GRL Goal Oriented Requirements Language -
  description of business goals and non-functional
  requirements, alternatives and rationales
• UCM Use Case Maps description of functional
  requirements as causal scenarios

3
What is Requirements Engineering?

• RE activities can be divided into five
  categories
• requirements elicitation
• requirements modeling
• requirements specification
• requirements validation
• requirements management

4
URN Objectives

• URN is meant to have the following capabilities
• describe scenarios as first-class (and reusable)
  entities
• capture user requirements when very little design
  detail is available
• facilitate the transition from a requirements
  specification to a high level design
• have dynamic refinement capability with the
  ability to allocate scenario responsibilities to
  architectural components
• facilitate the detection and avoidance of
  undesirable interactions between features (or
  services)
• provide insights at the requirements level

5
Motivation for URN
SDL or UML Statechart diagrams
MSC or UML interaction diagrams
Informal requirements Use Cases
URN

• Need improvement to cope with new realities of
  complex, dynamic, and evolving systems
• Common design and standardisation methodologies
  already use scenarios

6
GRLWhy Goal-Orientation?

• Requirements Acquisition
• Relating Requirements to Organizational and
  Business Context
• Clarifying Requirements
• Dealing with Conflicts
• Driving Design
• Other RE tasks

7
GRL

• A language for supporting goal-oriented modeling
  and reasoning of requirements, especially for
  dealing with non-functional requirements.
• There are three main categories of concepts
  intentional elements, links, and actors
• Intentional Elements Are
• Goal
• Softgoal
• Task
• Resource
• Belief
• There are also five categories of intentional
  relations, which connect elements
• Contribution
• Correlation
• Means-end
• Decomposition
• Dependency

8
Softgoal Operationalizations Contribution
Relationship
Side-effects to softgoals Correlation
Relationship
9
Basic GRL Notation
10
Evaluations with GRL
11
Use Case Maps

• The Use Case Map notation aims to link behavior
  and structure in an explicit and visual way.
• UCM paths are first-class architectural entities
  that describe causal relationships between
  responsibilities, which are bound to underlying
  organizational structures of abstract components.
• These paths represent scenarios that intend to
  bridge the gap between requirements (use cases)
  and detailed design.
• UCMs can be derived from informal requirements,
  or from use cases if they are available.
• Responsibilities need to be stated or be inferred
  from these requirements.
• The strength of this notation mainly resides in
  the integration of scenarios. It is important to
  clearly define the interface between the
  environment and the system under description.

12
Pool
StartPoint
Stub
AND-Fork
Slot
End Point
Responsibility
Component
a) Root UCM
13
Concepts and Notation

• UCMs have four basic concepts
• - Start point Captures preconditions and
  triggering events (filled circle).
• - Responsibilities locations where computation
  (procedure, activity, function, etc.) is
  necessary (cross).
• - End point Represents resulting events and
  post-conditions (bar).
• - Paths Connects start points to end points and
  can link responsibilities in a causal way.
• Operators for choice (OR-fork, OR-join) and
  parallelism (AND-fork, AND-join) are used to
  describe alternative paths (accompanied by
  guards, between square brackets), common
  segments, concurrent segments and their
  synchronization.
• Other basic elements indicate waiting places,
  with or without a timer. An event triggering the
  end of the waiting period can come from the
  environment or from another UCM scenario (through
  juxtaposition of an end point).

14
Concepts and Notation

• Optionally, scenario elements can be allocated to
  the components part of the system architecture
  and/or of its environment.
• A component represents an abstract entity
  (object, process, server, database, user, etc.).
• Complex and lengthy scenarios can be decomposed
  and structured thanks to submaps called plug-ins,
  used (and reused) in map containers called stubs
  and displayed as diamonds.

15
UCM Component Notation

• Rectangles are call teams and are allowed to
  contain components of any type. This is a
  default/generic component used most UCMs.
• Parallelograms are active components (processes)
  whereas rounded rectangles are passive components
  (objects).
• Dashed components are called slots and may be
  populated with different instances at different
  times. Slots are containers for dynamic
  components (DC) in execution, while pools are
  containers for DCs that are not executing (they
  act as data).
• Dynamic components can be created, moved, stored,
  and deleted with dynamic responsibilities such as
  create, put, get, and move

16
Advanced UCM Path Notation

• When maps become too complex to be represented as
  one single UCM, a mechanism for defining and
  structuring sub-maps becomes necessary. A
  top-level UCM, referred to as a root map, can
  include containers (called stubs) for sub-maps
  (called plug-ins).
• The two types of stubs are
• Static stubs
• Dynamic stubs

17

• Synchronous interactions are shown by having the
  end point of one path touching the start point
  (or a waiting place) of another path.
• A path touching the start point (or a waiting
  place) represents an asynchronous interaction.
• Other notational elements include
• Timer special waiting place triggered by the
  timely arrival of a specific event. It can also
  trigger a time-out path when this event does not
  arrive in time.
• Abort a path can terminate the execution of
  another causal chain of responsibilities.
• Failure point indicates potential failure points
  on a path.
• Shared responsibility represents a complex
  activity that involves negotiation between two or
  more components.

18
Scenario Definitions and Path Traversal

• The concept of scenario definition offers the
  possibility to describe and extract individual
  scenarios from a complex UCM model.
• These individual scenarios can be used to explain
  and visually emphasize particularly interesting
  cases, to analyze potentially conflicting
  situations (for instance, between interacting
  services), or to generate other types of models
  (e.g. MSCs, test cases, etc.).
• A scenario definition is composed of four
  elements a name, a list of starting points, a
  set of initial conditions, and (optionally) a set
  of post-conditions.

19
UCM Path Traversal - Example I
?
?
?
?
A
R
A,1
3
2
5
4,?
5,?
,7,R
,6,?
3,?
20
UCM Path Traversal - Example II
?
B
S
3
A
R
5
B
?
A,1
2
7,?
4,?
5,?
3,R
,8,S
B,6,?
21
Example
User
Elevator Control System
down
not requested
already on list
switch on
moving
motor up
select elevator
in elevator
door close
at floor
app. floor
on list
decide on direction
app. floor
motor down
app. floor
else
switch off
stationary- memory
requested
!OnList
in elevator
add to list
motor stop
Up
!Requested
door open
!Requested
door closing-delay
Requested
remove from list
at requested floor
Arrival Sensor
Service Personnel
switch on
approaching floor
22
Uses of UCM

• Use Case Maps are used to describe and integrate
  use cases representing the requirements.
• UCMs include high-level design information
  (internal responsibilities and components), but
  they do not commit to messages between components
  (in contrast with MSCs).
• UCMs excel at integrating individual features
  through the use of stubs and plug-ins, while at
  the same time allowing for reasoning about
  potential undesirable interactions.
• UCMs are not executable as is, but they can be
  manually translated to a model that allows for
  fast prototyping and validation.
• UCMs can also serve as a basis for the definition
  of abstract validation test suites based on the
  design.
• Finally, the use of the UCM Navigator tool
  enables the automated generation of documentation
  and of XML code.

23
Transformations and Validation

• Use Case Maps provide an excellent source of
  information for guiding the generation of more
  detailed models. Various transformations towards
  LOTOS and SDL have been explored in order to
  validate requirements, generate designs, generate
  tests, detect undesirable scenario/feature
  interactions, and analyze performance.
• Scenario definitions also enable transformations
  towards other languages. In particular, the
  generation of MSC scenarios help visualizing and
  analyzing long scenarios that traverse multiple
  maps (through stubs and plug-ins).
• Such MSCs help to quickly find whether
  undesirable interactions, which often result from
  the composition of multiple plug-ins or complex
  conditions, can happen in a given context. When
  conditions to be traversed are incomplete or
  ambiguous, the path traversal mechanism can
  return a warning.

24
Performance Evaluation

• GRL supports performance attributes to the same
  extent it supports any other nonfunctional
  requirement, i.e. with textual attributes. UCMs
  however have placeholders for specific
  performance attributes used to generate
  performance models. Additionally, some of the
  annotations capture real performance requirements
  (e.g. response time between two timestamps, but
  not the resource model or the deployment
  information) which then become documented,
  analyzable up front, traceable to GRL models, and
  transferable to design models, e.g. in SDL.

25
UCM Performance Annotations

• Device Characteristics
• Processors, disks, DSP, external services
• Speed factors

• Arrival
• Characteristics
• Exponential, or
• Deterministic, or
• Uniform, or
• Erlang, or
• Other
• Population size

Timestamp

• Response Time
• Requirement
• From T1 to T2
• Name
• Response time
• Percentage

AgentA
AgentB
UserB
UserA
T1
upd
chk
vrfy
ring
req
denied

• Components
• Allocated responsibilities
• Processor assignment

• Responsibilities
• Data access modes
• Device demand parameters
• Mean CPU load (time)
• Mean operations on other devices

• OR Forks
• Relative weights(probability)

26
Generation of MSCs

• UCMs are good for (Stage 1)
• Describing multiple scenarios abstractly
• For analysing architectural alternatives
• MSC Sequence Diagrams are better for (Stage 2)
• Developing and presenting the details of
  interactions
• Describing lengthy sequences of messages in
  scenarios
• Providing access to well-developed methodologies
  and tools for analysis and synthesis
• UCM-to-MSC transformation helps to further bridge
  the gap between Stage 1 descriptions
  (requirements) and Stage 2 descriptions (design).

Stage 1 Requirements and Service Description,
Stage 2 Message Sequence Information
27
MSC Generation - Example I
System
A,1
2
4,?
5,?
,6,?
3,?
28
MSC Generation - Example II
System
?

4
8
2
S
5
7
1
A
3
R
6
?
B
29
Back to the Example
30
GRL - UCM Relationship

• Goal-based approach
• Focuses on answering why questions
• Addresses functional and non-functional
  requirements
• Scenario-based approach
• Focuses on answering what questions
• Goals are operationalized into tasks and tasks
  are elaborated in (mapped to) UCM scenarios
• Focuses on answering how questions

31
URN OMG/SG17 Puzzle
UCMs represent visually use cases in terms of
causal responsibilities
UCMs link to operationalizations(tasks) in GRL
models
UCMs visually associate behavior with structure
at the system level
UCMs provide a framework for making high level
and detailed design decisions