Daniel Amyot

1
Using theUser Requirements Notation
ITU-T Workshop on the "Use of Description
Techniques"

• Daniel Amyot
• Q.18/17 Rapporteur
• SITE, University of Ottawa, Canada
• damyot_at_site.uottawa.ca

2
About this presentation

• What is the User Requirements Notation (URN)?
• What can we model with URN?
• What answers can these models provide?
• What are the typical/potential usages?

3
URN Main objectives

• Focus on early stages of development with goals
  and scenarios
• From user requirements to system functional and
  non-functional requirements
• No messages, components, or component states
  required
• Reusability
• of argumentations (goal patterns and analysis)
• of scenarios (patterns and architectural
  alternatives)
• Early performance analysis
• Traceability and transformations to other
  languages
• Particularly MSC, SDL, TTCN, and UML

4
Current Proposal for URN

• Draft documents for Z.150, Z.151, Z.152
• 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
• http//www.UseCaseMaps.org/urn/

5
URN Missing Piece ofthe Modelling Puzzle?
DataASN.1 whereappropriate
UCMs link to operationalizations(tasks) in GRL
models
UCMs represent visually use cases in terms of
causal responsibilities
UCMs visually associate behavior and structure at
the system level
UCMs provide a framework for making high level
and detailed design decisions
6
GRL in a Nutshell

• Goal-oriented Requirement Language
• graphical notation
• connects requirements of requirements to business
  objectives
• allows reasoning about (non-functional)
  requirements
• GRL models the why aspect
• objectives, alternatives, as well as decision
  rationale
• no operational details
• Supports goal analysis and evaluations

7
Basic GRL Notation
8
Evaluations with GRL
9
UCMs in a Nutshell

• Use Case Maps
• graphical scenario notation
• causal relationships between responsibilities
• scenario elements may (optionally) be allocated
  to components
• UCMs model the what aspects
• functional requirements as scenarios
• integration and reusability of scenarios
• guidance for architecture and detailed behaviour
• Performance analysis, conflict detection

10
Pool
StartPoint
Stub
AND-Fork
Slot
End Point
Responsibility
Component
a) Root UCM
11
GRL - UCM Relationship

• Goal-based approach
• Focuses on answering why questions
• 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
• GRL goals can guide the selection of a particular
  architecture for the UCM scenarios

12
Typical Usage of URN

• Modelling and documentation
• User and system requirements, rationales
• Analysis of business goals
• Evaluations of alternative requirements or
  solutions
• Discovery of tradeoffs that can optimize the
  stakeholders degree of satisfaction for
  conflicting goals
• Architecture analysis
• Based on NFRs and design constraints
• Performance analysis
• Generation of individual scenarios
• Training, documentation
• Detection of conflicts
• Transformation to MSC and test cases
• Reverse-engineering

13
Experiences with GRL

• Used on industrial projects
• New family of Web-based telephone sets
• Documentation of discussions involving multiple
  stakeholders
• Visualization and analysis of conflicting goals
• Evaluation of architectural solutions, and
  rationales for the retained solution
• Proved to be very helpful for keeping discussions
  on track and for avoiding repeating the same
  discussions over and over again.
• Accelerated the reaching of an agreement and
• Improved (short-term and long-term)
  understanding.
• Used in academic projects
• Security applications
• Web-based systems (in combination with UCMs)
• Architectural/performance tradeoffs at a
  qualitative level

14
Performance Engineering with UCMs

• 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

Security
E_Accountant
TaxPayer
T1
CheckBio
Continue
Ready
Access
Rejected

• 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)

Automated translation to Layered Queuing Networks
(LQNs), for analytical evaluations and
simulations. Being applied to industrial case
studies.
15
UCM Scenario Definitions and Path Traversal
(Highlight)

• Extraction of individual scenarios
• Conditions attached to selection points
• Initialization of Boolean variables, and
  selection of start points

16
Tool Support UCMNav 2.1
17
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...)

18
Experiences with TIAs Wireless Intelligent
Network
ICS invocation with Normal Termination and
Distinctive Alerting
19
Simplified UCM for Incoming Call Screening

• WIN Phase 1 covers three major services
• Calling Name Presentation (CNAP)
• Incoming Call Screening (ICS)
• Voice Controlled Services (VCS)
• The following ICS Use Case Map is for
  illustration purpose.

20
Incoming Call Screening Scenario on Functional
Entities
IC
IC
FE5
FE1
FE3
FE1
FE3
CS
S
NA
FE1
IC
S
FE6
FE2
FE4
FE2
FE4
S
CB
CB
CB
NA
NA
PBA
PBA
PBA
CS
CS
(a) First Structure
(b) Second Structure
(c) Different Mapping of UCM
21
Binding Functional Entities to Network Entities
22
Refinement with MSC
IC
NE2
FE3
S
S
NA
FE4
S
PBA
CB
CB
NA
PBA
CS
(a) UCM to FEs to NEs
(b) A MSC for ltIC,S,NA,CSgt
(c) A MSC for ltIC,S,PBA,CBgt
23
Plug-in UCM for ICS
24
Coming soon

• URN-oriented Reverse-Engineering
• UCMs for reverse-engineering already popular.
• Can cope with very complex systems
• UCM to UML scenarios
• UCM to TTCN test cases
• URN and Requirements Management
• UCM and Requirements-based Design (synthesis)
• Already a tool-support mapping to LOTOS

25
Conclusions

• URN
• Allows engineers to specify or discover
  requirements for a proposed system or an evolving
  system, and review such requirements for
  correctness and completeness.
• Is usable in industry and in standardization
  bodies
• Combines goals and scenarios
• Helps bridging the gap between informal and
  formal concepts, and between requirements models
  and design models
• Big benefits for little modelling investment,
  even when used informally
• GRL
• For incomplete, tentative, (non-functional)
  requirements
• Capture goals, objectives, alternatives and
  rationales
• UCM
• For operational and functional requirements
• Enables analysis and transformations
• Architectural alternatives and dynamic systems

26

• 7th Feature Interaction Workshop
• Ottawa, June 9-11, 2003
• http//www.site.uottawa.ca/fiw03/
• Submission deadline December 9