using the user requirements notation l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Using the User Requirements Notation PowerPoint Presentation
Download Presentation
Using the User Requirements Notation

Loading in 2 Seconds...

play fullscreen
1 / 26

Using the User Requirements Notation - PowerPoint PPT Presentation


  • 241 Views
  • Uploaded on

ITU-T Workshop on the "Use of Description Techniques" . Using the User Requirements Notation. Daniel Amyot Q.18/17 Rapporteur SITE, University of Ottawa, Canada damyot@site.uottawa.ca. About this presentation. What is the User Requirements Notation (URN)? What can we model with URN?

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Using the User Requirements Notation' - anana


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
using the user requirements notation

ITU-T Workshop on the "Use of Description Techniques"

Using theUser Requirements Notation

Daniel Amyot

Q.18/17 Rapporteur

SITE, University of Ottawa, Canada

damyot@site.uottawa.ca

about this presentation
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?
urn main objectives
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
current proposal for urn
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/
urn missing piece of the modelling puzzle

URN-NFR/GRL

Goals, non-functional requirements, alterna-tives, rationales

Informal Requirements, Textual Use Cases

?

Structural Diagrams

SDL, eODL, or UML class, object, component, & deployment diagrams

URN-FR / UCMs

Superimpose visually system level behavior onto structures of abstract components. Can replace UML use case & deployment diagams.

?

MSC, UML Use Case Diagram & Activity Diagram

Behavioral Diagrams

MSC/SDL, or UML sequence, collabor., & statechart diagrams

Testing and Performance LanguagesTTCN, LQN, ...

DataASN.1 whereappropriate

URN — Missing Piece ofthe Modelling Puzzle?

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

grl in a nutshell
GRL in a Nutshell
  • Goal-oriented Requirement Language
    • graphical notation
    • connects 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
basic grl notation

SystemSecurity

Softgoal

Break

Hurt

Some-

Unknown

Cost of

Terminal

Belief

Contribution

Make

Help

Some+

Equal

Biometrics is no

regular off-the-shelftechnology

Security of

Terminal

Security of

Host

.

.

Make

?

Argumentation

Access

Authorization

Encryption

Task

Decomposition

(AND)

Correlation(side-effect)

Authentication

Identification

Means-End

Goal

Cardkey

Password

Biometrics

Basic GRL Notation
evaluations with grl

Satisficed

SystemSecurity

Weakly Satisficed

Cost of

Terminal

Undecided

Biometrics is no

regular off-the-shelftechnology

Weakly Denied

Security of

Host

Security of

Terminal

.

.

Denied

Access

Authorization

Encryption

Authentication

Identification

Cardkey

Password

Biometrics

Evaluations with GRL
ucms in a nutshell
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
slide10

c) PassWord Plug-in

b) Biometrics Plug-In

Timer

OR-Fork

Pool

StartPoint

Stub

AND-Fork

Slot

End Point

Responsibility

Component

a) Root UCM

grl ucm relationship
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
typical usage of urn
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
experiences with grl
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
performance engineering with ucms

T2

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

TaxPayer

Security

E_Accountant

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.

ucm scenario definitions and path traversal highlight
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
from ucm requirements to more detailed design models
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...)
slide18

Experiences with TIA’s Wireless Intelligent Network

ICS invocation with Normal Termination and Distinctive Alerting

simplified ucm for incoming call screening

NormalAlerting (NA)

CallSetup(CS)

Screening (S)

IncomingCall

(IC)

PlayBlockAnnounce (PBA)

CallBlocked(CB)

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.
incoming call screening scenario on functional entities
Incoming Call Screening Scenario on Functional Entities

IC

IC

FE5

FE1

FE3

FE1

FE3

CS

NA

S

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

slide21

NE1

NE3

NE2

NE4

NE1

NE3

NE3

NE1

FE1

FE2

FE3

FE1

FE2

FE3

FE1

FE4

NE2

NE2

FE2

FE3

FE4

FE4

(a) First Structure

(b) Second Structure

(c) Different Mapping of FEs

Binding Functional Entities to Network Entities

refinement with msc

NE1

NE3

NE3

NE2

NE1

NE1

NE2

NE3

FE2

FE1

IC

IC

m1

m1

m2

m4

m2

m5

m3

CS

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 <IC,S,NA,CS>

(c) A MSC for <IC,S,PBA,CB>

plug in ucm for ics

+

+

SCP

Legend

Blk : Blocking

Chk : Check

CF : CheckFunction

DA : DistinctiveAlerting

NA : NormalAlerting

Nb : Number

PBA : PlayBlockAnnounce

Req : Request

SF : ScreeningFunction

VM : VoiceMail

Loc : Location

HLR

LRFH

SDF

SF

Chk

SCF

NA

DA

SCF

Loc

CF

VM

Nb

MSC

MACF

Routing

SSF

IP

SRF

PBA

Blk

IncomingCall

CCF

CallSetup

Req

VoiceMail

SRF

Announcement

CallForwarded

CallBlocked

+

+

Plug-in UCM for ICS
coming soon
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
conclusions
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
slide26
7th Feature Interaction Workshop

Ottawa, June 9-11, 2003

http://www.site.uottawa.ca/fiw03/

Submission deadline: December 9