Daniel Amyot

1
User Requirements Notation (URN )

• Daniel Amyot
• Q18/17 (URN) Rapporteur
• damyot_at_site.uottawa.ca

2
Objectives

• Brief overview of URN
• Goal-oriented Requirement Language (GRL), Use
  Case Maps (UCMs), and their relationships
• Connections between URN and several languages
  from ITU and OMG
• Several Challenges

3
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

4
URN - Initial Objectives

• Focus on early stages of design, with scenarios
• Capture user requirements when little design
  detail is available
• No messages, components, or component states
  required
• Reusability of scenarios and allocation to
  components
• Dynamic refinement capabilities
• Modelling of agent systems, early performance
  analysis, and early detection of undesirable
  interactions

5
URN - Additional Objectives

• Express, analyse and deal with non-functional
  requirements (NFRs)
• Express the relationship between business
  objectives/goals and system requirements
• Capture reusable analysis (argumentation) and
  design knowledge (patterns) for addressing
  non-functional requirements
• Connect to other ITU-T languages (and to UML)

6
Current Proposal for URN

• Draft documents for Z.150, Z.151, Z.152
• http//www.UseCaseMaps.org/urn/
• Combined use of two complementary notations
• Goal-oriented Requirement Language (GRL) for NFRs
  (http//www.cs.toronto.edu/km/GRL/)
• Use Case Maps (UCM) for Functional Requirements
  (http//www.UseCaseMaps.org/)
• Create ITU-T standard by end of 2003 (Z.150-153)

7
GRL in a Nutshell

• Goal-oriented Requirement Language a graphical
  notation that allows reasoning about
  (non-functional) requirements
• GRL is concerned with intentional elements,
  actors, and their relationships
• Intentional elements model the why aspect
  objectives, alternatives, as well as decision
  rationale and criteria but not operational
  details
• GRL satisfies most of URNs additional objectives

8
Basic GRL Notation
Softgoal
Belief
Contribution
Make
Argumentation
Task
Decomposition (AND)
Correlation(side-effect)
Means-End
Goal
9
Evaluations with GRL
10
UCMs in a Nutshell

• Use Case Maps a graphical scenario notation for
  describing causal relationships between
  responsibilities
• Scenario elements may (optionally) be linked to
  components
• The intent of UCMs is to facilitate the
  integration and reusability of scenarios, and to
  guide the design of high level architectures and
  detailed scenarios from requirements
• UCMs satisfy most initial URN requirements

11
Pool
StartPoint
Stub
AND-Fork
Slot
End Point
Responsibility
Component
a) Root UCM
12
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

13
From UCM Requirements to More Detailed Design
Models

• Requires
• Path Data Model (global Booleans variables)
• Scenario Definitions
• Path Traversal Mechanism
• Mapping Rules (MSC, UML, TTCN, LQN, LOTOS...)

14
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
15
Key Points - URN Puzzles

• Goal-based (e.g. GRL) and scenario-based (e.g.
  UCMs) notations complement each other
• GRL and UCMs, as part of the User Requirements
  Notation (URN), propose to fill a void in
  methodologies based on ITU-T languages
• UCMs offer more capabilities than use case
  diagrams and activity diagrams
• Compared to other scenario notations, UCMs are
  graphical, do not require components with
  interactions/messages, and support dynamic
  behavior and structures well

16
Key Points - URN Puzzles

• URN fits well into scenario-based software
  development methodologies
• GRL provides the decision making framework for
  software engineering activities
• UCMs become the focal point for early activities
  in software development, bringing together
  stakeholders with expertise in many different
  areas
• UCMs provide a good basis for design-time feature
  interaction detection and for model construction
  (tests, performance, MSC / Sequence Diagrams,
  LOTOS, and others)

17
Several Challenges (I)

• Degree of formalisation
• Qualitative/quantitative GRL evaluations?
• UCM path traversal algorithms?
• Reasoning in presence of looseness,
  incompleteness, inconsistencies?
• Formalisation of languages
• BNF? Graphical grammar? XML schemas?
• Layout information?

18
Several Challenges (II)

• Extensibility and Adaptability
• UML Profiles?
• Connections to other languages
• Traceability, transformations, meta-model?
• Methodologies
• What subsets of languages make sense together?
• Do methodologies drive the evolution of standard
  languages?
• Who are the stakeholders?

19
Main References

• http//www.UseCaseMaps.org/urn/
• Amyot, D. and Logrippo, L., Use Case Maps and
  LOTOS for the Prototyping and Validation of a
  Mobile Group Call System, InComputer
  Communications 23(8), 2000.
• Amyot, D. and Mussbacher, G., On the Extension of
  UML with Use Case Maps Concepts, UML2000, York,
  UK, October 2000.
• Buhr, R.J.A., Use Case Maps as Architectural
  Entities for Complex Systems, In Transactions on
  Software Engineering, IEEE, Vol. 24, No. 12,
  December 1998, pp. 1131-1155.
• Chung, L., Nixon, B.A., Yu, E. and Mylopoulos,
  J., Non-Functional Requirements in Software
  Engineering. Kluwer Academic Publishers, 2000.
• Liu, L. and Yu, E., From Requirements to
  Architectural Design Using Goals and Scenarios,
  In From Software Requirements to Architectures
  Workshop (STRAW 2001), Toronto, Canada, May 2001.
• Miga, A., Amyot, D., Bordeleau, F., Cameron, D.,
  and Woodside, M., Deriving Message Sequence
  Charts from Use Case Maps Scenario
  Specifications, 10th SDL Forum, Copenhagen,
  Denmark, June 2001.
• Monkewich, O., Sales, I., and Probert, R., OSPF
  Efficient LSA Refreshment Function in SDL, 10th
  SDL Forum, Copenhagen, Denmark, June 2001.
• Scratchley, W.C., Evaluation and Diagnosis of
  Concurrency Architectures, Ph.D. thesis, Carleton
  University, Canada, November 2000.